👵 📷 🍠 كيف اخترنا في Sportmaster نظام التخزين المؤقت. الجزء الأول 👼🏻 😀 👩🏿‍🤝‍👩🏼

مرحبا! اسمي أليكسي بيانكوف ، وأنا مطور في Sportmaster. في هذا المنشور ، تحدثت عن كيف بدأ العمل على موقع Sportmaster على الويب في عام 2012 ، وما هي المبادرات التي تمكنا من دفعها ، والعكس صحيح ، أي أشعل النار جمعنا.

اليوم أريد أن أشارك الأفكار التي تتبع قصة أخرى - اختيار نظام التخزين المؤقت لواجهة جافا الخلفية في لوحة الإدارة بالموقع. هذه المؤامرة ذات أهمية خاصة بالنسبة لي - على الرغم من أن القصة حدثت لمدة شهرين فقط ، ولكن في هذه الأيام 60 عملنا لمدة 12-16 ساعة وبدون يوم عطلة. لم أفكر أبدًا وتخيلت أنه يمكنك العمل كثيرًا.

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

عندما تم إطلاق الإصدار الجديد من موقع Sportmaster في الإنتاج ، جاءت البيانات بطريقة ما ، بشكل معتدل ، وليس مناسبًا للغاية. كان الأساس هو الجداول التي تم إعدادها للإصدار السابق من الموقع (Bitrix) ، والتي كان يجب تشديدها في ETL ، وأضفت إلى مظهر جديد وثراء بأشياء صغيرة مختلفة من اثني عشر نظامًا آخر. من أجل ظهور صورة أو وصف منتج جديد على الموقع ، كان عليك الانتظار حتى اليوم التالي - التحديث فقط في الليل ، مرة واحدة في اليوم.

في البداية ، كان هناك الكثير من المخاوف من الأسابيع الأولى لبدء الإنتاج لدرجة أن مثل هذه المضايقات لمديري المحتوى كانت تافهة. ولكن ، بمجرد أن استقر كل شيء ، استمر تطوير المشروع - بعد بضعة أشهر ، في بداية عام 2015 ، بدأنا في تطوير لوحة الإدارة بنشاط. في عامي 2015 و 2016 ، كل شيء يسير على ما يرام ، وسنقوم بإصداره بانتظام ، وتغطي المنطقة الإدارية الجزء الأكبر من إعداد البيانات ، ونحن نستعد لحقيقة أن فريقنا سيتم تكليفه قريبًا بأهم شيء وأكثره تعقيدًا - دائرة السلع (التحضير الكامل وصيانة البيانات لجميع السلع). ولكن في صيف عام 2017 ، قبل إطلاق خط الإنتاج مباشرة ، سيكون المشروع في وضع صعب للغاية - على وجه التحديد بسبب مشكلات التخزين المؤقت. أريد أن أتحدث عن هذه الحلقة في الجزء الثاني من هذا المنشور المكون من جزأين.

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

عندما تنشأ مهمة ذاكرة التخزين المؤقت

لا تظهر مهمة التخزين المؤقت فقط. نحن مطورين ونكتب منتج برمجيات ونريده أن يكون مطلوبًا. إذا كان المنتج مطلوبًا وناجحًا ، يصل المستخدمون. ويأتي المزيد والمزيد. وبالتالي هناك الكثير من المستخدمين ومن ثم يصبح المنتج محملاً للغاية.

في المراحل الأولى ، لا نفكر في التحسين وأداء الشفرة. الشيء الرئيسي هو الوظيفة ، طرح الفرضيات التجريبية والاختبارية بسرعة. وإذا نما الحمل ، نقوم بضخ الحديد. نزيدها بعامل اثنين ، ثلاثة ، خمسة ، فليكن 10 مرات. في مكان ما هنا - لن يسمح التمويل بعد الآن. وكم مرة سيزداد عدد المستخدمين؟ لن تكون 2-5-10 فقط ، ولكن إذا نجحت ، فستكون من 100-1000 وتصل إلى 100 ألف مرة. هذا ، عاجلاً أم آجلاً ، ولكن يجب أن يتم التحسين.

