همه‌ی راهنماها
راهنمایی با این جستوجو پیدا نشد.
انتخاب سیاست‌ها
ببینید هر محافظت پاسخ کدام مشکل است، طبقه‌بند شما چگونه شکست را تعریف می‌کند و کدام گزینه‌ها را باید خودتان اندازه بگیرید.
در این صفحه
کتابخانهٔ Reqtide برای مهلت‌ها، محدودیت‌ها، پنجره‌ها و تأخیرها مقدار پیش‌فرض ندارد و این راهنماها هم عددی پیشنهاد نمی‌کنند. مقدار درست به وابستگی، ترافیک و ریسک شما بستگی دارد.
هر بلوک کد در راهنماهای محافظت از examples/09-choosing-policies.php (opens in a new tab) یا مثالی هم‌خانواده با آن گرفته شده است. اسکریپتی آن‌ها را اجرا می‌کند و خروجی را با خروجی ثبت‌شده مقایسه می‌کند. عددها فقط کمک می‌کنند هر محافظت در چند خط دیده شود و توصیه نیستند.
همهٔ محدودیت‌ها داخل یک پردازش PHP اعمال می‌شوند. در PHP-FPM پایپ‌لاینی که داخل یک درخواست ساخته شود، هر درخواست را از نو شروع می‌کند. محدودیت‌های Reqtide را ببینید.
کدام مشکل، کدام سیاست
| مشکل | سیاست | فراخوانی builder | راهنما |
|---|---|---|---|
| یک تماس کند، فراخوانی‌کننده را بیش از حد معطل می‌کند | مهلت کل، به‌علاوهٔ مهلت هر تلاش | متدهای newContext(timeout) و attemptTimeout()، که هر دو الزامی‌اند | مفاهیم |
| خطاهای کوتاه‌مدتی که تلاش دوم ممکن است رفع کند | تلاش مجدد با backoff که از سهمیهٔ تلاش مجدد پرداخت می‌شود | متدهای retry() و retryBudget() | تلاش مجدد و سهمیه |
| نباید از سهمیهٔ ارائه‌دهنده بیشتر مصرف کرد | محدودیت نرخ | متد rateLimit() | محدودیت نرخ |
| یک وابستگی از کار افتاده است و فراخوانی‌کننده‌ها مدام به آن تماس می‌گیرند | مدارشکن | متد circuitBreaker() | مدارشکن |
| یک وابستگی کند تمام کار هم‌زمان پردازش را مصرف می‌کند | سقف اجرای هم‌زمان (Bulkhead) | متد bulkhead() | سقف اجرای هم‌زمان و دورهٔ انتظار |
| سرور گفته است «بعد از N ثانیه دوباره امتحان کن» | رعایت Retry-After به‌عنوان کران پایین، به‌علاوهٔ دورهٔ انتظار مشترک | متدهای ExceptionClassifier::retryAfterFrom() و cooldown() | تلاش مجدد و سهمیه، سقف اجرای هم‌زمان و دورهٔ انتظار |
| وقتی تماس شکست می‌خورد، فراخوانی‌کننده‌ها به چیز قابل‌استفاده‌ای نیاز دارند | راهکار جایگزین (Fallback) | متد fallbackScope() و یک fallback در newContext() | راهکار جایگزین |
فقط برای چیزی که تنظیم کرده‌اید هزینه می‌پردازید. سیاست فقط وقتی وجود دارد که متدش را صدا بزنید.
طبقه‌بند تعیین می‌کند چه چیزی حساب می‌شود
سیاست‌ها روی نتیجهٔ هر تلاش عمل می‌کنند و طبقه‌بند (classifier) شما معنای هر نتیجه را مشخص می‌کند. کلاس ExceptionClassifier محافظه‌کارانه شروع می‌کند:
- مقدار برگشتی موفقیت است.
- استثنا دوباره امتحان نمی‌شود و fallback هم جای آن را نمی‌گیرد، مگر اینکه کلاس آن را با
retryOn()یاfallbackOn()فهرست کنید. - هر استثنا شکست مدار حساب می‌شود. می‌توانید کلاسی را در
ignoreForCircuit()بگذارید، مثلاً خطای اعتبارسنجی خود فراخوانی‌کننده، یا باcountAsCircuitFailure()شکست‌ها را محدود کنید.
متد unacceptableValuesWhen() مقدار برگشتی را شکست علامت می‌زند. چنین مقداری شکست مدار است، هیچ‌وقت دوباره امتحان نمی‌شود و هیچ‌وقت جایگزین نمی‌شود. متد retryAfterFrom() از یک استثنا مدت انتظار را بیرون می‌کشد. جدول تصمیم در docblock کلاس ExceptionClassifier (opens in a new tab) آمده است.
رد شدن‌های ناشی از محدودیت نرخ، مدارشکن، سقف هم‌زمانی و دورهٔ انتظار، لغوها و خطاهای ذخیره‌سازی خنثی‌اند. هیچ‌کدام شکست وابستگی حساب نمی‌شوند.
استثنایی را که کسی فهرست نکرده، Reqtide دوباره امتحان نمی‌کند، چون تکرار یک شکست غیرمنتظره تصمیمی است که باید صریح بگیرید. با این حال آن را شکست مدار می‌شمارد. مداری که شکست‌های ناشناخته را نادیده بگیرد، در برابر وابستگی‌ای که به شکلی پیش‌بینی‌نشده خراب می‌شود بسته می‌ماند. تطبیق با instanceof انجام می‌شود، پس کلاس والد یا interface فهرست‌شده زیرکلاس‌هایش را هم پوشش می‌دهد.
شروع مشترک همهٔ قطعه‌ها
راهنماهای محافظت پایپ‌لاین‌های خود را با دو گزینهٔ الزامی می‌سازند. مهلت هر تلاش الزامی است. مقدار Cooperative یعنی کد شما زمان را رعایت می‌کند، چون runtime همگام نمی‌تواند آن را متوقف کند. مهلت کلی که به newContext() می‌دهید جدا از آن است و کل عملیات را در بر می‌گیرد.
/** Every pipeline below starts from the same two required options. */
$base = static fn(): PipelineBuilder => PipelineBuilder::profile('choosing', 'v1')
->partition('shop', 'prod', 'catalog-api')
->attemptTimeout(Duration::seconds(2), AttemptTimeoutRequirement::Cooperative);
$ok = static fn(): string => 'ok';
$context = static fn(CompiledPipeline $pipeline): ExecutionContext => $pipeline->newContext(Duration::seconds(30));چه چیزی به چه ترتیبی بررسی می‌شود
برای هر تلاش، Reqtide ابتدا مهلت کل و context را بررسی می‌کند. سپس واجد شرایط بودن برای تلاش مجدد، کمینهٔ زمان باقی‌مانده و رزرو سهمیهٔ تلاش مجدد را می‌سنجد. دو بررسی آخر فقط برای تلاش‌های بعد از اولی انجام می‌شود. بعد نوبت مدارشکن، سقف هم‌زمانی، دورهٔ انتظار مشترک و محدودیت نرخ است و سپس ارسال. اگر یکی از بررسی‌های بعدی رد کند، Reqtide مجوزهای قبلی را آزاد می‌کند. در تأخیر بین تلاش‌ها چیزی نگه داشته نمی‌شود. مفاهیم این ترتیب را در یک جدول نشان می‌دهد.
فهرست اندازه‌گیری
ترکیب تنظیم‌ها را Reqtide هنگام کامپایل بررسی می‌کند و پیام‌هایش نام گزینه را می‌گویند. این‌ها قیدهایی است که اعمال می‌کند و مقدار پیشنهادی نیستند.
- هر اجاره (lease) باید بیش از 1 ثانیه از مهلت هر تلاش بیشتر باشد. این شامل اجارهٔ سقف هم‌زمانی، اجارهٔ مجوز مدار و اجارهٔ رزرو سهمیهٔ تلاش مجدد می‌شود.
- متد
retry()با بیش از یک تلاش بهretryBudget()نیاز دارد.retryBudget()بدونretry()پذیرفته نمی‌شود. - کمینهٔ تعداد نمونه‌های مدار نمی‌تواند از پنجرهٔ شمارشی بیشتر باشد. آستانهٔ موفقیت تماس آزمایشی نمی‌تواند از ظرفیت تماس آزمایشی بیشتر باشد.
- گزینهٔ
fallbackScope(IncludeAdmissionRefusals)دست‌کم به یک سیاست پذیرش نیاز دارد.
بقیهٔ موارد تصمیم‌هایی دربارهٔ وابستگی شماست: محدودیت‌ها، پنجره‌ها، تأخیرها و اندازهٔ مخزن‌ها. آن را اندازه بگیرید، مقدارها را یادداشت کنید و پایپ‌لاین را با زمان مجازی آزمون کنید (آزمون با ساعت مجازی).
برای هر محافظت یک راهنما
- تلاش مجدد و سهمیه: تلاش‌ها، backoff، jitter، سهمیهٔ تلاش مجدد و Retry-After.
- محدودیت نرخ: سطل توکن، پنجرهٔ ثابت، شمارندهٔ لغزان و معنای هزینه.
- مدارشکن: پنجره‌ها، آستانه‌ها و تماس‌های آزمایشی.
- سقف اجرای هم‌زمان و دورهٔ انتظار: جای‌های هم‌زمانی، اجاره‌ها و دورهٔ انتظار مشترک.
- راهکار جایگزین: fallback چه چیزی را می‌تواند جایگزین کند و چه چیزی را هیچ‌وقت.
این صفحه مفید بود؟