Kuyruk, gönderen sistem ile mesajı işleyecek sistemin aynı anda hazır olma zorunluluğunu azaltır. Örneğin sipariş alan servis bir mesajı kuyruğa bırakabilir; stok entegrasyonu bu mesajı kapasitesi elverdiğinde alır. Hedef sistem geçici olarak kapalıyken mesajlar broker’da bekleyebilir.
Artemis, bu mesajları kabul eden, kuyruklarda tutan ve tüketicilere teslim eden broker’dır. Lunex projesi ise mesajı üreten veya işleyen akışı çalıştırır. Broker, proje runtime’ından ayrı bir servistir.
Hangi problemi çözer?
| İhtiyaç | Kuyruğun katkısı |
|---|---|
| Sipariş yoğunluğu anlık artıyor | Tüketici kapasitesini aşan mesajlar kuyrukta bekler. |
| Hedef sistem kısa süreyle kapalı | Uygun kalıcılık ve yeniden teslim politikasıyla mesaj sonradan işlenebilir. |
| İki uygulama farklı hızlarda çalışıyor | Gönderme ile işleme birbirinden ayrılır. |
| Bazı mesajlar sürekli hata veriyor | Mesaj dead letter olarak saklanır; neden giderildiğinde yeniden denenir. |
| Aynı olayı birden fazla bağımsız süreç kullanıyor | Multicast adresi ve ayrı abonelik kuyruklarıyla dağıtım tasarlanır. |
Kuyruk kullanmak hedef sistemde çift sipariş oluşmasını kendiliğinden engellemez. Başarılı dış çağrıdan sonra bağlantı veya onay kaybolursa aynı mesaj yeniden işlenebilir. İş kimliği ve tekrarları tanıyan işlem tasarımı gerekir.
Temel kavramlar
| Kavram | Anlamı |
|---|---|
| Producer | Broker’a mesaj gönderen akış. |
| Consumer | Kuyruktan mesaj alan ve işleyen akış. |
| Address | Gönderilen mesajın broker üzerindeki yönlendirme adresi. |
| Queue | Adrese bağlı, tüketilmeyi bekleyen mesajların tutulduğu yapı. |
| ANYCAST | Mesaj adresteki bir kuyruğa yönlendirilir; aynı kuyruktaki tüketiciler işi paylaşır. |
| MULTICAST | Mesaj, adrese bağlı uygun kuyrukların her birine yönlendirilir. Ayrı uygulamalar için ayrı kuyruklar kullanılır. |
| Durable | Kuyruk tanımının kalıcı olması. Mesajın da kalıcı gönderilmesi ve broker depolamasının korunması gerekir. |
| Dead letter | Teslim edilemeyen ve yeniden denenene veya silinene kadar saklanan mesaj. Kurulumun bütün dead letter’ları DLA adresinde toplanır. |
Adres, kuyruk ve yönlendirme türünün birlikte çalışması için Artemis adres modeli esas alınır. Basit iş kuyruğu için adres ve kuyruk adını aynı tutan ANYCAST düzeni kullanabilirsiniz.
Proje ve izolasyon sınırı
Kurulumdaki ortak Artemis broker’ı birden fazla projeye hizmet eder. Bir projenin silinmesi broker kuyruğunu veya içindeki mesajları silmez. Kuyruklar, broker kullanıcıları ve erişim kuralları broker üzerinde yönetilir.
orders.incoming adını iki projede kullanmak aralarında veri alışverişi kurabilir. Proje adları otomatik kuyruk güvenlik sınırı değildir. Farklı ekipler veya müşteriler için uygun broker kullanıcıları, adres izinleri, adlandırma, kapasite ve gerekirse ayrı broker kurulumları planlayın.
İlk kurulum adımları
- Yöneticiden broker adresi, protokol, kuyruk adı, mesajlaşma kullanıcı bilgileri ve TLS gereksinimini alın.
- Yetkili kullanıcıyla Artemis console üzerinden adres ve kuyruğu oluşturun.
- Lunex projesinde bağlantı bean’ini ve Secret referanslarını tanımlayın.
- Bir tüketici akışı ve bir test üreticisi hazırlayın.
- Mesajın broker’a geldiğini, tüketildiğini ve Message Monitor sonucunu kontrol edin.
Kuyruk oluşturma ve teslim rehberi bu adımları örneklerle açıklar. Hata olduğunda Lunex’in mesajı nasıl sakladığını sorumluluk ve dead letter’lar sayfası açıklar.
Kalıcılık ve kapasite
Kalıcı kuyruk ile kalıcı mesaj birlikte kullanıldığında broker yeniden başlasa da veri korunabilir; bunun için kalıcı disk ve doğru broker yapılandırması gerekir. Yerel kurulumun volume veya kümesini silmek veriyi koruyan bir işlem değildir.
Ortak broker’ın disk, bellek ve bağlantı kapasitesi tüm istemcileri etkiler. Kuyruk büyümesi, tüketici sayısı ve dead letter sayısını birlikte takip edin. Tek broker kurulumu tek başına yüksek erişilebilirlik veya otomatik felaket kurtarma sağlamaz.