صف ارسال و قطعی شبکه
رویدادها هنگام قطعی در صف میمانند، قطعی هرگز باعث کنار گذاشتن رویداد نمی‌شود و رویدادهای قدیمی نجات داده میشوند.
پاسخ کوتاه
هر رویداد پیش از ارسال در صفی روی خود رایانه ذخیره میشود و تنها پس از تأیید سرور از صف برمی‌خیزد. قطعی اینترنت یا خرابی سرور ابری هرگز رویدادی را کنار نمی‌گذارد؛ فقط رویدادی که سرور صریحاً «نمی‌پذیرم» بگوید، پس از چند ده بار تلاش جداگانه کنار گذاشته میشود.
این صف همان عدد «صف ارسال: N رویداد» در کادر «سرور ابری» است و فایلش در پوشهٔ داده برنامه (Data) نگه‌داری میشود، پس بستن برنامه یا خاموشی رایانه رویدادها را از بین نمی‌برد.
هنگام قطعی چه میشود
- ▸قطع اینترنت، پاسخ ندادن سرور، خطاهای ۵۰۲/۵۰۳/۵۰۴ هنگام ری‌استارت سرور، خرابی پایگاه داده‌ی سرور، کلید باطل‌شده یا محدودیت نرخ، همه «قطعی» حساب میشوند.
- ▸در قطعی، برنامه تکرار می‌کند ولی هر بار صبر بیشتری می‌کند: ۱، ۲، ۴، ۸، ۱۶ و سپس هر ۳۰ ثانیه (سقف انتظار ۳۰ ثانیه).
- ▸قطعی هر قدر هم طولانی باشد، هیچ رویدادی کنار گذاشته نمی‌شود؛ پس از وصل شدن، صف در دسته‌های ۲۰تایی پشت‌سرهم خالی میشود.
- ▸هر دقیقه یک «علامت حضور» هم برای ابر میرود؛ همان است که وضعیت آنلاین/تأخیر/آفلاین شعبه را در داشبورد می‌سازد.
رویداد مشکل‌دار (رد شده توسط سرور)
اگر سرور اعلام کند خودِ محتوای یک رویداد را نمی‌پذیرد (پاسخ‌های ۴۰۰، ۴۱۳، ۴۲۲ یا خطای «project …» از سمت سرور)، فقط همین رویداد شمرده میشود:
- ▸پس از ۵ رد شدن پیاپی، آن رویداد تنها (بدون هم‌دسته) فرستاده میشود تا رویدادهای سالم همراهش آسیب نبینند.
- ▸پس از ۲۵ رد شدن، رویداد در فایل cloud-deadletter.json در پوشهٔ داده کنار گذاشته میشود تا بقیهٔ صف پشت آن نماند.
- ▸رویداد کنارگذاشته‌شده فروش را از بین نمی‌برد؛ فقط آن یک نسخهٔ ابری ثبت نشده است.
نجات رویدادهای قدیمی
نسخه‌های قدیمی‌تر اشتباهاً هر قطعی بیش از حدود ۲۵ ثانیه را «رد شدن» می‌شمردند و قدیمی‌ترین رویدادهای ارسال‌نشده را در cloud-deadletter.json کنار می‌گذاشتند. نسخهٔ فعلی هر بار که اتصال ابری برقرار میشود آن فایل را بررسی می‌کند: رویدادهایی که علتشان قطعی بوده به ابتدای صف و به ترتیب اصلی برمی‌گردند (با همان شناسه، پس سرور تکراری‌ها را نادیده می‌گیرد) و رویدادهای واقعاً رد‌شده در فایل میمانند.
اینترنت شعبه از ساعت ۲۰:۰۰ تا ۲۲:۳۰ قطع بوده و در این مدت ۳۴۰ رویداد (فاکتور، پرداخت، حرکت انبار) ثبت شده است.
- ۲۰:۰۰ تا ۲۲:۳۰
- نوار وضعیت «متصل نیست»؛ «صف ارسال» تا ۳۴۰ بالا میرود؛ فروش عادی ادامه دارد
- وضعیت شعبه در داشبورد
- پس از ۳ دقیقه «تأخیر» و پس از ۳۰ دقیقه «آفلاین»
- ۲۲:۳۰ (اینترنت برگشت)
- حداکثر ۳۰ ثانیه بعد تلاش بعدی موفق میشود
- دقایق بعد
- صف در دسته‌های ۲۰تایی (حدود ۱۷ دسته) تخلیه و «صف ارسال» صفر میشود
- نتیجه
- هر ۳۴۰ رویداد در داشبورد با زمان ثبت اصلی‌شان هستند؛ هیچ ورودی دستی لازم نیست
شمارش دسته‌ها: ۳۴۰ ÷ ۲۰ = ۱۷ دسته. ابر هر رکورد را با شناسه‌اش به‌روز می‌کند، پس رویداد دوباره‌ارسال‌شده تکراری ثبت نمی‌شود.
اگر … شد
- ▸در «لاگ خام سیستم» (صفحهٔ «لاگ سیستم») خطوط «cloud: push … events: …» علت آخرین شکست را می‌گویند؛ خط «cloud: requeued N events parked during an earlier outage» یعنی N رویداد قدیمی نجات یافتند.
- ▸فایل cloud-deadletter.json پر است و عدد آن کم نمی‌شود: یعنی سرور آن رویدادها را رد کرده است؛ ساده‌ترین راه، «⬆ ارسال همه» برای بازسازی رکوردهاست.
- ▸پس از یک نسخهٔ جدید صف مدتی بزرگ است: همگام‌سازی خودکار پس از به‌روزرسانی.
پرسش‌های متداول
؟اگر چند روز اینترنت نباشد، فروشها از دست میروند؟
نه. رویدادها روی دیسک رایانهٔ صندوق در صف میمانند و هر مدت که قطعی باشد کنار گذاشته نمیشوند. پس از وصل شدن به ترتیب ارسال میشوند.
؟cloud-deadletter.json چیست و باید پاکش کنم؟
محل رویدادهایی است که سرور آنها را صریحاً نپذیرفته. لازم نیست پاک کنید؛ و اگر برنامه رویدادی را بهاشتباه بهخاطر قطعی آنجا گذاشته باشد، در اتصال بعدی خودکار به صف برمیگرداند.
؟چرا شعبه در داشبورد آفلاین است ولی عدد صف کوچک است؟
علامت حضور هر دقیقه میرود؛ اگر ۳۰ دقیقه نرسیده باشد شعبه «آفلاین» میشود، حتی اگر در این مدت فروشی نبوده و صف خالی باشد. اینترنت و «متصل به سرور ابری» بودن را بررسی کنید.