كلنا نحب القصص. نحب أن نجلس بجانب النار ونتحدث عن انتصاراتنا السابقة ، أو معاركنا ، أو فقط عن تجربة عملنا.
اليوم هو مثل هذا اليوم. وحتى لو لم تكن بجانب النار الآن ولكن لدينا قصة لك. قصة كيف بدأنا العمل مع التخزين في Tarantool.
ذات مرة في شركتنا كان هناك زوجان من "monoliths" و "سقف" واحد للجميع ، والتي كانت هذه الوحدات المتراصة تقترب ببطء ولكن بثبات ، مما يحد من رحلة شركتنا ، تطورنا. وكان هناك تفاهم لا لبس فيه: في يوم من الأيام سنضرب هذا السقف بشدة.
نحن الآن تحت سيطرة أيديولوجية تقسيم كل شيء وكل شخص ، من المعدات إلى منطق الأعمال. نتيجة لذلك ، لدينا ، على سبيل المثال ، اثنين من مراكز البيانات المستقلة عمليًا على مستوى الشبكة. ثم كان كل شيء مختلفًا تمامًا.
اليوم ، هناك مجموعة من الأدوات والأدوات لإجراء تغييرات في شكل CI / CD ، K8S ، إلخ. في الوقت "المترابط" ، لم نكن بحاجة إلى الكثير من الكلمات الأجنبية. كان يكفي فقط لإصلاح "التخزين" في قاعدة البيانات.
لكن الوقت مضى قدمًا ، ومضى عدد الطلبات قدمًا معه ، وأحيانًا أطلق RPS بما يتجاوز قدراتنا. مع دخول السوق في بلدان رابطة الدول المستقلة ، لم ينخفض الحمل على معالج قاعدة البيانات لأول متراصة عن 90٪ ، وظلت RPS عند مستوى 2400. ولم تكن هذه مجرد محددات صغيرة ، ولكنها استعلامات ضخمة مع مجموعة من عمليات الفحص و JOINs التي يمكن تشغيلها تقريبًا نصف البيانات على خلفية IO كبيرة.
عندما بدأت المبيعات الكاملة لـ Black Friday بالظهور على المسرح - وبدأت Wildberries في جعلها واحدة من أولى العروض في روسيا - أصبح الوضع حزينًا تمامًا. بعد كل شيء ، فإن الحمل في مثل هذه الأيام يتضاعف ثلاث مرات.
أوه ، هذه "الأوقات المتجانسة"! أنا متأكد من أنك واجهت شيئًا مشابهًا ، وما زلت لا تستطيع فهم كيف يمكن أن يحدث لك هذا.
ما الذي يمكنك فعله - الموضة متأصلة في التكنولوجيا. حتى قبل 5 سنوات ، كان علينا إعادة التفكير في أحد هذه التعديلات في شكل موقع موجود على خادم .NET و MS SQL ، والذي احتفظ بعناية بمنطق الموقع نفسه. لقد احتفظ بها بعناية شديدة لدرجة أن قطع مثل هذا المنحدر كان متعة طويلة وصعبة للغاية.
استطرادية صغيرة.
في مناسبات مختلفة أقول: "إذا لم تكن قد رأيت المتراصة ، فأنت لم تنمو!" أنا مهتم برأيك في هذا الموضوع اكتبه من فضلك في التعليقات.
صوت الرعد
دعنا نعود إلى "نارنا". لتوزيع عبء الوظائف "المتجانسة" ، قررنا تقسيم النظام إلى خدمات مصغرة تعتمد على تقنيات مفتوحة المصدر. لأنها ، على الأقل ، أرخص في القياس. وكان فهم أنه يتعين علينا التوسع (والكثير) 100٪. في الواقع ، لقد اتضح بالفعل في ذلك الوقت دخول أسواق البلدان المجاورة ، وبدأ عدد التسجيلات ، وكذلك عدد الطلبات ، في النمو أكثر.
بعد تحليل المتقدمين الأوائل لترك المتراصة في الخدمات المصغرة ، أدركنا أنه في 80٪ منهم ، 99٪ منهم يكتبون من أنظمة المكتب الخلفي ، ويقرؤون من أنظمة الواجهة الأمامية. أولاً وقبل كل شيء ، يتعلق هذا بنظمين فرعيين مهمين بالنسبة لنا - بيانات المستخدم ونظام حساب التكلفة النهائية للبضائع بناءً على معلومات حول الخصومات والقسائم الإضافية للعملاء.
مسافة بادئة. الآن من المخيف تخيل ذلك ، ولكن بالإضافة إلى الأنظمة الفرعية المذكورة أعلاه ، تم أيضًا إخراج كتالوجات المنتجات ، وسلة المستخدم ، ونظام البحث عن المنتج ، ونظام تصفية كتالوجات المنتجات وأنظمة التوصية المختلفة من منصة لدينا. لتشغيل كل منها ، هناك فئات منفصلة من الأنظمة التي تم شحذها بشكل ضيق ، ولكن في وقت واحد كانوا يعيشون جميعًا في "منزل صغير" واحد.
خططنا لنقل البيانات حول عملائنا إلى نظام مُقسَّم. تطلبت إزالة وظيفة حساب التكلفة النهائية للسلع قابلية جيدة للقراءة ، لأنها خلقت أكبر حمل RPS وكان الأكثر صعوبة في التنفيذ لقاعدة البيانات (يتم تضمين الكثير من البيانات في عملية الحساب).
نتيجة لذلك ، لدينا مخطط يعمل بشكل جيد مع Tarantool.
في ذلك الوقت ، من أجل تشغيل الخدمات المصغرة ، تم اختيار مخططات للعمل مع عدة مراكز بيانات على الأجهزة الافتراضية والأجهزة. كما هو موضح في الأشكال ، تم تطبيق خيارات النسخ المتماثل لـ Tarantool في كلا الوضعين الرئيسي - الرئيسي - السيد - التابع.
هندسة معمارية. الخيار 1. خدمة المستخدم
في الوقت الحالي هناك 24 قطعة ، لكل منها مثيلين (واحد لكل DC) ، وكلها في الوضع الرئيسي - الرئيسي.
في أعلى قاعدة البيانات توجد التطبيقات التي تصل إلى النسخ المتماثلة لقاعدة البيانات. تعمل التطبيقات مع Tarantool من خلال مكتبتنا المخصصة ، والتي تنفذ واجهة برنامج تشغيل Tarantool Go. ترى جميع النسخ المتماثلة ويمكنها العمل مع المعلم للقراءة والكتابة. في الواقع ، يقوم بتنفيذ نموذج مجموعة النسخ المتماثلة ، والذي يضيف منطق اختيار النسخ المتماثلة وإجراء عمليات إعادة المحاولة وقاطع الدائرة وحد المعدل.
في الوقت نفسه ، من الممكن تكوين سياسة اختيار نسخة متماثلة في سياق جزء. على سبيل المثال ، roundrobin.
هندسة معمارية. الخيار 2. خدمة لحساب التكلفة النهائية للسلع
منذ عدة أشهر ، ذهبت معظم طلبات حساب التكلفة النهائية للسلع إلى خدمة جديدة ، تعمل ، من حيث المبدأ ، بدون قواعد بيانات ، ولكن منذ بعض الوقت كانت تتم معالجتها بنسبة 100٪ بواسطة الخدمة مع Tarantool تحت الغطاء.
قاعدة بيانات الخدمة عبارة عن 4 وحدات رئيسية يقوم المزامن بجمع البيانات فيها ، ويقوم كل من هذه النسخ الرئيسية بتوزيع البيانات على النسخ المتماثلة للقراءة فقط. كل سيد لديه حوالي 15 سطرًا.
في كلا النظامين الأول والثاني ، إذا كان أحد DC غير متوفر ، يمكن للتطبيق تلقي البيانات في الثانية.
وتجدر الإشارة إلى أن النسخ المتماثل في Tarantool مرن للغاية وقابل للتكوين في وقت التشغيل. في أنظمة أخرى ، كانت هناك صعوبات. على سبيل المثال ، يتطلب تغيير معلمات max_wal_senders و max_replication_slots في PostgreSQL إعادة تشغيل المعالج ، مما قد يؤدي في بعض الحالات إلى قطع الاتصال بين التطبيق ونظام إدارة قواعد البيانات.
تسعى وسوف تجد!
لماذا لم نفعل ذلك "مثل الناس العاديين" ، لكننا اخترنا طريقة غير نمطية؟ هذا يعتمد على ما يعتبر طبيعيا. يصنع العديد من الأشخاص عمومًا كتلة من مونغو وينشرونها على ثلاثة مراكز توزيع جغرافية موزعة جغرافيًا.
في ذلك الوقت ، كان لدينا بالفعل مشروعين على Redis. الأول عبارة عن ذاكرة تخزين مؤقت ، والثاني هو تخزين دائم للبيانات غير الهامة للغاية. كان الأمر صعبًا معه ، جزئيًا بسبب خطأنا. في بعض الأحيان كانت هناك أحجام كبيرة جدًا في المفتاح ، ومن وقت لآخر شعر الموقع بالسوء. استخدمنا هذا النظام في إصدار السيد والعبد. وكان هناك العديد من الحالات عندما حدث شيء ما للسيد وانكسر التكرار.
وهذا يعني أن Redis جيد للمهام عديمة الجنسية ، وليس المهام ذات الحالة. من حيث المبدأ ، سمح بحل معظم المشكلات ، ولكن فقط إذا كانت هذه حلول ذات قيمة أساسية بزوج من المؤشرات. لكن في ذلك الوقت ، كان ريديس حزينًا جدًا مع المثابرة والتكرار. بالإضافة إلى ذلك ، كانت هناك شكاوى حول الأداء.
التفكير في MySQL و PostgreSQL. لكن الأول لم يتجذر معنا بطريقة ما ، والثاني منتج معقد إلى حد ما بحد ذاته ، وسيكون من غير المناسب بناء خدمات بسيطة عليه.
جربنا RIAK و Cassandra وحتى قاعدة بيانات الرسم البياني. كل هذه حلول متخصصة تمامًا لا تتناسب مع دور أداة عالمية عامة لإنشاء الخدمات.
في النهاية ، استقرنا على Tarantool.
لقد تواصلنا معه عندما كان في الإصدار 1.6. كنا مهتمين بها في تكافل قيمة المفتاح ووظيفة قاعدة البيانات العلائقية. هناك فهارس ثانوية ومعاملات ومسافات ، فهي مثل الجداول ، ولكنها ليست بسيطة ، يمكنك تخزين عدد مختلف من الأعمدة فيها. لكن ميزات Tarantool القاتلة كانت فهارس ثانوية مقترنة بقيمة المفتاح والمعاملات.
لعب المجتمع الناطق بالروسية المستجيب دورًا أيضًا ، وعلى استعداد للمساعدة في الدردشة. استخدمنا هذا بنشاط وعشنا في الدردشة مباشرة. ولا تنسى الإصرار اللائق دون أخطاء واضحة وعضادات. إذا نظرت إلى تاريخنا مع Tarantool ، فقد واجهنا الكثير من الآلام والتزوير في النسخ المتماثل ، لكننا لم نفقد البيانات أبدًا بسبب خطأه!
بدأ التنفيذ صعبًا
في ذلك الوقت ، كانت حزمة التطوير الرئيسية لدينا هي .NET ، والتي لم يكن هناك موصل لها لـ Tarantool. بدأنا على الفور في فعل شيء ما في Go. عملت Lua بشكل جيد أيضًا. كانت المشكلة الرئيسية في ذلك الوقت مع تصحيح الأخطاء: في .NET كل شيء رائع مع هذا ، وبعد ذلك كان من الصعب الانغماس في عالم Lua المضمن ، عندما كنت ، إلى جانب السجلات ، ليس لديك تصحيح أخطاء ، كان صعبًا. بالإضافة إلى ذلك ، انهار التكرار بشكل دوري لسبب ما ، لذلك كان عليّ الخوض في هيكل محرك Tarantool. ساعدت الدردشة في هذا ، إلى حد أقل - التوثيق ، وأحيانًا نظرت إلى الكود. في ذلك الوقت ، كانت الوثائق على ما يرام.
لذلك ، في غضون بضعة أشهر ، تمكنت من ملء الأقماع والحصول على نتائج جيدة عند العمل مع Tarantool. قمنا بإضفاء الطابع الرسمي على التطورات المرجعية في git ، مما ساعد في تكوين خدمات مصغرة جديدة. على سبيل المثال ، عندما ظهرت المهمة: لإنشاء خدمة مصغرة أخرى ، نظر المطور في الكود المصدري للحل المرجعي في المستودع ، ولم يستغرق الأمر أكثر من أسبوع لإنشاء خدمة جديدة.
كانت هذه أوقاتًا خاصة. بشكل تقليدي ، كان من الممكن حينها الاتصال بالمسؤول على الجدول التالي واسأله: "أعطني آلة افتراضية". بعد ثلاثين دقيقة كان لديك السيارة بالفعل. أنت نفسك متصل ، وثبت كل شيء ، وحصلت على حركة المرور إليه.
اليوم لن يعمل على هذا النحو: تحتاج إلى إنهاء المراقبة وتسجيل الدخول إلى الخدمة وتغطية الوظائف بالاختبارات وطلب جهاز افتراضي أو تزويد Kuber ، إلخ بشكل عام ، سيكون أفضل ، رغم أنه أطول وأكثر إزعاجًا.
فرق تسد. ماذا عن لوا؟
كانت هناك معضلة خطيرة: لم تتمكن بعض الفرق من إجراء تغييرات موثوقة في خدمة بها الكثير من منطق Lua. كان هذا غالبًا مصحوبًا بعدم قابلية تشغيل الخدمة.
أي أن المطورين يستعدون لنوع من التغيير. يبدأ Tarantool الترحيل ، ولا تزال النسخة المتماثلة تحتوي على الكود القديم ؛ بعض DDL ، شيء آخر ، يصل إلى هناك عن طريق النسخ المتماثل ، ويتفكك الرمز ببساطة ، لأنه لا يؤخذ في الاعتبار. نتيجة لذلك ، تمت جدولة إجراء التحديث للمسؤولين على الورقة A4: إيقاف النسخ المتماثل ، وتحديثه ، وتمكين النسخ المتماثل ، وإيقاف تشغيله هنا ، والتحديث هناك. كابوس!
نتيجة لذلك ، نحاول الآن في أغلب الأحيان عدم القيام بأي شيء في Lua. فقط باستخدام iproto (بروتوكول ثنائي للتواصل مع الخادم) ، وهذا كل شيء. ربما يكون هذا نقصًا في المعرفة بين المطورين ، ولكن من وجهة النظر هذه ، فإن النظام معقد.
نحن لا نتبع هذا السيناريو دائمًا بشكل أعمى. اليوم ليس لدينا أبيض وأسود: إما أن يكون كل شيء في Lua ، أو كل شيء في Go. نحن نفهم بالفعل كيف يمكنك دمجها حتى لا تواجهك مشكلات في الترحيل لاحقًا.
أين تارانتول الآن؟
يستخدم Tarantool في خدمة حساب التكلفة النهائية للسلع ، مع الأخذ في الاعتبار كوبونات الخصم ، المعروف أيضا باسم "المروج". كما قلت سابقًا ، فقد تقاعد الآن: يتم استبداله بخدمة كتالوج جديدة بأسعار محسوبة مسبقًا ، ولكن قبل ستة أشهر ، تم إجراء جميع الحسابات في شركة Promoter. في السابق ، كان نصف منطقها مكتوبًا بلغة لوا. منذ عامين ، تم إنشاء تخزين من الخدمة ، وتمت إعادة كتابة المنطق إلى Go ، لأن آليات الخصومات تغيرت قليلاً وافتقرت الخدمة إلى الأداء.
يعد ملف تعريف المستخدم من أكثر الخدمات أهمية. أي أنه يتم تخزين جميع مستخدمي Wildberries في Tarantool ، ويوجد حوالي 50 مليونًا منهم ، وهو نظام مُقسَّم حسب معرّف المستخدم ، وموزع على عدة مراكز تحكم متصلة بخدمات Go.
وفقًا لـ RPS ، كان "Promoter" في يوم من الأيام الرائد ، حيث وصل إلى 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 habr.com/ru/company/mailru/blog/510440
- اختيار القائد الموثوق به في خرطوشة Tarantool habr.com/ru/company/mailru/blog/513912
- قناة Tarantool Telegram مع أخبار المنتج t.me/tarantool_news
- مناقشة Tarantool في دردشة المجتمع t.me/tarantoolru