بنية إعداد الفواتير من الجيل التالي: الانتقال إلى Tarantool

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



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

مشروع الفواتير واحد

المشروع الذي سيتم مناقشته يسمى "الفواتير الفردية". لقد أظهر فيه تارانتول أفضل صفاته.



لم يواكب نمو أداء أجهزة Hi-End نمو قاعدة المشتركين والنمو في عدد الخدمات ، كما كان من المتوقع حدوث نمو أكبر في عدد المشتركين والخدمات بسبب M2M و IoT ، وميزات الفروع أدت إلى تدهور وقت السوق. قررت الشركة إنشاء نظام أعمال موحد بهندسة نمطية فريدة من نوعها على مستوى عالمي ، بدلاً من 8 أنظمة فوترة مختلفة حالية.

MegaFon هي ثماني شركات في واحدة . في عام 2009 ، تم الانتهاء من إعادة التنظيم: تم دمج فروع في جميع أنحاء روسيا في شركة واحدة MegaFon OJSC (الآن PJSC). وبالتالي ، فإن الشركة لديها 8 أنظمة فوترة مع حلولها "المخصصة" الخاصة بها ، وميزات الفروع وهيكل تنظيمي مختلف وتكنولوجيا المعلومات والتسويق.

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

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

التحجيم العمودي . حتى أروع الحديد في ذلك الوقت لم يلبي الاحتياجات. استخدمنا معدات Hewlett-Packard ، خط Superdome Hi-End ، لكنه لم يستلزم الحاجة حتى لفرعين. أردت التوسع الأفقي دون تكاليف المعاملات الكبيرة واستثمارات رأس المال.

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

التحديات التكنولوجية

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

التدرجية

إذا كان هناك في وقت سابق ، دعنا نقول ، 8 حسابات فواتير لـ 15 مليون مشترك ، والآن 100 مليون مشترك ، وكان من المفترض أن يكون عدد المشتركين قد تجاوزوا - كان الحمل أعلى من حيث الحجم.

لقد أصبحنا مماثلين في الحجم لمشغلي الإنترنت الرئيسيين مثل Mail.ru أو Netflix.

لكن المزيد من الحركة لزيادة الحمل وقاعدة المشتركين شكلت تحديات خطيرة بالنسبة لنا.

جغرافية بلادنا الشاسعة

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

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

خطأ التسامح

هذا هو الجانب الآخر من المركزية.

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

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

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

تجربة العالم

والمثير للدهشة أننا لم نجد إشارة واحدة في عالم الاتصالات.

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

لتحليل البنية ، تم تجميع Dream Team ، بقيادة IBM ، مهندسين من مختلف المجالات. يمكن لهؤلاء الأشخاص تقييم ما نقوم به على نحو كاف وتقديم معرفة معينة إلى بنيتنا.

سلم

بعض الأرقام لتوضيح.

نقوم بتصميم نظام لـ 80 مليون مشترك مع احتياطي مليار . لذلك نحن نزيل العتبات المستقبلية. هذا ليس لأننا سنتولى السيطرة على الصين ، ولكن بسبب ضغط إنترنت الأشياء و M2M.

تتم معالجة 300 مليون وثيقة في الوقت الحقيقي . على الرغم من أن لدينا 80 مليون مشترك ، فإننا نعمل مع العملاء المحتملين وأولئك الذين تركونا إذا احتجنا إلى تحصيل المستحقات. لذلك ، المجلدات الحقيقية أكبر بكثير.

2 مليار معاملة تغير الرصيد يوميا - هذه هي المدفوعات والرسوم والمكالمات وغيرها من الأحداث. 200 تيرابايت من البيانات تتغير بشكل نشط ، 8 PB من البيانات تتغير بشكل أبطأ قليلاً ، وهذا ليس أرشيفًا ، لكنه بيانات حية في فوترة واحدة. مقياس مركز البيانات هو 5 آلاف خادم في 14 موقعًا .

كومة التكنولوجيا

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



المكدس يشبه مكدسات اللاعبين الرئيسيين الآخرين: Netflix و Twitter و Viber. يتكون من 6 مكونات ، لكننا نريد تقليله وتوحيده.

المرونة جيدة ، لكن في شركة كبيرة لا توجد وسيلة بدون توحيد.

لن نقوم بتغيير نفس Oracle إلى Tarantool. في واقع الشركات الكبيرة ، هذا هو اليوتوبيا ، أو حملة صليبية لمدة 5-10 سنوات مع نتيجة غير مفهومة. لكن يمكن استبدال Cassandra و Couchbase بـ Tarantool ، ونحن ملتزمون بهذا.

