ForHosting KIT · أدوات المطورين

احسب جدول التراجع الأسي لمحاولات إعادة التنفيذ

تحوّل حاسبة التراجع الأسي هذه أربعة إعدادات لإعادة التنفيذ إلى قائمة دقيقة بفترات التأخير.

● Betaمجاني · داخل متصفحك

استخدمها من الويبAPIالبريدTelegramالتطبيق قريبًا

أدخلوا التأخير السابق للمحاولة الأولى، ومعامل الزيادة، وأقصى تأخير مسموح، وعدد المحاولات. تعرض النتيجة مدة الانتظار قبل كل محاولة بالوحدة الزمنية نفسها التي تقدمونها. تفيدكم في مراجعة الإعدادات، وتوثيق سلوك البرامج العميلة، ومقارنة السياسات، واكتشاف فترات الاستعادة الطويلة على نحو غير متوقع قبل نقل منطق إعادة التنفيذ إلى بيئة الإنتاج.

حدّدوا سياسة إعادة التنفيذ بوحدة زمنية موحدة

ابدؤوا بالتأخير الأساسي، وهو مدة الانتظار قبل محاولة إعادة التنفيذ الأولى. اختاروا وحدة تناسب النظام الذي تضبطونه، مثل المللي ثانية أو الثانية، واستخدموا الوحدة نفسها للتأخير الأقصى. لا تفرض الحاسبة وحدة بعينها لأن حساب التراجع الأسي لا يتغير باختلاف الوحدة. يتحكم المعامل في سرعة نمو التأخير قبل تطبيق الحد. يضاعف المعامل اثنان كل مدة انتظار تالية، بينما ينتج المعامل واحد فاصلًا ثابتًا. ويشير عدد المحاولات إلى محاولات الإعادة، ولا يشمل العملية الأصلية؛ فإذا أدخلتم خمسة، تحصلون على خمسة سجلات مرقمة من واحد إلى خمسة. يمنع توضيح هذا الفرق خطأ شائعًا في العد ضمن أدلة التشغيل ومراجعات الإعداد. يجب أن يكون التأخير الأساسي موجبًا، والمعامل واحدًا على الأقل، والحد الأقصى موجبًا، وعدد المحاولات عددًا صحيحًا من واحد إلى ألف. تحافظ هذه القيود على معنى الجدول وتضع حدًا لحجم المخرجات. إذا كان تطبيقكم يستخدم المللي ثانية، فضعوا هذه الوحدة على النتائج المنسوخة كيلا يفسرها أحد لاحقًا على أنها ثوانٍ.

افهموا النمو وحد التأخير الأقصى

في محاولة إعادة التنفيذ رقم n، يساوي التأخير غير المحدود التأخير الأساسي مضروبًا في المعامل مرفوعًا إلى القوة n ناقص واحد. يكون التأخير الناتج أصغر القيمتين: هذه النتيجة أو التأخير الأقصى. فمثلًا، ينتج عن أساس 250 ومعامل اثنين وحد 2,000 القيم 250 ثم 500 ثم 1,000 ثم 2,000، وتظل القيمة 2,000 في جميع المحاولات اللاحقة. يطبق الحد حتى عندما يكون أقل من التأخير الأساسي؛ ولذلك يعيد أساس مقداره عشرة وحد مقداره ثلاثة القيمة ثلاثة منذ المحاولة الأولى. يحترم هذا السلوك حدًا صارمًا ويظهر الإعدادات غير المعتادة بدل تعديلها خفية. تتقدم الخوارزمية تكراريًا بدل الاعتماد على أس غير محدود، وتتوقف عن النمو عند بلوغ الحد. وهكذا تظل المعاملات الكبيرة جدًا حتمية من دون تسريب قيمة لانهائية إلى نتيجة JSON. لا يتضمن الجدول تفاوتًا عشوائيًا، وذلك مقصود لإظهار السياسة الحتمية الأساسية التي سيغيرها التفاوت، ولجعل النتيجة مناسبة للاختبارات والتوثيق والمقارنة. أضيفوا التفاوت بصورة منفصلة وفق القواعد الدقيقة لمكتبة البرنامج العميل التي تستخدمونها.

طبّقوا الجدول من دون إحداث عاصفة من المحاولات

استخدموا المخرجات لمراجعة الإطار الزمني قبل نشر سياسة إعادة التنفيذ. قد يبدو التأخير الأساسي القصير غير ضار، لكن المعامل المرتفع يوصل المحاولات اللاحقة سريعًا إلى الحد وقد يطيل فترة الاستعادة الإجمالية. قارنوا كل مدة انتظار بمهلة الطلبات، وفترات ظهور الرسائل في الطوابير، وأوقات إعادة ضبط حدود المعدل، وأطول مدة يمكن للمستخدمين قبولها. تعرض الحاسبة الانتظار السابق لمحاولات الإعادة، ولا تشمل مدة الطلب الأصلي أو العمل المنفذ أثناء كل محاولة فاشلة. اجمعوا تلك المدد بصورة منفصلة عند تقدير أسوأ زمن إجمالي. في الأنظمة الموزعة، قد تدفع الجداول الحتمية عددًا كبيرًا من البرامج العميلة إلى إعادة التنفيذ في اللحظة نفسها بعد عطل مشترك. عادةً ما تضيف برامج الإنتاج تفاوتًا عشوائيًا محدودًا لتوزيع الحمل، مع إبقاء الجدول المحسوب حدًا أعلى أو قيمة مركزية. لا تنفذ هذه القدرة طلبات، ولا تنتظر، ولا تتصل بخدمة، ولا تقرر ما إذا كان الخطأ قابلًا لإعادة المحاولة. إنها تحسب الجدول فقط، بلا شبكة أو حالة مخزنة. التنفيذ في المتصفح مجاني، أما الأتمتة عبر API فتكلف $0.002 لكل طلب.

