AWS IoT ile bir iş kuyruğu için ana ve yük devretme MQTT abonelerini nasıl ayarlayabilirim?

Bir istemci (diyelim ki ClientA diyelim) belirli bir MQTT konusuna isteklerini yayınlayabileceği bir sistemim var. Aracı, önemli olması durumunda Amazon Web Services'dir. Daha sonra her zaman aynı konuya abone olan başka bir istemcim (buna MainSubscriber diyelim) var, böylece ClientA'dan gelen istekleri alabilir ve sonunda bir veritabanı işlemine dönüşen bazı işler yapabilir. Veritabanı, önemli olması halinde, DynamoDB'dir.

MainSubscriber her zaman erişilebilir / çevrimiçi olmayabileceğinden, ana abonenin yük devretme yedeği olmak için yük devretme abonesine sahip olma isteği vardır. Fikir, ana abone talebi zamanında ele almazsa, yük devretme abonesi devreye girecek ve eşdeğer iş / veritabanı işlemini yapacaktı. Buradaki zorluk, "iş" ve sonuçta ortaya çıkan "veritabanı işleminin" hem ana hem de yük devretme aboneleri tarafından çoğaltılmaması gerektiğidir.

İşte bu sistem için mantıksal bir sistem mimarisi çizimi.

                   -----> MainSubscriber ----
                  /                          \
ClientA --> Broker                            ---> Database
                  \                          /
                   ---> FailoverSubscriber --

Açıkçası, böyle bir sistemle ilgili bazı zorluklar vardır:

1. Ana abone, yük devretme abonesine istek üzerinde çalıştığını nasıl gösteriyor?
2. Yük devretme abonesi, ana abonenin isteği almadığını ve üzerinde çalışmaya başlaması gerektiğini nasıl algılar?
3. Yük devretme abonesi, aniden tekrar çevrimiçi olması ve isteği alması durumunda ana aboneyi nasıl durdurur?
4. Ana ve yük devretme aboneleri arasındaki eşzamanlılık sorunlarıyla nasıl başa çıkılır?

Böyle bir şema için mevcut bir çözüm zaten mevcutsa, tekerleği yeniden icat etmek istemem. Yani, ilk sorum zaten orada bir şey olup olmadığı?

Değilse, o zaman Ana ve Yük Devretme abonesi arasında arabulucu olarak hareket etmek için DynamoDB'yi Kesinlikle Tutarlı okumalarla kullanmayı düşünüyordum. Yani, ikinci sorum bunu yapmak için iyi kurulmuş bir program olup olmadığıdır.

Göre AWS SQS Dokümantasyon bu doğal olmalı (eğer komisyoncu AWS söyleyen gibi):

Mesaj alındıktan hemen sonra, kuyrukta kalır. Diğer tüketicilerin mesajı tekrar işlemesini önlemek için Amazon SQS, Amazon SQS'nin diğer tüketen bileşenlerin mesajı almasını ve işlemesini engellediği bir zaman aralığı olan bir görünürlük zaman aşımı belirler.

Sorun, maksimum işlem sürenize göre doğru görünürlük zaman aşımını bulmaktır.

Her iki abonenin de aynı mesajı işleme alma şansı düşüktür, bu durumda abone kodunuz veritabanı için idempotent çıktı oluşturmaya çalışmalıdır (en azından aynı birincil anahtar) ve aynı kaydı eklemeye çalışırken başarısız bir şekilde işlenmelidir.

AWS SQS'nin ölü harf kuyrukları kavramına bakmak isteyebilirsiniz . AWS belgelerinden:

Ölü harf kuyruğu, diğer (kaynak) kuyrukların başarıyla işlenemeyen (tüketilemeyen) iletiler için hedefleyebileceği bir kuyruktur. İşlemlerin neden başarılı olamadığını belirlemek için bu iletileri çıkmaz kuyrukta bir kenara bırakıp yalıtabilirsiniz.

Bu nedenle, ana aboneyi normal kuyruktan dinlemeye, ikincil aboneyi de ölü harf kuyruğundan dinlemeye yönlendirirseniz, yük devretme sorunu çözülmelidir.

Ayrıca bununla 1, 2 ve 3 problemleriniz halledilir. Bu durumda ana ve ikincil abonelerin birbirleriyle konuşmasına gerek yoktur.

Ayrıca Tensibai cevabı üzerine inşa seferinde bir mesaj almak için olarak emin abone kod böylece yazılır hale çoklu aboneler aynı sıraya dinlerken eğer nedeniylevisibility timeout

Dezavantajı, işlemede bir gecikme yaratacağı, mesajların bir süre sonra ölü harf kuyruğuna girmesi olacaktır.

Yani, bunu istemezseniz, Tensibai'nin cevabına devam edebilirsiniz. Durum denetimleri için fazladan bir Dinamo tablosu kullanmak yerine bunu tolere edebilirseniz, bunu kullanabilirsiniz.