Warum benötigt ein Unternehmen wie MegaFon Tarantool im Billing? Es scheint, als komme normalerweise ein Anbieter, bringe eine groĂe Kiste mit, stecke den Stecker in die Steckdose â und da ist das Billing! FrĂŒher war es so, aber das ist jetzt Archaik, und solche Dinosaurier sind entweder ausgestorben oder stehen kurz vor dem Aussterben. UrsprĂŒnglich war Billing ein System zur Rechnungsstellung â ein ZĂ€hler oder Taschenrechner. Im modernen Telekommunikationsbereich ist es ein System zur Automatisierung des gesamten Lebenszyklus der Interaktion mit dem Abonnenten, von der Vertragsunterzeichnung bis zur KĂŒndigung, einschlieĂlich der Echtzeittarifierung, Zahlungsannahme und noch vielem mehr. Billing in Telekommunikationsunternehmen Ă€hnelt einem Kampfroboter â groĂ, mĂ€chtig und mit Waffen ĂŒberladen.
Was hat es also mit Tarantool auf sich? DarĂŒber werden Oleg Ivlev und Andrey Knyazev. Oleg ist der leitende Architekt der Firma mit umfangreicher Erfahrung in internationalen Unternehmen, Andrey ist Direktor fĂŒr GeschĂ€ftssysteme. Aus der Transkription ihres Vortrags auf der  werden Sie erfahren, warum R&D in Unternehmen nötig ist, was Tarantool ist, wie das Ende der vertikalen Skalierung und die Globalisierung die Voraussetzungen fĂŒr das Entstehen dieser Datenbank im Unternehmen schufen, ĂŒber technologische Herausforderungen, die Transformation der Architektur und wie sich der Tech-Stack von MegaFon von Netflix, Google und Amazon unterscheidet.
Projekt "Einheitliches Billing"
Das Projekt, ĂŒber das hier gesprochen wird, heiĂt "Einheitliches Billing". Gerade hier hat Tarantool seine besten Eigenschaften gezeigt.
Das Wachstum der LeistungsfĂ€higkeit von High-End-GerĂ€ten konnte mit dem Wachstum der Abonnentenbasis und der Anzahl der Dienstleistungen nicht mithalten. Es wurde ein weiteres Wachstum der Abonnenten und Dienstleistungen aufgrund von M2M, IoT erwartet, und die filialen Besonderheiten fĂŒhrten zu einer Verschlechterung der Time-to-Market. Das Unternehmen entschloss sich, ein einheitliches GeschĂ€ftssystem mit einer einzigartigen modularen Architektur auf Weltklasse-Niveau zu schaffen, als Ersatz fĂŒr 8 bestehende, unterschiedliche Billing-Systeme.
MegaFon ist acht Unternehmen in einem. 2009 wurde die Reorganisation abgeschlossen: Die Filialen in ganz Russland schlossen sich zu einem einzigen Unternehmen, OAO "MegaFon" (jetzt PJSC) zusammen. So entstanden im Unternehmen 8 Billing-Systeme mit eigenen "maĂgeschneiderten" Lösungen, filialen Besonderheiten und unterschiedlichen organisatorischen Strukturen, IT und Marketing.
Alles war gut, bis wir ein gemeinsames Bundesprojekt starten mussten. Plötzlich traten jede Menge Schwierigkeiten auf: Bei einigen gab es eine Abrechnung mit Aufrundung nach oben, bei anderen nach unten, und wieder andere verwendeten den arithmetischen Mittelwert. Solche Probleme gab es tausendfach.
Trotz der Tatsache, dass es nur eine Version des Abrechnungssystems und einen Anbieter gab, waren die Einstellungen so unterschiedlich, dass es lange dauerte, alles zusammenzufĂŒgen. Wir versuchten, die Anzahl zu reduzieren, und stieĂen auf ein zweites Problem, das vielen Unternehmen bekannt ist.
Vertikale Skalierung. Selbst die beste Hardware zur damaligen Zeit erfĂŒllte nicht die Anforderungen. In der Arbeit verwendeten wir Hewlett-Packard-AusrĂŒstung der Superdome Hi-End-Serie, aber sie konnte nicht einmal die Anforderungen von zwei Filialen bewĂ€ltigen. Wir wollten eine horizontale Skalierung ohne hohe Betriebskosten und Investitionen.
Die Erwartung eines Wachstums der Anzahl der Abonnenten und Dienstleistungen. Berater brachten in die Telekommunikationswelt Geschichten ĂŒber IoT und M2M: Es kommen Zeiten, in denen in jedem Telefon und jedem BĂŒgeleisen eine SIM-Karte sein wird, und in KĂŒhlschrĂ€nken sogar zwei. Heute haben wir eine bestimmte Anzahl von Abonnenten, in naher Zukunft werden es jedoch erheblich mehr sein.
Technologische Herausforderungen
Diese vier GrĂŒnde trieben uns zu ernsthaften VerĂ€nderungen. Es gab die Wahl zwischen der Modernisierung des Systems und der Neugestaltung von Grund auf. Wir dachten lange nach, trafen ernsthafte Entscheidungen und veranstalteten Ausschreibungen. SchlieĂlich entschieden wir uns fĂŒr eine komplette Neugestaltung und nahmen interessante Herausforderungen an â technologische Herausforderungen.
Skalierbarkeit
FrĂŒher waren es, sagen wir, 8 Abrechnungssysteme fĂŒr 15 Millionen Abonnenten, und jetzt sollte es 100 Millionen Abonnenten und mehr geben â die Last ist um ein Vielfaches höher.
Wir wurden hinsichtlich des MaĂstabes vergleichbar mit groĂen Internetspielern wie Mail.ru oder Netflix.
Aber die weitere Steigerung der Last und der Abonnentenzahl stellte ernsthafte Aufgaben fĂŒr uns dar.
Die Geografie unseres riesigen Landes
Zwischen Kaliningrad und Wladiwostok 7500 km und 10 Zeitzonen. Die Lichtgeschwindigkeit ist endlich, und auf solchen Distanzen sind die Verzögerungen bereits signifikant. 150 ms auf den besten modernen GlasfaserkanĂ€len sind zu viel fĂŒr eine Echtzeit-Abrechnung, besonders in der Telekommunikation in Russland, wie sie jetzt ist. DarĂŒber hinaus muss man innerhalb eines Arbeitstags aktualisieren, und mit den unterschiedlichen Zeitzonen ist das ein Problem.
Wir bieten nicht nur Dienste gegen eine AbogebĂŒhr an, sondern haben auch komplexe Tarife, Pakete und verschiedene Modifizierungen. Es reicht nicht aus, dem Abonnenten zu gestatten oder zu verbieten, zu sprechen; wir mĂŒssen ihm eine bestimmte Quote geben â Anrufe und Aktionen in Echtzeit zu berechnen, sodass er es nicht bemerkt.
Fehlertoleranz
Dies ist die Kehrseite der Zentralisierung.
Wenn wir alle Abonnenten in einem System sammeln, sind alle NotfĂ€lle und Katastrophen katastrophal fĂŒr das GeschĂ€ft. Daher entwerfen wir die Systeme so, dass sie den Einfluss von UnfĂ€llen auf die gesamte Abonnentenbasis ausschlieĂen.
Dies ist das Resultat wiederum der Abkehr von vertikaler Skalierung. Als wir auf horizontale Skalierung umstiegen, erhöhten wir die Anzahl der Server von hunderten auf tausende. Diese mĂŒssen verwaltet und austauschbar gemacht werden, IT-Infrastruktur automatisch gesichert und das verteilte System wiederhergestellt werden.
Solche interessanten Herausforderungen standen vor uns. Wir haben das System entworfen und in diesem Moment versucht, den weltweiten besten Praktiken zu folgen, um zu ĂŒberprĂŒfen, wie sehr wir im Trend liegen, wie sehr wir modernen Technologien folgen.
Weltweite Erfahrung
Erstaunlicherweise fanden wir in der globalen Telekommunikation keinen einzigen Referenzpunkt.
Europa fiel aufgrund der Anzahl der Abonnenten und des MaĂstabs weg, die USA aufgrund der Flachheit ihrer Tarife. Wir schauten etwas in China und fanden etwas in Indien und holten Spezialisten von Vodafone India.
FĂŒr die Analyse der Architektur haben wir ein Dream Team unter der Leitung von IBM zusammengestellt â Architekten aus verschiedenen Bereichen. Diese Leute konnten angemessen bewerten, was wir tun, und bestimmtes Wissen in unsere Architektur einbringen.
Skalierung
Einige Zahlen zur Veranschaulichung.
Wir entwerfen das System fĂŒr 80 Millionen Abonnenten mit einem Puffer fĂŒr eine Milliarde. So beseitigen wir zukĂŒnftige Schwellenwerte. Das liegt nicht daran, dass wir China erobern wollen, sondern wegen des Drucks von IoT und M2M.
300 Millionen Dokumente werden in Echtzeit verarbeitet. Obwohl wir 80 Millionen Abonnenten haben, arbeiten wir auch mit potenziellen Kunden und solchen, die uns verlassen haben, falls wir Forderungen eintreiben mĂŒssen. Daher sind die tatsĂ€chlichen Volumina deutlich gröĂer.
2 Milliarden Transaktionen Ă€ndern tĂ€glich den Saldo â das sind Zahlungen, Buchungen, Anrufe und andere Ereignisse. 200 TB Daten Ă€ndern sich aktiv, etwas langsamer Ă€ndern sich 8 PB Daten, und das ist kein Archiv, sondern lebendige Daten in einer einzigen Abrechnung. Der MaĂstab bezĂŒglich der Rechenzentren â 5 tausend Server an 14 Standorten.
Technologischer Stack
Als wir die Architektur geplant und mit dem Aufbau des Systems begonnen haben, haben wir uns die interessantesten und fortschrittlichsten Technologien importiert. Es entstand ein technologischer Stack, der jedem Internet-Player und Unternehmen, die hochbelastete Systeme erstellen, bekannt ist.
Der Stack Ă€hnelt den Stacks anderer groĂer Player: Netflix, Twitter, Viber. Er besteht aus 6 Komponenten, aber wir möchten ihn verkleinern und vereinheitlichen.
FlexibilitĂ€t ist gut, aber in einem groĂen Unternehmen kommt man ohne Vereinheitlichung nicht weiter.
Wir wollen Oracle nicht gegen Tarantool austauschen. In der RealitĂ€t groĂer Firmen ist das Utopie, oder ein Kreuzzug von 5-10 Jahren mit ungewissem Ausgang. Aber Cassandra und Couchbase lassen sich gut durch Tarantool ersetzen, und darauf arbeiten wir hin.
Warum Tarantool?
Es gibt 4 einfache Kriterien, warum wir diese DB gewÀhlt haben.
Geschwindigkeit. Wir haben Lasttests auf industriellen Systemen von MegaFon durchgefĂŒhrt. Tarantool hat gewonnen â es zeigte die beste Leistung.
Man kann nicht sagen, dass andere Systeme die Anforderungen von MegaFon nicht erfĂŒllen. Die aktuellen Memory-Lösungen sind so leistungsfĂ€hig, dass dieser Puffer fĂŒr das Unternehmen ausreichend ist. Aber uns interessiert es, mit einem MarktfĂŒhrer zu arbeiten und nicht mit dem, der hinterherhinkt, auch im Lasttest.
Tarantool deckt die BedĂŒrfnisse des Unternehmens sogar auf lange Sicht ab.
TCO-Kosten. Der Support von Couchbase bei den Volumina von MegaFon kostet astronomische Summen, wÀhrend die Situation mit Tarantool viel angenehmer ist und sie funktional Àhnlich sind.
Eine weitere angenehme Eigenschaft, die unseren Entscheidungsprozess etwas beeinflusst hat, ist, dass Tarantool besser mit Speicher arbeitet als andere Datenbanken. Es zeigt maximale Effizienz.
ZuverlĂ€ssigkeit. MegaFon investiert in ZuverlĂ€ssigkeit wie wohl niemand anderer. Daher haben wir, als wir Tarantool betrachteten, festgestellt, dass wir es so gestalten mĂŒssen, dass es unseren Anforderungen entspricht.
Wir haben Zeit und Finanzen investiert und gemeinsam mit Mail.ru eine Enterprise-Version geschaffen, die jetzt bereits in mehreren anderen Unternehmen verwendet wird.
Tarantool-Enterprise hat uns in Bezug auf Sicherheit, ZuverlĂ€ssigkeit und Logging vollstĂ€ndig ĂŒberzeugt.
Partnerschaft
Das Wichtigste fĂŒr mich ist der direkte Kontakt mit dem Entwickler. Das ist genau das, womit uns die Leute von Tarantool gewonnen haben.
Wenn du zu einem Spieler kommst, besonders zu einem, der mit einem Anchor-Kunden arbeitet, und sagst, dass du willst, dass die DB dies, das und jenes kann, antwortet er normalerweise:
â Gut, legen Sie die Anforderungen ans Ende des Stapels â irgendwann werden wir sie wahrscheinlich erreichen.
Viele haben einen Fahrplan fĂŒr die nĂ€chsten 2-3 Jahre, und es ist nahezu unmöglich, sich dort einzufĂŒgen. Die Entwickler von Tarantool ĂŒberzeugen durch Offenheit, nicht nur mit MegaFon, und passen ihr System an den Kunden an. Das ist groĂartig und gefĂ€llt uns sehr.
Wo wir Tarantool angewendet haben
Wir nutzen Tarantool in mehreren Elementen. Das Erste â im Pilotprojekt, das wir auf einem Adresskatalog-System gemacht haben. Damals wollten wir, dass es ein System wird, das Ă€hnlich ist wie Yandex Maps und Google Maps, aber es kam etwas anders heraus.
Zum Beispiel der Adresskatalog in der VerkaufsoberflĂ€che. Bei Oracle dauert die Suche nach der richtigen Adresse 12-13 Sekunden â unkomfortable Zahlen. Wenn wir zu Tarantool wechseln, Oracle in der Konsole durch eine andere DB ersetzen und die gleiche Suche durchfĂŒhren, erhalten wir eine Beschleunigung um das 200-Fache! Die Stadt erscheint nach dem dritten Buchstaben. Momentan passen wir die OberflĂ€che an, damit dies nach dem ersten Buchstaben geschieht. Dennoch ist die Reaktionsgeschwindigkeit ganz anders â jetzt Millisekunden statt Sekunden.
Die zweite Anwendung â das modische Thema, das âzwei Geschwindigkeiten ITâ genannt wird. Das liegt daran, dass Berater aus jedem Radio sagen, dass Unternehmen dorthin gehen sollten.
Hier gibt es eine Schicht von Infrastruktur, darĂŒber liegen DomĂ€nen, zum Beispiel ein Abrechnungssystem, wie es bei Telekommunikation der Fall ist, Unternehmenssysteme, Unternehmensberichterstattung. Das ist der Kern, den man nicht anfassen sollte. Das heiĂt, man kann natĂŒrlich, aber man muss paranoid die QualitĂ€t sichern, denn das bringt dem Unternehmen Geld.
DarĂŒber hinaus gibt es eine Schicht von Mikrodiensten â das, was den Betreiber oder einen anderen Spieler differenziert. Mikrodienste können schnell auf Basis gewisser Caches erstellt werden, indem Daten aus verschiedenen DomĂ€nen hochgeholt werden. Hier ist Raum fĂŒr Experimente â wenn etwas nicht funktioniert, schlieĂt man einen Mikrodienst und öffnet einen anderen. Das sorgt wirklich fĂŒr eine erhöhte Marktreaktionszeit und steigert die ZuverlĂ€ssigkeit und Geschwindigkeit des Unternehmens.
Mikrodienste sind wahrscheinlich die Hauptrolle von Tarantool bei MegaFon.
Wo wir planen, Tarantool anzuwenden
Im Vergleich zu unserem erfolgreichen Abrechnungsprojekt mit den Transformationsprogrammen bei Deutsche Telekom, ĐĄĐČŃĐ·ŃĐșĐŸĐŒ, Vodafone India ist es erstaunlich dynamisch und kreativ. Im Verlauf der Umsetzung dieses Projekts wurde nicht nur MegaFon und seine Struktur transformiert, sondern es entstand auch Tarantool-enterprise bei Mail.ru, und unser Anbieter Nexign (frĂŒher âĐĐ”ŃĐ”Ń-ĐĄĐ”ŃĐČĐžŃâ) â BSS Box (eine Box-Lösung fĂŒr Abrechnung).
Das ist in gewisser Hinsicht ein historisches Projekt fĂŒr den russischen Markt. Man kann es mit dem vergleichen, was in Frederick Brookss Buch "Mythical Man-Month" beschrieben wird. Damals, in den 60er Jahren, zog IBM fĂŒr die Entwicklung des neuen Betriebssystems OS/360 fĂŒr Mainframes 5.000 Menschen heran. Bei uns sind es weniger â 1.800, aber unsere Leute sind motiviert, und unter BerĂŒcksichtigung des Einsatzes von Open Source und neuer AnsĂ€tze arbeiten wir produktiver.
Unten sind die Domains der Abrechnung oder, um es breiter zu fassen, der GeschĂ€ftssysteme aufgefĂŒhrt. Die Leute aus dem Enterprise-Bereich kennen CRM bestens. Andere Systeme sollten bereits bei allen vorhanden sein: Open API, API Gateway.
Open API
Lass uns erneut auf die Zahlen schauen und darauf, wie Open API derzeit funktioniert. Die Last betrĂ€gt 10.000 Transaktionen pro Sekunde. Da wir planen, die Schicht der Mikroservices aktiv weiterzuentwickeln und eine öffentliche API fĂŒr MegaFon aufzubauen, erwarten wir in diesem Bereich zukĂŒnftig ein deutliches Wachstum. 100.000 Transaktionen werden es sicherlich sein..
Ich weiĂ nicht, ob wir bei SSO mit Mail.ru mithalten können â die haben anscheinend 1.000.0000 Transaktionen pro Sekunde. Ihre Lösung interessiert uns sehr und wir planen, ihre Erfahrungen zu ĂŒbernehmen â zum Beispiel, um eine funktionale Reserve fĂŒr SSO mit Hilfe von Tarantool zu schaffen. Momentan beschĂ€ftigt sich ein Team von Mail.ru damit bei uns.
CRM
CRM sind die 80 Millionen Abonnenten, die wir auf eine Milliarde bringen möchten, da bereits 300 Millionen Dokumente vorliegen, die eine dreijĂ€hrige Historie enthalten. Wir warten wirklich auf neue Dienstleistungen, und hier ist der Wachstumspunkt â das sind die angebundenen Dienstleistungen. Es ist ein Bereich, der wachsen wird, weil es immer mehr Dienstleistungen geben wird. Folglich wird eine Historie benötigt, und wir möchten uns daran nicht die Finger verbrennen.
Die Abrechnung selbst in Bezug auf Rechnungsstellung und das Management der Forderungen der Kunden hat sich in eine separate Domain transformiert.Um die LeistungsfÀhigkeit zu steigern, wurde das Architekturmuster der Domain-Architektur angewendet..
Das System ist in DomÀnen unterteilt, die Last ist verteilt und die Fehlertoleranz ist gewÀhrleistet. ZusÀtzlich wurde an der verteilten Architektur gearbeitet.
Alles andere sind Lösungen auf Unternehmensebene. Im Call-Speicher â 2 Milliarden pro Tag, 60 Milliarden pro Monat. Manchmal mĂŒssen sie fĂŒr den Monat neu berechnet werden, und es ist besser, das schnell zu tun. Finanzmonitoring â das sind die 300 Millionen, die stĂ€ndig wachsen: die Abonnenten wechseln hĂ€ufig zwischen den Anbietern, was diesen Teil erhöht.
Die mobilfunkseitig bedeutendsten Komponenten sind Online-Tarifierung. Das sind die Systeme, die es Ihnen ermöglichen, zu telefonieren oder nicht, und Entscheidungen in Echtzeit treffen. Hier betrĂ€gt die Last 30.000 Transaktionen pro Sekunde, aber angesichts des Wachstums der DatenĂŒbertragung planen wir 250.000 Transaktionen, und deshalb sind wir sehr an Tarantool interessiert.
Das vorherige Bild zeigt die DomĂ€nen, in denen wir Tarantool anwenden möchten. Das CRM selbst ist natĂŒrlich umfassender und wir planen, es im Kern zu verwenden.
Meine berechnete Zahl von 100 Millionen Abonnenten beunruhigt mich als Architekt â was, wenn es 101 Millionen sind? Muss alles wieder ĂŒberarbeitet werden? Um das zu vermeiden, verwenden wir Caches, wĂ€hrend wir gleichzeitig die VerfĂŒgbarkeit erhöhen.
Insgesamt gibt es zwei AnsÀtze zur Anwendung von Tarantool. Der erste ist alle Caches auf Mikroservice-Ebene aufzubauen.Soweit ich informiert bin, geht VympelCom auf diesem Weg und erstellt einen Kunden-Cache.
Wir sind hingegen weniger von Anbietern abhĂ€ngig, Ă€ndern den Kern des BSS, deshalb haben wir bereits eine einheitliche Kundenkartei "out of the box". Aber wir möchten sie erweitern. Daher verwenden wir einen etwas anderen Ansatz â wir erstellen Caches in die Systeme hinein..
Das verringert die Synchronisationsprobleme â ein System ist fĂŒr den Cache und die Masterquelle verantwortlich.
Dieser Ansatz passt gut zu Tarantool mit einer transaktionalen Struktur, bei der nur die Teile aktualisiert werden, die Ănderungen betreffen, also DatenĂ€nderungen. Alles andere kann woanders gespeichert werden. Es gibt keinen riesigen Data Lake, keinen unmanagebaren globalen Cache. Caches werden fĂŒr das System, die Produkte oder die Kunden entworfen, um die Wartung zu erleichtern. Wenn ein verĂ€rgerter Abonnent anruft, möchte man ihm qualitativ hochwertig helfen.
RTO und RPO
In der IT gibt es zwei Begriffe â RTO und RPO.
Recovery Time Objective â dies ist die Wiederherstellungszeit des Dienstes nach einem Ausfall. RTO = 0 bedeutet, dass der Dienst auch dann weiterlĂ€uft, wenn etwas ausfĂ€llt.
Wiederherstellungspunktziel â dies ist die Zeit zur Wiederherstellung von Daten, wie viele Daten wir in einem bestimmten Zeitraum verlieren können. RPO = 0 bedeutet, dass wir keine Daten verlieren.
Aufgabe fĂŒr Tarantool
Lassen Sie uns versuchen, die Aufgabe fĂŒr Tarantool zu lösen.
Gegeben: ein allgemein verstĂ€ndlicher Warenkorb, zum Beispiel bei Amazon oder anderswo. Erforderlich dass der Warenkorb 24 Stunden an 7 Tagen in der Woche oder 99,99% der Zeit funktioniert. Die Bestellungen, die bei uns eingehen, mĂŒssen in der Reihenfolge bleiben, da wir die Verbindung zu einem Abonnenten nicht chaotisch ein- oder ausschalten können â alles muss strikt sequenziell sein. Das vorherige Abonnement beeinflusst das nĂ€chste, daher sind die Daten wichtig â nichts darf verloren gehen.
Lösung. Man könnte versuchen, direkt zu fragen und die Datenbankentwickler zu kontaktieren, aber die Aufgabe ist mathematisch nicht lösbar. Man könnte sich an Theoreme, Erhaltungsgesetze und Quantenphysik erinnern, aber wozu â sie ist auf Datenbankebene nicht lösbar.
Hier kommt ein altbewĂ€hrter architektonischer Ansatz zur Anwendung â man muss das Fachgebiet gut kennen, um dieses RĂ€tsel damit zu lösen.
Unsere Lösung: Wir erstellen ein verteiltes Antragsregister fĂŒr Tarantool â einen geo-verteilten Cluster. Auf dem Diagramm sind das drei verschiedene Rechenzentren â zwei vor dem Ural, eines hinter dem Ural, und wir verteilen alle AntrĂ€ge auf diese Zentren.
Netflix, das jetzt als eines der fĂŒhrenden Unternehmen in der IT gilt, hatte bis 2012 nur ein Rechenzentrum. Am Vorabend des katholischen Weihnachtsfestes, dem 24. Dezember, fiel dieses Rechenzentrum aus. Die Benutzer in Kanada und den USA blieben ohne ihre Lieblingsfilme, waren sehr enttĂ€uscht und haben darĂŒber in den sozialen Netzwerken geschrieben. Jetzt hat Netflix drei Rechenzentren an der West-Ost-KĂŒste und eines in Westeuropa.
Wir bauen von Anfang an eine geo-verteilte Lösung â uns ist die Ausfallsicherheit wichtig.
Also haben wir einen Cluster, aber wie gehen wir mit RPO = 0 und RTO = 0 um? Die Lösung ist einfach und hÀngt vom Fachgebiet ab.
Was ist wichtig bei AntrĂ€gen? Zwei Teile: das Zusammenstellen des Warenkorbs VOR der Kaufentscheidung, und NACH. Der Teil VOR wird im Telekommunikationsbereich normalerweise als Bestellaufnahme oder Bestellverhandlung. Im Telekommunikationsbereich kann dies viel komplizierter sein als in einem Online-Shop, weil der Kunde dort bedient werden muss, man muss ihm 5 verschiedene Optionen anbieten, und das alles braucht eine Weile, aber der Warenkorb fĂŒllt sich. In diesem Moment kann ein Ausfall möglich sein, aber das ist nicht schlimm, weil es in einem interaktiven Modus unter Aufsicht einer Person geschieht.
Wenn das Moskauer Rechenzentrum plötzlich ausfĂ€llt, können wir automatisch auf ein anderes Rechenzentrum umschalten und die Arbeit fortsetzen. Theoretisch kann ein Produkt im Warenkorb verloren gehen, aber Sie sehen das, fĂŒgen den Warenkorb wieder hinzu und arbeiten weiter. In diesem Fall betrĂ€gt RTO = 0.
Es gibt auch eine zweite Option: Wenn wir auf âAbsendenâ klicken, möchten wir, dass die Daten nicht verloren gehen. Ab diesem Zeitpunkt beginnt die Automatisierung zu funktionieren â das ist bereits RPO = 0. Die Anwendung dieser beiden unterschiedlichen Muster kann in einem Fall einfach ein geografisch verteiltes Cluster mit einem umschaltbaren Master sein, im anderen Fall eine Quorum-Aufzeichnung. Die Muster können variieren, aber wir lösen das Problem.
Des Weiteren, mit einem verteilten Register fĂŒr AntrĂ€ge, können wir das Ganze auch skalieren â viele Dispatcher und AusfĂŒhrende haben, die auf dieses Register zugreifen.
Cassandra und Tarantool zusammen
Es gibt noch einen weiteren Fall â âBalanceanzeigeâ. Hier ist gerade ein interessanter Fall des gemeinsamen Einsatzes von Cassandra und Tarantool.
Wir verwenden Cassandra, weil 2 Milliarden Anrufe pro Tag â keine Grenze sind, und es werden mehr werden. Vermarkter lieben es, den Traffic nach Quellen zu gliedern, es kommen immer mehr Details ĂŒber soziale Netzwerke hinzu, zum Beispiel. Das alles erweitert die Historie.
Cassandra ermöglicht eine horizontale Skalierung auf beliebige Volumina.
Wir fĂŒhlen uns mit Cassandra wohl, aber sie hat ein Problem â sie ist beim Lesen nicht gut. Beim Schreiben ist alles in Ordnung, 30.000 pro Sekunde sind kein Problem â das Problem liegt beim Lesen.
Deshalb kam das Thema Cache auf, und wir haben gleichzeitig das folgende Problem gelöst: Es gibt einen alten traditionellen Fall, bei dem Daten vom Switch zur Online-Tarifierung in Dateien kommen, die wir in Cassandra hochladen. Wir haben das Problem des zuverlĂ€ssigen Uploads dieser Dateien angegangen und sogar auf den Rat eines IBM-Managers hin eine DateiĂŒbertragungsverwaltung angewendet â es gibt solche Lösungen, die die DatenĂŒbertragung effizient steuern und das UDP-Protokoll, zum Beispiel, anstelle von TCP verwenden. Das ist gut, aber immer noch dauert es Minuten, und bis wir das alles geladen haben, kann der Operator im Call-Center dem Kunden nicht sagen, was mit seinem Guthaben passiert ist â man muss warten.
Um dies zu verhindern, verwenden wir eine parallele funktionale Reserve. Wenn wir ein Ereignis durch Kafka an Tarantool senden und Aggregate in Echtzeit neu berechnen, zum Beispiel fĂŒr heute, erhalten wir Cache von Guthaben, der Guthaben mit beliebiger Geschwindigkeit bereitstellen kann, zum Beispiel 100.000 Transaktionen pro Sekunde und die gleichen 2 Sekunden.
Das Ziel ist es, dass nach einem Anruf bereits nach 2 Sekunden im persönlichen Bereich nicht nur der geÀnderte Betrag sichtbar ist, sondern auch die Information, warum er sich geÀndert hat.
Fazit
Das waren Beispiele fĂŒr die Verwendung von Tarantool. Wir haben die Offenheit von Mail.ru und ihre Bereitschaft, verschiedene FĂ€lle zu betrachten, sehr geschĂ€tzt.
Berater von BCG oder McKinsey, Accenture oder IBM können uns schon schwer mit etwas Neuem ĂŒberraschen â vieles von dem, was sie anbieten, machen wir entweder bereits, haben wir gemacht oder planen, es zu tun. Ich denke, dass Tarantool in unserem Technologiestack einen wĂŒrdigen Platz einnehmen wird und viele bereits existierende Technologien ersetzen kann. Wir befinden uns in der aktiven Phase der Entwicklung dieses Projekts.
Der Vortrag von Oleg und Andrei war einer der besten auf der Tarantool Conference des letzten Jahres, und bereits am 17. Juni wird Oleg Ivlev auf der  mit dem Vortrag . AuĂerdem wird Alexander Deulin von MegaFon mit einem Vortrag . Wir werden erfahren, was sich geĂ€ndert hat und welche PlĂ€ne bereits umgesetzt wurden. SchlieĂen Sie sich uns an â die Konferenz ist kostenlos, man muss sich nur . Alle und das Programm der Konferenz wurde erstellt: neue FĂ€lle, neue Erfahrungen mit der Nutzung von Tarantool, Architektur, Enterprise, Tutorials und Mikrodienste.
Quelle: habr.com
