Cloudflare تشرح رياضيات consistent hashing: عند 100 خادم قد يحمل أحدها ضعف نصيبه
القيمة الافتراضية التي توزّع الحمل بعدل هي نفسها التي استهلكت 6 جيجابايت من الذاكرة في خدمة واحدة، ولم يراجعها أحد لأنها افتراضية.
نشرت Cloudflare في 18 سبتمبر 2026 مقالًا بعنوان Saving another 100TB of RAM with math (and Rust)، كتبه Kevin Guthrie وMariia Iurchenko وZaidoon Abd Al Hadi وIvan Babrou. ويتناول خدمة Pingora Backend Router، التي بلغ استهلاكها للذاكرة 6 جيجابايت في بعض الحالات بسبب مكتبة pingora-ketama.
تعتمد المكتبة على consistent hashing، وهي طريقة لتوزيع الطلبات على الخوادم: يُحوَّل كل خادم وكل طلب إلى رقم على دائرة واحدة، ويذهب الطلب إلى أقرب خادم عليها. وميزتها أن إضافة خادم أو إزالته لا تحرك إلا جزءًا صغيرًا من الطلبات.
مشكلة العشوائية
لأن مواقع الخوادم على الدائرة عشوائية، فالمسافات بينها غير متساوية. ويحسب المقال معامل الاختلاف لحصة الخادم الواحد بالصيغة √((N-1)/(N+1))، وعند 100 خادم يبلغ نحو 99%. أي أن خادمًا قد يحمل ضعف ما يُفترض أن يحمله.
والحل المعروف أن يُمنح كل خادم نقاطًا افتراضية متعددة على الدائرة بدل نقطة واحدة، فتتوازن المساحات. والقيمة الافتراضية مثبتة في NGINX على 160 نقطة لكل خادم، وتستخدم Pingora القيمة نفسها، وهذا يخفض معامل الاختلاف من 99% إلى نحو 8%. وتسمح خوارزمية ketama بالأوزان أيضًا: إذا أُريد لخادم أن يحمل w ضعف خادم آخر، يُعطى w ضعف عدد النقاط، وتستخدم Cloudflare مساحة القرص وزنًا.
لكن لكل نقطة ثمن في الذاكرة. ولأن كل تركيبة من الخصائص تحتاج إلى دائرة مستقلة، إذ لا يستطيع كل خادم خدمة كل طلب، تراكمت عشرات الدوائر. ومن الإصلاحات التي يذكرها المقال بنية بيانات اسمها Point من 8 بايت، كان أحد حقليها أوسع من الحاجة.
والمفارقة أن الرقم الذي يضمن عدالة التوزيع هو نفسه ما استهلك الذاكرة، ولم يلتفت إليه أحد لأنه قيمة افتراضية. وهذا النوع من المشكلات يعيش طويلًا: ليس خطأً في الكود، بل اختيارًا اتُّخذ مرة ولم يُراجَع.