نحن جميعا نحب القصص. نحب أن نجلس حول النار ونتحدث عن انتصاراتنا أو معاركنا الماضية أو ببساطة عن خبرتنا في العمل.
اليوم هو مجرد مثل هذا اليوم. وحتى لو لم تكن على النار الآن، فلدينا قصة لك. قصة كيف بدأنا العمل مع التخزين على Tarantool.
ذات مرة، كان لدى شركتنا زوجان من "المتراصة" و"سقف" واحد للجميع، والتي كانت هذه المتراصة تقترب منها ببطء ولكن بثبات، مما يحد من هروب شركتنا وتطورنا. وكان هناك تفاهم واضح: في يوم من الأيام سوف نصل إلى هذا السقف بقوة.
إنها الآن الأيديولوجية السائدة المتمثلة في فصل كل شيء وكل شخص، من المعدات إلى منطق الأعمال. ونتيجة لذلك، لدينا، على سبيل المثال، اثنين من مراكز البيانات المستقلة عمليا على مستوى الشبكة. وبعد ذلك أصبح كل شيء مختلفًا تمامًا.
يوجد اليوم الكثير من الأدوات والأدوات اللازمة لإجراء التغييرات في شكل CI/CD وK8S وما إلى ذلك. في الزمن "المتجانس"، لم نكن بحاجة إلى الكثير من الكلمات الأجنبية. كان يكفي مجرد تصحيح "التخزين" في قاعدة البيانات.
لكن الوقت تقدم للأمام، وتحرك معه عدد الطلبات، مما أدى في بعض الأحيان إلى إطلاق RPS بما يتجاوز قدراتنا. مع دخول بلدان رابطة الدول المستقلة إلى السوق، لم يقل الحمل على معالج قاعدة البيانات للمونوليث الأول عن 90٪، وظل RPS عند مستوى 2400. ولم تكن هذه مجرد محددات صغيرة، بل كانت استعلامات ضخمة مع مجموعة من عمليات التحقق وعمليات الانضمام التي يمكن تشغيلها تقريبًا لنصف البيانات على خلفية عمليات الإدخال والإخراج الكبيرة.
عندما بدأت مبيعات الجمعة السوداء الكاملة في الظهور على الساحة - وكان Wildberry من أوائل من أقاموها في روسيا - أصبح الوضع حزينًا تمامًا. بعد كل شيء، يزيد الحمل في مثل هذه الأيام ثلاث مرات.
أوه، هذه "الأزمنة المتجانسة"! أنا متأكد من أنك واجهت شيئًا مشابهًا، وما زلت لا تستطيع فهم كيف يمكن أن يحدث لك هذا.
ماذا يمكنك أن تفعل - الموضة متأصلة في التكنولوجيا. منذ حوالي 5 سنوات، كان علينا إعادة التفكير في أحد هذه التعديلات في شكل موقع موجود على خادم .NET وMS SQL، والذي قام بتخزين كل منطق الموقع بعناية. لقد احتفظت به بعناية شديدة لدرجة أن نشر مثل هذا المتراصة تبين أنه كان متعة طويلة وليست سهلة على الإطلاق.
استطرادا صغيرا.
في مناسبات مختلفة أقول: "إذا لم ترَ كتلةً متراصة، فأنت لم تنمو!" أنا مهتم برأيك في هذا الشأن، يرجى كتابته في التعليقات.
صوت الرعد
دعونا نعود إلى "النار" لدينا. لتوزيع عبء الوظائف "المتجانسة"، قررنا تقسيم النظام إلى خدمات صغيرة تعتمد على تقنيات مفتوحة المصدر. لأنها، على أقل تقدير، أرخص من حيث الحجم. وكان لدينا فهم بنسبة 100% أنه سيتعين علينا التوسع (والكثير). بعد كل شيء، في ذلك الوقت كان من الممكن دخول أسواق البلدان المجاورة، وبدأ عدد التسجيلات، وكذلك عدد الطلبات، في النمو بقوة أكبر.
بعد تحليل المرشحين الأوائل للانطلاق من النظام الموحد إلى الخدمات الصغيرة، أدركنا أن 80% من الكتابة فيها تأتي من أنظمة المكتب الخلفي، والقراءة من المكتب الأمامي. بادئ ذي بدء، يتعلق الأمر بزوجين من الأنظمة الفرعية المهمة بالنسبة لنا - بيانات المستخدم ونظام حساب التكلفة النهائية للبضائع بناء على معلومات حول خصومات العملاء الإضافية وكوبونات.
مسافة بادئة. من المخيف الآن أن نتخيل ذلك، ولكن بالإضافة إلى الأنظمة الفرعية المذكورة أعلاه، تمت إزالة كتالوجات المنتجات وعربة تسوق المستخدم ونظام البحث عن المنتجات ونظام تصفية كتالوجات المنتجات وأنواع مختلفة من أنظمة التوصية من متراصتنا. لتشغيل كل واحد منهم، هناك فئات منفصلة من الأنظمة المصممة بشكل ضيق، ولكن ذات مرة كانوا جميعًا يعيشون في "منزل" واحد.
لقد خططنا على الفور لنقل البيانات المتعلقة بعملائنا إلى النظام المجزأ. تتطلب إزالة وظيفة حساب التكلفة النهائية للبضائع قابلية توسعة جيدة للقراءة، لأنها خلقت أكبر حمل RPS وكان الأكثر صعوبة في التنفيذ لقاعدة البيانات (يتم تضمين الكثير من البيانات في عملية الحساب).
ونتيجة لذلك، توصلنا إلى مخطط يناسب بشكل جيد Tarantool.
في ذلك الوقت، تم اختيار مخططات للعمل مع العديد من مراكز البيانات على الأجهزة الافتراضية والأجهزة لتشغيل الخدمات الصغيرة. كما هو موضح في الأشكال، تم تطبيق خيارات النسخ المتماثل Tarantool في وضعي السيد والسيد والعبد.
بنيان. الخيار 1. خدمة المستخدم
في الوقت الحالي، هناك 24 جزءًا، كل منها يحتوي على مثيلين (واحد لكل DC)، كل ذلك في الوضع الرئيسي.
توجد في أعلى قاعدة البيانات تطبيقات يمكنها الوصول إلى النسخ المتماثلة لقاعدة البيانات. تعمل التطبيقات مع Tarantool من خلال مكتبتنا المخصصة، والتي تنفذ واجهة برنامج تشغيل Tarantool Go. ترى جميع النسخ المتماثلة ويمكنها العمل مع السيد للقراءة والكتابة. بشكل أساسي، فهو يطبق نموذج مجموعة النسخ المتماثلة، الذي يضيف منطقًا لاختيار النسخ المتماثلة، وإجراء عمليات إعادة المحاولة، وقاطع الدائرة الكهربائية، وحد المعدل.
في هذه الحالة، من الممكن تكوين سياسة اختيار النسخة المتماثلة في سياق الأجزاء. على سبيل المثال، جولة روبن.
بنيان. الخيار 2. خدمة حساب التكلفة النهائية للبضائع
قبل بضعة أشهر، ذهبت معظم طلبات حساب التكلفة النهائية للبضائع إلى خدمة جديدة، والتي، من حيث المبدأ، تعمل بدون قواعد بيانات، ولكن منذ بعض الوقت تمت معالجة كل شيء بنسبة 100٪ من خلال خدمة مع Tarantool تحت الغطاء.
تتكون قاعدة بيانات الخدمة من 4 وحدات رئيسية يقوم المزامن بجمع البيانات فيها، ويقوم كل من وحدات النسخ الرئيسية هذه بتوزيع البيانات على النسخ المتماثلة للقراءة فقط. كل سيد لديه ما يقرب من 15 نسخة متماثلة.
سواء في المخطط الأول أو في المخطط الثاني، إذا لم يتوفر أحد وحدات تحكم المجال DC، فيمكن للتطبيق تلقي البيانات في المخطط الثاني.
تجدر الإشارة إلى أن النسخ المتماثل في Tarantool مرن للغاية ويمكن تهيئته في وقت التشغيل. وفي الأنظمة الأخرى، نشأت صعوبات. على سبيل المثال، يتطلب تغيير معلمات max_wal_senders وmax_replication_slots في PostgreSQL إعادة تشغيل المعالج، الأمر الذي قد يؤدي في بعض الحالات إلى قطع الاتصالات بين التطبيق ونظام إدارة قواعد البيانات (DBMS).
ابحث واعثر!
لماذا لم نفعل ذلك "مثل الأشخاص العاديين"، بل اخترنا طريقة غير نمطية؟ ذلك يعتمد على ما يعتبر طبيعيا. يقوم العديد من الأشخاص عمومًا بإنشاء مجموعة من Mongo ونشرها عبر ثلاث وحدات تحكم المجال DC الموزعة جغرافيًا.
في ذلك الوقت، كان لدينا بالفعل مشروعان من مشاريع Redis. الأول عبارة عن ذاكرة تخزين مؤقت، والثاني عبارة عن تخزين مستمر للبيانات غير المهمة. لقد كان الأمر صعبًا للغاية معه، ويرجع ذلك جزئيًا إلى خطأنا. في بعض الأحيان كانت هناك كميات كبيرة جدًا في المفتاح، ومن وقت لآخر أصبح الموقع على ما يرام. استخدمنا هذا النظام في الإصدار الرئيسي والعبد. وكانت هناك العديد من الحالات التي حدث فيها شيء ما للسيد وتعطل النسخ المتماثل.
وهذا يعني أن Redis جيد للمهام عديمة الحالة، وليس المهام ذات الحالة. من حيث المبدأ، سمح بحل معظم المشاكل، ولكن فقط إذا كانت حلول ذات قيمة أساسية مع زوج من الفهارس. لكن Redis في ذلك الوقت كان حزينًا جدًا على المثابرة والتكرار. وبالإضافة إلى ذلك، كانت هناك شكاوى حول الأداء.
لقد فكرنا في MySQL وPostgreSQL. لكن الأول بطريقة أو بأخرى لم يلحق بنا، والثاني هو منتج متطور إلى حد ما في حد ذاته، ولن يكون من المناسب بناء خدمات بسيطة عليه.
لقد جربنا RIAK، وCassandra، وحتى قاعدة بيانات الرسم البياني. هذه كلها حلول متخصصة إلى حد ما ولم تكن مناسبة لدور الأداة العالمية العامة لإنشاء الخدمات.
في النهاية استقرنا على Tarantool.
لقد لجأنا إليه عندما كان في الإصدار 1.6. لقد كنا مهتمين به من خلال التعايش بين القيمة الرئيسية ووظيفة قاعدة البيانات العلائقية. هناك فهارس ومعاملات ومسافات ثانوية، وهي تشبه الجداول، ولكنها ليست بسيطة، حيث يمكنك تخزين أعداد مختلفة من الأعمدة فيها. لكن الميزة القاتلة في Tarantool كانت الفهارس الثانوية المدمجة مع القيمة الرئيسية والمعاملات.
كما لعب المجتمع الناطق باللغة الروسية المستجيب والمستعد للمساعدة في الدردشة دورًا أيضًا. لقد استخدمنا هذا بنشاط ونعيش مباشرة في الدردشة. ولا تنسى المثابرة اللائقة دون أخطاء وأخطاء واضحة. إذا نظرت إلى تاريخنا مع Tarantool، فقد واجهنا الكثير من الألم والإخفاقات في النسخ، لكننا لم نفقد البيانات أبدًا بسبب خطأه!
بدأ التنفيذ بداية صعبة
في ذلك الوقت، كان برنامج التطوير الرئيسي لدينا هو .NET، والذي لم يكن هناك رابط لـ Tarantool. لقد بدأنا على الفور في فعل شيء ما في Go. لقد عملت بشكل جيد مع لوا أيضًا. كانت المشكلة الرئيسية في ذلك الوقت هي تصحيح الأخطاء: في .NET، كل شيء رائع مع هذا، ولكن بعد ذلك كان من الصعب الانغماس في عالم Lua المضمن، عندما لا يكون لديك تصحيح أخطاء باستثناء السجلات. بالإضافة إلى ذلك، لسبب ما، انهار النسخ المتماثل بشكل دوري، لذلك اضطررت إلى الخوض في هيكل محرك Tarantool. لقد ساعدتنا الدردشة في هذا الأمر، وبدرجة أقل، في التوثيق، وفي بعض الأحيان كنا ننظر إلى الكود. في ذلك الوقت، كان التوثيق هكذا.
لذلك، على مدار عدة أشهر، تمكنت من التفكير والحصول على نتائج جيدة من العمل مع Tarantool. قمنا بتجميع التطورات المرجعية في git والتي ساعدت في تشكيل خدمات صغيرة جديدة. على سبيل المثال، عندما نشأت مهمة: لإنشاء خدمة صغيرة أخرى، نظر المطور إلى الكود المصدري للحل المرجعي في المستودع، ولم يستغرق إنشاء خدمة جديدة أكثر من أسبوع.
كانت هذه أوقاتًا خاصة. تقليديًا، يمكنك الذهاب إلى المسؤول في الجدول التالي وسؤاله: "أعطني جهازًا افتراضيًا". وبعد حوالي ثلاثين دقيقة كانت السيارة معك بالفعل. لقد قمت بتوصيل نفسك، وقمت بتثبيت كل شيء، وتم إرسال حركة المرور إليك.
اليوم لن يعمل هذا بعد الآن: تحتاج إلى إضافة مراقبة وتسجيل إلى الخدمة، وتغطية الوظيفة بالاختبارات، وطلب جهاز افتراضي أو التسليم إلى Kuber، وما إلى ذلك. بشكل عام، سيكون الأمر أفضل بهذه الطريقة، على الرغم من أنها ستستغرق وقتًا أطول وستكون أكثر إزعاجًا.
تقسيم وحكم. ما هي الصفقة مع لوا؟
كانت هناك معضلة خطيرة: لم تتمكن بعض الفرق من إجراء تغييرات على الخدمة بشكل موثوق به مع الكثير من المنطق في Lua. كان هذا غالبًا مصحوبًا بتوقف الخدمة عن العمل.
أي أن المطورين يعدون نوعًا من التغيير. يبدأ Tarantool في إجراء الترحيل، لكن النسخة المتماثلة لا تزال تحتوي على الكود القديم؛ بعض DDL أو أي شيء آخر يصل إلى هناك عن طريق النسخ المتماثل، وينهار الكود ببساطة لأنه لم يتم أخذه في الاعتبار. ونتيجة لذلك، تم وضع إجراء التحديث للمسؤولين على ورقة A4: إيقاف النسخ المتماثل، وتحديث هذا، وتشغيل النسخ المتماثل، وإيقاف التشغيل هنا، والتحديث هناك. كابوس!
نتيجة لذلك، نحاول الآن في أغلب الأحيان عدم القيام بأي شيء في لوا. ما عليك سوى استخدام iproto (بروتوكول ثنائي للتفاعل مع الخادم)، وهذا كل شيء. ولعل هذا هو نقص المعرفة بين المطورين، ولكن من وجهة النظر هذه فإن النظام معقد.
نحن لا نتبع دائمًا هذا السيناريو بشكل أعمى. اليوم ليس لدينا أبيض وأسود: إما كل شيء في Lua، أو كل شيء في Go. ونحن نفهم بالفعل كيف يمكننا الجمع بينهما حتى لا نواجه مشاكل الهجرة في وقت لاحق.
أين تارانتوول الآن؟
يتم استخدام Tarantool في الخدمة لحساب التكلفة النهائية للسلع مع مراعاة كوبونات الخصم، والمعروفة أيضًا باسم "المروج". كما قلت سابقًا، فهو الآن على التقاعد: يتم استبداله بخدمة كتالوج جديدة بأسعار محسوبة مسبقًا، ولكن قبل ستة أشهر تم إجراء جميع الحسابات في المروج. في السابق، كان نصف منطقها مكتوبًا بلغة لوا. قبل عامين، تم تحويل الخدمة إلى منشأة تخزين، وتمت إعادة كتابة المنطق في Go، لأن آليات الخصومات تغيرت قليلاً وكانت الخدمة تفتقر إلى الأداء.
واحدة من الخدمات الأكثر أهمية هي ملف تعريف المستخدم. أي أن جميع مستخدمي Wildberry مخزنون في Tarantool، وهناك حوالي 50 مليون منهم، وهو نظام مقسم بواسطة معرف المستخدم، وموزع عبر العديد من وحدات تحكم المجال المتصلة بخدمات Go.
وفقًا لـ RPS، كان المروج هو الرائد في السابق، حيث وصل إلى 6 آلاف طلب. في وقت ما كان لدينا 50-60 نسخة. الآن الرائد في RPS هو ملفات تعريف المستخدمين، حوالي 12 ألفًا، وتستخدم هذه الخدمة تقسيمًا مخصصًا، مقسمة على نطاقات معرفات المستخدمين. تخدم الخدمة أكثر من 20 جهازًا، لكن هذا عدد كبير جدًا، ونحن نخطط لتقليل الموارد المخصصة، لأن سعة 4-5 أجهزة كافية لها.
خدمة الجلسة هي خدمتنا الأولى على vshard وCartridge. تطلب إعداد vshard وتحديث Cartridge منا بعض الجهد، ولكن في النهاية نجح كل شيء.
كانت خدمة عرض اللافتات المختلفة على موقع الويب وفي تطبيق الهاتف المحمول من أولى الخدمات التي تم إصدارها مباشرة على Tarantool. تتميز هذه الخدمة بحقيقة أن عمرها من 6 إلى 7 سنوات ولا تزال قيد التشغيل ولم يتم إعادة تشغيلها مطلقًا. تم استخدام النسخ المتماثل ماجستير-ماجستير. لا شيء كسر من أي وقت مضى.
يوجد مثال لاستخدام Tarantool لوظيفة المرجع السريع في نظام المستودعات للتحقق بسرعة من المعلومات في بعض الحالات. لقد حاولنا استخدام Redis لهذا الغرض، لكن البيانات الموجودة في الذاكرة تشغل مساحة أكبر من Tarantool.
تعمل أيضًا خدمات قائمة الانتظار واشتراكات العملاء والقصص العصرية والسلع المؤجلة أيضًا مع Tarantool. آخر خدمة في الذاكرة تشغل حوالي 120 جيجابايت. هذه هي الخدمة الأكثر شمولاً مما سبق.
اختتام
بفضل الفهارس الثانوية المدمجة مع القيمة الرئيسية والمعاملات، يعد Tarantool مناسبًا تمامًا للبنيات القائمة على الخدمات الصغيرة. ومع ذلك، واجهنا صعوبات عند تنفيذ التغييرات على الخدمات التي تحتوي على قدر كبير من المنطق في Lua - غالبًا ما تتوقف الخدمات عن العمل. لم نتمكن من التغلب على هذا، ومع مرور الوقت توصلنا إلى مجموعات مختلفة من Lua وGo: نحن نعرف أين نستخدم لغة واحدة وأين نستخدم لغة أخرى.
ماذا تقرأ عن الموضوع
- إنشاء تطبيق عالي التحميل من الصفر باستخدام Tarantool
- اختيار قائد موثوق به في خرطوشة Tarantool
- قناة Telegram Tarantool تحتوي على أخبار حول المنتج
- ناقش Tarantool في دردشة المجتمع
المصدر: www.habr.com