IOSOR دانش

وب‌هوک‌های SMS ورودی: تلاش‌های مجدد، ترتیب رویداد و ایدمپوتنسی هنگام دریافت

راهنمای ساخت برای تیم‌های B2B که SMS ورودی را مدیریت می‌کنند: چرا تلاش‌های مجدد رخ می‌دهند، چرا ترتیب رویدادها تضمین نمی‌شود، و چگونه نقطه پایانی دریافت خود را ایدمپوتنت کنید به‌جای تکرار مکالمات و پردازش STOP.

هر پردازشگر پیام ورودی سرانجام با همان سه سورپرایز روبرو می‌شود: همان webhook دو بار فعال می‌شود، یک رویداد «delivered» بعد از «failed»ای که قرار بود جایگزینش شود می‌رسد، و پاسخ STOP یک مشتری دو بار پردازش می‌شود زیرا دو سرور همان تلاش مجدد را دریافت کرده‌اند. هیچ‌کدام از این‌ها باگ پلتفرمی نیست که webhook را برای شما می‌فرستد — این رفتار عادی هر سیستم تحویل «حداقل یک‌بار» است، و نقطه پایانی دریافت شما باید از روز اول برای این واقعیت ساخته شود.

IOSOR پیام‌های ورودی، کلیدواژه‌های STOP/HELP و رویدادهای تحویل را به‌صورت webhook‌های پیش‌پرداخت وایت‌لیبل ارسال می‌کند — رفتار تلاش مجدد و ترتیب توضیح داده‌شده در زیر چیزی است که هر یکپارچه‌سازی جدی B2B باید فرض کند، صرف‌نظر از اینکه کدام پلتفرم پشت آن است.

چرا webhookها اصلاً تلاش مجدد می‌کنند

یک ارائه‌دهنده webhook نمی‌تواند با اطمینان بداند که نقطه پایانی شما یک تحویل را پردازش کرده است. سرور شما ممکن است پس از commit به پایگاه داده‌ای که سپس rollback می‌شود، ۲۰۰ برگرداند؛ یک load balancer ممکن است پاسخ را در مسیر بازگشت گم کند با وجود اینکه پردازشگر شما موفق بوده؛ یک استقرار ممکن است فرآیند شما را در وسط یک درخواست دوباره راه‌اندازی کند.

سه حالت خرابی که باید برای آن‌ها طراحی کنید

حالت خرابی چه اتفاقی می‌افتد اگر نادیده بگیرید چه چیزی خراب می‌شود
تحویل تکراری همان شناسه رویداد ۲ بار یا بیشتر می‌رسد پاسخ‌های دوبار شمرده‌شده، پردازش STOP تکراری، رشته‌های مکالمه تکراری
رویدادهای خارج از ترتیب رویدادی با برچسب زمانی جدیدتر قبل از رویداد قبلی می‌رسد وضعیت «delivered» به «sent» بازنویسی می‌شود
خرابی جزئی/مبهم پردازشگر شما رویداد را پردازش

ایدمپوتنسی: تنها ویژگی‌ای که هر سه را حل می‌کند

یک نقطه پایانی دریافت ایدمپوتنت، صرف‌نظر از اینکه همان رویداد چند بار تحویل داده شود، همان وضعیت نهایی را تولید می‌کند. مکانیزم ساده و به‌خوبی شناخته‌شده است: هر رویداد ورودی یک شناسه رویداد منحصربه‌فرد حمل می‌کند؛ قبل از پردازش، بررسی می‌کنید که آیا قبلاً آن شناسه را ثبت کرده‌اید؛ اگر بله، بلافاصله موفقیت را بدون پردازش مجدد برمی‌گردانید. ۱.

ترتیب رویدادها: چرا «آخرین نوشتن برنده می‌شود» خطرناک است

رویدادهای webhook برای همان پیام تضمینی برای رسیدن به ترتیب وقوع‌شان ندارند. تلاش مجدد یک رویداد قبلی «queued» ممکن است به دلیل لرزش شبکه، صف‌بندی در سمت ارائه‌دهنده، یا استخر worker خودتان که درخواست‌ها را خارج از ترتیب پردازش می‌کند، بعد از یک رویداد بعدی «delivered» برسد.

STOP، HELP و سایر کلیدواژه‌های ورودی به همان انضباط نیاز دارند

کلیدواژه‌های ورودی حیاتی برای انطباق، سخت‌گیرانه‌ترین ایدمپوتنسی از همه را می‌طلبند. یک STOP تکراری هرگز نباید یک رویداد انصراف را دوبار ثبت کند یا دو پاسخ تأیید ارسال کند. یک HELP تکراری هرگز نباید دو پیام اطلاعات پشتیبانی جداگانه به همان شماره در همان دقیقه فعال کند.

با IOSOR شروع کنید

گزارش webhook ورودی هفتهٔ پیش را بکشید و شناسهٔ رویدادهایی را بشمارید که بیش از یک بار رسیدند. یک تکراری و یک جفت بی‌ترتیب (failed سپس delivered) پخش کنید. گیرنده یک اثر نگه می‌دارد: یک ردیف صندوق، یک نوشتن STOP، یک لمس کیف. Last-write-wins که STOP را برمی‌گرداند شکست است. این لادوری در دریافت و ترتیب تلاش دوباره است، نه اعتبار امضا و نه قفل دروازه پیش از صف.

جمع‌بندی IOSOR

وب‌هوک ورودی دوباره تلاش می‌کند. لادوری در دریافت تنها پاسخ امن است؛ ترتیب وعده نیست.

بکنید: رویداد را کلید بزنید و همزاد را نادیده بگیرید. نکنید: last-write-wins روی STOP یا دو بار کسر همان رویداد.

آیا این راهنما مفید بود؟

راهنماهای مرتبط