لنفترض أن جزءًا من الشفرة (لنطلق على هذا الجزء وظيفة) يعمل بشكل غير لائق لفترة طويلة ، ونريد تقليل وقت التنفيذ. الوظيفة - يمكن الوصول إلى قاعدة البيانات ، يمكن أن يكون تنفيذ بعض المنطق المعقد - الشيء الرئيسي هو أنه يستغرق وقتًا طويلاً. كم يمكنك تقليل مهلة؟ في الحد - يمكن تخفيضها إلى الصفر ، لا مزيد. وكيف يمكنك تقليل وقت التشغيل إلى الصفر؟ الجواب: استبعاد التنفيذ بشكل عام. بدلاً من ذلك ، قم بإرجاع النتيجة على الفور. وكيف تعرف النتيجة؟ الجواب: إما أن تحسب أو أن تبحث في مكان ما. احسب وقت طويل. وللحذف ، على سبيل المثال ، تذكر النتيجة التي أنتجتها الوظيفة في المرة الأخيرة عند استدعاؤها بنفس المعلمات.

أي أن تنفيذ الوظيفة لا يهمنا. يكفي أن تعرف المعلمات التي تعتمد عليها النتيجة. بعد ذلك ، إذا تم تقديم قيم المعلمات في شكل كائن يمكن استخدامه كمفتاح في بعض وحدات التخزين ، فيمكننا حفظ نتيجة الحساب وقراءتها في المرة القادمة. إذا كانت نتائج القراءة والكتابة هذه أسرع من أداء الوظيفة ، فلدينا ربح في السرعة. يمكن أن تصل قيمة الربح إلى 100 و 1000 و 100 ألف مرة (من المرجح أن يكون 10 ^ 5 استثناء ، ولكن في حالة وجود قاعدة متخلفة إلى حد ما ، فمن الممكن تمامًا).

متطلبات التخزين المؤقت للمفتاح

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

دعونا نلعب مثل هذه الحالة.

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

وإذا كان العرض الأولي للحديد يمكن أن يكون من 2 إلى 5 مرات ، فعندئذ ، بمساعدة ذاكرة التخزين المؤقت ، يمكننا تشديد الإنتاجية كل 10 أو ، في حالة جيدة ، مرة واحدة كل 100 ، في بعض الأماكن ، ربما حتى 1000. أي ، على نفس الحديد - عملية 100 مرة أكثر من الطلبات. عظيم ، يستحق خبز الزنجبيل!

ولكن الآن ، عند نقطة واحدة ، عن طريق الصدفة ، تعطل النظام وتحطم ذاكرة التخزين المؤقت. لا شيء خاص - بعد كل شيء ، تم اختيار ذاكرة التخزين المؤقت عند الطلب "قراءة وكتابة بسرعة عالية ، والباقي لا يهم".

فيما يتعلق بحمل البدء ، كان احتياطي الحديد 2-5 مرات ، ونما الحمل خلال هذا الوقت 10-100 مرة. بمساعدة ذاكرة التخزين المؤقت ، قمنا بإلغاء المكالمات للوظائف الثقيلة وبالتالي كل شيء طار. والآن ، بدون ذاكرة تخزين مؤقت - كم مرة يتدلى نظامنا؟ ماذا سيحدث لنا؟ سوف يسقط النظام.

حتى إذا لم تتعطل ذاكرة التخزين المؤقت لدينا ، ولكن تم مسحها لفترة من الوقت ، فستحتاج إلى تسخينها ، وسيستغرق ذلك بعض الوقت. وفي هذا الوقت - يقع العبء الرئيسي على الوظائف.

الخلاصة: تتطلب المشاريع ذات الأحمال العالية في الإنتاج من نظام التخزين المؤقت ليس فقط سرعة عالية للقراءة والكتابة ، ولكن أيضًا أمان البيانات ومقاومة الفشل.

طحين الاختيار

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

المفسد: كيف نشأت الظروف بالضبط أننا فقدنا مثل هذه الخسارة وحصلنا على موقف حاد ومتوتر - سأقول في الجزء الثاني - وكيف خرجنا وكيف خرجنا. ولكن الآن - سأقول فقط أنه كان كثيرًا من الضغط ، و "فكر - بطريقة ما لا أعتقد ، هز الزجاجة". "اهتزاز الزجاجة" هو أيضا مفسد ، حول هذا أبعد قليلا.

