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

مخابئ Tarantool

لقد تحدثنا كثيرًا بالفعل عن كيفية تنفيذنا للفوترة الموحدة في MegaFon ، ولن نتطرق إلى هذا بالتفصيل ، ولكن المشروع الآن في مرحلة الاكتمال. لذلك ، مجرد القليل من الإحصائيات:



مع ما اقتربنا من مهمتنا:

• 80 مليون مشترك
• 300 مليون ملف تعريف مشترك ؛
• 2 مليار حدث معاملات لتغيير الرصيد في اليوم ؛
• 250 تيرابايت من البيانات النشطة ؛
• > 8 PB من المحفوظات ؛
• وكل هذا موجود على 5000 خادم في مراكز بيانات مختلفة.

أي أننا نتحدث عن نظام محمّل للغاية ، حيث بدأ كل نظام فرعي في خدمة 80 مليون مشترك. إذا كان لدينا سابقًا 7 مثيلات وقياس أفقي مشروط ، فقد انتقلنا الآن إلى المجال. كان هناك متراصة ، ولكن لدينا الآن DDD. النظام مغطى جيدًا بواسطة API ، مقسم إلى أنظمة فرعية ، ولكن لا يوجد ذاكرة تخزين مؤقت في كل مكان. نحن الآن نواجه حقيقة أن الأنظمة الفرعية تخلق حملاً متزايدًا باستمرار. بالإضافة إلى ذلك ، تظهر قنوات جديدة ، والتي تتطلب تزويدهم بـ 5000 طلب في الثانية لكل عملية مع زمن انتقال قدره 50 مللي ثانية في 95٪ من الحالات ، ولضمان توفرها عند مستوى 99.99٪.



بالتوازي مع ذلك ، بدأنا في إنشاء بنية الخدمات المصغرة.





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

كيفية بناء ذاكرة تخزين مؤقت للأنظمة الفرعية المغلقة؟

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



بدأنا في التفكير في كيفية التعامل مع أنظمتنا الرئيسية. الأسلوب الشائع جدًا هو التصميم المستند إلى الأحداث ، عندما نتلقى بيانات من نوع من الحافلات: إما أن يكون هذا موضوعًا من نوع كافكا ، أو تبادل RabbitMQ. يمكنك أيضًا الحصول على البيانات من Oracle: عن طريق المشغلات ، باستخدام CQN (أداة مجانية من Oracle) أو Golden Gate. نظرًا لعدم قدرتنا على الاندماج في التطبيق ، لم يكن خيارا الكتابة من خلال والكتابة الخلفية متاحين لنا.

استقبال البيانات من ناقل مرسل الرسائل

نحن نحب حقًا خيار قوائم الانتظار ومديري الرسائل. يتم استخدام RabbitMQ و Kafka بالفعل في "الفوترة الموحدة". قمنا بتجربة أحد الأنظمة وحصلنا على نتيجة ممتازة. نتلقى جميع الأحداث من RabbitMQ ونقوم بالتحميل البارد ، وكمية البيانات ليست كبيرة جدًا.





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

استرجاع البيانات من قاعدة البيانات: المشغلات

لا تزال هناك طريقة للحصول على البيانات لملء ذاكرة التخزين المؤقت من قاعدة البيانات.



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

استرجاع البيانات من قاعدة البيانات: CQN

الخيار الثاني للحصول على البيانات من قاعدة البيانات. نحن نستخدم Oracle ، ويدعم البائع حاليًا أداة مجانية واحدة فقط للحصول على البيانات من قاعدة البيانات - CQN.



تتيح لك هذه الآلية الاشتراك في إشعارات تغيير عمليات DDL أو DML. كل شيء بسيط للغاية هناك. توجد إشعارات بنمط JDBC و PL / SQL.



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



اخترنا PL / SQL لأنه يسمح لنا باعتراض الإشعار وتخزينه في جدول مؤقت في نفس قاعدة بيانات Oracle. وبهذه الطريقة يمكنك توفير بعض تكامل المعاملات.



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

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

بالنسبة للتطبيقات الثقيلة ، فإن CQN ليست مناسبة بالتأكيد. إنه جيد للتركيبات الصغيرة ، للعمل مع نوع من القواميس ، البيانات المرجعية.

استرجاع البيانات من قاعدة البيانات: Golden Gate

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





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



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

الاستنتاجات

ما هي الاستنتاجات التي يمكن استخلاصها مما سبق؟



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

PIM - عرض المواد الغذائية

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

هندسة معمارية

اسمحوا لي أن أذكرك أنه في هذه المقالة ، تعني "ذاكرة التخزين المؤقت" مزيجًا من تطبيق وقاعدة بيانات ، وهذا هو نمط الاستخدام الرئيسي لـ Tarantool.



خصوصية مشروع PIM هي أن نظام Oracle الرئيسي الأصلي "صغير" ، فقط 10 مليار سجل. يجب أن تقرأ. وأكبر مشكلة قمنا بحلها كانت إحماء ذاكرة التخزين المؤقت.



من أين بدأنا؟





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



لكن أولاً ، بضع كلمات حول بنية الكتلة.





هذا تطبيق مجزأ ، 9 أجزاء في 6 مضيفين ، موزعة على مركزي بيانات. لدينا Tarantool مع دور Replicator ، والذي يتلقى البيانات من Oracle ، ويستخدم مثيل آخر يسمى Importer للتمهيد البارد. يتم رفع إجمالي 1.1 تيرابايت من البيانات الساخنة في ذاكرة التخزين المؤقت.

التمهيد البارد

كيف تمكنا من حل مشكلة التمهيد البارد؟ تبين أن كل شيء تافه للغاية.





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



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



بعض الإحصائيات. في Oracle ، لدينا حوالي 2.5 تيرابايت من البيانات الأولية. قرأناها لمدة 5 ساعات ، وقمنا باستيرادها إلى ملف CSV. يستغرق التحميل في Tarantool مع التصفية والتطبيع 8 ساعات. ولمدة ست ساعات نلعب جذوع الأشجار المتراكمة التي تأتي إلينا من المسار. سرعة الذروة من 600 ألف سجل / ثانية. ما يصل إلى مليون في القمم. يقوم Tarantool بإدراج 1.1 تيرابايت من البيانات بسرعة 200 ألف سجل / ثانية.



الآن ، أصبح تسخين ذاكرة التخزين المؤقت بأحجام كبيرة أمرًا شائعًا بالنسبة لنا ، لأنه ليس لدينا تأثير كبير على Oracle.





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

كيف تعمل سلسلة النسخ المتماثل من Oracle إلى Tarantool

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

التقسيم

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

ماذا حدث في النهاية؟

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

ماذا لا يزال يتعين علينا القيام به؟

هذه سيناريوهات تشغيلية بشكل أساسي:

• التحكم الآلي في اتساق البيانات.
• اعمل على البرنامج النصي للتحويل Oracle Active-Standby ، سواء التبديل أو الفشل.
• تشغيل سجلات الأرشيف من GG.
• — DDL- -. , DDL , .

• «»: ? https://habr.com/ru/article/470842/
• : Tarantool https://habr.com/ru/company/mailru/blog/455694/
• Telegram Tarantool https://t.me/tarantool_news
• Tarantool - https://t.me/tarantoolru