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