لماذا تارانتول؟

هناك 4 معايير بسيطة لماذا اخترنا قاعدة البيانات هذه.

السرعة . أجرينا اختبارات الإجهاد على الأنظمة الصناعية MegaFon. فاز Tarantool - أظهر أفضل أداء.

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

يغطي Tarantool احتياجات الشركة حتى على المدى الطويل.

تكلفة التكلفة الإجمالية للملكية . يكلف دعم Couchbase على وحدات تخزين MegaFon أموالًا كبيرة ، مع Tarantool ، يكون الموقف أجمل كثيرًا ، وفيما يتعلق بالوظائف الوظيفية فهي قريبة.

ميزة أخرى لطيفة أثرت قليلاً على خيارنا - Tarantool يعمل بشكل أفضل من قواعد البيانات الأخرى مع الذاكرة. هذا يظهر أقصى قدر من الكفاءة .

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

لقد استثمرنا وقتنا وأموالنا ، وجنبا إلى جنب مع Mail.ru أنشأنا إصدار مؤسسة ، والذي تستخدمه الآن العديد من الشركات الأخرى.

راحت Tarantool-enterprise راضية تمامًا عن الأمان والموثوقية والتسجيل.

شراكة

أهم شيء بالنسبة لي هو الاتصال المباشر مع المطور . هذا هو بالضبط ما رشوة رفاق Tarantool.

إذا كنت تأتي إلى لاعب ، خاصةً من يعمل مع عميل رئيسي ، وتقول إنك بحاجة إلى قاعدة البيانات لتتمكن من القيام بذلك ، هذا وذاك ، وعادةً ما يجيب:

- حسنًا ، ضع المتطلبات أسفل هذا الكومة - في يوم من الأيام ، على الأرجح ، سنصل إليها.

لدى الكثير منها خارطة طريق لمدة 2-3 سنوات مقبلة ، ويكاد يكون من المستحيل الاندماج هناك ، ويطوّر مطورو Tarantool الانفتاح ، وليس فقط مع MegaFon ، ويتكيفون مع نظامهم مع العميل. هذا رائع ونحب حقًا.

أين نطبق Tarantool

فينا يستخدم Tarantool في عدة عناصر. الأول هو في الطيار ، الذي قطعناه على نظام دليل العنوان. في وقت واحد ، أردت أن يكون نظامًا مشابهًا لنظامي Yandex.Maps وخرائط Google ، لكنه اتضح بشكل مختلف بعض الشيء.

على سبيل المثال ، دليل العناوين في واجهة المبيعات. في Oracle ، يستغرق البحث عن العنوان الذي تحتاجه 12-13 ثانية. - أرقام غير مريحة. عندما نتحول إلى Tarantool ، نستبدل Oracle بقاعدة بيانات أخرى في وحدة التحكم ، ونجري نفس البحث ، نحصل على تسريع 200 مرة! المدينة للملوثات العضوية الثابتة بعد الحرف الثالث. الآن نقوم بتكييف الواجهة بحيث يحدث هذا بعد الأول. ومع ذلك ، فإن سرعة الاستجابة مختلفة تمامًا - ميلي ثانية بالفعل بدلاً من ثواني.

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



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

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

ربما تكون Microservices هي الدور الرئيسي لـ Tarantool في MegaFon.

حيث نخطط لتطبيق Tarantool

إذا قارنا مشروع الفوترة الناجح الخاص بنا مع برامج التحول في Deutsche Telekom و Svyazkome و Vodafone India ، فهو ديناميكي وخلاق بشكل مدهش. في عملية تنفيذ هذا المشروع ، لم يتم تحويل MegaFon وهيكلته فحسب ، ولكن ظهرت أيضًا Tarantool-enterprise على Mail.ru ، وكان لدى بائعنا Nexign (المعروف سابقًا باسم Peter-Service) حل BSS Box (حل الفواتير المعبأ في الصندوق).

بمعنى ما ، هذا مشروع تاريخي للسوق الروسية. يمكن مقارنته بما هو موصوف في كتاب فريدريك بروكس "شهر الأسطوري". ثم ، في الستينيات ، جذبت IBM 5000 شخص لتطوير نظام تشغيل OS / 360 جديد للإطارات الرئيسية. لدينا أقل - 1800 ، ولكن لدينا في سترات واقية ، ومع الأخذ في الاعتبار استخدام المصادر المفتوحة والنهج الجديدة ، ونحن نعمل بشكل أكثر إنتاجية.

