معماری صدور صورت حساب نسل جدید: تحول با انتقال به Tarantool

چرا شرکتی مانند مگافون در صورتحساب به Tarantool نیاز دارد؟ از بیرون به نظر می رسد که فروشنده معمولا می آید، نوعی جعبه بزرگ می آورد، دوشاخه را به پریز وصل می کند - و این یعنی صورتحساب! زمانی چنین بود، اما اکنون باستانی است و چنین دایناسورهایی قبلاً منقرض شده اند یا در حال انقراض هستند. در ابتدا، صورتحساب یک سیستم برای صدور فاکتورها - یک ماشین شمارش یا ماشین حساب است. در مخابرات مدرن این است سیستم اتوماسیون برای کل چرخه زندگی تعامل با یک مشترک از انعقاد قرارداد تا فسخ، از جمله صورتحساب بلادرنگ، پذیرش پرداخت و موارد دیگر. صورتحساب در شرکت های مخابراتی مانند یک ربات جنگی است - بزرگ، قدرتمند و مملو از سلاح.

ترانتول چه ربطی بهش داره؟ آنها در مورد آن صحبت خواهند کرد اولگ ایولف и آندری کنیازف. اولگ معمار ارشد شرکت است مگافون آندری با تجربه گسترده کار در شرکت های خارجی، مدیر سیستم های تجاری است. از متن گزارش آنها در کنفرانس Tarantool 2018 شما خواهید آموخت که چرا تحقیق و توسعه در شرکت ها مورد نیاز است، Tarantool چیست، چگونه بن بست مقیاس عمودی و جهانی شدن پیش نیازهای ظاهر این پایگاه داده در شرکت شد، در مورد چالش های تکنولوژیکی، تحولات معماری، و اینکه چگونه تکنواستاک MegaFon شبیه به Netflix است. ، گوگل و آمازون.

پروژه "صورتحساب یکپارچه"

پروژه مورد نظر "صورتحساب واحد" نام دارد. اینجا بود که ترانتول بهترین ویژگی های خود را نشان داد.

رشد بهره‌وری تجهیزات Hi-End همگام با رشد پایه مشترکین و رشد تعداد خدمات نبود؛ رشد بیشتر در تعداد مشترکین و خدمات به دلیل ویژگی‌های M2M، IoT و شعبه انتظار می‌رفت. به وخامت زمان ورود به بازار. این شرکت تصمیم گرفت به جای 8 سیستم صورتحساب مختلف فعلی، یک سیستم تجاری واحد با معماری مدولار منحصر به فرد در سطح جهانی ایجاد کند.

MegaFon هشت شرکت در یک است. در سال 2009، سازماندهی مجدد تکمیل شد: شعب در سراسر روسیه در یک شرکت واحد، MegaFon OJSC (اکنون PJSC) ادغام شدند. بنابراین، این شرکت دارای 8 سیستم صورتحساب با راه حل های "سفارشی"، ویژگی های شعبه و ساختارهای مختلف سازمانی، فناوری اطلاعات و بازاریابی است.

همه چیز خوب بود تا اینکه مجبور شدیم یک محصول مشترک فدرال را عرضه کنیم. در اینجا مشکلات زیادی به وجود آمد: برای برخی، تعرفه ها گرد می شوند، برای دیگران گرد می شوند، و برای برخی دیگر - بر اساس میانگین حسابی. هزاران لحظه از این دست وجود دارد.

علیرغم این واقعیت که تنها یک نسخه از سیستم صورتحساب وجود داشت، یک تامین کننده، تنظیمات آنقدر متفاوت بود که زمان زیادی طول کشید تا کنار هم قرار گیرند. ما سعی کردیم تعداد آنها را کاهش دهیم و به مشکل دومی برخوردیم که برای بسیاری از شرکت ها آشناست.

