جدول إعادة محاولة webhook
خمس إعادات أسية بقاعدة 1000 تنتظر 1000 و2000 و4000 و8000 و16000، بمجموع 31000: اختر عدد الإعادات والتأخير الأساسي والأسلوب لتحصل على الجدول الكامل مع الانتظار التراكمي. مجاني في متصفحك.
- مجاني
- يعمل في متصفحك
- دون تسجيل
- بياناتك لا تغادر جهازك
شغّل الأداة مجانًا
مثال محلول
- الحد الأقصى لإعادة المحاولة
- 5
- التأخير الأساسي
- 1,000
- الاستراتيجية
- Exponential
- التأخيرات
- 1,000, 2,000, 4,000, 8,000, 16,000
- إجمالي الانتظار
- 31,000
- عدد المحاولات
- 5
تراجع ثابت وخطي وأسي
لماذا ينبغي تدوين خطة إعادة المحاولة
عندما يفشل إشعار حدث، ينتظر النظام المرسل ثم يحاول من جديد. ويحتاج من يسلّم هذه الإشعارات ومن يستقبلها إلى قائمة صريحة بفترات الانتظار قبل كل محاولة، لا إلى وعد غامض بأن التراجع سيحدث في مكان ما. ومن دون جدول منشور لا يستطيع فريق التشغيل تقدير أسوأ تأخير في التسليم، ولا تعيد محاكاة الأحمال إنتاج الفواصل الدقيقة التي ستضيفها بيئة الإنتاج بين المحاولات. تأخذ هذه الأداة الحد الأقصى لعدد الإعادات وتأخيرًا أساسيًا أكبر من صفر وأسلوبًا، وتعيد تأخير كل محاولة والانتظار التراكمي وصيغة قصيرة يمكنك الاحتفاظ بها بجانب لوحة المتابعة أو في دليل التشغيل.
ثابت أم خطي أم أسي، والخطأ الشائع
يحافظ التراجع الثابت على التأخير الأساسي نفسه في كل محاولة، فهو سهل الفهم ورفيق بالجهات المستقبلة التي لا تحتاج إلا إلى استراحة قصيرة. ويضرب التراجع الخطي الأساس في رقم المحاولة بدءًا من واحد، فتنتظر المحاولات المتأخرة أطول بشكل متناسب دون أن تنمو بسرعة الأسي. أما الأسي فيضاعف في كل مرة: خمس إعادات من 1000 تعطي 1000 و2000 و4000 و8000 و16000، بمجموع 31000. والخطأ الشائع هو تأخير أساسي صفري أو سالب يجعل الطابور يدور بلا توقف، ولذلك يُرفض فورًا. واحرص على أن تكون كل فترات التأخير بوحدة واحدة، وهي عادةً الملّي ثانية.
الأسئلة الشائعة
هل يتضمن الجدول jitter عشوائياً؟
طبّقوا jitter الخاص بكم فوق ذلك إن احتجتم انتشاراً بين العمال.
كم يبلغ مجموع الانتظار مع خمس إعادات أسية؟
مع تأخير أساسي قدره 1000 تكون فترات الانتظار 1000 و2000 و4000 و8000 و16000، ويبلغ الانتظار التراكمي 31000 قبل المحاولة الخامسة. وتُستخدم الوحدة نفسها التي اخترتها، وهي عادةً الملّي ثانية.
ما الفرق بين التراجع الثابت والخطي والأسي؟
الثابت ينتظر التأخير الأساسي نفسه قبل كل محاولة. والخطي يضرب الأساس في رقم المحاولة بدءًا من واحد. أما الأسي فيضاعف الانتظار في كل مرة، أي الأساس مضروبًا في اثنين أس رقم المحاولة ناقص واحد.
ما الوحدة التي ينبغي استخدامها للتأخير الأساسي؟
أي وحدة تفضّلها ما دامت كل فترات التأخير تستخدمها، والمعتاد هو الملّي ثانية. ويجب أن يكون الأساس أكبر من صفر، لأن الانتظار الصفري أو السالب يجعل الطابور يعيد المحاولة بلا توقف، لذا تُرفض هذه القيم.
كم عدد الإعادات التي يمكن التخطيط لها؟
من 1 إلى 100. وتحصل كل محاولة على تأخير واحد قبل انطلاقها، ويعرض الجدول رقم المحاولة وتأخيرها والانتظار التراكمي حتى تلك اللحظة، فيسهل معرفة أسوأ زمن للتسليم.
أدوات ذات صلة
للمطوّرين — الوصول عبر API
كل ما في هذه الصفحة متاح برمجيًا. هذا القسم موجّه للفرق التقنية التي تريد ربط الأداة بأنظمتها الخاصة؛ بقية المستخدمين يمكنهم استخدام الأداة أعلاه مباشرة دون الحاجة لقراءة ما يلي.
الـEndpoint
صادِق على طلبك بترويسة Bearer، وأرسل طلب POST واحدًا لتدخل مهمتك قائمة التنفيذ فورًا؛ ثم تستلم النتيجة عبر webhook أو رابط موقّع.
استدعِ الخدمة من بيئتك
curl -X POST https://api.kit.forhosting.com/dev/webhook-retry-schedule-build \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"max_retries":5,"base_delay":1000,"strategy":"exponential"}'const res = await fetch("https://api.kit.forhosting.com/dev/webhook-retry-schedule-build", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"max_retries": 5,
"base_delay": 1000,
"strategy": "exponential"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/webhook-retry-schedule-build",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"max_retries": 5,
"base_delay": 1000,
"strategy": "exponential"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/webhook-retry-schedule-build", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"max_retries":5,"base_delay":1000,"strategy":"exponential"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"max_retries":5,"base_delay":1000,"strategy":"exponential"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/webhook-retry-schedule-build", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)مثال على الطلب
{
"max_retries": 5,
"base_delay": 1000,
"strategy": "exponential"
}مثال على الاستجابة
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.webhook_retry_schedule_build",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}الواجهة غير متزامنة: تستلم task_id فور الإرسال، ويمكنك الاستعلام عن الحالة بمعدل طلب واحد في الثانية.
الأسعار
السعر معلن كما تراه: لا tokens ولا نظام نقاط؛ وإن فشلت المهمة فلن تُحاسَب عليها.
الأخطاء
| HTTP | الرمز | المعنى |
|---|---|---|
401 | unauthorized | مفتاح الوصول مفقود أو غير صالح؛ تحقق من ترويسة Bearer في طلبك. |
402 | insufficient_balance | رصيدك لا يكفي لتنفيذ هذه المهمة؛ أعد شحن الرصيد ثم أعد المحاولة. |
404 | unknown_type | نوع المهمة المطلوب غير موجود في الكتالوج — راجع الاسم المرسل في الطلب. |
429 | rate_limited | تجاوزت الحد المسموح من الطلبات؛ انتظر قليلًا ثم أعد المحاولة. |
ملاحظات تقنية
تحتاج مستقبلات الـ webhook وعمال التسليم إلى قائمة صريحة بأوقات الانتظار قبل كل إعادة محاولة، لا إلى وعد غامض بأن التراجع سيُطبَّق في مكان ما من المكدس. يأخذ منشئ جدول إعادة محاولة تسليم الـ webhook هذا حداً أقصى لعدد المحاولات، وتأخيراً أساسياً موجباً بصرامة، واستراتيجية ثابتة أو خطية أو أسية، ثم يعيد التأخيرات لكل محاولة والانتظار التراكمي وصيغة قصيرة يمكنكم تثبيتها في الاختبارات أو عرضها بجانب لوحة متابعة. تعمل المنطق نفسه النقي مجاناً في المتصفح وعبر واجهة API، بحيث يطابق تخطيط سلم أسي بخمس إعادة محاولات دون اتصال ما سيستخدمه عاملكم الطرفي عند ضبط مسارات الإشعار أو حلقات التسليم المخصصة. تفشل التأخيرات الأساسية غير الصالحة فوراً بـ invalid_input بدل اختراع انتظار صفري أو سالب قد يُشغّل الطابور في حلقة مشغولة.
ما جدول إعادة محاولة الـ webhook وكيف تختلف الاستراتيجيات الثلاث
من دون جدول منشور لا يستطيع المشغّلون تقدير زمن التسليم في أسوأ الحالات، ولا تستطيع اختبارات الحمل إعادة إنتاج الفجوات الدقيقة التي يدرجها عامل الإنتاج بين إعادة المحاولات. يحافظ التراجع الثابت على التأخير الأساسي نفسه في كل محاولة: سهل الفهم ولطيف مع الأنظمة اللاحقة التي تحتاج فقط فترة تبريد قصيرة. يضرب التراجع الخطي التأخير الأساسي في رقم المحاولة (من واحد)، فتنتظر إعادة المحاولات اللاحقة زمناً أطول بنسبة دون أن تنفجر بسرعة النمو الأسي الخالص. ولأن الخوارزمية حساب صرف بلا ساعة حائط ولا عشوائية، ينتج طلبان متطابقان دائماً جداول مستقرة بايتياً تصلح للاختبارات الذهبية وللعمال متعددي المناطق الذين يجب أن يتفقوا دون تنسيق حالة. جدول إعادة محاولة تسليم الـ webhook هو القائمة المرتبة للتأخيرات التي تنتظرونها قبل المحاولة الأولى ثم الثانية وهكذا بعد POST فاشل إلى عنوان URL للمشترك. ترمّز هذه القدرة ثلاث عائلات شائعة من التراجع مستخدمة في حافلات الرسائل وعملاء HTTP. يضاعف التراجع الأسي التأخير السابق في كل مرة باستخدام base_delay مضروباً في اثنين مرفوعاً إلى (رقم المحاولة ناقص واحد)، وهو النمط الكلاسيكي لأعطال الشبكة العابرة وحدود المعدّل. تقدّمون max_retries بعدد خانات إعادة المحاولة المراد تجسيدها، وbase_delay كبذرة موجبة بالوحدة التي تختارونها (غالباً بالمللي ثانية)، وstrategy كواحدة من fixed أو linear أو exponential. تعيد الاستجابة تلك المدخلات، وتسرد التأخيرات بالترتيب، وتجمعها في total_wait، وتوسّع مصفوفة schedule برقم المحاولة والتأخير والانتظار التراكمي حتى لا تحتاج مخططات الواجهة ومولّدات الإعداد إلى حساب إضافي.
عقد الإدخال وشكل الاستجابة ومتى تفشل التحقق
يجب أن تكون strategy السلسلة fixed أو linear أو exponential (بدون تمييز حالة الأحرف بعد القص). أرسلوا عبر POST جسماً JSON بثلاثة حقول إلزامية. max_retries عدد صحيح من واحد إلى مئة يحدّد كم إعادة محاولة يجب جدولتها. base_delay عدد منتهٍ أكبر من الصفر بصرامة بأي وحدة متسقة؛ تُرفض الصفر والقيم السالبة لأن الانتظار غير الموجب إما يدوّر بشكل مشغول أو لا معنى له للجدولة. تُقبل أسماء بديلة مثل retries وbase_ms وbackoff حتى تتوافق أشكال الإعداد القائمة بسلاسة. الحقول الناقصة وmax_retries غير الصحيحة وbase_delay غير المنتهي والاستراتيجيات المجهولة ترفع invalid_input ولا تُفوتر. عند النجاح يتضمن الجسم max_retries وbase_delay وstrategy وdelays كمصفوفة مسطحة وtotal_wait كمجموع التأخيرات وattempt_count مساوياً لـ max_retries وschedule ككائنات فيها attempt وdelay وcumulative وformula التي تعيد الصيغة المغلقة للاستراتيجية المختارة. مثال: max_retries خمسة، base_delay ألف، strategy exponential يعطي تأخيرات ألف وألفين وأربعة آلاف وثمانية آلاف وستة عشر ألفاً مع total_wait واحد وثلاثين ألفاً. اقرنوا الجدول بسياسة jitter الخاصة بكم إن احتجتم انتشاراً عشوائياً؛ يحذف هذا الطرف عمداً الـ jitter والطوابع الزمنية لساعة الحائط حتى تبقى النتائج حتمية بين المتصفح وAPI. سقف max_retries مئة حتى لا يوسّع خطأ مطبعي الحمولة إلى حجم هائل أو يفيض نواتج وسيطة على سلالم أسية كبيرة.
أين يُثبت بناء جدول إعادة المحاولة قيمته في الأنظمة الحقيقية
تحقن منصّات اختبار الحمل مصفوفة التأخير نفسها التي يستخدمها عامل الإنتاج، فتلغي الفجوة الكلاسيكية حيث يعيد الاختبار المرحلي المحاولة أسرع من الإنتاج ويخفي أخطاء حد المعدّل. يمكن لمنصات التسليم التي تعرض إعدادات موثوقية الـ webhook استدعاء هذا المنشئ عندما يختار المشغّل الحد الأقصى لإعادة المحاولات ووضع التراجع، ثم تخزين التأخيرات الناتجة بجانب سرّ الطرف ومفتاح التوقيع. تستفيد كتيبات الحوادث من total_wait قابل للطباعة حتى يعرف فريق المناوبة كم قد يتأخر مشترك غير مستقر قبل المحاولة الأخيرة. يمكن لمولّدات OpenAPI وSDK توثيق سلالم أمثلة ملموسة دون صيانة يدوية لجداول تنحرف عن شيفرة التشغيل. ولأن التنفيذ parse خالص من المستوى A، يكلّف كل استدعاء ناجح السعر الأساسي المنشور $0.002 بلا رموز نموذج ولا شبكة صادرة؛ التحقق الفاشل لا يستهلك الرصيد. استخدموا أداة المتصفح المجانية لمعاينة الجداول في مراجعات التصميم، ثم انتقلوا إلى API من CI للتأكد من أن ملف الإعداد ما زال يتوسع إلى التأخيرات الذهبية التي ثبّتموها في التحكم بالمصدر. أبقوا base_delay وtotal_wait في نفس وحدة بدائيات sleep لديكم حتى لا تحوّلوا المللي ثانية إلى ثوانٍ بالخطأ عند ربط الجدول في حلقة عامل.
حالات التكامل
ضبط تراجع تسليم الـ webhook في لوحة التحكم
اسمحوا للمشغّلين باختيار الحد الأقصى لإعادة المحاولات واستراتيجية ثابتة أو خطية أو أسية، ثم حفظ قائمة التأخير المحسوبة بجانب كل طرف مشترك.
توثيق زمن التسليم في أسوأ الحالات
اعرضوا total_wait والتأخيرات التراكمية لكل محاولة في كتيبات التشغيل حتى يعرف فريق المناوبة كم قد تستغرق إعادة المحاولات قبل dead-letter.
تثبيت جداول ذهبية في CI
أكدوا أن ملفات الإعداد تتوسع إلى مصفوفات التأخير نفسها لعمال الإنتاج، فالتقطوا انحدارات strategy أو base_delay العرضية.
أسئلة تقنية
كيف أبني جدول إعادة محاولة تسليم webhook؟
أرسلوا max_retries (1–100) وbase_delay موجباً وstrategy بقيمة fixed أو linear أو exponential. تعيد API التأخيرات المرتبة وtotal_wait وجدولاً بانتظار تراكمي لكل محاولة.
ما الفرق بين التراجع الثابت والخطي والأسي؟
الثابت يكرر base_delay في كل محاولة. الخطي يستخدم base_delay مضروباً في رقم المحاولة. الأسي يستخدم base_delay مضروباً في اثنين مرفوعاً إلى (رقم المحاولة ناقص واحد).
لماذا يجب أن يكون base_delay موجباً؟
التأخيرات الصفرية أو السالبة لا تعرّف انتظاراً مفيداً قبل إعادة المحاولة وتخاطر بحلقة مشغولة لعامل التسليم. base_delay غير الموجب يفشل بـ invalid_input ولا يُفوتر.
كم يكلّف بناء جدول إعادة محاولة webhook؟
أداة المتصفح مجانية. طلبات API تستخدم رصيد KIT المدفوع مسبقاً بمبلغ $0.002 لكل استدعاء ناجح؛ الإدخال غير الصالح لا يُفوتر.