يتم عرض نطاقات الفوترة أو ، على نطاق أوسع ، أنظمة الأعمال أدناه. يعرف الأشخاص في المؤسسة CRM جيدًا. يجب أن يكون لدى الجميع بالفعل أنظمة أخرى: Open API ، Gateway API.

افتح API

دعنا ننظر مرة أخرى إلى الأرقام وكيف تعمل واجهة برمجة التطبيقات المفتوحة الآن. حمله هو 10000 المعاملات في الثانية الواحدة . نظرًا لأننا نخطط لتطوير طبقة الخدمات الميكروية بفعالية وبناء واجهة برمجة تطبيقات MegaFon العامة ، فإننا نتوقع مزيدًا من النمو في المستقبل في هذا الجزء بالذات. 100،000 المعاملات ستكون بالتأكيد .

لا أعرف ما إذا كان SSO مماثلًا لـ Mail.ru - فالرجال ، مثلهم ، لديهم 1،000،000 معاملة في الثانية الواحدة. نحن مهتمون للغاية بحلهم ونخطط للتعلم من تجربتهم - على سبيل المثال ، لإنشاء احتياطي SSO وظيفي باستخدام Tarantool. الآن المطورين من Mail.ru يفعلون هذا معنا.

CRM

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

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

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

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

أكثر مكونات الاتصالات في الاتصالات المتنقلة هي الفواتير عبر الإنترنت . هذه هي الأنظمة التي تسمح لك بالاتصال أو عدم الاتصال ، واتخاذ قرار في الوقت الفعلي. هنا ، يبلغ الحمل 30،000 معاملة في الثانية ، ولكن مع الأخذ في الاعتبار النمو في نقل البيانات ، نخطط لـ 250،000 معاملة ، وبالتالي نحن مهتمون جدًا بـ Tarantool.

الصورة السابقة هي المجالات التي سنستخدم فيها Tarantool. إدارة علاقات العملاء نفسها ، بطبيعة الحال ، أوسع وسنطبقها في جوهرها نفسه.

لدينا TTX المقدرة من 100 مليون مشترك يربك لي كمهندس معماري - ماذا لو 101 مليون؟ لإعادة كل شيء مرة أخرى؟ لمنع هذا ، نستخدم ذاكرة التخزين المؤقت ، وفي نفس الوقت نرفع إمكانية الوصول.



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

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

لذلك هناك أقل من rassynchron - نظام واحد مسؤول عن ذاكرة التخزين المؤقت وعن المصدر الرئيسي الرئيسي.

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

RTO و RPO

هناك فترتان في IT - RTO و RPO .

هدف وقت الاسترداد هو الوقت المناسب لاستعادة الخدمة بعد الفشل. RTO = 0 تعني أنه حتى في حالة حدوث شيء ما ، تستمر الخدمة في العمل.

الهدف من نقطة Rrecovery هو وقت استعادة البيانات ، وكم البيانات التي يمكن أن نفقدها خلال فترة زمنية. RPO = 0 يعني أننا لا نفقد البيانات.

التحدي Tarantool

دعونا نحاول حل مشكلة Tarantool.

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

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

النهج المعماري القديم الجيد هنا - تحتاج إلى معرفة الموضوع بشكل جيد وعلى حسابها حل هذا الرفض.



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

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

نحن في البداية نبني حلاً موزَّعًا جغرافيًا - تسامح الأعطال مهم بالنسبة لنا

لذلك ، لدينا مجموعة ، ولكن ماذا عن RPO = 0 و RTO = 0؟ الحل بسيط ، والذي يعتمد على الموضوع.

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

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

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

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

كاساندرا وتارانتول معا

هناك حالة أخرى - "عرض الأرصدة" . هنا مجرد حالة مثيرة للاهتمام للاستخدام المشترك من كاساندرا وتارانتول.

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

يتيح لك Cassandra إمكانية القياس أفقيًا على أي وحدة تخزين.

نشعر بالراحة مع كاساندرا ، لكن لديها مشكلة واحدة - إنها ليست جيدة في القراءة. , 30 000 — .

, : , - , Cassandra. , IBM manager file transfer — , , UDP, , TCP. , , , - , — .

, . Kafka Tarantool, , , , , , , 100 2 .

, 2 , , .

استنتاج

Tarantool. Mail.ru, .

BCG McKinsey, Accenture IBM - — , , , , . , Tarantool . .

— Tarantool Conference , 17 T+ Conference 2019 « Tarantool Enterprise» . « Tarantool Oracle» . , , . — , . : , Tarantool, , , .