ikinci yaklaşımın ilkinden çok daha iyi ama event-driven düşünmek gerekir, websocket yerine direkt Message Queue (RabbitMQ/Redis/Kafka) kullansan daha reliable olur, siparişler queueya düşer, workerlar kuyruğu dinler, otomatik load balancing yapılır, worker down olsa bile sipariş kaybolmaz, ölçeklendirmesi kolay olur, websocket de olur ama connection management zor, queue bu iş için endüstri standardıdır(BullMQ veya RabbitMQ işini görecektir, Kafka gereksiz olabilir) Polling kesinlikle çok kötü bir pratik zaten, 5 saniye beklemek yerine sipariş geldiği anda push etmek lazım. Lock konusunda da queue düzgün kullanılırsa her sipariş zaten tek workera gider, ekstra locka gerek kalmaz genelde distributed lock gibi, worker işi bitince ack gönderir mesaj silinir
Hocam yine rahatsız ediyorum ama ufak bir sorum daha var.
1 numaralı worker, 1 IDli siparişi aldı ve şu anda işliyor ise, diğer 9 sunucu boş demektir.
Diyelim ki bir sipariş daha geldi ve bu da yine 1 numaralı workera gitti. Böyle olunca diğer 9 sunucu hâlâ boşta kalıyor ama 1 makine 2 siparişi aynı anda işliyor, bu da servisi yavaşlatıyor.
Normalde, bu yeni siparişi diğer boş sunuculardan birinin alması gerekirdi.
Bunun için şöyle yapmak mantıklı mı:
Bütün workerların kendine ait bir WSS bağlantısı olacak, aradaki Redis sunucusu ise sırasıyla veya boşluk-doluluk oranına göre siparişleri rastgele atayacak.
Böyle yapmak mantıklı mı, yoksa daha mantıklı bir yöntem
var mı?