Aynı olayın yeniden görülmesi ne demek?
Bir sipariş değişikliği için iki kayıt görmek, iki gerçek sipariş oluştuğunu tek başına göstermez. Bildirim işleyen uygulamada teslim kimliğiyle işletme olayını birbirinden ayırın. Özellikle stok azaltma, bildirim e-postası veya muhasebe aktarımı yapan adımlarda aynı etkinin tekrar üretilmesini önlemek gerekir.
AWS'nin standart SQS teslim belgesi, mesajın yeniden alınabileceğini ve tüketicilerin idempotent tasarlanmasını önerir. Bu açıklama kullandığınız taşıma kanalına göre değerlendirilmelidir; bütün bildirim yöntemlerinin aynı teslim garantisine sahip olduğunu varsaymayın.
İşlem anahtarını işin gerçek anlamına göre seçin
Uygulama ekibinizle hangi olayın hangi kayıt üzerinde tek etki yaratacağını tanımlayın. Yalnız sipariş numarasını anahtar yapmak, aynı siparişin daha sonraki meşru değişikliğini yanlışlıkla engelleyebilir. Sürüm, olay türü veya işlem anlamına uygun başka alanlar gerekebilir; tasarım kullanılan şemaya bağlıdır.
Kontrol kaydını yalnız uygulama belleğinde tutmak yeniden başlatma sonrasında unutulabilir. Kalıcı kayıt ve eşzamanlı çalışanların aynı işi birlikte başlatmasını önleyen mekanizma planlayın. Buradaki amaç mesajları körlemesine silmek değil, doğru iş etkisini yalnız gerektiği kadar uygulamaktır.
Tamamlandı işaretini doğru aşamada yazın
İş başlamadan 'tamamlandı' yazılırsa yarıda kalan görev kaybolabilir. İş bittikten sonra kayıt yazılamazsa tekrar çalışma riski doğabilir. Bu sınırı geliştiriciyle açıkça değerlendirin; veritabanı güncellemesi ve dış servise gönderim gibi farklı etkilerin nasıl tutarlı kalacağını belirleyin.
Hata durumunda bütün mesajı ham biçimde e-postaya yollamak yerine olay kimliği, zaman ve maskeli hata kaydı kullanın. Deneme ortamında aynı mesajı iki kez, yarıda kesilmiş biçimde ve yeniden başlatma sonrasında işleyerek beklenen sonucu kontrol edin.
Bildirim gelmezse veri nasıl tamamlanacak?
Tekrarlı işlem kadar kaçırılan işlem de önemlidir. Amazon'un Notifications API rehberi kesinti veya gecikme durumunda gerekli bilgiyi başka yoldan alabilecek bir yedek mekanizma önerir. Bu nedenle periyodik mutabakatı işin önemine uygun kapsamda planlayın.
Mutabakat, sonsuz sıklıkta bütün veriyi okumak değildir. Son başarılı zaman, işlenen aralık ve beklenen durum karşılaştırılmalı. Kuyruk sağlığı, uygulama sağlığı ve işletme kaydı tutarlılığı ayrı göstergeler olarak izlenirse yalnız sunucu çalışıyor diye bütün sürecin doğru olduğu sanılmaz.
Mükerrer kayıt kontrolünü yanlış pozitiflerle de sınayın. Aynı siparişin birbirinden farklı iki gerçek güncellemesi geldiğinde ikinci olayın engellenmemesi gerekir. Test sonucunda stok veya durum tablosunda beklediğiniz etkiyi yazılı karşılaştırın; sadece uygulamanın hata vermemesi yeterli kabul ölçütü değildir.
Entegrasyonun çalıştığı ortam için Amazon VDS seçeneklerini ihtiyaçla karşılaştırabilirsiniz. rapor erişim sorunları; sunucu izleme planı; yedekleme planı rehberleri de iş akışını tamamlar. Sunucu kaynağı, Amazon'un uyguladığı izin veya API kullanım sınırlarının yerine geçmez.
Sıkça Sorulan Sorular
Aynı bildirim iki kez gelince ikinciyi her zaman silebilir miyim?
Önce gerçekten aynı iş olayını temsil ettiğini doğrulayın. Aynı siparişin farklı durum değişiklikleri meşru ayrı olaylar olabilir.
İdempotent işlem ne demek?
Aynı iş girdisi tekrar işlendiğinde stok veya ödeme gibi etkilerin yanlışlıkla ikinci kez uygulanmamasını sağlayan tasarımdır.
Sadece bellekte kimlik listesi tutmak yeterli mi?
Yeniden başlatma ve çoklu çalışan durumları için yeterli olmayabilir. Kalıcı ve eşzamanlılığı dikkate alan kayıt değerlendirilmelidir.
Sunucu açık ama bildirim yoksa neye bakılır?
Abonelik, taşıma kanalı, kuyruk ve son başarılı iş zamanı ayrı incelenir. Eksik veri için kontrollü mutabakat planı gerekir.