ماذا فعلنا:

نقوم بعمل قائمة بجميع الأنظمة التي يطلبها google و StackOverflow. ما يزيد قليلا عن 30
, . , - — , .
, , , . , – , .
17- , . « », .

ولكن هذا خيار عندما تحتاج إلى اختيار نظام "يزحف بسرعة" في الاختبارات المعدة مسبقًا. وإذا لم تكن هناك مثل هذه الاختبارات حتى الآن وترغب في الاختيار بشكل أسرع؟

سنقوم بمحاكاة مثل هذا الخيار (من الصعب أن نتخيل أن المطور المتوسط + يعيش في فراغ ، وفي وقت الاختيار لم يكن قد قرر بعد المنتج الذي سيجربه في المقام الأول - وبالتالي ، من المرجح أن يكون هناك مزيد من المناقشة حول المنظر / الفلسفة / حول صغار).

بعد تحديد المتطلبات ، سنبدأ في اختيار حل من الصندوق. لماذا إعادة اختراع العجلة: سنذهب ونأخذ نظام تخزين مؤقت جاهز.

إذا كنت قد بدأت للتو وستستخدم google ، فبالإضافة إلى الطلب أو طرحه ، ولكن بشكل عام ، ستكون الإرشادات هكذا. بادئ ذي بدء ، أنت تتعثر على Redis ، فهو مسموع في كل مكان. ثم ستكتشف أن هناك EhCache باعتباره أقدم وأثبت نظام. ثم سيتم كتابتها عن تارانتول - تطور محلي يوجد فيه جانب فريد من الحل. وأيضًا إشعاله ، لأنه الآن في ازدياد شعبيته ويتمتع بدعم SberTech. في النهاية ، هناك Hazelcast ، لأنه في عالم المؤسسات ، غالبًا ما تومض في خضم الشركات الكبيرة.

هذه القائمة لا تنتهي عند هذا الحد ، فهناك العشرات من الأنظمة. ونحن المسمار واحد فقط. خذ الأنظمة الخمسة المختارة لمسابقة الجمال وقم بالاختيار. من سيكون الفائز؟

ريديس

نقرأ ما يكتبونه على الموقع الرسمي.
Redis هو مشروع مفتوح المصدر. يوفر تخزين البيانات في الذاكرة ، والقدرة على حفظ القرص ، والتقسيم التلقائي إلى أقسام ، وتوافر عالٍ واسترداد من فواصل الشبكة.

يبدو أن كل شيء على ما يرام ، يمكنك أخذه وتثبيته - كل ما يحتاجه هو ما يفعله. ولكن دعونا فقط نبحث عن الاهتمام بالمرشحين الآخرين.

احشاش

EhCache - "ذاكرة التخزين المؤقت الأكثر استخدامًا لـ Java" (ترجمة الشعار من الموقع الرسمي). أيضا مفتوح المصدر. ونفهم هنا أن Redis ليس تحت جافا ، ولكنه عام ، وللتفاعل معه ، تحتاج إلى غلاف. وسيكون EhCache أكثر ملاءمة. ماذا وعد النظام؟ الموثوقية والإثبات والوظائف الكاملة. حسنًا ، وهي الأكثر شيوعًا. وتخزين تيرابايت من البيانات.

تم نسيان Redis ، وأنا على استعداد لاختيار EhCache.

لكن الشعور بالوطنية يدفعني إلى معرفة ما الذي يجعل تارانتول جيدًا.

تارانتول

تارانتول - يلبي تسمية "منصة تكامل البيانات في الوقت الحقيقي". يبدو الأمر صعبًا جدًا ، لذلك قرأنا الصفحة بالتفصيل ووجدنا عبارة صاخبة: "تخزن 100٪ من البيانات في ذاكرة الوصول العشوائي". يجب أن يثير هذا أسئلة - بعد كل شيء ، يمكن أن يكون هناك بيانات أكثر بكثير من الذاكرة. وتتمثل عملية فك التشفير هنا في أنه يشير ضمنيًا إلى أن تارانتول لا يقوم بتشغيل التسلسل لكتابة البيانات على القرص من الذاكرة. بدلاً من ذلك ، يستخدم ميزات النظام منخفضة المستوى عندما يتم تعيين الذاكرة ببساطة على نظام الملفات مع أداء إدخال / إخراج جيد جدًا. بشكل عام ، فعلوا ذلك بطريقة رائعة ورائعة.

