كيف يحوّل توزيع hash slots في Redis cluster أمر MGET واحدًا إلى مئات النداءات
بعض مشكلات الأداء ليست ضبطًا ناقصًا بل عيب توزيع موجود منذ السطر الأول، ولا يظهر إلا حين يكبر حجم الاستخدام.
نشر مطور في 22 سبتمبر 2026 مقالًا بعنوان Why didn’t anybody tell me about Redis hash slots، يشرح فيه مشكلة واجهها: أمر MGET واحد على آلاف المفاتيح، يظهر في أدوات التتبع كمئات النداءات المنفصلة، كل منها يحمل مفتاحًا واحدًا.
السبب هو آلية اسمها hash slots. فـ Redis cluster يقسّم البيانات على 16,384 خانة (slot). ولتحديد خانة أي مفتاح، يحسب Redis قيمة CRC16 للمفتاح ثم يأخذ باقي قسمتها على 16,384.
وهنا تكمن المشكلة. فالأوامر التي تعمل على أكثر من مفتاح، مثل MGET وMSET، لا تصلح إلا إذا وقعت كل المفاتيح في الخانة نفسها. واختلاف حرف واحد بين مفتاحين قد يرسلهما إلى خانتين مختلفتين تمامًا.
كانت مفاتيح صاحب المقال بصيغة origin:dest:resolution، وكل مفتاح يحمل معرّفات مختلفة، فانتهى كل مفتاح تقريبًا في خانة مستقلة. وهكذا اضطرت المكتبة إلى تقسيم أمر MGET الواحد إلى رحلة ذهاب وعودة لكل خانة.
والحل موجود في Redis نفسه، واسمه hash tags. فإذا وُضع جزء من المفتاح بين أقواس معقوفة، يحسب Redis الـ hash على ما بين الأقواس فقط ويتجاهل الباقي. فصارت المفاتيح عنده بصيغة {routing:v1:N}، حيث يُحدَّد الرقم N مرة واحدة عند التشغيل بحيث يقع كل رقم على node مختلف.
والدرس الأعم أن ما حدث ليس مسألة ضبط أداء. إنه عيب في توزيع البيانات كان موجودًا منذ التصميم الأول، ولم يظهر إلا حين كبر حجم الاستخدام. وهذا النوع من العيوب لا تكشفه بيئة التطوير عادة، لأن حجم البيانات فيها صغير.