حالات الاستخدام

راجعوا إعدادات إعادة التنفيذ في SDK

حوّلوا المعلمات المقترحة إلى فترات انتظار واضحة قبل اعتماد إعدادات برنامج عميل.

وثّقوا توقيت الاستعادة من الأعطال

أضيفوا جدولًا دقيقًا لكل محاولة إلى دليل التشغيل من دون حساب القوى يدويًا.

اختبروا مولدات الإعدادات

قارنوا السياسات المولدة بجداول حتمية محدودة ضمن اختبارات آلية.

الأسئلة الشائعة

ما الوحدة الزمنية التي تستخدمها الحاسبة؟

تصلح أي وحدة تستخدمونها باتساق. إذا كانت base_delay بالمللي ثانية، تكون كل فترة ناتجة و max_delay بالمللي ثانية أيضًا.

هل يشمل عدد المحاولات الطلب الأصلي؟

لا. إنه عدد محاولات الإعادة بعد الطلب الأصلي، ويحتوي الجدول على هذا العدد نفسه من السجلات.

هل يطبق الحد الأقصى قبل المحاولة الأولى؟

نعم. تخضع كل فترات التأخير للحد، ومنها الأولى، ولذلك يمكن أن تكون max_delay أقل من base_delay.

هل تتضمن النتيجة تفاوتًا عشوائيًا؟

لا. تحسب جدولًا أسيًا حتميًا. طبّقوا التفاوت منفصلًا وفق قواعد البرنامج العميل لديكم.

ماذا يحدث بعد بلوغ الحد؟

يبقى التأخير مساويًا لـ max_delay في تلك المحاولة وجميع المحاولات اللاحقة ضمن الجدول المطلوب.

للمطوّرين — الوصول عبر API

كل ما في هذه الصفحة متاح برمجيًا. هذا القسم موجّه للفرق التقنية التي تريد ربط الأداة بأنظمتها الخاصة؛ بقية المستخدمين يمكنهم استخدام الأداة أعلاه مباشرة دون الحاجة لقراءة ما يلي.

الـEndpoint

POSThttps://api.kit.forhosting.com/dev2/retry-backoff-schedule

صادِق على طلبك بترويسة Bearer، وأرسل طلب POST واحدًا لتدخل مهمتك قائمة التنفيذ فورًا؛ ثم تستلم النتيجة عبر webhook أو رابط موقّع.

استدعِ الخدمة من بيئتك

curl -X POST https://api.kit.forhosting.com/dev2/retry-backoff-schedule \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"base_delay":250,"multiplier":2,"max_delay":8000,"attempts":6}'

const res = await fetch("https://api.kit.forhosting.com/dev2/retry-backoff-schedule", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "base_delay": 250,
    "multiplier": 2,
    "max_delay": 8000,
    "attempts": 6
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/dev2/retry-backoff-schedule",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "base_delay": 250,
    "multiplier": 2,
    "max_delay": 8000,
    "attempts": 6
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev2/retry-backoff-schedule", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"base_delay":250,"multiplier":2,"max_delay":8000,"attempts":6}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"base_delay":250,"multiplier":2,"max_delay":8000,"attempts":6}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev2/retry-backoff-schedule", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

مثال على الطلب

{
  "base_delay": 250,
  "multiplier": 2,
  "max_delay": 8000,
  "attempts": 6
}

مثال على الاستجابة

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev2.retry_backoff_schedule",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

الواجهة غير متزامنة: تستلم task_id فور الإرسال، ويمكنك الاستعلام عن الحالة بمعدل طلب واحد في الثانية.

الأسعار

لكل طلب$0.002

السعر معلن كما تراه: لا tokens ولا نظام نقاط؛ وإن فشلت المهمة فلن تُحاسَب عليها.

الحدود

max_attempts 1000

الأخطاء

HTTP	الرمز	المعنى
`401`	`unauthorized`	مفتاح الوصول مفقود أو غير صالح؛ تحقق من ترويسة Bearer في طلبك.
`402`	`insufficient_balance`	رصيدك لا يكفي لتنفيذ هذه المهمة؛ أعد شحن الرصيد ثم أعد المحاولة.
`404`	`unknown_type`	نوع المهمة المطلوب غير موجود في الكتالوج — راجع الاسم المرسل في الطلب.
`429`	`rate_limited`	تجاوزت الحد المسموح من الطلبات؛ انتظر قليلًا ثم أعد المحاولة.

اطّلع على توثيق KIT الكامل ←