دعونا نلقي نظرة على التنفيذ: طريق Mail.ru السريع للشركات ، Avito ، Beeline ، Megafon ، Alfa-Bank ، Gazprom ...

إذا كان لا يزال هناك أي شكوك حول تارانتول ، فإن تقديم تطبيق ماستركارد سيقتلني. أنا آخذ تارانتول.

لكن على اي حال…

اشعل

... هناك Ignite ، المعلنة على أنها "منصة حوسبة داخل الذاكرة ... سرعات داخل الذاكرة على بيتابايت من البيانات." هناك أيضًا العديد من المزايا: ذاكرة التخزين المؤقت الموزعة في الذاكرة ، وذاكرة التخزين المؤقت ذات القيمة الرئيسية الأسرع ، والتحجيم الأفقي ، والتوافر العالي ، والتكامل الصارم. بشكل عام ، اتضح أن الأسرع هو Ignite.

التطبيقات: Sberbank ، American Airlines ، Yahoo! اليابان ثم ما زلت أجد أن Ignite لا يتم تطبيقه فقط في Sberbank ، ولكن فريق SberTech يرسل أفراده إلى فريق Ignite لإنهاء المنتج. هذا آسر تمامًا وأنا على استعداد لاتخاذ Ignite.

من غير المفهوم تمامًا لماذا ، أنظر إلى النقطة الخامسة.

البندق

أذهب إلى موقع Hazelcast ، اقرأه . وتبين أن الحل الأسرع للتخزين المؤقت الموزع هو Hazelcast. إنه أوامر بحجم أسرع من جميع الحلول الأخرى وبشكل عام فهو رائد في مجال شبكة البيانات في الذاكرة. على هذه الخلفية ، خذ شيئًا آخر - لا تحترم نفسك. ويستخدم أيضًا تخزين بيانات فائض للتشغيل المستمر للكتلة دون فقدان البيانات.

كل شيء ، أنا على استعداد لاتخاذ Hazelcast.

مقارنة

ولكن إذا نظرت ، فسيتم رسم جميع المرشحين الخمسة بحيث يكون كل منهم هو الأفضل. كيفة تختار؟ يمكننا أن نرى أيهما الأكثر شعبية ، والبحث عن المقارنات ، وسوف يمر الصداع.

نجد مثل هذه المراجعة ، اختر أنظمتنا الخمسة.

هنا يتم فرزها: في الجزء العلوي من Redis ، في المركز الثاني هو Hazelcast ، Tarantool و Ignite تكتسب شعبية ، EhCache كانت ولا تزال.

ولكن دعونا نلقي نظرة على طريقة الحساب : روابط لمواقع الويب ، اهتمام عام بالنظام ، عروض عمل - رائع! أي عندما يسقط نظامي ، سأقول: "لا ، إنه موثوق! هنا الكثير من عروض العمل ... ". لن تعمل مثل هذه المقارنة البسيطة.

كل هذه الأنظمة ليست مجرد أنظمة تخزين مؤقت. لا يزال لديهم الكثير من الوظائف ، بما في ذلك عندما لا يتم نقل البيانات إلى العميل للمعالجة ، بل بالأحرى: الرمز الذي يجب تنفيذه على البيانات ينتقل إلى الخادم ، ويتم تنفيذه هناك ، ويتم إرجاع النتيجة. وكنظام منفصل للتخزين المؤقت ، لا يتم اعتبارها في كثير من الأحيان.

حسنًا ، لا تستسلم ، نجد مقارنة مباشرة للأنظمة. خذ الخيارين الأوائل - Redis و Hazelcast. نحن مهتمون بالسرعة ، يمكننا مقارنتها بهذه المعلمة.

هرتز مقابل ريديس

نجد مثل هذه المقارنة :

