Kendime Notlar – Reliable Messaging Without Distributed Transactions

Okuma Süresi: 4 dakika

Geliştirdiğimiz mesajlaşma sistemlerinin en kritik ve hata oluşabilecek noktalarından bir tanesi dağıtık işlemlerin hepsinin tek bir paket gibi olmasını sağlayan yapılar.

Uygulamanın beklenmedik şekilde durması (crash olması) ve tekrar çalışması sonrasında her şey en baştan başlamıyor veya kaldığı yerden devam etmiyor. Keşke başlasa ve hiç bir şey olmamış gibi tekrardan işlemleri yapabilsek.

Bunun için bazı geliştirici arkadaşlarım DTC (Distributed Transaction Coordinator) kullanmamı önerebilir. Hızlı çözüm olarak düşünülebilir ama aslında bazı durumlarda işimize yaramayacaktır. Udi Dahan[1] yukarıdaki videoda bu senaryoyu anlatarak, DTC kullanmadan bu sorunu nasıl çözüleceğini anlatıyor.

Notlarım

Videoyu izledikten sonra kendimce geri dönüp baktığımda çözümleri hızlı hatırlamamı sağlayacak notlar aldım.

Sistemi Görselleştir

Geliştirme yapacakken sistemin ya da verilerin akışının görselleştirmesi işleri çok daha kolay hale getirebilir. Ayrıca hataların ya da olası risk noktalarının bu görsel üzerinden çözülmesi sistemin bütününün anlaşılması için kolaylık sağlayacaktır.

Idempotency

“Ne değişik bir kelime” duyduğumda ilk verdiğim tepkim. Bu videoda direk geçmiyor ancak daha sonradan kelimeyi başka bir makaleden öğrenip anlatılanlarla ilişkilendirdiğim zaman tam olarak bunu demek istediğini anladım.

Bir işlem sistem içerisinde birden fazla kere uygulanmasına rağmen bir kere uygulanmış gibi sistem aynı durumdaysa, bu işlem idempotent bir işlemdir.[2][3]

Örneğin; sisteme bir retrieve işlemi geldi. Bu işlem 1 kere de çalıştırılsa 50 kere de çalıştırılsa aynı sonucu verecektir. Yani retrieve işlemi idempotent’tir. Başka bir örnek olarak sisteme bir create işlemi geldi. Create işlemi birden çok çalıştırıldığında bilgileri aynı olan ama farkı tekil tanımlayıcılara sahip olan kayıtlar oluşturacaktır. Bu yüzden create işlemi idempotent değildir.

Videoda anlatıldığı üzere idempotency özelliğinin sağlanması ya da daha basit haliyle bir mesajın birden çok kere işlenmesinin engellenmesi için, gelen mesajın id değerini sistemin veri tabanına kaydedilmesi yeterli olacaktır.

Dışarı Haber Vermek

Mesaj geldi, kaydedildi ve iş akışı çalıştı. Sonrasında sistemin dışarı haber verilecek noktaya gelindi. Burada yine önemli bir soru var. Ya mesajları gönderemeden ya da bir kısmını gönderdikten sonra uygulama aniden durursa? Mesajlar kaçtı gitti…

Çözüm olarak mesajları dışarı göndermek (Bus.Publish) yerine mesaj işlenirken yapılan diğer veritabanı işlemleriyle birlikte kaydetmek. Mesajlar kaydedildi, kim gönderecek? Mesaj işlemcisi (handler) bu işi de üstlenecek.

Mesaj Gönderildi mi?

Gelen mesaj işlendi ve dışarı gidecek mesajlar kaydedildi. Gönderim sırasında bir hata oldu. Bunun çözümü de basit. Gönderilen mesajların işaretlenmesi ve her uygulama başladığında tekrar gönderilmeyenlerin gönderilmesi.

Mesaj Id

Peki her seferinde yolladığım bu mesajlar farklı id alacak ve kurduğumuz sistem kendi ayağına sıkacak bir duruma gelecek. Bunun için çözüm, gidecek mesajlara hep aynı id değerini vermek olacaktır.

Bitsin Bu Akış

Bu kadar akış oldu bitti hayırlı olsun. Mesajı en son olarak geldiği kaynaktan temizlemeyi unutmamak lazım. Yoksa mesaj sürekli takılı kalabilir. Bunun için veri tabanı işlemleri kaydettikten ve dışarı başarılı olarak bütün mesajları gönderdikten sonra kaynaktan temizleme işlemi yapılabilir.

Toparlama

Videoyu çizim yaparak dinlemek daha rahat anlamamı sağladı. Videoda zaten Udi Dahan çiziyor. Ama kendi notlarımı kendi çizimim üzerine almak daha hoşuma gitti.

Reliable Messaging Without Distributed Transactions El Çizimi
Reliable Messaging Without Distributed Transactions El Çizimim

Referanslar

Bir cevap yazın

E-posta hesabınız yayımlanmayacak.