مصرف‌کننده Idempotent - مدیریت پیام‌های تکراری 🛡

چه اتفاقی می‌افتد وقتی یک پیام دوباره تلاش (retry) می‌شود در یک سیستم رویداد-محور (event-driven)؟
این اتفاق بیشتر از آن چیزی که فکر می‌کنید، رخ می‌دهد.

بدترین سناریو 😱 این است که پیام دو بار پردازش شود، و عوارض جانبی (side effects) نیز می‌توانند بیش از یک بار اعمال شوند.

آیا می‌خواهید حساب بانکی شما دو بار شارژ شود؟ 💳
من فرض می‌کنم پاسخ منفی است، البته.

شما می‌توانید از الگوی مصرف‌کننده Idempotent برای حل این مشکل استفاده کنید.

در این مقاله به شما نشان خواهم داد:

🔹 الگوی مصرف‌کننده Idempotent چگونه کار می‌کند

🔹 چگونه یک مصرف‌کننده Idempotent را پیاده‌سازی کنیم

🔹 مزایا و معایبی که باید در نظر بگیرید

بیایید ببینیم چرا الگوی مصرف‌کننده Idempotent ارزشمند است.

الگوی مصرف‌کننده Idempotent چگونه کار می‌کند؟ 🤔
ایده پشت الگوی مصرف‌کننده Idempotent چیست؟

یک عملیات idempotent عملیاتی است که اگر بیش از یک بار با همان پارامترهای ورودی فراخوانی شود، هیچ تأثیر اضافی ندارد.

ما می‌خواهیم از مدیریت یک پیام یکسان بیش از یک بار، اجتناب کنیم.
این امر نیازمند تضمین تحویل پیام دقیقاً-یک‌باره (Exactly-once) از سیستم پیام‌رسانی ما خواهد بود. و این یک مشکل واقعاً سخت برای حل کردن در سیستم‌های توزیع‌شده است.

یک تضمین تحویل سست‌تر، حداقل-یک‌باره (At-least-once) است، که در آن ما آگاه هستیم که تلاش مجدد می‌تواند اتفاق بیفتد و می‌توانیم یک پیام یکسان را بیش از یک بار دریافت کنیم.

الگوی مصرف‌کننده Idempotent با تحویل پیام حداقل-یک‌باره به خوبی کار می‌کند و مشکل پیام‌های تکراری را حل می‌کند.

در اینجا الگوریتم از لحظه‌ای که ما یک پیام دریافت می‌کنیم، به این شکل است: ⚙️

1️⃣ آیا پیام قبلاً پردازش شده است؟

2️⃣ اگر بله، این یک پیام تکراری است و کاری برای انجام دادن وجود ندارد.

3️⃣ اگر نه، ما باید پیام را مدیریت کنیم.

4️⃣ ما همچنین باید شناسه پیام را ذخیره کنیم.