الأزرق هو Redis ، الأحمر هو Hazelcast. البندق يفوز في كل مكان ، ويتم إعطاء الأساس المنطقي: إنه متعدد الخيوط ، محسن للغاية ، يعمل كل خيط مع قسمه الخاص ، لذلك لا توجد أقفال. و Redis مترابط واحد ، ولا يأخذ مكاسب من وحدات المعالجة المركزية الحديثة متعددة النواة. يحتوي Hazelcast على منافذ إدخال / إخراج غير متزامنة ، ولدى Redis-Jedis مآخذ حجب. في النهاية ، يستخدم Hazelcast بروتوكولًا ثنائيًا ، في حين أن Redis موجه للنص ، مما يعني أنه غير فعال.

تحسبًا فقط ، ننتقل إلى مصدر آخر للمقارنة. ماذا سيرينا؟

Redis vs Hz

مقارنة أخرى :

هنا ، على العكس ، الأحمر هو Redis. أي أن Redis يتفوق على أداء Hazelcast. في المقارنة الأولى ، فاز Hazelcast في المركز الثاني - Redis. هنا ، شرحوا بدقة بالغة سبب فوز Hazelcast في المقارنة السابقة.

اتضح أن نتيجة الأول تم تزويرها بالفعل: تم أخذ Redis في صندوق القاعدة ، وتم سجن Hazelcast في حالة اختبار. ثم اتضح: أولاً ، لا يمكن الوثوق بأحد ، وثانيًا ، عندما نختار نظامًا ، فإننا ما زلنا بحاجة إلى تكوينه بشكل صحيح. تتضمن هذه الإعدادات العشرات ، ما يقرب من مئات المعلمات.

هز الزجاجة

وكل العملية التي قمنا بها للتو ، يمكنني أن أشرح بمثل هذه الاستعارة ، "رج الزجاجة". هذا هو ، الآن لا يمكنك البرمجة ، الآن الشيء الرئيسي هو أن تكون قادرًا على قراءة تدفق مكدس. وفي فريقي هناك شخص ، محترف ، يعمل بهذه الطريقة في اللحظات الحرجة.

ماذا يفعل؟ يرى شيئًا مكسورًا ، يرى تتبع مكدس ، يأخذ بعض كلماته (أي تلك هي خبرته في البرنامج) ، يبحث في Google ، يجد تدفق مكدس بين الإجابات. من دون قراءة ، دون تفكير ، من بين إجابات السؤال - يختار شيئًا مشابهًا أكثر للجملة "افعل هذا وذاك" (اختيار مثل هذه الإجابة هو موهبته ، لأنها ليست دائمًا الإجابة التي تجمع المزيد من الإعجابات) ، فهو يستخدم ، يبدو: إذا تغير شيء ما ، فلا بأس. إذا لم تتغير ، فإننا نتراجع. ونكرر البحث عن بدء الاختيار. وبهذه الطريقة البديهية ، أدرك أنه بعد مرور بعض الوقت يعمل الكود. لا يعرف لماذا ، لا يعرف ما فعله ، لا يستطيع أن يشرح. لكن! تعمل هذه العدوى. و "النار تنطفئ". الآن نحن نفهم ما قمنا به. عندما يعمل البرنامج ، يكون الأمر أسهل بكثير.ويوفر الوقت بشكل ملحوظ.

يتم شرح هذه الطريقة بشكل جيد للغاية بمثل هذا المثال.

كانت ذات مرة تحظى بشعبية كبيرة لجمع مركب شراعي في زجاجة. في نفس الوقت ، المراكب الشراعية كبيرة وهشة ، ورقبة الزجاجة ضيقة للغاية ؛ لا يمكنك دفعها إلى الداخل. كيفية تجميعها؟

هناك مثل هذه الطريقة ، سريعة جدا وفعالة للغاية.

تتكون السفينة من مجموعة من الأشياء الصغيرة: العصي والحبال والأشرعة والغراء. نضع كل هذا في زجاجة.
نأخذ الزجاجة بكلتا يديك ونبدأ في الاهتزاز. نحن نرتجف. وعادة - تحصل على القمامة الكاملة ، بالطبع. ولكن احيانا. في بعض الأحيان تحصل على سفينة! بتعبير أدق ، شيء مشابه للسفينة.

