تعمل Cloudflare على نطاق ضخم لدرجة أنه حتى بعد العمل هنا لسنوات، لا يبدو الأمر حقيقيًا. لدينا آلاف الخوادم في جميع أنحاء العالم ببيتابايت من الذاكرة العشوائية وملايين أنوية المعالجة، وكل ذلك يُستغل إلى أقصى حد. وعلى الرغم من أن هذه الموارد تبدو هائلة، إلا أنها لا تزال محدودة، وعندما تحتاج إلى تشغيل كل خدمة على كل عقدة، فإن ذلك لا يترك مجالًا لإهدار المساحة. على هذا النطاق، تتضخم التحسينات الصغيرة بشكل كبير، لذا حتى التحسينات بنسبة 1% في كل مرة تستحق الاحتفال. وبعض التعديلات تتراكم لتصبح أكثر بكثير: في هذا المقال، سنلقي نظرة على كيف أدت تغييرات صغيرة في خوارزمية واحدة إلى تقليل البصمة الذاكرية لإحدى خدماتنا القائمة على Pingora بشكل كبير. وقد أتاح لنا ذلك استعادة أكثر من 100 تيرابايت من الذاكرة العشوائية عالميًا، بالإضافة إلى 100 تيرابايت من الذاكرة التي تمكن فريق DNS من تحريرها الشهر الماضي.

لا تهدر الحفاظ على توزيع عادل للموارد بين الفرق ليس بالأمر السهل، خاصة في المؤسسات الكبيرة. ومن الطرق التي تضمن بها Cloudflare الحفاظ على التوازن هي الجهود الدؤوبة لفريق Performance الرائع. تبدأ هذه القصة بتذكرة قدمها Ivan وجد فيها: استخدام مفرط للذاكرة من pingora-ketama في Pingora Backend Router. كانت النتيجة أن خدمة موازنة التحميل الداخلية لدينا، Pingora Backend Router (نعم، PBR)، كانت تستخدم ذاكرة أكثر بكثير من المتوقع — وتحديدًا في البنى المرتبطة بـ pingora-ketama، وهي مكتبتنا مفتوحة المصدر للتعامل مع التجزئة المتسقة. لكي نتحدث عن كيفية معالجتنا لهذا الاستخدام المفرط الظاهري للذاكرة، نحتاج إلى الحديث عن ماهية التجزئة المتسقة، ولماذا نستخدمها في PBR، وكيف أصبحت بهذا الشره للذاكرة. وعلى طول الطريق، سنتعلم بعض Rust وحتى القليل من الرياضيات.

التجزئة المتسقة التجزئة المتسقة هي طريقة مستخدمة على نطاق واسع لتوزيع المهام عبر خوادم متعددة بطريقة لا تتطلب تغييرات كبيرة عند إضافة الخوادم أو إزالتها. نستخدمها داخليًا لتوجيه الطلبات القابلة للتخزين المؤقت إلى الخوادم حسب عنوان URL. وهذا يسمح لنا بالاحتفاظ بنسخة واحدة فقط من الملف المخزن لكل مركز بيانات ويوفر طريقة مستقرة للعثور على موقع كل ملف. لقد ذكرنا هذا النظام من قبل، لكن دعونا نأخذ الوقت لشرح كيف ولماذا تُستخدم هذه الخوارزمية وكيف تعمل. المفهوم الأساسي للتجزئة المتسقة هو أنه بينما يمكن لدوال التجزئة قبول أي نوع من المدخلات، فإن مخرجاتها تقتصر على عدد صحيح واحد غير موقع (أعداد صحيحة 32 أو 64 أو 128 بت حسب دالة التجزئة). وهذا يسمح لنا بربط المهام والخوادم ببعضها البعض بطريقة متسقة. معظم المناقشات حول التجزئة المتسقة تجعلك تتصور مساحة المخرجات تلك كحلقة دائرية مستمرة تلتف من قيمتها القصوى إلى الصفر. هذا التصور ينتج بعض الرسوم التوضيحية الجميلة، لكنه قد يجعل أيضًا مفهوم نطاقات الأعداد الصحيحة البسيط يبدو أكثر تعقيدًا مما ينبغي. في مناقشتنا، سنمثل مخرجات دالة التجزئة ذات 32 بت كخط أعداد. الآن، لنفترض أن لدينا مجموعة من الخوادم، A وB وC، ومجموعة من المهام t-z. يمكننا تعيين كل منها على خط الأعداد بناءً على تجزئة قيمها التمثيلية، مثل عناوين IP للخوادم ومفاتيح التخزين المؤقت للمهام. أصبح إسناد المهام إلى الخوادم الآن مجرد مسألة العثور على أول خادم على يسار كل مهمة. يمكننا تمثيل ذلك بصريًا بتلوين منطقة التجزئات التي ستُربط بكل خادم. لاحظ أن النطاق الذي يغطيه الخادم C يلتف إلى البداية، ومن هنا جاءت فكرة أن التجزئات موجودة في حلقة. وهذا كل شيء. على المستوى الأساسي، التجزئة المتسقة بهذه البساطة — لكن لا يستغرق الأمر وقتًا طويلًا لترى أن هناك مجالًا للتحسين. لاحظ أن النطاق الذي يغطيه الخادم A في مثالنا أكبر بكثير من نطاق B أو C. هذه مشكلة لأن نسبة الطلبات التي يتعامل معها الخادم ستكون متناسبة مع حجم نطاقه على خط الأعداد. من الناحية المثالية، نود ضمان أن يكون لكل خادم حجم متساوٍ، ولكن لأن التجزئات هي في الأساس أرقام عشوائية، علينا...