Warum benötigt ein Unternehmen wie MegaFon Tarantool in der Abrechnung? Von außen sieht es so aus, als ob der Verkäufer normalerweise kommt, eine Art große Kiste mitbringt, den Stecker in die Steckdose steckt – und das ist die Abrechnung! Das war einmal so, aber jetzt ist es archaisch, und solche Dinosaurier sind bereits ausgestorben oder werden aussterben. Bei der Abrechnung handelt es sich zunächst um ein System zur Rechnungsstellung – eine Zählmaschine oder einen Taschenrechner. In der modernen Telekommunikation ist dies der Fall Automatisierungssystem für den gesamten Lebenszyklus der Interaktion mit einem Abonnenten vom Vertragsabschluss bis zur Kündigung, inklusive Abrechnung in Echtzeit, Zahlungsannahme und vieles mehr. Die Abrechnung in Telekommunikationsunternehmen ist wie ein Kampfroboter – groß, leistungsstark und voller Waffen.
Was hat Tarantool damit zu tun? Sie werden darüber reden Oleg Ivlev и Andrey Knyazev. Oleg ist der Chefarchitekt des Unternehmens Andrey verfügt über umfangreiche Erfahrung in ausländischen Unternehmen und ist Direktor für Geschäftssysteme. Aus der Abschrift ihres Berichts am Sie erfahren, warum in Unternehmen Forschung und Entwicklung erforderlich sind, was Tarantool ist, wie die Sackgasse der vertikalen Skalierung und Globalisierung zur Voraussetzung für das Erscheinen dieser Datenbank im Unternehmen wurde, über technologische Herausforderungen, architektonische Veränderungen und wie der Technostack von MegaFon Netflix ähnelt , Google und Amazon.
Projekt „Einheitliche Abrechnung“
Das Projekt heißt „Unified Billing“. Hier zeigte Tarantool seine besten Qualitäten.
Das Produktivitätswachstum von Hi-End-Geräten hielt nicht mit dem Wachstum der Abonnentenbasis und der Anzahl der Dienste Schritt; ein weiteres Wachstum der Anzahl der Abonnenten und Dienste wurde aufgrund von M2M, IoT und Filialfunktionen erwartet zu einer Verschlechterung der Time-to-Market. Das Unternehmen beschloss, anstelle der derzeit acht unterschiedlichen Abrechnungssysteme ein einheitliches Geschäftssystem mit einer einzigartigen modularen Architektur von Weltklasse zu schaffen.
MegaFon besteht aus acht Unternehmen in einem. Im Jahr 2009 wurde die Umstrukturierung abgeschlossen: Niederlassungen in ganz Russland fusionierten zu einem einzigen Unternehmen, MegaFon OJSC (jetzt PJSC). Somit verfügt das Unternehmen über 8 Abrechnungssysteme mit eigenen „maßgeschneiderten“ Lösungen, Filialfunktionen und unterschiedlichen Organisationsstrukturen, IT und Marketing.
Alles war in Ordnung, bis wir ein gemeinsames Bundesprodukt auf den Markt bringen mussten. Hier traten viele Schwierigkeiten auf: Bei manchen werden die Tarife aufgerundet, bei anderen abgerundet und bei wieder anderen – basierend auf dem arithmetischen Mittel. Es gibt Tausende solcher Momente.
Obwohl es nur eine Version des Abrechnungssystems und einen einzigen Anbieter gab, waren die Einstellungen so unterschiedlich, dass die Zusammenstellung lange dauerte. Wir haben versucht, ihre Zahl zu reduzieren und sind dabei auf ein zweites Problem gestoßen, das vielen Unternehmen bekannt ist.
Vertikale Skalierung. Auch die damals coolste Hardware genügte den Ansprüchen nicht. Wir haben Hewlett-Packard-Geräte aus der Superdome Hi-End-Reihe verwendet, aber diese entsprachen nicht einmal den Anforderungen von zwei Filialen. Ich wollte eine horizontale Skalierung ohne große Betriebskosten und Kapitalinvestitionen.
Erwartung eines Wachstums der Zahl der Abonnenten und Dienste. Berater haben schon lange Geschichten über IoT und M2M in die Telekommunikationswelt gebracht: Die Zeit wird kommen, in der jedes Telefon und jedes Bügeleisen eine SIM-Karte haben wird und zwei im Kühlschrank. Heute haben wir eine Abonnentenzahl, aber in naher Zukunft werden es noch viel mehr sein.
Technologische Herausforderungen
Diese vier Gründe motivierten uns zu gravierenden Veränderungen. Es gab die Wahl zwischen einem Upgrade des Systems oder einem völlig neuen Design. Wir haben lange nachgedacht, ernsthafte Entscheidungen getroffen, Ausschreibungen gespielt. Deshalb haben wir uns von Anfang an für das Design entschieden und uns interessanten Herausforderungen gestellt – technologischen Herausforderungen.
Skalierbarkeit
Wenn es vorher war, sagen wir mal, sagen wir mal 8 Abrechnungen für 15 Millionen Abonnenten, und jetzt hätte es funktionieren sollen 100 Millionen Abonnenten und mehr - Die Belastung ist um eine Größenordnung höher.
Wir sind mittlerweile mit großen Internetanbietern wie Mail.ru oder Netflix vergleichbar.
Aber die weitere Bewegung zur Erhöhung der Auslastung und der Abonnentenbasis hat uns vor große Herausforderungen gestellt.
Geographie unseres riesigen Landes
Zwischen Kaliningrad und Wladiwostok 7500 km und 10 Zeitzonen. Die Lichtgeschwindigkeit ist endlich und bei solchen Entfernungen sind die Verzögerungen bereits erheblich. 150 ms auf den coolsten modernen optischen Kanälen sind zu viel für eine Echtzeitabrechnung, insbesondere wie es jetzt in der Telekommunikation in Russland der Fall ist. Darüber hinaus müssen Sie die Aktualisierung innerhalb eines Werktages durchführen, was bei unterschiedlichen Zeitzonen ein Problem darstellt.
Wir bieten nicht nur Dienstleistungen gegen eine Abonnementgebühr an, sondern bieten auch komplexe Tarife, Pakete und verschiedene Modifikatoren an. Wir müssen dem Teilnehmer nicht nur das Sprechen erlauben oder verweigern, sondern ihm auch eine bestimmte Quote geben – Anrufe und Aktionen in Echtzeit berechnen, damit er es nicht bemerkt.
Fehlertoleranz
Das ist die andere Seite der Zentralisierung.
Wenn wir alle Abonnenten in einem System sammeln, sind Notfälle und Katastrophen katastrophal für das Unternehmen. Deshalb gestalten wir das System so, dass die Auswirkungen von Unfällen auf den gesamten Abonnentenstamm ausgeschlossen sind.
Dies ist wiederum eine Folge der Weigerung, vertikal zu skalieren. Bei der horizontalen Skalierung haben wir die Anzahl der Server von Hunderten auf Tausende erhöht. Sie müssen verwaltet und austauschbar sein, die IT-Infrastruktur automatisch sichern und das verteilte System wiederherstellen.
Wir standen vor so interessanten Herausforderungen. Wir haben das System entworfen und in diesem Moment versucht, globale Best Practices zu finden, um zu überprüfen, wie sehr wir im Trend liegen und wie sehr wir fortschrittlichen Technologien folgen.
Welterfahrung
Überraschenderweise haben wir im globalen Telekommunikationsbereich keine einzige Referenz gefunden.
Europa ist in Bezug auf Abonnentenzahl und Umfang zurückgefallen, die USA in Bezug auf die Flachheit ihrer Tarife. Wir haben uns einige in China angesehen, einige in Indien gefunden und Spezialisten von Vodafone India engagiert.
Um die Architektur zu analysieren, haben wir ein Dream Team unter der Leitung von IBM zusammengestellt – Architekten aus verschiedenen Bereichen. Diese Leute konnten angemessen beurteilen, was wir taten, und bestimmte Kenntnisse in unsere Architektur einbringen.
Maßstab
Ein paar Zahlen zur Veranschaulichung.
Wir entwerfen das System für 80 Millionen Abonnenten mit einer Reserve von einer Milliarde. So beseitigen wir künftige Schwellenwerte. Das liegt nicht daran, dass wir China übernehmen werden, sondern am Ansturm von IoT und M2M.
300 Millionen Dokumente in Echtzeit verarbeitet. Obwohl wir 80 Millionen Abonnenten haben, arbeiten wir sowohl mit potenziellen Kunden als auch mit denen zusammen, die uns verlassen haben, wenn wir Forderungen eintreiben müssen. Daher sind die tatsächlichen Volumina deutlich größer.
2 Milliarden Transaktionen Der Kontostand ändert sich täglich – das sind Zahlungen, Gebühren, Anrufe und andere Ereignisse. 200 TB Daten verändern sich aktiv, etwas langsamer ändern 8 PB Daten, und dabei handelt es sich nicht um ein Archiv, sondern um Live-Daten in einer einzigen Abrechnung. Skalierung nach Rechenzentrum – 5 Server an 14 Standorten.
Technologie-Stack
Als wir die Architektur planten und mit dem Aufbau des Systems begannen, importierten wir die interessantesten und fortschrittlichsten Technologien. Das Ergebnis ist ein Technologie-Stack, der jedem Internet-Player und jedem Unternehmen vertraut ist, das Hochlastsysteme herstellt.
Der Stack ähnelt den Stacks anderer großer Player: Netflix, Twitter, Viber. Es besteht aus 6 Komponenten, wir wollen es aber verkürzen und vereinheitlichen.
Flexibilität ist gut, aber in einem großen Konzern geht es nicht ohne Vereinheitlichung.
Wir werden nicht dasselbe Oracle in Tarantool ändern. In der Realität großer Unternehmen ist dies eine Utopie oder ein Kreuzzug über 5–10 Jahre mit unklarem Ausgang. Aber Cassandra und Couchbase können leicht durch Tarantool ersetzt werden, und das ist es, was wir anstreben.
Warum Tarantool?
Es gibt 4 einfache Kriterien, warum wir uns für diese Datenbank entschieden haben.
Geschwindigkeit. Wir haben Belastungstests auf MegaFon-Industriesystemen durchgeführt. Tarantool hat gewonnen – es zeigte die beste Leistung.
Das soll nicht heißen, dass andere Systeme die Anforderungen von MegaFon nicht erfüllen. Aktuelle Speicherlösungen sind so produktiv, dass die Reserven des Unternehmens mehr als ausreichen. Uns interessiert aber der Umgang mit einem Leader und nicht mit jemandem, der auch im Belastungstest hinterherhinkt.
Tarantool deckt den Bedarf des Unternehmens auch langfristig ab.
TCO-Kosten. Die Unterstützung von Couchbase auf MegaFon-Volumes kostet astronomische Summen, aber mit Tarantool ist die Situation viel angenehmer und sie sind in der Funktionalität ähnlich.
Ein weiteres nettes Feature, das unsere Wahl leicht beeinflusst hat, ist, dass Tarantool besser mit dem Speicher arbeitet als andere Datenbanken. Er zeigt maximale Effizienz.
Zuverlässigkeit. MegaFon investiert wahrscheinlich mehr als jeder andere in Zuverlässigkeit. Als wir uns Tarantool ansahen, wurde uns klar, dass wir es an unsere Anforderungen anpassen mussten.
Wir haben unsere Zeit und Finanzen investiert und gemeinsam mit Mail.ru eine Unternehmensversion erstellt, die mittlerweile in mehreren anderen Unternehmen eingesetzt wird.
Tarantool-enterprise hat uns hinsichtlich Sicherheit, Zuverlässigkeit und Protokollierung voll und ganz zufrieden gestellt.
Partnerschaft
Das Wichtigste für mich ist Direkter Kontakt mit dem Entwickler. Genau damit haben die Jungs von Tarantool bestochen.
Wenn Sie zu einem Spieler kommen, insbesondere zu einem, der mit einem Anker-Client arbeitet, und sagen, dass Sie die Datenbank benötigen, um dies, dies und das tun zu können, antwortet er normalerweise:
– Okay, legen Sie die Anforderungen unten auf den Stapel – eines Tages werden wir sie wahrscheinlich erreichen.
Viele haben eine Roadmap für die nächsten 2-3 Jahre und eine Integration dort ist fast unmöglich, aber Tarantool-Entwickler bestechen durch ihre Offenheit, nicht nur bei MegaFon, und passen ihr System an den Kunden an. Es ist cool und wir mögen es wirklich.
Wo wir Tarantool verwendet haben
Wir verwenden Tarantool in mehreren Elementen. Der erste ist im Pilotfilm, die wir im Adressverzeichnissystem erstellt haben. Früher wollte ich, dass es ein System ist, das Yandex.Maps und Google Maps ähnelt, aber es kam etwas anders.
Beispielsweise der Adresskatalog in der Vertriebsoberfläche. Unter Oracle dauert die Suche nach der gewünschten Adresse 12-13 Sekunden. - unbequeme Zahlen. Wenn wir zu Tarantool wechseln, Oracle durch eine andere Datenbank in der Konsole ersetzen und die gleiche Suche durchführen, erhalten wir eine 200-fache Beschleunigung! Die Stadt erscheint nach dem dritten Buchstaben. Jetzt passen wir die Schnittstelle so an, dass dies nach dem ersten geschieht. Allerdings ist die Reaktionsgeschwindigkeit völlig anders – Millisekunden statt Sekunden.
Die zweite Anwendung ist ein trendiges Thema namens Two-Speed-IT. Denn Berater aus aller Welt sagen, dass Unternehmen dorthin gehen sollten.
Es gibt eine Infrastrukturschicht, darüber befinden sich Domänen, zum Beispiel ein Abrechnungssystem wie eine Telekommunikation, Unternehmenssysteme, Unternehmensberichte. Dies ist der Kern, der nicht berührt werden muss. Das ist natürlich möglich, aber die Sicherstellung der Qualität ist paranoid, weil sie dem Unternehmen Geld bringt.
Als nächstes kommt die Ebene der Microservices – was den Betreiber oder andere Spieler auszeichnet. Auf Basis bestimmter Caches können schnell Microservices erstellt werden, die Daten aus unterschiedlichen Domänen dorthin bringen. Hier Feld für Experimente — Wenn etwas nicht geklappt hat, habe ich einen Microservice geschlossen und einen anderen geöffnet. Dies sorgt für eine deutlich längere Time-to-Market und erhöht die Zuverlässigkeit und Geschwindigkeit des Unternehmens.
Microservices sind vielleicht die Hauptrolle von Tarantool bei MegaFon.
Wo wir Tarantool einsetzen wollen
Wenn wir unser erfolgreiches Abrechnungsprojekt mit den Transformationsprogrammen der Deutschen Telekom, Svyazcom und Vodafone India vergleichen, ist es überraschend dynamisch und kreativ. Im Zuge der Umsetzung dieses Projekts wurden nicht nur MegaFon und seine Struktur verändert, sondern auch Tarantool-enterprise erschien bei Mail.ru und unser Anbieter Nexign (ehemals Peter-Service) – BSS Box (eine Box-Abrechnungslösung).
Dies ist gewissermaßen ein historisches Projekt für den russischen Markt. Es kann mit dem verglichen werden, was in dem Buch „The Mythical Man-Month“ von Frederick Brooks beschrieben wird. Dann stellte IBM in den 60er Jahren 360 Leute ein, um das neue Betriebssystem OS/5 für Großrechner zu entwickeln. Wir haben weniger – 000, aber unsere sind investiert, und unter Berücksichtigung der Nutzung von Open Source und neuen Ansätzen arbeiten wir produktiver.
Im Folgenden sind die Bereiche der Abrechnung oder, allgemeiner ausgedrückt, der Geschäftssysteme aufgeführt. Leute aus der Wirtschaft kennen sich mit CRM sehr gut aus. Jeder sollte bereits andere Systeme haben: Open API, API Gateway.
Offene API
Schauen wir uns noch einmal die Zahlen an und wie die Open API derzeit funktioniert. Seine Last ist 10 Transaktionen pro Sekunde. Da wir planen, die Microservices-Schicht aktiv weiterzuentwickeln und die öffentliche MegaFon-API aufzubauen, erwarten wir in diesem Teil in Zukunft ein größeres Wachstum. Es wird auf jeden Fall 100 Transaktionen geben.
Ich weiß nicht, ob wir uns in SSO mit Mail.ru vergleichen können – die Jungs scheinen 1 Transaktionen pro Sekunde zu haben. Ihre Lösung ist für uns äußerst interessant und wir planen, ihre Erfahrungen zu übernehmen – zum Beispiel bei der Erstellung eines funktionsfähigen SSO-Backups mit Tarantool. Jetzt erledigen das die Entwickler von Mail.ru für uns.
CRM
CRM sind die gleichen 80 Millionen Abonnenten, die wir auf eine Milliarde steigern wollen, weil es bereits 300 Millionen Dokumente gibt, die eine dreijährige Historie umfassen. Wir freuen uns sehr auf neue Dienstleistungen und hier Wachstumspunkt sind vernetzte Dienste. Das ist ein Ball, der wachsen wird, weil es immer mehr Dienste geben wird. Dementsprechend brauchen wir eine Geschichte, darüber wollen wir nicht stolpern.
Selbstabrechnung im Sinne der Rechnungsstellung, Bearbeitung der Debitorenbuchhaltung in eine eigene Domäne umgewandelt. Um die Leistung zu verbessern, Angewandte Domänenarchitektur, Architekturmuster.
Das System wird in Domänen aufgeteilt, die Last verteilt und Fehlertoleranz gewährleistet. Darüber hinaus haben wir mit verteilter Architektur gearbeitet.
Alles andere sind Lösungen auf Unternehmensebene. Im Anrufspeicher - 2 Milliarden pro Tag, 60 Milliarden pro Monat. Manchmal muss man sie in einem Monat zählen, und schnell geht es besser. Finanzielle Überwachung - Das sind genau die gleichen 300 Millionen, die ständig wachsen und wachsen: Abonnenten wechseln oft zwischen Betreibern, wodurch dieser Teil zunimmt.
Die Telekommunikationskomponente der mobilen Kommunikation ist Online-Abrechnung. Dies sind die Systeme, die es Ihnen ermöglichen, anzurufen oder nicht anzurufen und Entscheidungen in Echtzeit zu treffen. Hier beträgt die Auslastung 30 Transaktionen pro Sekunde, aber unter Berücksichtigung des Wachstums der Datenübertragung planen wir 250 Transaktionen, und deshalb sind wir sehr an Tarantool interessiert.
Das vorherige Bild zeigt die Domänen, in denen wir Tarantool verwenden werden. CRM selbst ist natürlich umfassender und wir werden es im Kern selbst verwenden.
Unsere geschätzte TTX-Zahl von 100 Millionen Abonnenten verwirrt mich als Architekt – was wäre, wenn 101 Millionen? Muss man alles noch einmal machen? Um dies zu verhindern, verwenden wir Caches und erhöhen gleichzeitig die Zugänglichkeit.
Im Allgemeinen gibt es zwei Ansätze zur Verwendung von Tarantool. Erste - Erstellen Sie alle Caches auf Microservice-Ebene. Soweit ich weiß, geht VimpelCom diesen Weg und erstellt einen Client-Cache.
Wir sind weniger abhängig von Anbietern, wir ändern den BSS-Kern, sodass wir sofort eine einzige Client-Datei haben. Aber wir wollen es ausbauen. Daher verfolgen wir einen etwas anderen Ansatz – Erstellen Sie Caches innerhalb von Systemen.
Auf diese Weise gibt es weniger Synchronisierung – ein System ist sowohl für den Cache als auch für die Haupt-Master-Quelle verantwortlich.
Die Methode passt gut zum Tarantool-Ansatz mit einem Transaktionsgerüst, bei dem nur Teile aktualisiert werden, die sich auf Aktualisierungen, also Datenänderungen, beziehen. Alles andere kann woanders gespeichert werden. Es gibt keinen riesigen Datensee und keinen nicht verwalteten globalen Cache. Caches sind für das System, für Produkte oder für Kunden konzipiert oder sollen das Leben bei der Wartung erleichtern. Wenn ein Teilnehmer anruft und über die Qualität Ihres Dienstes verärgert ist, möchten Sie einen qualitativ hochwertigen Service bieten.
RTO und RPO
In der IT gibt es zwei Begriffe: RTO и RPO.
Erholungszeitziel ist die Zeit, die benötigt wird, um den Dienst nach einem Ausfall wiederherzustellen. RTO = 0 bedeutet, dass der Dienst auch dann weiter funktioniert, wenn etwas ausfällt.
Wiederherstellungspunktziel – Dies ist die Datenwiederherstellungszeit, also wie viele Daten wir über einen bestimmten Zeitraum verlieren können. RPO = 0 bedeutet, dass wir keine Daten verlieren.
Tarantool-Aufgabe
Versuchen wir, ein Problem für Tarantool zu lösen.
Gegeben: ein Korb mit Anwendungen, die jeder versteht, zum Beispiel bei Amazon oder anderswo. Erforderlich sodass der Warenkorb 24 Stunden, 7 Tage die Woche, also 99,99 % der Zeit, funktioniert. Die Befehle, die bei uns eingehen, müssen in Ordnung bleiben, denn wir können den Anschluss des Teilnehmers nicht willkürlich ein- oder ausschalten – alles muss streng konsistent sein. Das vorherige Abonnement wirkt sich auf das nächste aus, daher sind die Daten wichtig – es sollte nichts verloren gehen.
Lösung. Sie können versuchen, das Problem direkt zu lösen und die Datenbankentwickler zu fragen, aber mathematisch lässt sich das Problem nicht lösen. Sie können sich an Theoreme, Erhaltungssätze und Quantenphysik erinnern, aber warum – es kann nicht auf DB-Ebene gelöst werden.
Hier funktioniert der gute alte architektonische Ansatz – man muss das Themengebiet gut kennen und es nutzen, um dieses Rätsel zu lösen.
Unsere Lösung: Erstellen eines verteilten Anwendungsregisters auf Tarantool – einem geografisch verteilten Cluster. Im Diagramm handelt es sich um drei verschiedene Rechenzentren – zwei vor dem Ural, eines jenseits des Urals, und wir verteilen alle Anfragen auf diese Zentren.
Netflix, das heute als einer der führenden Anbieter im IT-Bereich gilt, verfügte bis 2012 nur über ein Rechenzentrum. Am Vorabend des katholischen Weihnachtsfestes, dem 24. Dezember, fiel dieses Rechenzentrum aus. Nutzer in Kanada und den USA blieben ohne ihre Lieblingsfilme zurück, waren sehr verärgert und schrieben darüber in sozialen Netzwerken. Netflix verfügt mittlerweile über drei Rechenzentren an der West-Ostküste und eines in Westeuropa.
Wir bauen zunächst eine geoverteilte Lösung auf – Fehlertoleranz ist uns wichtig.
Wir haben also einen Cluster, aber was ist mit RPO = 0 und RTO = 0? Die Lösung ist je nach Thema einfach.
Was ist bei Bewerbungen wichtig? Zwei Teile: Korbwerfen VOR eine Kaufentscheidung treffen und Nachher. Der DO-Teil in der Telekommunikation wird normalerweise aufgerufen Auftragserfassung oder Auftragsverhandlung. In der Telekommunikation kann dies viel schwieriger sein als in einem Online-Shop, da der Kunde dort bedient werden muss, 5 Optionen angeboten werden müssen und dies alles eine Weile dauert, aber der Warenkorb gefüllt ist. In diesem Moment ist ein Scheitern möglich, aber nicht beängstigend, da es interaktiv unter menschlicher Aufsicht geschieht.
Sollte das Moskauer Rechenzentrum plötzlich ausfallen, können wir durch den automatischen Wechsel zu einem anderen Rechenzentrum weiterarbeiten. Theoretisch kann ein Produkt im Warenkorb verloren gehen, aber Sie sehen es, legen es erneut in den Warenkorb und arbeiten weiter. In diesem Fall ist RTO = 0.
Gleichzeitig gibt es noch eine zweite Möglichkeit: Wenn wir auf „Senden“ geklickt haben, möchten wir, dass die Daten nicht verloren gehen. Ab diesem Moment beginnt die Automatisierung zu funktionieren – das ist RPO = 0. Bei Verwendung dieser beiden unterschiedlichen Muster könnte es sich in einem Fall einfach um einen geografisch verteilten Cluster mit einem umschaltbaren Master handeln, in einem anderen Fall um eine Art Quorum-Datensatz. Muster können variieren, aber wir lösen das Problem.
Darüber hinaus können wir mit einer verteilten Anwendungsregistrierung auch alles skalieren – wir verfügen über viele Dispatcher und Ausführende, die auf diese Registrierung zugreifen.
Cassandra und Tarantool zusammen
Es gibt noch einen anderen Fall - „Schaufenster der Bilanzen“. Hier ist ein interessanter Fall der gemeinsamen Verwendung von Cassandra und Tarantool.
Wir verwenden Cassandra, weil 2 Milliarden Anrufe pro Tag nicht die Grenze sind und es noch mehr sein werden. Vermarkter lieben es, den Traffic nach Quelle einzufärben; immer mehr Details tauchen beispielsweise in sozialen Netzwerken auf. Das alles trägt zur Geschichte bei.
Mit Cassandra können Sie horizontal auf jede beliebige Größe skalieren.
Wir fühlen uns mit Cassandra wohl, aber sie hat ein Problem: Sie kann nicht gut lesen. Bei der Aufnahme ist alles in Ordnung, 30 pro Sekunde sind kein Problem - Leseproblem.
Daher ist ein Thema mit einem Cache aufgetaucht und wir haben gleichzeitig das folgende Problem gelöst: Es gibt einen alten traditionellen Fall, bei dem Geräte aus einem Wechsel von der Online-Abrechnung in die Dateien gelangen, die wir in Cassandra laden. Wir hatten mit dem Problem des zuverlässigen Herunterladens dieser Dateien zu kämpfen, selbst wenn wir den Rat des IBM Dateiübertragungsmanagers befolgten – es gibt Lösungen, die die Dateiübertragung effizient verwalten, beispielsweise mithilfe des UDP-Protokolls anstelle von TCP. Das ist gut, aber es sind noch Minuten, und wir haben noch nicht alles geladen, der Operator im Callcenter kann dem Kunden nicht antworten, was mit seinem Guthaben passiert ist – wir müssen warten.
Um dies zu verhindern, haben wir Wir nutzen parallele Funktionsreserven. Wenn wir ein Ereignis über Kafka an Tarantool senden und die Aggregate beispielsweise für heute in Echtzeit neu berechnen, erhalten wir Barguthaben, das Guthaben mit jeder Geschwindigkeit übertragen kann, zum Beispiel 100 Transaktionen pro Sekunde und die gleichen 2 Sekunden.
Das Ziel besteht darin, dass nach einem Anruf innerhalb von 2 Sekunden in Ihrem persönlichen Konto nicht nur der geänderte Kontostand, sondern auch Informationen darüber angezeigt werden, warum er sich geändert hat.
Abschluss
Dies waren Beispiele für die Verwendung von Tarantool. Uns gefielen die Offenheit von Mail.ru und ihre Bereitschaft, verschiedene Fälle zu berücksichtigen.
Für Berater von BCG oder McKinsey, Accenture oder IBM ist es ohnehin schwierig, uns mit etwas Neuem zu überraschen – vieles von dem, was sie anbieten, machen wir entweder bereits, haben es getan oder planen es zu tun. Ich denke, dass Tarantool seinen rechtmäßigen Platz in unserem Technologie-Stack einnehmen und viele bestehende Technologien ersetzen wird. Wir befinden uns in der aktiven Entwicklungsphase dieses Projekts.
Der Bericht von Oleg und Andrey ist einer der besten auf der Tarantool-Konferenz im letzten Jahr, und am 17. Juni wird Oleg Ivlev dort sprechen mit einem Bericht . Auch Alexander Deulin wird einen Vortrag von MegaFon halten . Lassen Sie uns herausfinden, was sich geändert hat und welche Pläne umgesetzt wurden. Nehmen Sie teil – die Konferenz ist kostenlos, Sie müssen sich nur anmelden . Alle und das Konferenzprogramm wurde erstellt: neue Fälle, neue Erfahrungen im Umgang mit Tarantool, Architektur, Unternehmen, Tutorials und Microservices.
Source: habr.com