مرحبًا! اسمي Alexey Pyankov، أنا مطور في شركة Sportmaster. في هذا أخبرت كيف بدأ العمل على موقع Sportmaster في عام 2012، وما هي المبادرات التي تمكنا من "الدفع بها" والعكس، وما هي أشعل النار التي جمعناها.
أريد اليوم مشاركة الأفكار التي تتبع موضوعًا آخر - اختيار نظام التخزين المؤقت لواجهة Java الخلفية في لوحة إدارة الموقع. بالنسبة لي، هذه المؤامرة لها معنى خاص - على الرغم من أن القصة تكشفت لمدة شهرين فقط، خلال هذه الأيام الستين عملنا 2-60 ساعة ودون يوم عطلة واحد. لم أفكر أو أتخيل أبدًا أنه من الممكن العمل بهذا القدر من الجدية.
لذلك قمت بتقسيم النص إلى جزأين حتى لا يتم تحميله بالكامل. على العكس من ذلك، سيكون الجزء الأول خفيفًا جدًا - التحضير والمقدمة وبعض الاعتبارات حول ماهية التخزين المؤقت. إذا كنت بالفعل مطورًا ذا خبرة أو عملت مع ذاكرات التخزين المؤقت، فمن المرجح ألا يكون هناك شيء جديد في هذه المقالة من الجانب الفني. لكن بالنسبة للمبتدئ، فإن مثل هذه المراجعة الصغيرة يمكن أن تخبره في أي اتجاه يجب أن ينظر إذا وجد نفسه عند مفترق طرق كهذا.
عندما تم إطلاق الإصدار الجديد من موقع 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
- نكتب اختبارات بحمل نموذجي للإنتاج. للقيام بذلك، قمنا بتسجيل البيانات التي تمر عبر النظام في بيئة الإنتاج - وهو نوع من شم البيانات ليس على الشبكة، ولكن داخل النظام. بالضبط تم استخدام هذه البيانات في الاختبارات.
- مع الفريق بأكمله، يختار الجميع النظام التالي من القائمة، ويقومون بتكوينه، وإجراء الاختبارات. إنه لا يجتاز الاختبار، ولا يحمل العبء - نرميه بعيدًا وننتقل إلى الاختبار التالي في الصف.
- في النظام السابع عشر أصبح من الواضح أن كل شيء كان ميؤوسًا منه. توقف عن رج الزجاجة، لقد حان الوقت للتفكير بجدية.
ولكن هذا خيار عندما تحتاج إلى اختيار نظام "يتجاوز السرعة" في الاختبارات المعدة مسبقًا. ماذا لو لم تكن هناك مثل هذه الاختبارات بعد وتريد الاختيار بسرعة؟
دعونا نمثل هذا الخيار (من الصعب أن نتخيل أن المطور الأوسط + يعيش في فراغ، وفي وقت الاختيار لم يحدد بعد تفضيله فيما يتعلق بالمنتج الذي يجب تجربته أولاً - وبالتالي، فإن المزيد من التفكير هو أكثر من مجرد نظرية/فلسفة/ عن صغار).
وبعد تحديد المتطلبات، سنبدأ في اختيار حل خارج الصندوق. لماذا نعيد اختراع العجلة: سنذهب ونأخذ نظام التخزين المؤقت الجاهز.
إذا كنت قد بدأت للتو وبحثت عنه في جوجل، فقم بإعطاء الطلب أو قبوله، ولكن بشكل عام، ستكون الإرشادات على هذا النحو. بادئ ذي بدء، سوف تصادف Redis، وهو مسموع في كل مكان. ثم ستكتشف أن EhCache هو النظام الأقدم والأكثر إثباتًا. بعد ذلك سنكتب عن Tarantool، وهو تطوير محلي له جانب فريد من الحل. وأيضا Ignite، لأنه الآن في ارتفاع شعبيته ويتمتع بدعم SberTech. في النهاية هناك أيضًا Hazelcast، لأنه غالبًا ما يظهر في عالم المؤسسات بين الشركات الكبيرة.
القائمة ليست شاملة، فهناك العشرات من الأنظمة. ونحن سوف المسمار شيء واحد فقط. لنأخذ الأنظمة الخمسة المختارة لـ "مسابقة الجمال" ونقوم بالاختيار. من سيكون الفائز؟
رديس
نقرأ ما يكتبونه على الموقع الرسمي.
- مشروع مفتوح المصدر. يوفر تخزين البيانات في الذاكرة، والقدرة على الحفظ على القرص، والتقسيم التلقائي، والتوفر العالي والاسترداد من انقطاع الشبكة.
يبدو أن كل شيء على ما يرام، يمكنك أن تأخذه وتثبته - كل ما تحتاجه، يحدث. ولكن من أجل المتعة فقط، دعونا ننظر إلى المرشحين الآخرين.
EhCache
- "ذاكرة التخزين المؤقت الأكثر استخدامًا لـ Java" (ترجمة الشعار من الموقع الرسمي). مفتوح المصدر أيضًا. وبعد ذلك نفهم أن Redis ليس مخصصًا لجافا، ولكنه عام، وللتفاعل معه تحتاج إلى غلاف. وسيكون EhCache أكثر ملاءمة. ماذا وعد النظام؟ الموثوقية، المثبتة، الوظائف الكاملة. حسنًا، إنه أيضًا الأكثر شيوعًا. ويخزن تيرابايت من البيانات.
تم نسيان Redis، وأنا على استعداد لاختيار EhCache.
لكن الشعور بالوطنية يدفعني إلى رؤية ما هو جيد في تارانتوول.
تارانتول
- يفي بمسمى "منصة تكامل البيانات في الوقت الحقيقي". يبدو الأمر معقدًا للغاية، لذلك نقرأ الصفحة بالتفصيل ونجد عبارة عالية: "يخزن 100% من البيانات في ذاكرة الوصول العشوائي مؤقتًا". يجب أن يثير هذا أسئلة - ففي النهاية، يمكن أن يكون هناك بيانات أكثر بكثير من الذاكرة. التفسير هو أن هذا يعني أن Tarantool لا يقوم بتشغيل التسلسل لكتابة البيانات إلى القرص من الذاكرة. بدلاً من ذلك، فإنه يستخدم ميزات النظام ذات المستوى المنخفض، عندما يتم تعيين الذاكرة ببساطة إلى نظام ملفات يتمتع بأداء إدخال/إخراج جيد جدًا. بشكل عام، لقد فعلوا شيئًا رائعًا ورائعًا.
دعونا نلقي نظرة على التطبيقات: الطريق السريع للشركات Mail.ru، Avito، Beeline، Megafon، Alfa-Bank، Gazprom...
إذا كانت لا تزال هناك أي شكوك حول Tarantool، فإن حالة التنفيذ في Mastercard تقضي علي. أنا آخذ تارانتوول.
لكن على اي حال…
إشعال
... هل هناك المزيد ، يتم وصفها بأنها "منصة حوسبة في الذاكرة...سرعات في الذاكرة ببيتابايت من البيانات." هناك أيضًا العديد من المزايا هنا: ذاكرة التخزين المؤقت الموزعة في الذاكرة، وأسرع تخزين وذاكرة تخزين مؤقت لقيمة المفتاح، والقياس الأفقي، والتوافر العالي، والنزاهة الصارمة. بشكل عام، اتضح أن الأسرع هو إشعال.
التنفيذ: سبيربنك، الخطوط الجوية الأمريكية، ياهو! اليابان. ثم اكتشفت أن Ignite لا يتم تنفيذه في Sberbank فحسب، بل يرسل فريق SberTech أفراده إلى فريق Ignite نفسه لتحسين المنتج. هذا أمر آسر تمامًا وأنا على استعداد لأخذ Ignite.
ليس من الواضح تمامًا السبب، وأنا أنظر إلى النقطة الخامسة.
البندق
أذهب إلى الموقع ، قراءة. واتضح أن الحل الأسرع للتخزين المؤقت الموزع هو Hazelcast. إنها أسرع من جميع الحلول الأخرى، وهي بشكل عام رائدة في مجال شبكة البيانات في الذاكرة. في ظل هذه الخلفية، فإن قبول شيء آخر لا يعني احترام نفسك. كما أنه يستخدم تخزين البيانات الزائدة عن الحاجة للتشغيل المستمر للمجموعة دون فقدان البيانات.
هذا كل شيء، وأنا على استعداد لأخذ Hazelcast.
مقارنة
ولكن إذا نظرت، ستجد أن جميع المرشحين الخمسة موصوفون بطريقة تجعل كل واحد منهم هو الأفضل. كيفة تختار؟ يمكننا أن نرى أيهما الأكثر شعبية، ونبحث عن المقارنات، وسوف يختفي الصداع.
نجد مثل هذا ، اختر أنظمتنا الخمسة.
هنا يتم فرزها: Redis في الأعلى، Hazelcast في المركز الثاني، Tarantool و Ignite يكتسبان شعبية، EhCache كان ولا يزال كما هو.
ولكن دعونا ننظر : روابط لمواقع الويب، الاهتمام العام بالنظام، عروض العمل - رائع! أي أنه عندما يفشل نظامي، سأقول: "لا، إنه موثوق!" هناك العديد من عروض العمل..." مثل هذه المقارنة البسيطة لن تجدي نفعاً.
كل هذه الأنظمة ليست مجرد أنظمة تخزين مؤقت. لديهم أيضًا الكثير من الوظائف، بما في ذلك عندما لا يتم ضخ البيانات إلى العميل للمعالجة، ولكن العكس صحيح: ينتقل الكود الذي يجب تنفيذه على البيانات إلى الخادم، ويتم تنفيذه هناك، ويتم إرجاع النتيجة. ولا يتم اعتبارها في كثير من الأحيان نظامًا منفصلاً للتخزين المؤقت.
حسنًا، دعونا لا نستسلم، فلنجد مقارنة مباشرة بين الأنظمة. لنأخذ الخيارين الأولين - Redis وHazelcast. نحن مهتمون بالسرعة، وسوف نقوم بمقارنتها بناءً على هذه المعلمة.
هرتز مقابل ريديس
نجد هذا :
الأزرق هو Redis، والأحمر هو Hazelcast. يفوز Hazelcast في كل مكان، وهناك سبب منطقي لذلك: فهو متعدد الخيوط، ومُحسّن للغاية، ويعمل كل مؤشر ترابط مع القسم الخاص به، لذلك لا يوجد أي حظر. وRedis عبارة عن خيط مفرد، ولا يستفيد من وحدات المعالجة المركزية الحديثة متعددة النواة. يحتوي Hazelcast على إدخال/إخراج غير متزامن، بينما يحتوي Redis-Jedis على مآخذ حظر. بعد كل شيء، يستخدم Hazelcast بروتوكولًا ثنائيًا، بينما يركز Redis على النص، مما يعني أنه غير فعال.
فقط في حالة، دعونا ننتقل إلى مصدر آخر للمقارنة. ماذا سيظهر لنا؟
ريديس مقابل هرتز
آخر :
هنا، على العكس من ذلك، الأحمر هو Redis. أي أن Redis يتفوق على Hazelcast من حيث الأداء. فاز Hazelcast في المقارنة الأولى، وفاز Redis بالثانية. شرح بدقة شديدة سبب فوز Hazelcast في المقارنة السابقة.
اتضح أن نتيجة النتيجة الأولى كانت مزورة بالفعل: تم أخذ Redis في الصندوق الأساسي، وتم تصميم Hazelcast لحالة اختبار. ثم اتضح: أولا، لا يمكننا الوثوق بأي شخص، وثانيا، عندما نختار النظام أخيرا، ما زلنا بحاجة إلى تكوينه بشكل صحيح. تتضمن هذه الإعدادات العشرات، والمئات تقريبًا من المعلمات.
هز الزجاجة
ويمكنني أن أشرح العملية برمتها التي قمنا بها الآن باستخدام الاستعارة التالية: "رج الزجاجة". وهذا يعني أنك لست مضطرًا إلى البرمجة الآن، والشيء الرئيسي الآن هو أن تكون قادرًا على قراءة تدفق المكدس. ولدي شخص محترف في فريقي يعمل بهذه الطريقة تمامًا في اللحظات الحرجة.
ماذا يفعل؟ يرى شيئًا مكسورًا، ويرى أثرًا مكدسًا، ويأخذ منه بعض الكلمات (التي تمثل خبرته في البرنامج)، ويبحث على Google، ويجد تدفق المكدس بين الإجابات. دون قراءة، دون تفكير، من بين أجوبة السؤال، يختار ما يشبه جملة "افعل هذا وذاك" (اختيار مثل هذه الإجابة هو موهبته، لأنها ليست دائما الإجابة التي تنال أكبر عدد من الإعجابات)، ينطبق، يبدو: إذا تغير شيء ما، فهذا رائع. إذا لم يتغير، استرجعه. وكرر البحث والتحقق من الإطلاق. وبهذه الطريقة البديهية، يضمن أن الكود يعمل بعد مرور بعض الوقت. إنه لا يعرف السبب، ولا يعرف ما فعله، ولا يستطيع الشرح. لكن! تعمل هذه العدوى. و"طفئت النار". الآن دعونا معرفة ما فعلناه. عندما يعمل البرنامج، هو أمر من حيث الحجم أسهل. ويوفر الكثير من الوقت.
تم شرح هذه الطريقة جيدًا بهذا المثال.
لقد كان من الشائع جدًا جمع المراكب الشراعية في زجاجة. وفي الوقت نفسه، يكون المراكب الشراعية كبيرًا وهشًا، وعنق الزجاجة ضيق جدًا، ومن المستحيل دفعه إلى الداخل. كيفية تجميعها؟
هناك مثل هذه الطريقة، سريعة جدًا وفعالة جدًا.
تتكون السفينة من مجموعة من الأشياء الصغيرة: العصي والحبال والأشرعة والغراء. نضع كل هذا في زجاجة.
نأخذ الزجاجة بكلتا يديها ونبدأ في رجها. نحن نهزها ونهزها. وعادة ما يتبين أنها قمامة كاملة بالطبع. ولكن احيانا. في بعض الأحيان يتبين أنها سفينة! بتعبير أدق، شيء مشابه للسفينة.
نعرض هذا شيئًا لشخص ما: "سيريوجا، هل ترى!؟" وبالفعل تبدو من بعيد وكأنها سفينة. لكن لا يمكن السماح لهذا بالاستمرار.
هناك طريقة أخرى. يتم استخدامها من قبل أشخاص أكثر تقدمًا، مثل المتسللين.
لقد أعطيت هذا الرجل مهمة، لقد فعل كل شيء وغادر. وأنت تنظر - يبدو أن الأمر قد تم. وبعد فترة من الوقت، عندما يلزم الانتهاء من الكود، يبدأ هذا بسببه... من الجيد أنه تمكن بالفعل من الهرب بعيدًا. هؤلاء هم الرجال الذين، باستخدام مثال الزجاجة، سوف يفعلون ذلك: كما ترى، حيث يكون الجزء السفلي، ينحني الزجاج. وليس من الواضح تماما ما إذا كانت شفافة أم لا. ثم يقوم "المتسللون" بقطع هذا القاع، وإدخال سفينة هناك، ثم لصق الجزء السفلي مرة أخرى، ويبدو الأمر كما لو كان هذا هو ما يفترض أن يكون.
من وجهة نظر تحديد المشكلة، يبدو أن كل شيء صحيح. لكن باستخدام السفن كمثال: لماذا نصنع هذه السفينة أصلاً، ومن يحتاجها على أي حال؟ أنها لا توفر أي وظيفة. عادة ما تكون هذه السفن هدايا للأشخاص رفيعي المستوى، الذين يضعونها على الرف فوقهم، كنوع من الرمز، كعلامة. وإذا كان مثل هذا الشخص، رئيس شركة كبيرة أو مسؤول رفيع المستوى، فكيف سيقف العلم لمثل هذا الاختراق الذي قطعت رقبته؟ سيكون من الأفضل لو لم يعلم بذلك أبدًا. إذًا، كيف ينتهي بهم الأمر إلى صنع هذه السفن التي يمكن تقديمها لشخص مهم؟
المكان الرئيسي الوحيد الذي لا يمكنك فعل أي شيء حياله هو الجسد. ويتناسب بدن السفينة مباشرة مع الرقبة. بينما السفينة مجمعة خارج الزجاجة. لكن الأمر لا يقتصر على تجميع سفينة، بل هو حرفة مجوهرات حقيقية. تتم إضافة رافعات خاصة إلى المكونات، والتي تسمح بعد ذلك برفعها. على سبيل المثال، يتم طي الأشرعة، وإدخالها بعناية إلى الداخل، ثم بمساعدة الملقط، يتم سحبها ورفعها بدقة شديدة. والنتيجة هي عمل فني يمكن إهدائه بضمير مرتاح وفخر.
وإذا أردنا أن ينجح المشروع، يجب أن يكون هناك صائغ واحد على الأقل في الفريق. شخص يهتم بجودة المنتج ويراعي كافة الجوانب، دون التضحية بأي شيء، حتى في لحظات التوتر، عندما تتطلب الظروف القيام بالعاجل على حساب المهم. جميع المشاريع الناجحة المستدامة، والتي صمدت أمام اختبار الزمن، مبنية على هذا المبدأ. هناك شيء دقيق للغاية وفريد من نوعه في هذه الأشياء، شيء يستفيد من جميع الإمكانيات المتاحة. في المثال مع السفينة في الزجاجة، يتم لعب حقيقة أن بدن السفينة يمر عبر الرقبة.
وبالعودة إلى مهمة اختيار خادم التخزين المؤقت، كيف يمكن تطبيق هذه الطريقة؟ أقدم خيار الاختيار من بين جميع الأنظمة الموجودة - لا تهز الزجاجة، ولا تختار، ولكن انظر إلى ما لديهم من حيث المبدأ، وما الذي تبحث عنه عند اختيار النظام.
أين تبحث عن عنق الزجاجة
دعونا نحاول ألا نرج الزجاجة، وألا نستعرض كل ما هو موجود واحداً تلو الآخر، ولكن دعونا نرى ما هي المشاكل التي ستنشأ إذا قمنا فجأة، من أجل مهمتنا، بتصميم مثل هذا النظام بأنفسنا. بالطبع، لن نقوم بتجميع الدراجة، ولكننا سنستخدم هذا الرسم البياني لمساعدتنا في معرفة النقاط التي يجب الانتباه إليها في وصف المنتج. دعونا نرسم مثل هذا المخطط.
إذا تم توزيع النظام، فسيكون لدينا عدة خوادم (6). لنفترض أن هناك أربعة (من المناسب وضعها في الصورة، ولكن، بالطبع، يمكن أن يكون هناك أي عدد تريده). إذا كانت الخوادم موجودة في عقد مختلفة، فهذا يعني أنها جميعًا تقوم بتشغيل بعض التعليمات البرمجية المسؤولة عن التأكد من أن هذه العقد تشكل كتلة، وفي حالة حدوث انقطاع، تتصل وتتعرف على بعضها البعض.
نحتاج أيضًا إلى منطق الكود (2)، والذي يتعلق في الواقع بالتخزين المؤقت. يتفاعل العملاء مع هذا الرمز عبر بعض واجهات برمجة التطبيقات (API). يمكن أن يكون رمز العميل (1) إما داخل نفس JVM أو الوصول إليه عبر الشبكة. المنطق المطبق في الداخل هو تحديد الكائنات التي يجب تركها في ذاكرة التخزين المؤقت وأيها يجب التخلص منها. نستخدم الذاكرة (3) لتخزين ذاكرة التخزين المؤقت، ولكن إذا لزم الأمر، يمكننا حفظ بعض البيانات على القرص (4).
دعونا نرى في أي الأجزاء سيحدث الحمل. في الواقع، سيتم تحميل كل سهم وكل عقدة. أولاً، بين رمز العميل وواجهة برمجة التطبيقات، إذا كان هذا اتصالاً بالشبكة، فقد يكون الهبوط ملحوظًا تمامًا. ثانيًا، في إطار واجهة برمجة التطبيقات نفسها - إذا بالغنا في استخدام المنطق المعقد، فقد نواجه مشكلات في وحدة المعالجة المركزية. وسيكون من الرائع لو أن المنطق لم يضيع الوقت في الذاكرة. ويبقى التفاعل مع نظام الملفات - في الإصدار المعتاد يتم إجراء تسلسل / استعادة وكتابة / قراءة.
التالي هو التفاعل مع الكتلة. على الأرجح، سيكون في نفس النظام، ولكن يمكن أن يكون بشكل منفصل. هنا تحتاج أيضًا إلى مراعاة نقل البيانات إليها وسرعة تسلسل البيانات والتفاعلات بين المجموعة.
الآن، من ناحية، يمكننا أن نتخيل "ما هي التروس التي ستتحول" في نظام ذاكرة التخزين المؤقت عند معالجة الطلبات من التعليمات البرمجية الخاصة بنا، ومن ناحية أخرى، يمكننا تقدير عدد الطلبات التي ستنشئها التعليمات البرمجية الخاصة بنا لهذا النظام وعددها. وهذا يكفي لاتخاذ خيار أكثر أو أقل رصانة - لاختيار نظام يناسب حالة الاستخدام الخاصة بنا.
البندق
دعونا نرى كيفية تطبيق هذا التحلل على قائمتنا. على سبيل المثال، هازلكاست.
من أجل وضع/أخذ البيانات من Hazelcast، يصل رمز العميل إلى (1) واجهة برمجة التطبيقات. يسمح لك هرتز بتشغيل الخادم كخادم مضمن، وفي هذه الحالة، يعد الوصول إلى واجهة برمجة التطبيقات بمثابة استدعاء أسلوب داخل JVM، والذي يمكن اعتباره مجانيًا.
لكي يعمل المنطق الموجود في (2)، يعتمد هرتز على تجزئة مصفوفة البايت للمفتاح المتسلسل - أي أنه سيتم إجراء تسلسل للمفتاح في أي حال. هذا أمر لا مفر منه بالنسبة للهرتز.
يتم تنفيذ استراتيجيات الإخلاء بشكل جيد، ولكن في الحالات الخاصة يمكنك إضافة استراتيجيات خاصة بك. لا داعي للقلق بشأن هذا الجزء.
يمكن توصيل وحدة التخزين (4). عظيم. يمكن اعتبار التفاعل (5) المضمن فوريًا. تبادل البيانات بين العقد في المجموعة (6) - نعم، موجود. وهذا استثمار في تحمل الخطأ على حساب السرعة. تتيح لك ميزة ذاكرة التخزين المؤقت القريبة من هرتز تقليل السعر - سيتم تخزين البيانات الواردة من العقد الأخرى في المجموعة مؤقتًا.
ما الذي يمكن عمله في مثل هذه الظروف لزيادة السرعة؟
على سبيل المثال، لتجنب تسلسل المفتاح في (2) - قم بإرفاق ذاكرة تخزين مؤقت أخرى أعلى Hazelcast، للحصول على أهم البيانات. اختار سبورتماستر الكافيين لهذا الغرض.
بالنسبة للالتواء عند المستوى (6)، يقدم هرتز نوعين من التخزين: IMap وReplicatedMap.
ومن الجدير بالذكر كيف دخلت Hazelcast إلى مجموعة تكنولوجيا Sportmaster.
في عام 2012، عندما كنا نعمل على الإصدار التجريبي الأول للموقع المستقبلي، كان Hazelcast هو الرابط الأول الذي أعاده محرك البحث. بدأ التعارف "في المرة الأولى" - لقد انبهرنا بحقيقة أنه بعد ساعتين فقط، عندما قمنا بتثبيت هرتز في النظام، نجح الأمر. وقد عملت بشكل جيد. بحلول نهاية اليوم، أكملنا عددًا من الاختبارات وكنا سعداء. وكان هذا الاحتياطي من القوة كافياً للتغلب على المفاجآت التي أحدثها هرتز مع مرور الوقت. الآن ليس لدى فريق Sportmaster أي سبب للتخلي عن Hazelcast.
لكن الحجج مثل "الرابط الأول في محرك البحث" و"تم تجميع HelloWorld بسرعة" هي بالطبع استثناء وسمة للحظة التي تم فيها الاختيار. تبدأ الاختبارات الحقيقية للنظام المختار بالإصدار في الإنتاج، وفي هذه المرحلة يجب عليك الانتباه عند اختيار أي نظام، بما في ذلك ذاكرة التخزين المؤقت. في الواقع، في حالتنا يمكننا القول أننا اخترنا Hazelcast عن طريق الصدفة، ولكن بعد ذلك اتضح أننا اخترنا بشكل صحيح.
بالنسبة للإنتاج، الأهم من ذلك بكثير: المراقبة، ومعالجة حالات الفشل في العقد الفردية، وتكرار البيانات، وتكلفة القياس. وهذا هو، يستحق الاهتمام بالمهام التي ستنشأ أثناء صيانة النظام - عندما يكون الحمل أعلى بعشرات المرات مما هو مخطط له، عندما نقوم بتحميل شيء ما عن غير قصد في المكان الخطأ، عندما نحتاج إلى طرح إصدار جديد من التعليمات البرمجية، واستبدال البيانات والقيام بذلك دون أن يلاحظها أحد للعملاء.
لجميع هذه المتطلبات، Hazelcast بالتأكيد يناسب الفاتورة.
يتبع
ولكن Hazelcast ليس حلا سحريا. في عام 2017، اخترنا Hazelcast لذاكرة التخزين المؤقت للمشرف، وذلك بناءً على الانطباعات الجيدة من التجربة السابقة. وقد لعب هذا دورًا رئيسيًا في نكتة قاسية للغاية، والتي بسببها وجدنا أنفسنا في موقف صعب وخرجنا منه "بطوليًا" لمدة 60 يومًا. ولكن المزيد عن ذلك في الجزء التالي.
في هذه الأثناء... كود جديد سعيد!
المصدر: www.habr.com