تخصيص الوكيل الأقل استخدامًا بشكل ذرّي في Redis

عندما يتشارك عدة عمّال مجموعة وكلاء عبر Redis، يمكن لمجموعة مرتبة أن تنفّذ سياسة بسيطة: اختيار الوكيل المؤهل الذي لديه أقل عدد مسجّل من التخصيصات. خزّن معرّف الوكيل كعضو وعدد تخصيصاته كدرجة.

بالنسبة لمجموعة تخدم طلبات عامة مسموحًا بها، يمكن أن توفّر قائمة الوكلاء المجانية مرشّحي نقاط نهاية لتقييمهم وفق قواعد الأهلية لتلك المجموعة. ابدأ الأعضاء المؤهلين بعدد أولي متفق عليه. ثم اجعل الاختيار والزيادة عملية واحدة على الخادم:

local chosen = redis.call('ZRANGE', KEYS[1], 0, 0)[1]
if not chosen then
    return nil
end

redis.call('ZINCRBY', KEYS[1], 1, chosen)
return chosen

مرّر مفتاح المجموعة المرتبة كوسيط المفتاح الوحيد للنص عبر واجهة EVAL في عميل Redis. تنتج المجموعة الفارغة نتيجة null يجب على التطبيق التعامل معها دون إرسال طلب.

لماذا نجمع الأمرين؟

القراءة والزيادة المنفصلتان تتيحان لعاملين رؤية الحد الأدنى نفسه قبل أن يحدّثه أي منهما. ينفّذ Redis نص Lua بشكل ذرّي، لذا لا يمكن لعامل آخر إدخال اختيار بين قراءة هذا النص وزيادته. أبقِ النص قصيرًا لأن تنفيذه يعطّل أعمال Redis الأخرى.

يعيد ZRANGE أدنى درجة أولًا؛ وتُحسم الدرجات المتساوية بترتيب الأعضاء لا عشوائيًا. يرفع ZINCRBY درجة العضو المختار بواحد للتخصيص التالي.

حدّد معنى الدرجة

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

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

تتطلب سياسة «الأقل تزامنًا» دورة حياة مختلفة، تشمل الإكمال والتعامل مع المهام المهجورة. لا تفسّر هذا العدّاد التراكمي على أنه تلك الدورة.