مقیاس بندی عمودی. حتی جالب ترین سخت افزارهای آن زمان هم جوابگوی نیازها نبود. ما از تجهیزات Hewlett-Packard از خط Superdome Hi-End استفاده کردیم، اما پاسخگوی نیازهای حتی دو شعبه نبود. من مقیاس افقی را بدون هزینه های عملیاتی زیاد و سرمایه گذاری می خواستم.

انتظار رشد در تعداد مشترکین و خدمات. مشاوران مدت‌هاست که داستان‌هایی درباره اینترنت اشیا و M2M به دنیای مخابرات آورده‌اند: زمانی فرا می‌رسد که هر تلفن و اتو یک سیم‌کارت و دو تا در یخچال داشته باشد. امروز ما یک تعداد مشترک داریم، اما در آینده نزدیک تعداد آنها بسیار بیشتر خواهد بود.

چالش های تکنولوژیکی

این چهار دلیل ما را به ایجاد تغییرات جدی ترغیب کرد. بین ارتقای سیستم و طراحی از ابتدا یک انتخاب وجود داشت. ما برای مدت طولانی فکر کردیم، تصمیمات جدی گرفتیم، مناقصه بازی کردیم. در نتیجه، ما از همان ابتدا تصمیم به طراحی گرفتیم و چالش های جالبی را به عهده گرفتیم - چالش های تکنولوژیکی.

مقیاس پذیری

اگر قبلا بود، بگوییم، بگوییم 8 قبض برای 15 میلیون مشترک، و حالا باید کار می کرد 100 میلیون مشترک و بیشتر - بار یک مرتبه بزرگتر است.

ما در مقیاس با پخش کننده های اینترنتی بزرگ مانند Mail.ru یا Netflix قابل مقایسه شده ایم.

اما حرکت بیشتر برای افزایش بار و پایه مشترک، چالش های جدی را برای ما ایجاد کرده است.

جغرافیای کشور پهناور ما

بین کالینینگراد و ولادی وستوک 7500 کیلومتر و 10 منطقه زمانی. سرعت نور محدود است و در چنین فواصلی تأخیرها از قبل قابل توجه است. 150 میلی‌ثانیه در جالب‌ترین کانال‌های نوری مدرن برای صورت‌حساب بلادرنگ بسیار زیاد است، به خصوص که اکنون در مخابرات روسیه وجود دارد. علاوه بر این، شما باید در یک روز کاری به روز رسانی کنید، و با مناطق زمانی مختلف این یک مشکل است.

ما فقط با هزینه اشتراک خدمات ارائه نمی کنیم، ما تعرفه ها، بسته ها و اصلاح کننده های مختلفی داریم. ما باید نه تنها به مشترک اجازه صحبت کنیم یا آن را رد کنیم، بلکه یک سهمیه مشخص به او بدهیم - تماس ها و اقدامات را در زمان واقعی محاسبه کنیم تا متوجه نشود.

تحمل خطا

این طرف دیگر تمرکز است.

اگر همه مشترکین را در یک سیستم جمع آوری کنیم، هر گونه رویداد اضطراری و فاجعه برای تجارت فاجعه بار است. بنابراین سیستم را به گونه ای طراحی می کنیم که تاثیر تصادفات را بر کل پایگاه مشترک از بین ببریم.

این دوباره نتیجه امتناع از مقیاس عمودی است. هنگامی که به صورت افقی مقیاس بندی کردیم، تعداد سرورها را از صدها به هزاران افزایش دادیم. آنها باید مدیریت شوند و قابل تعویض باشند، به طور خودکار از زیرساخت فناوری اطلاعات پشتیبان تهیه کنند و سیستم توزیع شده را بازیابی کنند.

ما با چنین چالش های جالبی روبرو بودیم. ما سیستم را طراحی کردیم و در آن لحظه سعی کردیم بهترین شیوه های جهانی را پیدا کنیم تا بررسی کنیم که چقدر در روند هستیم، چقدر از فناوری های پیشرفته پیروی می کنیم.

تجربه جهانی

با کمال تعجب، ما یک مرجع واحد را در مخابرات جهانی پیدا نکردیم.

