जिस queue में at least once delivery की गारंटी है, उसके लिए consumer आप कैसे डिजाइन करते हैं?

मान लें कि हर message एक से ज्यादा बार आ सकता है और processing को idempotent बनाएं। message से एक स्थिर key निकालें, और या तो काम करने से पहले उसे किसी store में जांचकर दर्ज करें या conditional write इस्तेमाल करें ताकि दोहराव कुछ करे ही नहीं। visibility timeout अपने सबसे खराब processing time से ऊपर रखें, लंबे काम के लिए उसे बढ़ाएं, और कुछ नाकामियों के बाद message को dead letter queue में भेजें ताकि जहरीले message आगे का रास्ता न रोकें।

मैं इस मान्यता से शुरू करता हूं कि हर message किसी न किसी वक्त कम से कम दो बार आएगा, आमतौर पर इसलिए कि consumer धीमा था और काम commit हो जाने के बाद visibility timeout खत्म हो गया। तो consumer को idempotent होना चाहिए, और मैं चाहता हूं कि वह इच्छा नहीं, एक ठोस चीज हो। आमतौर पर वह message से निकली एक idempotency key होती है, या तो producer की सेट की हुई id या अर्थपूर्ण content का hash, जिसे काम के उसी transaction के भीतर unique constraint वाली table में दर्ज किया जाता है। अगर insert टकराता है, तो हम यह पहले कर चुके हैं, acknowledge करके आगे बढ़ो। जहां असर किसी store में write होना है वहां मैं इसके बजाय conditional update पसंद करता हूं, ताकि उसे दो बार लगाने पर भी वही स्थिति बने। ऑपरेशनल तौर पर visibility timeout को सबसे धीमे वास्तविक processing time से ऊपर होना चाहिए, और सचमुच लंबे काम के लिए मैं एक बड़ा global timeout रखने के बजाय चलते चलते lease बढ़ाता रहता हूं। नाकामियां exponential backoff और jitter के साथ retry होती हैं, और थोड़ी कोशिशों के बाद message error के साथ dead letter queue में चला जाता है, ताकि एक खराब message बाकी सब को कभी न रोके।