سفارش‌های تکراری هنگام کار با API: دلایل و محافظت
چرا تکرارها پس از یک اقدام ظاهر می‌شوند
صاحب پنل ممکن است یک بار روی دکمه کلیک کند و چند سفارش یکسان ببیند: برای فالوور، بازدید، واکنش یا سرویس دیگر. معمولاً مشکل در خود کلیک نیست، بلکه در زنجیره بین کلاینت، API، پایگاه داده و تأمین‌کننده است.
از دید سرور، «یک درخواست» همیشه یکی نیست. ممکن است کلاینت پاسخ را دریافت نکرده باشد و ارسال را تکرار کرده باشد، در حالی که عملیات اول قبلاً ذخیره شده است. گاهی سفارش یک بار در پایگاه داده پنل ایجاد می‌شود اما دو بار به تأمین‌کننده ارسال می‌شود. این‌ها سناریوهای متفاوتی هستند و به روش‌های مختلفی رفع می‌شوند.
تایم‌اوت به معنای عدم ایجاد سفارش نیست
شایع‌ترین دلیل این است که کلاینت برای مدت محدودی منتظر پاسخ می‌ماند. سرور درخواست را می‌پذیرد، سفارش را ایجاد می‌کند، اما دیرتر از تایم‌اوت تعیین‌شده پاسخ می‌دهد. کلاینت عملیات را ناموفق می‌داند و آن را دوباره ارسال می‌کند.
در نتیجه سفارش اول قبلاً در پایگاه داده وجود دارد و درخواست دوم یکی دیگر ایجاد می‌کند. این اتفاق به‌ویژه هنگام پاسخ کند API خارجی، صف پرترافیک یا اتصال ناپایدار بین سرویس‌ها بیشتر رخ می‌دهد.
تایم‌اوت فقط از نبود پاسخ خبر می‌دهد، نه از عدم پردازش درخواست.
تکرارهای خودکار در سمت کلاینت
کتابخانه‌های درخواست HTTP، وظایف پس‌زمینه و سرویس‌های یکپارچه‌سازی اغلب درخواست را به‌طور خودکار تکرار می‌کنند. دلیل آن می‌تواند خطای اتصال، کد پاسخ سرور، قطع شبکه یا پاسخ بیش از حد طولانی باشد.
تکرار به‌خودی‌خود مفید است: تعداد سفارش‌های ازدست‌رفته را در خرابی‌های موقت کاهش می‌دهد. عیب این رویکرد این است که بدون محافظت در برابر پردازش مجدد، هر ناپایداری شبکه را به تکرار تبدیل می‌کند.
- تکرار ممکن است در کد سایت یا ربات اجرا شود؛
- صف ممکن است وظیفه را دوباره راه‌اندازی کند؛
- پروکسی یا ماژول یکپارچه‌سازی ممکن است درخواست را تکرار کند؛
- اپراتور ممکن است پس از خطا سفارش را دستی دوباره ارسال کند.
درخواست مکرر پیش از پاسخ اول می‌رسد
گاهی دو درخواست یکسان واقعاً تقریباً همزمان به API می‌رسند. مثلاً کاربر فرم را دو بار ارسال کرده، فرانت‌اند دکمه را قفل نکرده یا وظیفه پس‌زمینه پیش از پایان اولی دوباره شروع شده است.
اگر پردازشگر ابتدا وجود سفارش را بررسی کند و سپس آن را ایجاد کند، دو عملیات موازی می‌توانند همزمان از بررسی عبور کنند. هر کدام خواهند دید که سفارشی وجود ندارد و هر کدام رکورد جدیدی اضافه خواهند کرد.
به این وضعیت race condition می‌گویند. بررسی ساده پیش از ایجاد در کد به‌طور کامل از آن محافظت نمی‌کند. عیب بررسی بدون محدودیت در سطح پایگاه داده این است که تحت بار موازی شکسته می‌شود.
سفارش ثبت شد اما پاسخ API گم شد
درخواست از چند مرحله عبور می‌کند: سرور داده‌ها را دریافت می‌کند، رکورد را ایجاد می‌کند، وظیفه را در صف قرار می‌دهد، پاسخ را ارسال می‌کند. خرابی بین هر یک از این مراحل ممکن است. مثلاً پایگاه داده قبلاً ایجاد سفارش را تأیید کرده اما اتصال پیش از انتقال پاسخ به کلاینت قطع شده است.
کلاینت نمی‌داند آیا سفارش پذیرفته شده و عملیات را تکرار می‌کند. API بدون مکانیزم بررسی جداگانه، درخواست را جدید می‌داند. در لاگ این اغلب طوری به نظر می‌رسد که سرویس دو سفارش را «خودش» ایجاد کرده، در حالی که دو درخواست ورودی داشته است.
کلید idempotency برای ایجاد سفارش
برای عملیات ایجاد، کلید idempotency یکتا لازم است. کلاینت آن را پیش از اولین ارسال تولید می‌کند و همراه با پارامترهای سفارش ارسال می‌کند. هنگام تکرار به‌دلیل تایم‌اوت یا خطا، همان کلید استفاده می‌شود.
API کلید را همراه با نتیجه پردازش ذخیره می‌کند. اگر درخواستی با کلید شناخته‌شده برسد، سرور سفارش جدیدی ایجاد نمی‌کند، بلکه نتیجه اولین درخواست را برمی‌گرداند: شناسه سفارش، وضعیت آن یا خطای قبلاً تولیدشده.
یک کلید باید با یک عملیات تجاری مطابقت داشته باشد، نه با یک اتصال HTTP.
عیب این روش این است که کلیدها باید ذخیره شوند، طبق قوانین پاک‌سازی شوند و در سمت API بررسی شوند. اگر در هر تکرار کلید جدیدی تولید شود، محافظت کار نمی‌کند. اگر یک کلید برای سفارش‌های مختلف استفاده شود، بخشی از عملیات جدید به‌اشتباه رد می‌شود.
یکتایی باید توسط پایگاه داده کنترل شود
بهتر است idempotency با محدودیت یکتایی در پایگاه داده تکمیل شود. برای این کار ترکیبی انتخاب می‌شود که سفارش را به‌طور یکتا توصیف کند: شناسه داخلی کلاینت، کلید idempotency، نوع سرویس و سایر فیلدهای لازم.
پایگاه داده باید رکورد دوم را رد کند، حتی اگر دو پردازشگر همزمان به مرحله ایجاد رسیده باشند. پس از تعارض، API سفارش موجود را برمی‌گرداند، نه خطایی بدون توضیح.
عیب محدودیت یکتایی سخت این است که نمی‌توان آن را فقط بر اساس لینک یا username ساخت. کلاینت ممکن است آگاهانه یک سرویس را چند بار برای همان کانال سفارش دهد. محدودیت بیش از حد گسترده خریدهای تکراری عادی را مسدود می‌کند.
صف ممکن است وظیفه را بیش از یک بار تحویل دهد
صف‌های وظیفه اغلب بر اساس اصل «تحویل حداقل یک بار» کار می‌کنند. اگر worker وظیفه را پردازش کرده اما نتوانسته انجام آن را تأیید کند، صف ممکن است همان وظیفه را دوباره به worker دیگری تحویل دهد.
برای صف این روشی عادی برای از دست ندادن وظیفه است. برای ایجاد سفارش بدون idempotency، منبع تکرارهاست. شناسه وظیفه یا کلید جداگانه عملیات باید تا پردازشگر نهایی، از جمله ماژول ارسال سفارش به تأمین‌کننده، منتقل شود.
عیب غیرفعال کردن تحویل مجدد این است که با سقوط worker بخشی از سفارش‌ها ممکن است از بین برود. ایمن‌تر است که تکرارهای احتمالی پذیرفته شوند و پردازشگر در برابر آن‌ها مقاوم شود.
تکرارها بین پنل و تأمین‌کننده ایجاد می‌شوند
سفارش داخلی ممکن است یک بار ایجاد شود اما درخواست به API خارجی دو بار ارسال شود. دلیل همان است: پنل پاسخ تأمین‌کننده را دریافت نکرده و تصمیم گرفته ارسال را تکرار کند. اگر تأمین‌کننده درخواست اول را پذیرفته باشد، در سمت او دو درخواست یکسان ظاهر می‌شود.
اتصال جداگانه سفارش داخلی به خارجی لازم است: شناسه ارسال، کلید idempotency یا پاسخ ذخیره‌شده تأمین‌کننده. نمی‌توان فرض کرد که محافظت در ورودی پنل خودکار از فراخوانی‌های خروجی محافظت می‌کند.
عیب تطبیق با API شخص ثالث این است که هر تأمین‌کننده‌ای جستجو بر اساس کلید خارجی را پشتیبانی نمی‌کند. در این صورت باید تلاش‌های ارسال ثبت شوند و وضعیت‌های نامشخص جداگانه بررسی شوند.
وب‌هوک نباید سفارش جدیدی ایجاد کند
وب‌هوک‌ها از تغییرات خبر می‌دهند: سفارش پذیرفته شد، شروع شد، انجام شد، لغو شد یا نیاز به بررسی دارد. خطا زمانی رخ می‌دهد که پردازشگر وب‌هوک اعلان را به‌عنوان دستور ایجاد مجدد سفارش تلقی کند.
یک وب‌هوک ممکن است دوباره برسد. فرستنده در صورت عدم دریافت تأیید، تحویل را تکرار می‌کند و اعلان‌ها گاهی خارج از ترتیب می‌رسند. پردازشگر باید سفارش موجود را بر اساس شناسه خارجی پیدا کند و وضعیت را به‌روزرسانی کند.
عیب پردازش وب‌هوک‌ها فقط بر اساس زمان دریافت این است که اعلان دیررس ممکن است وضعیت فعلی را با وضعیت قدیمی بازنویسی کند. شناسه رویداد، نسخه وضعیت یا قوانین مشخص انتقال وضعیت لازم است.
کدام رکوردها به یافتن منبع تکرارها کمک می‌کنند
برای بررسی، دیدن فقط دو شماره سفارش کافی نیست. داده‌های هر مرحله پردازش لازم است: زمان درخواست، کلید idempotency، شناسه کلاینت، پارامترهای سفارش، شماره وظیفه پس‌زمینه، پاسخ API خارجی و تلاش‌های ارسال مجدد.
- تکرارها را بر اساس کلید عملیات تطبیق دهید، نه فقط بر اساس لینک؛
- بررسی کنید آیا درخواست‌های یکسان در لاگ API ورودی وجود داشته‌اند؛
- ببینید آیا وظیفه در صف تکرار شده است؛
- ایجاد سفارش داخلی را از ارسال به تأمین‌کننده جدا کنید؛
- شناسه خارجی درخواست را بلافاصله پس از دریافت پاسخ ذخیره کنید.
عیب لاگ‌های بیش از حد کوتاه این است که منبع مشکل پیش از بررسی ناپدید می‌شود. عیب لاگ‌گیری بیش از حد این است که توکن‌ها، داده‌های شخصی و سایر فیلدهای حساس ممکن است در رکورد بیفتند، بنابراین باید ماسک شوند.
نحوه پردازش نتیجه نامشخص درخواست
پس از تایم‌اوت نمی‌توان بلافاصله سفارش را با داده‌های جدید دوباره ایجاد کرد. ابتدا API باید عملیات را بر اساس کلید idempotency یا شناسه کلاینت بررسی کند. اگر سفارش پیدا شد، وضعیت فعلی آن برگردانده می‌شود. اگر پردازش هنوز در جریان است، کلاینت وضعیت انتظار دریافت می‌کند.
- کلید عملیات را پیش از اولین درخواست ایجاد کنید.
- در هر تکرار همان کلید را ارسال کنید.
- کلید و سفارش را در یک عملیات محافظت‌شده پایگاه داده ذخیره کنید.
- شناسه عملیات را به صف و API خارجی منتقل کنید.
- در درخواست مجدد، سفارش قبلاً ایجادشده را برگردانید.
این سناریو نیازمند توسعه API و یکپارچه‌سازی کلاینت است. عیب آن دشوارتر بودن اشکال‌زدایی و تعداد بیشتر وضعیت‌های سفارش است، اما تحویل مجدد درخواست دیگر به‌طور خودکار به معنای خرید مجدد نخواهد بود.
Last Articles
چه چیزهایی در طراحی و عملکرد تغییر کرده است ما سایت را به‌روزرسانی کرده‌ایم تا کار با آن سریع‌تر و راحت‌تر باشد. تغییرات اصلی مربوط به رابط کاربری، ح..
Good afternoon, I've collected all the news during this time.: 1. The main news is that prices for twitch viewers have been greatly reduced, while Tw..
1. از کد تبلیغاتی "December2025" برای 15% تخفیف برای همه بینندگان ما استفاده کنید2. ما تا 1 ژانویه قیمت‌های پایه برای ابزار پیکربندی و مقرون‌به‌صرفه‌ت..
خدمات Twitch با ثبات کار ميکنيم ، پس آماده ايم با گروه ها و فروشنده ها همکاري کنيم, صاحبان خدمات ، صاحبان ربات ها و بسیاری دیگر.اصطلاحات فردی را م..
ما خدمات twitch viewer ما را به طور کامل به روز کرده اند و اکنون کار پایدار. ما فقط از آدرس های ip با کیفیت بالا برای بینندگان استفاده می کنیم.این..
Hello everyone! Today, we are announcing a new feature—"Twitch Viewer Configurator". Now, you can customize any plan for your Twitch channel. Choo..
Greetings, I have compiled a guide for streamers, which will be very relevant at the moment. Now YouTube and twitch have disabled monetization from vi..
We have finally developed the APINow it will be more convenient for our partner sites to work with us.To update the maximum tariffs for YouTube, an up..
با توجه به محبوبیت بسیار زیاد خدمات مشارکتی و برنامه ارجاع، جدول همکاری تهیه کرده ایم. ماهیت بسیار ساده است: مخاطبان زنده بیشتر - تبلیغات بیشتر از طرف..
خدمات ما برای استریمرها
Shopee
خدمات ما برای تولیدکنندگان محتوا