نحن نظهر هذا لشخص ما: "سيرج ، انظر!؟". وبالفعل ، من بعيد - كما لو كانت سفينة. ولكن بعد ذلك لا يمكنك ترك هذا يذهب.

هناك طريقة أخرى. الرجال يستخدمون أكثر تقدما ، مثل المتسللين.

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

من وجهة نظر تحديد المشكلة ، يبدو أن كل شيء صحيح. ولكن هنا مثال للسفن: لماذا هذه السفينة بشكل عام ، من يحتاجها على الإطلاق؟ لا يحمل أي وظيفة. عادة ما تكون هذه السفن هدايا لأشخاص رفيعي المستوى للغاية يضعونها على الرف فوق أنفسهم ، كنوع من الرمز ، كعلامة. والآن ، إذا كان مثل هذا الشخص ، أو رئيس شركة كبيرة أو مسؤول رفيع المستوى ، كيف يقف العلم مثل هذه القمامة ، حيث يتم قطع الرقبة؟ سيكون من الأفضل إذا لم يكن يعرف عن ذلك. لذا ، كيف يمكن صنع هذه السفن في نهاية المطاف بحيث يمكن تقديمها لشخص مهم؟

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

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

بالعودة إلى مهمة اختيار خادم التخزين المؤقت لدينا ، كيف يمكن تطبيق هذه الطريقة؟ أقترح مثل هذا الخيار من جميع الأنظمة الموجودة - لا تهز الزجاجة ، لا تختار ، ولكن انظر ما لديهم ، من حيث المبدأ ، ما يبحثون عنه عند اختيار النظام.

أين تبحث عن عنق الزجاجة

دعونا نحاول عدم هز الزجاجة ، وليس لفرز كل ما هو بدوره ، ولكن دعونا نرى المهام التي تنشأ ، فجأة ، لمهمتك - لتصميم مثل هذا النظام بنفسك. بالطبع ، لن نقوم بتجميع الدراجة ، ولكننا سنستخدم هذا المخطط لتوجيه أنفسنا بشأن النقاط التي يجب الانتباه إليها في أوصاف المنتج. نوجز مثل هذا المخطط.

إذا تم توزيع النظام ، فسيكون لدينا عدة خوادم (6). لنفترض أربعة (من المناسب وضعها في الصورة ، ولكن بالطبع ، يمكن أن يكون هناك أي عدد منهم). إذا كانت الخوادم على عقد مختلفة ، فهذا يعني أن بعض الكودات تدور عليها جميعًا ، وهو المسؤول عن التأكد من أن هذه العقد تشكل كتلة ، وفي حالة حدوث انقطاع ، تتصل ، تتعرف على بعضها البعض.

لا تزال بحاجة إلى منطق الشفرة (2) ، والذي يتعلق في الواقع بالتخزين المؤقت. يتفاعل العملاء مع هذا الرمز من خلال بعض API. يمكن أن يكون رمز العميل (1) داخل نفس JVM والوصول إليه عبر الشبكة. المنطق الذي يتم تنفيذه بالداخل هو القرار الذي يعترض على تركه في ذاكرة التخزين المؤقت ، والذي يتم رميه. نستخدم الذاكرة (3) لتخزين ذاكرة التخزين المؤقت ، ولكن إذا لزم الأمر ، يمكننا أيضًا حفظ جزء من البيانات الموجودة على القرص (4).

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

مزيد من التفاعل مع الكتلة. على الأرجح ، سيكون في نفس النظام ، ولكن يمكن أن يكون بشكل منفصل. هنا ، تحتاج أيضًا إلى التفكير في نقل البيانات إليها ، وسرعة تسلسل البيانات والتفاعل بين المجموعة.

الآن ، من ناحية ، يمكننا أن نتخيل "التروس التي ستدور" في نظام ذاكرة التخزين المؤقت عند معالجة الطلبات من الشفرة الخاصة بنا ، ومن ناحية أخرى ، يمكننا تقدير عدد الطلبات التي ستولدها الشفرة الخاصة بنا لهذا النظام وعدد الطلبات. هذا يكفي لجعل الاختيار أكثر أو أقل واقعية - لاختيار نظام لحالة الاستخدام الخاصة بنا.

البندق