اروپا از نظر تعداد مشترکین و مقیاس، ایالات متحده - از نظر یکنواختی تعرفه های خود، سقوط کرده است. ما تعدادی را در چین بررسی کردیم و تعدادی را در هند یافتیم و متخصصانی را از Vodafone هند استخدام کردیم.

برای تجزیه و تحلیل معماری، ما یک تیم رویایی به رهبری IBM - معمارانی از زمینه های مختلف را جمع آوری کردیم. این افراد می‌توانستند آنچه را که ما انجام می‌دادیم به اندازه کافی ارزیابی کنند و دانش خاصی را به معماری ما بیاورند.

مقیاس

چند عدد برای مثال.

ما سیستم را برای 80 میلیون مشترک با ذخیره یک میلیاردی. به این ترتیب آستانه های آینده را حذف می کنیم. این به این دلیل نیست که ما قصد داریم چین را تسخیر کنیم، بلکه به دلیل هجوم IoT و M2M است.

300 میلیون سند در زمان واقعی پردازش شده است. اگرچه ما 80 میلیون مشترک داریم، اما در صورت نیاز به جمع آوری مطالبات، هم با مشتریان احتمالی و هم با کسانی که ما را ترک کرده اند کار می کنیم. بنابراین، حجم واقعی به طور قابل توجهی بزرگتر است.

2 میلیارد تراکنش موجودی روزانه تغییر می کند - اینها پرداخت ها، هزینه ها، تماس ها و سایر رویدادها هستند. 200 ترابایت داده به طور فعال در حال تغییر است، کمی کندتر تغییر دهید 8 PB داده، و این یک بایگانی نیست، بلکه داده های زنده در یک صورتحساب واحد است. مقیاس بر اساس مرکز داده - 5 هزار سرور در 14 سایت.

پشته فناوری

زمانی که معماری را برنامه ریزی کردیم و شروع به مونتاژ سیستم کردیم، جالب ترین و پیشرفته ترین فناوری ها را وارد کردیم. نتیجه یک پشته فناوری است که برای هر پخش کننده اینترنتی و شرکت هایی که سیستم های با بار بالا می سازند آشنا است.

پشته شبیه به پشته های دیگر بازیکنان اصلی است: نتفلیکس، توییتر، وایبر. این شامل 6 جزء است، اما ما می خواهیم آن را کوتاه و یکپارچه کنیم.

انعطاف پذیری خوب است، اما در یک شرکت بزرگ هیچ راهی بدون اتحاد وجود ندارد.

ما قرار نیست همان اوراکل را به Tarantool تغییر دهیم. در واقعیت های شرکت های بزرگ، این یک مدینه فاضله یا یک جنگ صلیبی برای 5-10 سال با نتیجه نامشخص است. اما Cassandra و Couchbase را می توان به راحتی با Tarantool جایگزین کرد، و این چیزی است که ما برای آن تلاش می کنیم.

چرا Tarantool؟

4 معیار ساده وجود دارد که چرا ما این پایگاه داده را انتخاب کردیم.

سرعت. ما آزمایش های بار را روی سیستم های صنعتی MegaFon انجام دادیم. Tarantool برنده شد - بهترین عملکرد را نشان داد.

این بدان معنا نیست که دیگر سیستم ها نیازهای مگافون را برآورده نمی کنند. راه حل های حافظه فعلی به قدری سازنده هستند که ذخایر این شرکت بیش از اندازه کافی است. اما ما علاقه مندیم که با یک رهبر سر و کار داشته باشیم و نه با کسی که از جمله در تست بار عقب مانده است.

Tarantool نیازهای شرکت را حتی در بلندمدت پوشش می دهد.

هزینه TCO. پشتیبانی از Couchbase در حجم های MegaFon هزینه های نجومی دارد، اما با Tarantool وضعیت بسیار خوشایندتر است و از نظر عملکرد مشابه هستند.

