2015-12-18 17 views
9

Facebook'ta arkadaşlık isteği göndermeye benzer bir uygulamam için bir senaryo var.MongoDB Concurrency Sayı

A kullanıcısı, kullanıcı B'ye arkadaşlık isteği gönderdiğinde, dahili olarak yeni bir arkadaşlık isteği belgesi oluşturulur. Daha sonra B kullanıcısı arkadaşlık isteğini A'ya göndermek istediğinde, sistem bir arkadaşlık isteği belgesinin var olduğunu ve böylece arkadaşlarının birbirinin dostu olması gerektiğini öğrenirdi, yeni arkadaşlık isteği belgesi oluşturulmayacaktı.

Ben kullanıcı A ve B kullanıcısı hem eşzamanlı sonra 2 arkadaş isteği belgeler oluşturmak ve belirsiz davranışlara yol açan olacaktır birbirlerine arkadaşlık isteği gönderdiğinde davayı anlamaya çalışıyorum ... için

sayesinde sizin öneriler .. Gerçekten takdir!

Düzeltme: Bir kaçının bunu çözmek için bir istek kuyruğu kullanmayı önerdiği; Ancak, kuyruk kullanma konusunda kafam karıştı çünkü ben istirahat işim bitimi işlem isteklerini sıralı olarak yapacağımı düşündüm. Kuyruk kullanarak çok iş parçacığının tüm faydalarını kaybetmez miyim? Yardım edemem ancak hizmetimin sıraya konması ve sıraya konması için milyonlarca talep beklenirse ne kadar kötü olacağını hayal edemiyorum. Üretimde görülen benzer sorunlar boyunca bir şey gören oldu mu?

cevap

4

Veritabanında eşzamanlı yazımları olan istemcimle benzer bir durum yaşadım, Uyguladığım bir Kuyruk hizmetidir.

Create a request in the queue rather than writing in the database, a separate reader will 
read one message from the queue at a time and check if it is valid to write it to 
database, write only if there is no previous request. 

Kendi kuyruğunu uygulayabilirsiniz ya da vb AWS-SQS'in, RabbitMQ, MSMQ gibi hizmetini kullanabilirsiniz

+0

Bu, sunucumun artık paralel olarak istekleri işleme koymayacağı anlamına gelmiyor, bu daha önce olduğu gibi performans göstermeyecek anlamına mı geliyor? – user1955934

+0

Hayır, yalnızca bu özel işlevin yazma işlemi bir sıradan geçecektir. –

+0

evet isterseniz paralel okuyucular olabilirsiniz, ancak eğer bir dizi yazma işlemi sıraya alınmışsa, yanıt çok yavaş mı yoksa hatta zaman aşımıyla sonuçlanmaz mıydı? Demek istediğim, bu nadir vakadaki performansa meydan okumak buna değer mi? Ben çok nadir bir durum bu tür çözmek için başka bir yol umuyoruz .. :( – user1955934

3

// Özgül bir üzerinde mongodb yazma operasyonlarda davanıza

  1. için tek belge atomiktir.
  2. mongodb benzersiz bir dizin özelliğine sahiptir.

Eğer ekleme yapmadan önce (sözlük sırasında isim sıralayarak örneğin "A_B" gibi) her ikisi için de benzersiz dizin oluşturarak bir _ID (ya da herhangi bir özel dizin) kişinin isimleri A ve B dokümanı eklemek Bu nedenle eğer. Bu belgenin yalnızca bir örneğini doğal olarak ekleyebileceksiniz.

// Genel esasen biz istiyorum ne

işlemler vardır ama MongoDB beri, şu andan itibaren böyle desteklemez.

  1. 2 faz taahhüt: Bunu başarmak için birkaç hile vardır işlemsel şekilde eklenmesini de destekler memcache kullanarak örneğin bir bayrak korumak için harici bir kaynak kullanma https://docs.mongodb.org/v3.0/tutorial/perform-two-phase-commits/

  2. /karşılaştırın ve Takas .bazı kullanıcı gibi, senden bir saniye veritabanı içinde daha sonra talep göndermek sana bir sistem çağrısı ve frontend'i gönderdiğinizde sistem o zaman veritabanından frontend için bir istek kovmalı önyüzdeki yöntemini çağıran kullanırsanız İşte

+0

arkadaş isteği, hangi kullanıcının istek gönderdiğine ve hangi kullanıcının hedeflendiğine işaretlemek için yönerge içerir. bu yüzden yalnızca A_B olarak değil, A_B ve B_A olarak temsil edilebilecek bir belge olamaz. Ve asıl mesele, beklenmedik bir şekilde değişebilecek bir duruma dayalı olarak hangi belgenin oluşturulacağını bilmesiyle bir işlem/atomisite sorunu değildir; Bu durumda, koşul "arkadaşlık isteği var mı?", ancak bu durum kontrol bittikten sonra artık geçerli olmayabilir ... – user1955934

+0

Yönüne dikkat çekmek için, her zaman başka bir alan olabilir, yani requestFrom, requestTo. Benzersiz indeks, A ve B arasındaki ilişkiyi (A & B arasında benzersiz ve sadece bir kez) işaretlemek için tamamen farklı bir alan olmalıdır. –

+0

Yukarıdaki yorumu ekleyerek, bunun neden bir işlem sorunu olduğunu düşündüğümü açıklamama izin verin: Belirtildiği gibi, "asıl sorun bir koşula bağlı olarak hangi belgenin oluşturulacağını bilmek", bu çok basit bir problem. ur kodunda basit bir kontrol, AMA "bu durum kontrol bittikten sonra artık geçerli olmayabilir" nedeni bu durumun değişeceğinin sebebi, yazarken okunabilecek başka bir konu olup olmadığını bilmenin bir yolu olmadığını, bu problemin Bir şekilde belge üzerinde bir okuma/yazma kilidini alabilirseniz çözülün. Bu esasen işlem. –

2

kod acil doğru düğme metni

benzeri "gelen talebi"

yoksa "bir arkadaş ekle".

Yalnızca veritabanı kuruyorsanız, yalnızca , arkadaş isteği geldiğinde veya Belge oluşturulduğunda kullanıcı arabirimine yollayan bir sistem çağrısı yapın, sonraki işlem UI Developer tarafından ele alınacaktır. Teşekkür ederiz. Eğer cevabı beğenmediysen, bunun için özür dilerim ama beni reddetme çünkü Stack Overflow Topluluğu'nda yeniim.