دعونا نرى كيف ينطبق هذا التحلل على قائمتنا. على سبيل المثال ، Hazelcast.

من أجل وضع / أخذ البيانات من Hazelcast ، يصل رمز العميل إلى (1) واجهة برمجة التطبيقات. يسمح لك Hz ببدء تشغيل الخادم على أنه مضمن ، وفي هذه الحالة ، يعد الوصول إلى واجهة برمجة التطبيقات (API) مكالمة طريقة داخل JVM ، يمكنك قراءتها مجانًا.

لحل المنطق في (2) ، يعتمد هرتز على تجزئة من مجموعة البايت للمفتاح المسلسل - أي أن تسلسل المفتاح سيحدث على أي حال. هذا عبء لا مفر منه لهيرتز.
يتم تنفيذ استراتيجيات الإخلاء بشكل جيد ، ولكن بالنسبة للحالات الخاصة - يمكنك ربط الخاصة بك. لا داعي للقلق بشأن هذا الجزء.

يمكن توصيل التخزين (4). غرامة. يمكن اعتبار التفاعل (5) المضمّن فوريًا. تبادل البيانات بين العقد في العنقود (6) - نعم هو كذلك. هذا يساهم في المرونة على حساب السرعة. تسمح ميزة هرتز القريبة من ذاكرة التخزين المؤقت بخفض السعر - سيتم تخزين البيانات المستلمة من العقد الأخرى في المجموعة مؤقتًا.

ما الذي يمكن عمله في مثل هذه الظروف لزيادة السرعة؟

على سبيل المثال ، لتجنب إجراء تسلسل للمفتاح في (2) ، فوق Hazelcast ، قم بتثبيت ذاكرة تخزين مؤقت أخرى للحصول على البيانات الأكثر سخونة. في Sportmaster ، تم اختيار الكافيين لهذا الغرض.

للالتواء عند المستوى (6) ، يقدم هرتز نوعين من التخزين: IMap و ReplicatedMap.

تجدر الإشارة إلى كيفية دخول Hazelcast إلى مكدس تكنولوجيا Sportmaster.

في عام 2012 ، عندما عملنا على أول تجربة تجريبية للموقع المستقبلي ، كان Hazelcast هو الرابط الأول الذي أصدره محرك البحث. بدأ التعارف "في المرة الأولى" - لقد تأثرنا بحقيقة أنه بعد ساعتين فقط ، عندما أدخلنا هرتز في النظام ، نجح. وعملت بشكل جيد. حتى نهاية اليوم أضفنا بعض الاختبارات ، كنا سعداء. وكان هذا العرض النشط كافياً للتغلب على تلك المفاجآت التي أثارها هرتز بمرور الوقت. الآن ليس لدى فريق Sportmaster أي سبب للرفض من Hazelcast.

لكن الحجج مثل "الرابط الأول في محرك البحث" و "HelloWorld الذي تم تجميعه بسرعة" هي بالطبع استثناء وميزة في اللحظة التي حدث فيها الاختيار. تبدأ هذه الاختبارات للنظام المحدد بالإصدار في المنتج ، وفي هذه المرحلة يجب الانتباه عند اختيار أي نظام ، بما في ذلك ذاكرة التخزين المؤقت. في الواقع ، في حالتنا ، يمكننا القول أننا اخترنا Hazelcast عن طريق الصدفة ، ولكن اتضح بعد ذلك أننا اخترنا الحق.

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

بالنسبة لجميع هذه المتطلبات ، يعتبر Hazelcast مناسبًا بالتأكيد.

يتبع

لكن Hazelcast ليس حلا سحريا. في عام 2017 ، اخترنا Hazelcast لذاكرة التخزين المؤقت في لوحة المشرف ، معتمدين ببساطة على الانطباع الجيد عن التجربة السابقة. لعب هذا دورًا رئيسيًا في نكتة شريرة للغاية ، ولهذا السبب كنا في وضع صعب وخرجنا منه "بطوليًا" لمدة 60 يومًا. لكن المزيد عن ذلك في الجزء التالي.

في هذه الأثناء ... كود جديد سعيد!

كيف اخترنا في Sportmaster نظام التخزين المؤقت. الجزء الأول