Sunucumuza gelen olayların ortalama saniyede yaklaşık 1000 olayla (en fazla ~ 2000) olabileceği büyük bir olay akışıyla uğraşmak zorunda olduğum bir durum var.

Sorun

Sistemimiz Heroku'da barındırılıyor ve maksimum 500 DB bağlantısına izin veren nispeten pahalı bir Heroku Postgres DB kullanıyor . Sunucudan DB'ye bağlanmak için bağlantı havuzu kullanıyoruz.

Olaylar, DB bağlantı havuzunun işleyebileceğinden daha hızlı gelir

Sorun, olayların bağlantı havuzunun üstesinden gelebileceğinden daha hızlı gelmesidir. Bir bağlantı, sunucudan DB'ye gidiş dönüş ağını tamamladığında, havuza geri gönderilebilir, nek olaylar daha fazla gelir.

Sonunda olaylar birikir, kaydedilmeyi bekler ve havuzda kullanılabilir bağlantı olmadığından zaman aşımına uğrar ve tüm sistem çalışmaz hale getirilir.

Acil durumları rahatsız edici yüksek frekanslı olayları müşterilerden daha yavaş bir hızda yayarak çözdük, ancak yine de bu yüksek frekanslı olaylarla başa çıkmamız gerektiğinde bu senaryoların nasıl ele alınacağını bilmek istiyoruz.

Kısıtlamalar

Diğer müşteriler olayları aynı anda okumak isteyebilir

Diğer istemciler, henüz DB'ye kaydedilmemiş olsalar bile, belirli bir anahtarla tüm olayları sürekli olarak okumak ister.

GET api/v1/events?clientId=1İstemci 1 tarafından gönderilen tüm olayları sorgulayabilir ve alabilir, ancak bu olaylar henüz DB'de kaydedilmemiş olsa bile.

Bununla nasıl başa çıkılacağına dair "sınıf" örnekleri var mı?

Muhtemel çözümler

Sunucumuzdaki olayları sıkın