یکی دیگر از ویژگی های خوب که کمی بر انتخاب ما تأثیر گذاشت این است که Tarantool با حافظه بهتر از سایر پایگاه های داده کار می کند. او نشان می دهد حداکثر بهره وری.

قابلیت اطمینان. MegaFon احتمالاً بیش از هر کس دیگری روی قابلیت اطمینان سرمایه گذاری می کند. بنابراین وقتی به Tarantool نگاه کردیم، متوجه شدیم که باید آن را مطابق با نیازهایمان بسازیم.

ما زمان و امور مالی خود را سرمایه گذاری کردیم و همراه با Mail.ru یک نسخه سازمانی ایجاد کردیم که اکنون در چندین شرکت دیگر استفاده می شود.

Tarantool- Enterprise ما را از نظر امنیت، قابلیت اطمینان و ورود به سیستم کاملاً راضی کرد.

Партнерство

مهمترین چیز برای من این است تماس مستقیم با توسعه دهنده. این دقیقاً همان چیزی است که بچه های ترانتول با آن رشوه دادند.

اگر به بازیکنی بیایید، مخصوصاً بازیکنی که با یک انکر کلاینت کار می کند و بگویید که برای انجام این کار، این و این به پایگاه داده نیاز دارید، معمولاً پاسخ می دهد:

- بسیار خوب، الزامات را در انتهای آن انبوه قرار دهید - یک روز، احتمالاً به آنها خواهیم رسید.

بسیاری برای 2-3 سال آینده نقشه راه دارند و ادغام در آنجا تقریبا غیرممکن است، اما توسعه دهندگان Tarantool با باز بودن خود و نه تنها از مگافون، مجذوب خود می شوند و سیستم خود را با مشتری تطبیق می دهند. باحال است و ما واقعا آن را دوست داریم.

جایی که ما از Tarantool استفاده کردیم

ما از Tarantool در چندین عنصر استفاده می کنیم. اولین مورد در خلبان است، که ما در سیستم فهرست آدرس ساخته ایم. زمانی می‌خواستم سیستمی شبیه Yandex.Maps و Google Maps باشد، اما کمی متفاوت بود.

به عنوان مثال، کاتالوگ آدرس در رابط فروش. در اوراکل، جستجوی آدرس مورد نظر 12-13 ثانیه طول می کشد. - اعداد ناراحت کننده وقتی به Tarantool سوئیچ می کنیم، اوراکل را با پایگاه داده دیگری در کنسول جایگزین می کنیم و همان جستجو را انجام می دهیم، سرعت 200 برابری دریافت می کنیم! شهر بعد از حرف سوم ظاهر می شود. اکنون ما در حال تطبیق رابط کاربری هستیم تا بعد از اولین مورد این اتفاق بیفتد. با این حال، سرعت پاسخ کاملا متفاوت است - میلی ثانیه به جای ثانیه.

برنامه دوم یک تم مد روز به نام فناوری اطلاعات دو سرعته است. این به این دلیل است که مشاوران از هر گوشه ای می گویند که شرکت ها باید به آنجا بروند.

یک لایه زیرساخت وجود دارد، بالای آن دامنه هایی وجود دارد، به عنوان مثال، یک سیستم صورتحساب مانند مخابرات، سیستم های شرکتی، گزارش های شرکتی. این هسته ای است که نیازی به لمس آن نیست. این البته ممکن است، اما به طرز پارانوئیدی کیفیت را تضمین می کند، زیرا برای شرکت پول به ارمغان می آورد.

بعد لایه میکروسرویس ها قرار می گیرد - آنچه اپراتور یا پخش کننده دیگر را متمایز می کند. میکروسرویس ها را می توان به سرعت بر اساس کش های خاص ایجاد کرد و داده ها را از دامنه های مختلف به آنجا آورد. اینجا زمینه برای آزمایش - اگر چیزی درست نشد، یک میکروسرویس را بستم و دیگری را باز کردم. این باعث افزایش زمان واقعی برای بازار می شود و قابلیت اطمینان و سرعت شرکت را افزایش می دهد.

