مرحبًا لقد صادفت مؤخرًا وصفًا مثيرًا للاهتمام إلى حد ما لهندسة Pusher Channels وقررت ترجمته لك. في رأيي ، وصف المؤلف بسهولة شديدة الأساليب لبناء بنية محملة للغاية وقابلة للتطوير. على الأرجح ، ستكون المقالة مفيدة للمبتدئين ، وكذلك المتخصصين من المجالات ذات الصلة.
في مكتب Pusher ، لدينا عداد صغير مع عدد متزايد باستمرار. يعرض عدد الرسائل التي تم تسليمها لكامل قنوات الدفع. يوم الجمعة الساعة 22:20 بالتوقيت العالمي ، زاد العدد بفئة واحدة ووصل إلى 10.000.000.000.000. لديها 13 أصفار - 10 تريليون.
قد تعتقد أن إجمالي عدد الرسائل هو مقياس منتفخ عديم الفائدة. لكن هذا الرقم هو مؤشر رئيسي لنجاح Pusher Channels ، منتج الاتصال في الوقت الفعلي. أولاً ، يعكس هذا العداد الثقة التي منحنا إياها المستخدمون. ثانيًا ، يقيس قابلية نظامنا للتوسع. من أجل زيادة العدد ، يجب علينا في Pusher التأكد من أن المستخدمين يثقون في إرسال الرسائل إلى خدمتنا ، ويجب أن نتأكد من أن نظامنا قادر على معالجة هذه الرسائل. لكن ماذا يجب أن نقدم 10 تريليون رسالة؟ دعنا نرى.
يتم إرسال حوالي 200000 رسالة في الثانية من خلال قنوات الدفع ، والملايين في أوقات الذروة. على سبيل المثال ، عندما استخدمت صحيفة "نيويورك تايمز" الخدمة لإبقاء قرائها على علم بالتقدم المحرز في الانتخابات الرئاسية الأمريكية.
دعونا ننظر أولاً إلى Pusher Channels كمربع أسود كبير تمر من خلاله جميع هذه الرسائل:
Pusher Channels هو نظام من نوع النشر والاشتراك. يشترك العملاء في القنوات (على سبيل المثال ، "btc-usd" أو "private-user-jim") ، بينما يرسل عملاء آخرون رسائل إليهم. إذا كان هناك مليون شخص مشتركين في قناة "btc-usd" وأرسل شخص التكلفة الفعلية للبيتكوين هناك ، فإن قنوات Pusher ستحتاج إلى توصيل مليون رسالة. نقوم بذلك في غضون بضع ثوان.
لا يمكن لخادم واحد تسليم الكثير من رسائل الرسائل في مثل هذا الوقت القصير. لذلك ، نستخدم ثلاث تقنيات تم اختبارها بمرور الوقت: خروج المروحة ، والتجزئة ، وموازنة الحمل. دعونا نرى ما في الصندوق الأسود.
يتم توزيع ملايين المشتركين عبر ما يقرب من 170 خادمًا قويًا ، يحتوي كل منها على ما يقرب من 20000 اتصال. يتذكر كل خادم من هذا القبيل قائمة القنوات التي تهم عملاءه ويشترك فيها في خدمة Redis المركزية. حتى إذا كان 2000 عميل مهتمًا بـ "btc-usd" على خادم الحافة ، فإنه يحتاج إلى الاشتراك فيه مرة واحدة فقط. وهكذا ، عندما تصل رسالة جديدة إلى القناة ، يرسل Redis 170 رسالة إلى خوادم الحافة ، والتي ترسل بالفعل 20000 رسالة إلى المشتركين فيها. يُسمى هذا النهج بالمروحة.
ولكن مجرد الاكتفاء ليس كافياً بالنسبة لنا ، لأنه لا يزال هناك مكون مركزي واحد لـ Redis يذهب من خلاله كل من يرسل الرسائل. يحد هذا المركزية من عدد الرسائل المرسلة في الثانية. للتغلب على هذا القيد ، تتكون خدمة Redis المركزية من العديد من أجزاء Redis. وترتبط كل قناة بدورها بـ Redis-shard بتجزئة اسمها. عندما يريد العميل إرسال رسالة ، يذهب إلى الخدمة المتبقية. تقوم الأخيرة بتجزئة اسم القناة ، وبناءً على النتيجة ، تحدد الجزء الضروري من Redis الذي يجب إرسال الرسالة إليه. يسمى هذا النهج تقسيم.
يبدو أننا نحول المركزية فقط من خدمة Redis إلى خدمة الراحة. لكن الأمر ليس كذلك ، لأن بقية الخدمة نفسها تتكون من حوالي 90 خادمًا تؤدي نفس العمل: فهي تتلقى طلبات للنشر ، وتحسب Redis-shards وترسل الرسائل إليها. عندما يريد الناشر إرسال رسالة ، يذهب إلى أحد خوادم الراحة العديدة. يسمى هذا الأسلوب موازنة التحميل.
تسمح كل من التهوية والتجزئ وموازنة الحمل للنظام بأن يكون له مكون مركزي واحد. هذه الخاصية هي مفتاح تحقيق قابلية التوسع الأفقية ، والتي تسمح بإرسال ملايين الرسائل في الثانية.
لقد فحصنا المكونات المركزية لخدمة Pusher Channels ، ولكن هناك أجزاء أخرى ، مثل المقاييس (كيف نحصل على هذا الرقم البالغ 10 تريليون دولار) ، والبريد الإلكتروني (كيف نبلغ العملاء عن الأحداث المثيرة للاهتمام) ، والتفويض (تقييد الوصول إلى القنوات) ، والبيانات عن النشطة المستخدمين ، تحديد المعدل (كيف نتأكد من أن عملائنا يستخدمون العديد من الموارد التي دفعوا مقابلها بالضبط ، وأنهم لا يتدخلون مع العملاء الآخرين). يجب تنفيذ كل هذه الوظائف الإضافية دون التضحية بالنطاق الترددي ووقت تسليم الرسالة وتوافر خدمتنا ككل.