Sunucudaki olayları sıraya koyabiliriz (kuyrukta maksimum eşzamanlılık 400'dür, bu nedenle bağlantı havuzu tükenmez).

Bu kötü bir fikir çünkü:

• Kullanılabilir sunucu belleğini tüketir. Yığılmış olarak sıralanan olaylar büyük miktarlarda RAM tüketir.
• Sunucularımız 24 saatte bir yeniden başlatılır . Bu Heroku tarafından zor bir sınırlamadır . Olaylar kuyruğa alınırken sunucu yeniden başlatılabilir.
• Sunucuya durum kazandırır, böylece ölçeklenebilirliğe zarar verir. Çok sunuculu bir kurulumumuz varsa ve bir istemci, kaydedilen + kaydedilen tüm etkinlikleri okumak istiyorsa, kaydedilen etkinliklerin hangi sunucuda yaşadığını bilemeyiz.

Ayrı bir mesaj kuyruğu kullanma

Mesaj kuyruğunu ( RabbitMQ gibi ) kullanabileceğimizi varsayalım , burada mesajları pompalıyoruz ve diğer tarafta sadece DB'deki olayları kaydetme ile ilgilenen başka bir sunucu var.

Başka bir istemci başka bir istemcinin iletilerini okumak istiyorsa, yalnızca kaydedilmiş iletileri DB'den ve bekleyen iletileri kuyruktan alabilirim. ve bunları bir araya getirerek okuma isteği istemcisine geri gönderebiliyorum.

Her biri iletilerin bir kısmını merkezi bir DB koordinatörü sunucusuna kaydetmek için birden çok veritabanı kullanın.

Yine de başka bir çözüm, merkezi bir "DB koordinatörü / yük dengeleyici" ile birden fazla veritabanı kullanmaktır. Bir olay alındıktan sonra bu koordinatör mesajı yazmak için veritabanlarından birini seçecektir. Bu, birden fazla Heroku veritabanını kullanmamızı sağlamalı, böylece bağlantı sınırını 500 x veritabanına kadar yükseltmeliyiz.

Bir okuma sorgusu üzerine, bu koordinatör SELECTher bir veritabanına sorgu gönderebilir, tüm sonuçları birleştirebilir ve bunları okuma isteyen istemciye geri gönderebilir.

Bu kötü bir fikir çünkü:

• Bu fikir ... ahem .. aşırı mühendislik gibi mi geliyor? De yönetmek için bir kabus olurdu (yedekler vb ..). İnşaatı ve bakımı karmaşıktır ve kesinlikle gerekli olmadıkça KISS ihlali gibi görünür .
• Tutarlılığı feda eder . Bu fikirle devam edersek, birden çok DB'de işlem yapmak bir hareket etmiyor.

Giriş akışı

1000 etkinliğin / saniyenin zirveleri temsil edip etmediği veya sürekli bir yük olup olmadığı net değildir:

• en yüksek seviyedeyse, DB sunucusundaki yükü daha uzun süre yaymak için arabellek olarak bir ileti kuyruğu kullanabilirsiniz;
• sürekli yüklüyse, DB sunucusu hiçbir zaman yakalayamayacağından ileti kuyruğu tek başına yeterli olmaz. Sonra dağıtılmış bir veritabanı düşünmek gerekir.

Önerilen çözüm

Sezgisel olarak, her iki durumda da Kafka merkezli bir etkinlik akışına giderdim :

• Tüm olaylar bir kafka konusunda sistematik olarak yayınlanır
• Bir tüketici olaylara abone olur ve bunları veritabanında saklar.
• Bir sorgu işlemcisi istemcilerden gelen istekleri işleyecek ve DB'yi sorgulayacaktır.

Bu, tüm düzeylerde ölçeklendirilebilir:

• DB sunucusu darboğazdaysa, sadece birkaç tüketici ekleyin. Her biri konuya abone olabilir ve farklı bir DB sunucusuna yazabilir. Ancak, dağıtım DB sunucuları arasında rasgele gerçekleşirse, sorgu işlemcisi DB sunucusunu alıp birkaç DB sunucusunu sorgulaması gerektiğini tahmin edemez. Bu, sorgu tarafında yeni bir darboğaz oluşmasına neden olabilir.
• Bu nedenle DB dağıtım şeması, olay akışının çeşitli konulara (örneğin, anahtarları veya özellik gruplarını kullanarak, DB'yi öngörülebilir bir mantığa göre bölümlemek için) düzenleyerek öngörülebilir.
• Bir mesaj sunucusu giderek artan girdi olaylarını idare etmek için yeterli değilse, kafka konularını birkaç fiziksel sunucuya dağıtmak için kafka bölümleri ekleyebilirsiniz .

DB'de henüz yazılmayan olayları istemcilere sunmak

Müşterilerinizin hala kanalda olan ve henüz DB'ye yazılmayan bilgilere erişmesini istersiniz. Bu biraz daha hassas.

Seçenek 1: db sorgularını tamamlamak için önbellek kullanma

Derinlemesine analiz etmedim, ama aklıma gelen ilk fikir, sorgu işlemcilerini kafka konularının bir tüketici (ler) i değil, farklı bir kafka tüketici grubunda yapmaktı . İstek işlemcisi daha sonra DB yazarının alacağı tüm iletileri bağımsız olarak alacaktır. Daha sonra onları yerel bir önbellekte tutabilir. Sorgular daha sonra DB + önbelleğinde (+ yinelenenlerin kaldırılması) çalışır.

Tasarım daha sonra şöyle görünecektir:

Bu sorgu katmanının ölçeklenebilirliği, daha fazla sorgu işlemcisi (her biri kendi tüketici grubunda) eklenerek elde edilebilir.

2.Seçenek: Çift API tasarlayın

Daha iyi bir yaklaşım IMHO, ikili bir API sunmak olacaktır (ayrı tüketici grubunun mekanizmasını kullanın):

• DB'deki olaylara erişmek ve / veya analiz yapmak için bir sorgu API'sı
• iletileri doğrudan konudan ileten bir akış API'sı

Avantajı, müşterinin neyin ilginç olduğuna karar vermesine izin vermenizdir. Bu, istemci yalnızca yeni gelen olaylarla ilgileniyorsa, DB verilerini yeni para birimindeki verilerle sistematik olarak birleştirmenizi engelleyebilir. Yeni ve arşivlenmiş etkinlikler arasında hassas birleştirme gerçekten gerekliyse, müşteri bunu organize etmek zorunda kalır.

Varyantlar

Kafka'yı önerdim çünkü kalıcı mesajlarla çok yüksek hacimler için tasarlandı, böylece gerekirse sunucuları yeniden başlatabilirsiniz.

RabbitMQ ile benzer bir mimari inşa edebilirsiniz. Ancak kalıcı kuyruklara ihtiyacınız varsa performansı düşürebilir . Ayrıca, bildiğim kadarıyla, aynı mesajların birkaç okuyucu (örn. Yazar + önbellek) tarafından RabbitMQ ile paralel tüketimini elde etmenin tek yolu kuyrukları klonlamaktır . Böylece daha yüksek bir ölçeklenebilirlik daha yüksek bir fiyata gelebilir.

Benim tahminim, reddettiğiniz bir yaklaşımı daha dikkatli bir şekilde keşfetmeniz gerektiğidir

• Sunucumuzdaki olayları sıkın

Benim önerim, LMAX mimarisi hakkında yayınlanan çeşitli makaleleri okumaya başlamak olacaktır . Kullanım durumları için yüksek hacimli harmanlama işleri yapmayı başardılar ve ticari işlemlerinizi daha çok onlarınkine benzetmek mümkün olabilir.

Ayrıca, okumaları yoldan alıp alamayacağınızı görmek isteyebilirsiniz - ideal olarak bunları yazılardan bağımsız olarak ölçeklendirmek istersiniz. Bu, CQRS'ye bakmak anlamına gelebilir (komut sorgusu sorumluluk ayrımı).

Olaylar kuyruğa alınırken sunucu yeniden başlatılabilir.

Dağıtılmış bir sistemde, mesajların kaybolacağından oldukça emin olabileceğinizi düşünüyorum. Sekans engelleriniz hakkında dürüst davranarak bunun bazı etkilerini hafifletebilirsiniz (örneğin, olay, sistemin dışında paylaşılmadan önce - dayanıklı depolama alanına yazmanın gerçekleşmesini sağlamak).

• Her biri iletilerin bir kısmını merkezi bir DB koordinatörü sunucusuna kaydetmek için birden çok veritabanı kullanın.

Belki de - verileri parçalayacak doğal yerler olup olmadığını görmek için işletme sınırlarınıza bakma olasılığı daha yüksektir.

Veri kaybetmenin kabul edilebilir bir takas olduğu durumlar var mı?

Sanırım olabilirdi, ama gittiğim yer bu değildi. Mesele şu ki, tasarım, mesaj kaybı karşısında ilerlemek için gereken sağlamlığı içine almalıydı.

Bunun genellikle neye benzediği, bildirimleri olan çekmeli bir modeldir. Sağlayıcı, mesajları düzenli bir dayanıklı mağazaya yazar. Tüketici mesajları kendi yüksek su işaretini takip ederek mağazadan alır. Anlık bildirimler gecikme azaltma cihazı olarak kullanılır - ancak bildirim kaybolursa, tüketici hala düzenli bir program çektiği için (sonunda) mesaj getirilir (fark, bildirim alındığında çekmenin daha erken gerçekleşmesidir) ).

Udi Dahan'ın (zaten Andy tarafından atıfta bulunulan ) Dağıtılmış İşlemler Olmadan Güvenilir Mesajlaşma ve Greg Young'ın Polyglot Verilerine bakın .

Doğru anlıyorsam, akım:

1. Almak ve olay (HTTP ile varsayıyorum?)
2. Havuzdan bağlantı isteyin.
3. Olayı DB'ye ekle
4. Havuz bağlantısını kesin.

Eğer öyleyse tasarımda ilk değişiklik bile her olayda havuza kod dönüş bağlantıları işleme sahip durdurmak için olacağını düşünüyorum. Bunun yerine, DB bağlantılarının sayısı ile 1'e 1 olan bir ekleme iş parçacığı / işlemi havuzu oluşturun. Bunların her birinin özel bir DB bağlantısı olacaktır.

Bir tür eşzamanlı kuyruk kullanarak, bu iş parçacıklarının iletileri eşzamanlı kuyruktan almasını ve eklemesini sağlarsınız. Teorik olarak, asla havuza bağlantıyı iade etmeleri veya yeni bir tane talep etmeleri gerekmez, ancak bağlantının bozulması durumunda işlem yapmanız gerekebilir. İş parçacığını / işlemi öldürmek ve yeni bir işlem başlatmak en kolay yol olabilir.

Bu, bağlantı havuzu yükünü etkili bir şekilde ortadan kaldırmalıdır. Elbette her bağlantıda saniyede en az 1000 / bağlantı olayı yapabilmeniz gerekir. Aynı tablolarda çalışan 500 bağlantının DB üzerinde çekişme yaratabileceğinden farklı sayıda bağlantı denemek isteyebilirsiniz, ancak bu tamamen farklı bir soru. Dikkate alınması gereken başka bir şey, toplu kesici uçların kullanılmasıdır, yani her bir iş parçacığı birkaç mesaj çeker ve hepsini bir kerede iter. Ayrıca, aynı satırları güncellemeye çalışan birden fazla bağlantıya sahip olmaktan kaçının.

Varsayımlar

Tarif ettiğiniz yükün sabit olduğunu varsayacağım, çünkü bu çözülmesi daha zor bir senaryodur.

Ayrıca, web uygulama sürecinizin dışında tetiklenmiş, uzun süreli iş yüklerini çalıştırmanın bir yolunu olduğunu varsayacağım.

Çözüm

Çözülmesi gereken birincil sorun, süreciniz ile Postgres veritabanı arasındaki darboğazınızı doğru bir şekilde belirlediğinizi varsayarsak. Çözümün, olayları alındıktan sonra mümkün olan en kısa sürede okumak isteyen diğer müşterilerle olan tutarlılığınızdaki kısıtlamayı hesaba katması gerekir.

Gecikme sorununu çözmek için, saklanacak olay başına gerçekleşen gecikme miktarını en aza indirecek şekilde çalışmanız gerekir. Donanımı değiştirmeye istekli veya değiştiremiyorsanız, başarmanız gereken anahtar şey budur . PaaS hizmetlerinde olduğunuz ve donanım veya ağ üzerinde herhangi bir denetiminiz olmadığı göz önüne alındığında, olay başına gecikmeyi azaltmanın tek yolu, bir dizi toplu yazma olayı olacaktır.

Yerel olarak, belirli bir boyuta ulaştığında veya geçen süreden sonra db'nize düzenli olarak kızartılır ve yazılır bir olay sırasını depolamanız gerekir. Bir işlemin mağazaya yıkamayı tetiklemek için bu kuyruğu izlemesi gerekecektir. Seçtiğiniz dilde periyodik olarak temizlenen eşzamanlı bir kuyruğun nasıl yönetileceği konusunda birçok örnek olmalıdır - İşte popüler Serilog günlük kütüphanesinin periyodik harmanlama lavabosundan C # 'da bir örnek .

Bu SO yanıtı , Postgres'deki verileri temizlemenin en hızlı yolunu açıklar - toplu işinizin kuyruğu diskte depolamasını gerektirir ve diskiniz Heroku'da yeniden başlatıldığında kaybolduğunda muhtemelen çözülmesi gereken bir sorun vardır.

Kısıtlama

Başka bir cevap zaten CQRS'den bahsetti ve bu kısıtlamayı çözmek için doğru yaklaşım. Her olay işlenirken okunan modelleri nemlendirmek istersiniz - Bir Aracı deseni , bir olayın kapsüllenmesine ve işlem sırasında birden çok işleyiciye dağıtılmasına yardımcı olabilir. Bu nedenle, bir işleyici olayı istemcilerin sorgulayabileceği bellekte olan okuma modelinize ekleyebilir ve başka bir işleyici de olayı toplu toplu yazma işleminden kuyruğa almaktan sorumlu olabilir.

CQRS'nin en önemli yararı, kavramsal okuma ve yazma modellerinizi birbirinden ayırmanızdır; bu, bir modele yazdığınızı ve tamamen farklı bir modelden okuduğunuzu söylemenin süslü bir yoludur. CQRS'den ölçeklenebilirlik avantajları elde etmek için, genellikle her bir modelin kullanım şekilleri için en uygun şekilde ayrı olarak saklandığından emin olmak istersiniz. Bu durumda, okumalarımızın hızlı ve tutarlı olmasını sağlamak için toplu bir okuma modeli (örneğin, bir Redis önbelleği veya sadece bellek içi) kullanabiliriz, ancak yine de verilerimizi yazmak için işlem veritabanımızı kullanıyoruz.

Olaylar, DB bağlantı havuzunun işleyebileceğinden daha hızlı gelir

Her işlem bir veritabanı bağlantısı gerektiriyorsa, bu bir sorundur. Sistem, her çalışanın yalnızca bir veritabanı bağlantısına ihtiyaç duyduğu ve her çalışanın birden çok olayı işleyebileceği bir çalışan havuzuna sahip olacak şekilde tasarlanmalıdır.

İleti kuyruğu bu tasarımla kullanılabilir, olayları ileti kuyruğuna iten ileti üreticisine / üreticilerine ihtiyacınız vardır ve işçiler (tüketiciler) iletileri kuyruktan işler.

Diğer müşteriler olayları aynı anda okumak isteyebilir

Bu kısıtlama yalnızca veritabanında herhangi bir işleme tabi tutulmadan (ham olaylar) saklanan olaylarda mümkündür. Olaylar veritabanında saklanmadan önce işleniyorsa, olayları almanın tek yolu veritabanından almaktır.

Müşteriler sadece ham olayları sorgulamak istiyorsa, o zaman Elastik Arama gibi arama motorunu kullanmanızı öneririm. Hatta sorgu / arama API'sını ücretsiz olarak alırsınız.

Olayları veritabanına kaydedilmeden önce sorgulamak gibi göründüğü göz önüne alındığında, Elastik Arama gibi basit bir çözümün çalışması gerekir. Temelde sadece tüm olayları saklarsınız ve aynı verileri veritabanına kopyalayarak çoğaltmazsınız.

Elastik Aramayı Ölçeklemek kolaydır, ancak temel yapılandırmada bile oldukça yüksek performans gösterir.

İşlemeye ihtiyaç duyduğunuzda, işleminiz olayları ES'den alabilir, işleyebilir ve veritabanında saklayabilir. Bu işlemeden hangi performans düzeyine ihtiyacınız olduğunu bilmiyorum, ancak olayları ES'den sorgulamaktan tamamen ayrı olurdu. Sabit sayıda çalışanınız ve her biri tek bir veritabanı bağlantısına sahip olabileceğiniz için bağlantı sorunu yaşamanız gerekir.

Saniyede 1k veya 2k olay (5KB), uygun bir şema ve depolama altyapısına sahipse bir veritabanı için o kadar da fazla değildir. @Eddyce tarafından önerildiği gibi, bir veya daha fazla slave içeren bir master okuma sorgularını yazma işleminden ayırabilir. Daha az DB bağlantısı kullanmak size daha iyi bir genel verim sağlar.

Diğer müşteriler olayları aynı anda okumak isteyebilir

Bu istekler için, okuma kölelerine çoğaltma gecikmesi olacağından, ana db'den de okumaları gerekir.

Çok yüksek hacimli yazma işlemleri için TokuDB motorlu (Percona) MySQL kullandım. Ayrıca LSMtrees tabanlı MyRocks motoru da yazma yükleri için iyi. Hem bu motorlar hem de muhtemelen PostgreSQL için, işlem kapasitesinin yanı sıra yazma kapasitesini önemli ölçüde artırabilecek kesinleştirme davranışı ayarları da vardır. Geçmişte db istemcisine taahhüt edildiği bildirilen kayıp verileri 1s kadar kabul ettik. Diğer durumlarda, kayıpları önlemek için pil destekli SSD'ler vardı.

MySQL lezzetindeki Amazon RDS Aurora'nın sıfır maliyetli çoğaltma ile 6 kat daha yüksek yazma işlemine sahip olduğu iddia ediliyor (bir dosya sistemini master ile paylaşan kölelere benzer). Aurora PostgreSQL aroması da farklı bir gelişmiş çoğaltma mekanizmasına sahiptir.

Ben hep birlikte heroku bırakacak, yani, merkezi bir yaklaşım bırakacaktı: maksimum havuz bağlantısı zirve birden fazla yazar db kümeleri icat nerede ana nedenlerinden biridir, özellikle yazma yük yok neden kümedeki diğer db'ler tarafından gerçekleştirilebilen okuma istekleri ile db (ler), ben de bir ana-köle topolojisi ile denemek istiyorum, üstelik - başka birinin daha önce de belirtildiği gibi, kendi db kurulumları sahip tüm ayarlamak mümkün olacaktır sorgu yayılma zamanının doğru bir şekilde ele alındığından emin olmak için sistem.

İyi şanslar