میکروسرویس ها شاید نقش اصلی Tarantool در MegaFon باشند.

جایی که قصد داریم از Tarantool استفاده کنیم

اگر پروژه صورتحساب موفق خود را با برنامه های تحول در Deutsche Telekom، Svyazcom، Vodafone هند مقایسه کنیم، به طرز شگفت انگیزی پویا و خلاقانه است. در روند اجرای این پروژه، نه تنها MegaFon و ساختار آن تغییر یافت، بلکه Tarantool-enterprise نیز در Mail.ru ظاهر شد و فروشنده ما Nexign (پیتر-سرویس سابق) - BSS Box (یک راه حل صورتحساب جعبه ای).

این به یک معنا یک پروژه تاریخی برای بازار روسیه است. می توان آن را با آنچه در کتاب «ماه انسان اسطوره ای» نوشته فردریک بروکس توصیف شده است مقایسه کرد. سپس، در دهه 60، IBM 360 نفر را برای توسعه سیستم عامل جدید OS/5 برای پردازنده های مرکزی استخدام کرد. ما کمتر داریم - 000، اما ما جلیقه‌ها داریم، و با در نظر گرفتن استفاده از منبع باز و رویکردهای جدید، کارآمدتر کار می‌کنیم.

در زیر حوزه‌های صورت‌حساب یا به‌طور کلی‌تر، سیستم‌های تجاری آورده شده است. افراد سازمانی CRM را به خوبی می شناسند. همه باید قبلاً سیستم های دیگری داشته باشند: Open API، API Gateway.

API باز کردن

بیایید دوباره به اعداد و نحوه عملکرد Open API در حال حاضر نگاه کنیم. بار آن است 10 تراکنش در ثانیه. از آنجایی که ما قصد داریم به طور فعال لایه میکروسرویس را توسعه دهیم و API عمومی MegaFon را بسازیم، انتظار رشد بیشتری را در آینده در این بخش داریم. قطعا 100 تراکنش انجام خواهد شد.

نمی‌دانم می‌توانیم با Mail.ru در SSO مقایسه کنیم یا نه - به نظر می‌رسد بچه‌ها 1،000،0000 تراکنش در ثانیه دارند. راه حل آنها برای ما بسیار جالب است و ما قصد داریم از تجربه آنها استفاده کنیم - به عنوان مثال، ایجاد یک نسخه پشتیبان SSO کاربردی با استفاده از Tarantool. اکنون توسعه دهندگان Mail.ru این کار را برای ما انجام می دهند.

CRM

CRM همان 80 میلیون مشترکی است که می خواهیم به یک میلیارد برسانیم، زیرا در حال حاضر 300 میلیون سند وجود دارد که شامل سابقه سه ساله می شود. ما واقعا مشتاقانه منتظر خدمات جدید و اینجا هستیم نقطه رشد خدمات متصل است. این توپی است که رشد خواهد کرد، زیرا خدمات بیشتر و بیشتری وجود خواهد داشت. بر این اساس، ما به یک داستان نیاز خواهیم داشت؛ ما نمی خواهیم در این مورد تلو تلو بخوریم.

صورتحساب خود از نظر صدور فاکتورها، کار با حساب های دریافتنی مشتری تبدیل به یک دامنه جداگانه. برای بهبود عملکرد، الگوی معماری معماری دامنه کاربردی.

سیستم به دامنه ها تقسیم می شود، بار توزیع می شود و تحمل خطا تضمین می شود. علاوه بر این، ما با معماری توزیع شده کار کردیم.

همه چیز دیگر راه حل های سطح سازمانی است. در فضای ذخیره تماس - 2 میلیارد در روز، 60 میلیارد در ماه. گاهی اوقات باید آنها را در یک ماه بشمارید، و سریع بهتر است. نظارت مالی - این دقیقاً همان 300 میلیون است که دائماً در حال رشد و افزایش است: مشترکین اغلب بین اپراتورها اجرا می شوند و این قسمت را افزایش می دهند.

