SQL Maxis: RabbitMQ’yu neden Postgres Queue ile değiştirdik

• RabbitMQ’yu kaldırıp PostgresDB’de SQL kullanan bir kuyrukla değiştirdiler
• Geçiş yaklaşık yarım gün sürdü ve kaynak kod 580 satır azaldı
• Çok daha önemlisi, kararlılık ve dayanıklılık (resiliency) belirgin şekilde arttı
• Bu, RabbitMQ gibi kuyruk sistemlerinin sorunlarıyla ilgili bir yazı değil; sadece sistemi daha basit tutma çabasının bir parçası
  • Bu yazıyı yazan Prequel, büyük ölçekli veri hatlarıyla B2B SaaS şirketlerinin müşteri veritabanlarıyla senkronize olmasına yardımcı olan bir ürün sunuyor
• Yapıyı RabbitMQ + AQMP + Helm + GoLang wrapper ile kurmuşlardı; bir süre iyi çalıştı ama sonra sorunlar çıkmaya başladı
  • Mesaj iletimi çok gecikince mesajların iptal olduğu durumlar yaşandı
  • Consumer mesajları prefetch ederken, mevcut mesaj tamamlanana kadar bir sonraki mesajı elinde tuttuğu durumlar oluştu
  • Bu prefetch değerini 0 yapınca sonsuz oluyor, yani prefetch’i devre dışı bırakmak mümkün değildi
  • Sorunun nedeni, mesajı alıp işleyen görevlerin genelde uzun süren işler olmasıydı (veri aktarımı)
• Ne olduğunu tam olarak anlamışlardı ama hemen düzeltecek bir yol yoktu. Sorun production müşterilerinde yaşandığı için beklemek mümkün değildi
• Bu yüzden Postgres’te tek bir basit tabloyla okuma/yazma yapan bir yapıya geçtiler
  • Okuma/yazma için Row-Level Lock kullanarak, bir işi aynı anda yalnızca tek bir consumer’ın okumasını garanti ediyorlar
  • Aşırı derecede basit ama kusursuz biçimde çalışıyor
• Uygulama durumunun RabbitMQ ve Postgres arasında bölünmek yerine tek yerde birleşmesi de ayrı bir avantaj

[galadbran]

Ben de MySQL'de row-level lock ile kuyruğu doğrudan kendim implemente edip bunu yıllardır üründe sorunsuz çalıştırıyorum.
Amacım, birden fazla worker'a basitçe kuyruk benzeri bir işlev sunarken, kuyruk içindeki beklemede/devam ediyor/başarısız (tamamlandıysa silinen) durumlarını da payload ile birlikte saklayabilmekti.

Metinde RabbitMQ'dan kısa sürede veritabanına geçildiğini görünce, muhtemelen ayrı bir uzman kuyruk servisinin sunduğu genel kullanım esnekliğine ya da çeşitli özellik ve yapılandırma seçeneklerine gerçekten ihtiyaç duyulmadığını düşündüm.

[pseudojo]

Elle ACK gönderimi ile DB transaction arasında sıkışıp kalarak bir sorun çıkmış gibi görünüyor,
bunu mühendislikle çözmek yerine RabbitMQ’yu tamamen kaldırmayı seçmeleri ilginç.
Gerçi suç RabbitMQ’da olmayabilir...

[laracool]

https://news.ycombinator.com/item?id=35526846
Yorumlarda epey fazla görüş var.

[dddddd]

Benzer şekilde çalışan https://github.com/pjongy/jasyncq gibi bir şey de varmış.

[laracool]

Aynı anda select edilme ihtimali var gibi görünüyor; bunu nasıl çözdüklerini merak ediyorum.

[dddddd]

"row level lock" olarak yazıyor.