ApsaraMQ for RocketMQ:Message sending retry and throttling

Yeniden deneme süreci

İstemci SDK'sı yerleşik yeniden deneme mantığı içerir. Bir gönderim isteği başarısız olduğunda SDK mesajı otomatik olarak yeniden gönderir; uygulama düzeyinde ek bir yeniden deneme kodu yazmanıza gerek yoktur.

Üreticiyi başlatırken maksimum yeniden deneme sayısını ayarlayın. Bir istek başarısız olursa SDK, mesaj iletilene veya yeniden deneme sınırına ulaşılana kadar denemeye devam eder. Son yeniden deneme de başarısız olursa SDK uygulamanıza bir hata döndürür.

Yeniden deneme davranışı kullanılan gönderim moduna göre değişir:

Yeniden deneme tetikleyicileri

Yeniden denemeler iki kategoriye giren hata türleri tarafından tetiklenir:

İstemci tarafı hataları

• Bir ağ hatası bağlantı kopmasına veya istek zaman aşımına neden olur.

• Broker'ın yeniden başlatılması veya dağıtımının kaldırılması bağlantı hatalarına yol açar.

• Broker'ın yavaş çalışması istek zaman aşımlarına neden olur.

Broker tarafı hataları

• Sistem mantık hatası: Broker üzerindeki dahili işleme hatası.

• Sistem kısıtlama hatası: Broker, kapasitesini aştığı için isteği reddeder. Bkz. Kısıtlama.

Yeniden deneme aralığı

Yeniden deneme aralığı hata türüne bağlıdır:

Kısıtlama hataları için SDK aşağıdaki parametrelerle üstel geri çekilme kullanır:

Geri çekilme algoritması şu şekilde çalışır:

ConnectWithBackoff()
  current_backoff = INITIAL_BACKOFF
  current_deadline = now() + INITIAL_BACKOFF
  while (TryConnect(Max(current_deadline, now() + MIN_CONNECT_TIMEOUT)) != SUCCESS)
    SleepUntil(current_deadline)
    current_backoff = Min(current_backoff * MULTIPLIER, MAX_BACKOFF)
    current_deadline = now() + current_backoff +
      UniformRandom(-JITTER * current_backoff, JITTER * current_backoff)

Tam teknik özellikler için bkz. gRPC bağlantı geri çekilmesi.

Toplam yeniden deneme süresi bütçesini anlama

SDK yalnızca bir yeniden deneme kontrolü sunar: maksimum yeniden deneme sayısı. Eşzamanlı modda çağıran iş parçacığı tüm yeniden deneme dizisi boyunca bloke kalır. Bu nedenle toplam blokaj süresi, istek başına zaman aşımınız ile maksimum yeniden deneme sayısı arasındaki ilişkiye bağlıdır:

Total blocking time (worst case) = max_retries x per_request_timeout + sum_of_backoff_delays

Kısıtlama dışı hatalar (anında yeniden deneme) için geri çekilme gecikmesi sıfırdır:

Total blocking time = max_retries x per_request_timeout

Kısıtlama hatalarında ise geri çekilme gecikmeleri üstel olarak birikir. Örneğin, varsayılan parametreler ve 5 yeniden deneme ile:

Eşzamanlı modda çağıran iş parçacığının çok uzun süre bloke kalmasını önlemek için istek başına zaman aşımınızı ve maksimum yeniden deneme sayınızı birlikte değerlendirin.

Yeniden denemeler tükendikten sonra başarısız mesajları yönetme

Yerleşik yeniden denemeler teslimatı garanti etmez. Tüm yeniden denemeler başarısız olursa SDK bir hata döndürür. Bu hatayı uygulamanızda yakalayın ve bir geri dönüş stratejisi uygulayın:

• Başarısız mesajı daha sonra yeniden işlemek üzere yerel bir günlüğe veya ölü harf (dead-letter) deposuna yazın.

• Kök nedeni araştırabilmeniz için izleme sisteminizi uyarın.

Yeniden denemelerden kaynaklanan yinelenen mesajları yönetme

Bir gönderim isteği zaman aşımına uğradığında SDK broker'ın mesajı zaten alıp almadığını belirleyemez. Bir yeniden deneme, broker üzerinde yinelenen bir mesaj üretebilir. Bu, en az bir kez teslimat (at-least-once delivery) sistemlerinde temel bir ödünleşimdir.

Yinelenen mesajları yönetmek için tüketicilerinizi idempotent işleme için tasarlayın:

• Her mesaja benzersiz bir iş anahtarı atayın (örneğin, sipariş kimliği veya işlem kimliği).

• İşlemeden önce anahtarın daha önce işlenip işlenmediğini kontrol edin.

• Benzersizliği zorlamak için veritabanı kısıtlamalarını veya yinelenen öğe silme önbelleklerini kullanın.

Kısıtlama tetikleyicileri

Kısıtlama aşağıdaki senaryolarda tetiklenir:

• Depolama baskısı artışı: Bir tüketici grubu bir kuyruğun maksimum ofsetinden tüketmeye başlar. Bir tüketici grubunun belirli bir zamanda tüketmeye başlamasının gerektiği iş yayını gibi senaryolarda kuyruk üzerindeki depolama baskısı ani bir artış gösterir. Daha fazla bilgi için bkz. Tüketici ilerleme yönetimi.

• Mesaj birikimi: Tüketiciler gelen mesajların hızına yetişemediğinde tüketilmeyen mesajlar kuyrukta birikir. Birikim eşikleri aşarsa broker alt sistem üzerindeki baskıyı azaltmak için kısıtlamayı tetikler.

İstemci türüne göre hata kodları ve yeniden deneme davranışı

Kısıtlama tetiklendiğinde hata kodu ve yeniden deneme davranışı kullandığınız istemci protokolüne bağlıdır.

gRPC istemcileri

Remoting istemcileri

Remoting istemcileri için yeniden deneme davranışı SDK sürümüne göre değişir:

SDK sürümünüz kısıtlama hatalarında otomatik yeniden deneme yapmıyorsa uygulama kodunuzda üstel geri çekilme ile yeniden deneme mantığını uygulayın.

Kısıtlamayı önleme ve yönetme

Trafik artışlarından önce kapasiteyi izleyin

Sistem kullanımını ve kapasiteyi izlemek için ApsaraMQ for RocketMQ gözlemlenebilirlik özelliklerini kullanın. İş yayınından veya beklenen trafik artışlarından önce:

• Örneğinizin beklenen trafik için yeterli kaynağa sahip olduğunu doğrulayın.

• Birikim risklerini belirlemek için tüketici grubu gecikmesini kontrol edin.

• Gerekirse örneğinizi ölçeklendirin veya tüketici aktarım hızını optimize edin.

Çalışma zamanında beklenmeyen kısıtlamayı yönetin

Kısıtlama beklenmedik şekilde gerçekleşirse ve SDK'nın yerleşik yeniden denemeleri durumu kurtaramazsa:

• Kısıtlama koşulu geçene kadar istekleri bir geri dönüş sistemine yönlendirin.

• Kök nedeni teşhis etmeye yardımcı olmak için kısıtlama olaylarını günlüğe kaydedin (gRPC için 530 / TOO_MANY_REQUESTS veya Remoting için 215 / messages flow control hata kodlarını arayın).