بیشترین جزء مخابراتی ارتباطات سیار است صورتحساب آنلاین. اینها سیستم هایی هستند که به شما امکان می دهند تماس بگیرید یا تماس نگیرید و در زمان واقعی تصمیم بگیرید. در اینجا بار 30 تراکنش در ثانیه است، اما با در نظر گرفتن رشد انتقال داده، برنامه ریزی می کنیم 250 تراکنشو بنابراین ما به ترانتول علاقه زیادی داریم.

تصویر قبلی دامنه هایی است که قرار است از Tarantool استفاده کنیم. البته خود CRM گسترده تر است و ما قصد داریم از آن در هسته خود استفاده کنیم.

رقم تخمینی TTX ما از 100 میلیون مشترک، من را به عنوان یک معمار گیج می کند - اگر 101 میلیون باشد چه؟ آیا باید همه چیز را دوباره انجام دهید؟ برای جلوگیری از این اتفاق، از کش استفاده می کنیم و در عین حال دسترسی را افزایش می دهیم.

به طور کلی، دو رویکرد برای استفاده از Tarantool وجود دارد. اولین - تمام کش ها را در سطح میکروسرویس بسازید. تا آنجا که من متوجه شدم، VimpelCom این مسیر را دنبال می کند و یک کش از مشتریان ایجاد می کند.

ما کمتر به فروشندگان وابسته هستیم، هسته BSS را تغییر می دهیم، بنابراین یک فایل کلاینت از جعبه داریم. اما ما می خواهیم آن را گسترش دهیم. بنابراین، ما یک رویکرد کمی متفاوت داریم - ایجاد کش در داخل سیستم ها.

به این ترتیب همگام سازی کمتری وجود دارد - یک سیستم هم مسئول حافظه پنهان و هم منبع اصلی اصلی است.

این روش به خوبی با رویکرد Tarantool با یک اسکلت تراکنشی مطابقت دارد، زمانی که تنها بخش‌هایی که به به‌روزرسانی‌ها مربوط می‌شوند، یعنی تغییرات داده‌ها، به‌روزرسانی می‌شوند. هر چیز دیگری را می توان در جای دیگری ذخیره کرد. هیچ دریاچه داده عظیم، حافظه پنهان جهانی مدیریت نشده وجود ندارد. کش ها برای سیستم، یا برای محصولات، یا برای مشتریان، یا برای آسان کردن زندگی برای تعمیر و نگهداری طراحی شده اند. وقتی مشترکی تماس می گیرد و از کیفیت خدمات شما ناراحت است، می خواهید خدمات با کیفیتی ارائه دهید.

RTO و RPO

دو اصطلاح در IT وجود دارد - OTR и RPO.

هدف زمان بهبودی مدت زمانی است که برای بازیابی سرویس پس از خرابی لازم است. RTO = 0 به این معنی است که حتی اگر چیزی خراب شود، سرویس به کار خود ادامه می دهد.

هدف نقطه بازیابی - این زمان بازیابی اطلاعات است، چه مقدار داده می توانیم در یک دوره زمانی معین از دست بدهیم. RPO = 0 به این معنی است که داده ها را از دست نمی دهیم.

کار رتیل

بیایید سعی کنیم مشکلی را برای ترانتول حل کنیم.

داده شده: سبدی از برنامه‌هایی که همه آن‌ها را می‌فهمند، مثلاً در آمازون یا جای دیگری. مورد نیاز است به طوری که سبد خرید 24 ساعته در 7 روز هفته یا 99,99 درصد مواقع کار می کند. سفارشاتی که به ما می رسد باید مرتب باقی بمانند، زیرا نمی توانیم به طور تصادفی اتصال مشترک را روشن یا خاموش کنیم - همه چیز باید کاملاً سازگار باشد. اشتراک قبلی روی اشتراک بعدی تأثیر می گذارد، بنابراین داده ها مهم هستند - هیچ چیز نباید از دست برود.

تصمیم. می توانید سعی کنید آن را مستقیماً حل کنید و از توسعه دهندگان پایگاه داده بپرسید، اما مشکل را نمی توان به صورت ریاضی حل کرد. شما می توانید قضایا، قوانین بقا، فیزیک کوانتومی را به خاطر بسپارید، اما چرا - نمی توان آن را در سطح DB حل کرد.

رویکرد معماری قدیمی خوب در اینجا کار می کند - شما باید حوزه موضوع را به خوبی بشناسید و از آن برای حل این معما استفاده کنید.

راه حل ما: ایجاد یک رجیستری توزیع شده از برنامه ها در Tarantool - یک خوشه جغرافیایی توزیع شده. در نمودار، اینها سه مرکز پردازش داده مختلف هستند - دو مرکز قبل از اورال، یکی فراتر از اورال، و ما همه درخواست‌ها را بین این مراکز توزیع می‌کنیم.

نتفلیکس که در حال حاضر به عنوان یکی از رهبران فناوری اطلاعات شناخته می شود، تا سال 2012 تنها یک مرکز داده داشت. در آستانه کریسمس کاتولیک، 24 دسامبر، این مرکز داده از کار افتاد. کاربران در کانادا و آمریکا بدون فیلم های مورد علاقه خود ماندند، بسیار ناراحت شدند و در شبکه های اجتماعی در مورد آن نوشتند. نتفلیکس اکنون دارای سه مرکز داده در سواحل غربی شرقی و یک مرکز در غرب اروپا است.

ما در ابتدا در حال ساخت یک راه حل توزیع جغرافیایی هستیم - تحمل خطا برای ما مهم است.

بنابراین ما یک خوشه داریم، اما RPO = 0 و RTO = 0 چطور؟ راه حل ساده است، بسته به موضوع.

چه چیزی در برنامه ها مهم است؟ دو بخش: پرتاب سبد به تصمیم گیری برای خرید و پس از. بخش DO در مخابرات معمولا نامیده می شود ثبت سفارش یا مذاکره سفارش. در مخابرات، این می تواند بسیار دشوارتر از یک فروشگاه آنلاین باشد، زیرا در آنجا باید به مشتری خدمات داده شود، 5 گزینه ارائه شود، و این همه برای مدتی اتفاق می افتد، اما سبد پر است. در این لحظه، یک شکست ممکن است، اما ترسناک نیست، زیرا به صورت تعاملی تحت نظارت انسان اتفاق می افتد.

اگر مرکز داده مسکو به طور ناگهانی از کار بیفتد، با تغییر خودکار به مرکز داده دیگر، ما به کار خود ادامه خواهیم داد. از نظر تئوری ممکن است یک محصول در سبد خرید گم شود، اما شما آن را ببینید، دوباره به سبد خرید اضافه کنید و به کار خود ادامه دهید. در این حالت RTO = 0.

در همان لحظه، گزینه دوم وجود دارد: وقتی روی "submit" کلیک کردیم، می خواهیم داده ها از بین نرود. از این لحظه به بعد، اتوماسیون شروع به کار می کند - این RPO = 0 است. با استفاده از این دو الگوی مختلف، در یک مورد می تواند به سادگی یک خوشه توزیع شده جغرافیایی با یک استاد قابل تعویض باشد، در مورد دیگر نوعی رکورد حد نصاب. الگوها ممکن است متفاوت باشند، اما ما مشکل را حل می کنیم.

علاوه بر این، با داشتن یک رجیستری توزیع‌شده از برنامه‌ها، می‌توانیم همه آن را مقیاس‌بندی کنیم - توزیع‌کننده‌ها و مجری‌های زیادی داریم که به این رجیستری دسترسی دارند.

کاساندرا و تارانتول با هم

یک مورد دیگر وجود دارد - "ویترین موجودی". در اینجا یک مورد جالب از استفاده مشترک از Cassandra و Tarantool آورده شده است.

ما از کاساندرا استفاده می کنیم زیرا 2 میلیارد تماس در روز حد مجاز نیست و بیشتر خواهد بود. بازاریابان دوست دارند ترافیک را بر اساس منبع رنگی کنند؛ برای مثال، جزئیات بیشتر و بیشتری در شبکه های اجتماعی ظاهر می شود. همه اینها به داستان می افزاید.

Cassandra به شما امکان می دهد تا به صورت افقی در هر اندازه ای مقیاس بندی کنید.

ما با کاساندرا احساس راحتی می کنیم، اما یک مشکل دارد - در خواندن خوب نیست. همه چیز در ضبط درست است، 30 در ثانیه مشکلی نیست - مشکل خواندن.

بنابراین، موضوعی با حافظه پنهان ظاهر شد و در همان زمان ما مشکل زیر را حل کردیم: یک مورد سنتی قدیمی وجود دارد که تجهیزاتی از سوییچ از صورتحساب آنلاین به فایل هایی که در Cassandra بارگذاری می کنیم وارد می شود. ما با مشکل دانلود مطمئن این فایل‌ها، حتی با استفاده از توصیه‌های انتقال فایل مدیر IBM، دست و پنجه نرم کردیم - راه‌حل‌هایی وجود دارد که انتقال فایل را به طور مؤثر مدیریت می‌کنند، به عنوان مثال، به جای TCP از پروتکل UDP. این خوب است، اما هنوز چند دقیقه است، و ما هنوز همه آن را بارگذاری نکرده ایم، اپراتور در مرکز تماس نمی تواند به مشتری پاسخ دهد که چه اتفاقی برای موجودی او افتاده است - باید منتظر بمانیم.

برای جلوگیری از این اتفاق، ما ما از ذخیره عملکردی موازی استفاده می کنیم. وقتی رویدادی را از طریق کافکا به Tarantool می فرستیم، با محاسبه مجدد مجموع ها در زمان واقعی، به عنوان مثال، برای امروز، دریافت می کنیم موجودی های نقدی، که می تواند با هر سرعتی که باشد، مانده ها را انتقال دهد، مثلاً 100 هزار تراکنش در ثانیه و همان 2 ثانیه.

هدف این است که پس از برقراری تماس، در عرض 2 ثانیه در حساب شخصی شما نه تنها موجودی تغییر یافته، بلکه اطلاعاتی در مورد علت تغییر آن وجود داشته باشد.

نتیجه

اینها نمونه هایی از استفاده از Tarantool بود. ما واقعاً از باز بودن Mail.ru و تمایل آنها برای در نظر گرفتن موارد مختلف خوشمان آمد.

در حال حاضر برای مشاوران BCG یا McKinsey، Accenture یا IBM دشوار است که ما را با چیز جدیدی غافلگیر کنند - بسیاری از چیزهایی که آنها ارائه می دهند، ما یا قبلا انجام داده ایم، انجام داده ایم یا در حال برنامه ریزی برای انجام آن هستیم. من فکر می کنم که Tarantool جایگاه شایسته خود را در پشته فناوری ما خواهد گرفت و جایگزین بسیاری از فناوری های موجود خواهد شد. ما در مرحله فعال توسعه این پروژه هستیم.

گزارش اولگ و آندری یکی از بهترین گزارش های کنفرانس تارانتول در سال گذشته است و در 17 ژوئن اولگ ایولف در کنفرانس T+ 2019 با گزارش "چرا Tarantool در اینترپرایز". الکساندر دولین نیز از مگافون ارائه خواهد کرد کش های Tarantool و Replication از Oracle. بیایید دریابیم که چه چیزی تغییر کرده است، چه برنامه هایی اجرا شده است. بپیوندید - کنفرانس رایگان است، تنها کاری که باید انجام دهید این است ثبات. همه گزارشات پذیرفته شد و برنامه کنفرانس شکل گرفته است: موارد جدید، تجربه جدید در استفاده از Tarantool، معماری، سازمانی، آموزش و میکروسرویس.

منبع: www.habr.com