Miért van egy olyan vállalatnak, mint a MegaFon, szüksége a Tarantoolra a számlázásban? A külső szemlélő számára úgy tűnik, hogy általában a szállító hozza a nagy dobozt, bedugja a konnektorba - és voilà, itt a számlázás! Valaha így volt, de ma már ez elavult, és az ilyen dinoszauruszok vagy kihalnak, vagy kihalóban vannak. Eredetileg a számlázás egy a számlák kiállítására szolgáló rendszer - számológép vagy kalkulátor. A modern telekom szektorban ez a teljes életciklus automatizálásának rendszere az előfizetővel való interakcióban a szerződéskötéstől kezdve a megszüntetésig, beleértve a valós idejű tarifálást, a befizetések fogadását és még sok mást. A telekom cégekben a számlázás hasonlít egy harci robotra - nagy, erős és felfegyverzett.
Mi köze a Tarantoolnak ehhez? Erről mesélnek Oleg Ivlev és Andrey Knyazev. Oleg a cég főarchitektje , hatalmas tapasztalattal külföldi vállalatoknál, Andrey pedig az üzleti rendszerek igazgatója. A előadásukból megtudhatja, miért van szükség a K+F-re a vállalatoknál, mi az a Tarantool, hogyan vált a vertikális skálázás zsákutcája és a globalizáció a DB megjelenésének előfeltételeivé a cégnél, a technológiai kihívások, az architektúra átalakítása, és miben hasonlít a MegaFon technológiai könyezetéhez a Netflix, a Google és az Amazon.
Egységes számlázási projekt
A projekt, amiről szó lesz, az "Egységes számlázás" nevet viseli. Ebben mutatta meg a Tarantool a legjobb tulajdonságait.
A Hi-End berendezések teljesítménynövekedése nem tartott lépést az előfizetői bázis növekedésével és a szolgáltatások növekedésével, és a M2M, IoT miatt további előfizetők és szolgáltatások várhatóak, emellett a fióki sajátosságok rontották az időigényt az új piacon történő megjelenéshez. A cég úgy döntött, hogy létrehoz egy egyesített üzleti rendszert, világklasszis, egyedi moduláris architektúrával, a 8 különböző számlázási rendszer helyett.
A MegaFon nyolc vállalat egyesítése. 2009-ben befejeződött a reorganizáció: a fiókok Oroszország szerte egyesültek egyetlen OAO "MegaFon" (jelenleg PAO) nevű céggé. Így a cég nyolc különálló számlázási rendszerrel rendelkezett, saját "testreszabott" megoldásaikkal, fiókspecifikus jellemzőkkel és eltérő szervezeti struktúrával, IT-vel és marketinggel.
Minden rendben volt, amíg el nem indítottunk egy közös állami terméket. Itt számos nehézség merült fel: valakinek a tarifálása felfelé kerekít, valakinek lefelé, míg másoknál a matematikai átlag szerint működik. Ilyen pillanatokból ezernyi van.
Bár a billing rendszer verziója egy, ugyanaz a szolgáltató, a beállítások annyira eltértek, hogy az összeillesztés sokáig tartott. Megpróbáltuk csökkenteni a számukat, és rátaláltunk egy második problémára, ami sok vállalat számára ismerős.
Függőleges skálázás. Még a korabeli legmenőbb vas sem felelt meg az igényeknek. A munkában Hewlett-Packard Superdome Hi-End sorozatú berendezéseket használtunk, de ezek nem tudták kiszolgálni még két fiók igényeit sem. Szerettük volna a horizontális skálázást nagy működési költségek és tőkebefektetések nélkül.
Az előfizetők és szolgáltatások számának növekedésére való várakozás. A tanácsadók régóta elhozták a telekommunikációs világba az IoT és M2M történeteket: eljön az idő, amikor minden telefonban és vasalóban lesz egy SIM-kártya, a hűtőszekrényekben pedig kettő. Ma van egy bizonyos számú előfizetőnk, a közeljövőben azonban ennek a számnak a nagyságrenddel nagyobbnak kell lennie.
Technológiai kihívások
Ezek a négy ok indított el komoly változtatásokra minket. Két választásunk volt: a rendszer modernizálása vagy egy új projektel való tervezés. Hosszú ideig gondolkodtunk, komoly döntéseket hoztunk, tendereket játszottunk. Végül úgy döntöttünk, hogy az elejétől kezdve tervezzük meg és érdekes kihívások elé néztünk – technológiai kihívások.
Skálázhatóság
Ha régen, mondjuk úgy, 8 billing 15 millió előfizetővel, most már 100 millió előfizetőnek és még többre kellett volna jutnunk — a terhelés nagyságrenddel magasabb. Ezáltal méretben összehasonlíthatóvá váltunk olyan nagy internetes szereplőkkel, mint a Mail.ru vagy a Netflix.
De a terhelés és az előfizetői bázis további növelése komoly feladatokat helyezett elénk.
Országunk hatalmas geográfiája
Kalinyingrádtól Vlagyivosztokig
7500 km és 10 időzóna . A fény sebessége véges, és ilyen távolságok esetén a késleltetések már jelentősek. 150 ms a legjobb modern optikai csatornákon - túl sok a valós idejű tarifáláshoz, főleg a mai orosz telekommunikációs standardok mellett. Ezen kívül a frissítést egy munkanapon belül kell elvégezni, ami különböző időzónák esetén probléma.. A fény sebessége véges, és ilyen távolságokban a késlekedés már számottevő. 150 ms a legjobb modern optikai csatornákon - nem túl sok a valós idejű díjazás számára, különösen a jelenlegi orosz távközlési szektorban. Ezen kívül a frissítést egy munkanapon belül kell elvégezni, ami a különböző időzónák miatt probléma.
Nemcsak előfizetési szolgáltatásokat kínálunk, hanem bonyolult tarifákat, csomagokat és különféle módosítókat is. Nem csak annyit kell tennünk, hogy engedélyezzük vagy megtiltjuk az előfizetők beszélgetését, hanem egy meghatározott kvótát kell adni nekik – valós időben nyilvántartani a hívásokat és tevékenységeket, hogy azt észre se vegyék.
Hibatűrés
Ez a centralizáció ellentéte.
Ha az összes előfizetőt egy rendszerbe gyűjtjük, akkor bármilyen vészhelyzet és katasztrófa katasztrofális a vállalkozás számára. Ezért úgy tervezzük a rendszert, hogy megakadályozza a vészhelyzetek hatását az egész előfizetői bázisra.
Ez ismét a függőleges skálázásról való lemondás következménye. Amikor átálltunk a horizontális skálázásra, a szerverek számát százakról ezerre növeltük. Ezeket kezelni kell, és ki kell alakítani a helyettesíthetőséget, automatikusan helyreállítani az IT-infrastruktúrát és helyreállítani az elosztott rendszert.
Ilyen érdekes kihívásokkal néztünk szembe. Megterveztük a rendszert, és ebben a pillanatban megpróbáltuk megtalálni a világ élvonalbeli tapasztalatait, hogy ellenőrizzük, mennyire vagyunk naprakészen a trendekkel, mennyire követjük a korszerű technológiákat.
Világos tapasztalatok
Meglepő, de a globális telekommunikációban nem találtunk egyetlen hivatkozást sem.
Európa kiesett az előfizetők számát és a méretét tekintve, az USA a tarifák szélessége miatt. Néztünk valamit Kínában, és találtunk valamit Indiában, és szakembereket hoztunk a Vodafone India-tól.
Az architektúra elemzéséhez létrehoztuk a Dream Teamet az IBM vezetésével – különböző területek építészeivel. Ezek az emberek képesek voltak reálisan értékelni, amit csinálunk, és bizonyos tudást hozni a mi architektúránkba.
Skála
Néhány szám az illusztrációhoz.
A rendszert úgy tervezzük, hogy 80 millió előfizetőre és egy milliárd tartalékra. Így megszüntetjük a jövőbeli küszöböket. Nem azért, mert Kínát akarjuk meghódítani, hanem az IoT és az M2M nyomása miatt.
300 millió dokumentumot dolgozunk fel valós időben. Bár 80 millió előfizetőnk van, de dolgozunk potenciális ügyfelekkel és azokkal is, akik elhagytak minket, ha szükséges a követelés behajtásához. Ezért a valós mennyiségek jelentősen nagyobbak.
2 milliárd tranzakció naponta változtatja meg az egyenleget – ezek a kifizetések, jóváírások, hívások és egyéb események. 200 TB adat aktívan változik, kissé lassabban változik 8 PB adat, és ez nem egy archívum, hanem élő adatok egyetlen számlázási rendszerben. A méret a adatközpontok között – 5000 szerver 14 helyszínen.
Technológiai stack
Amikor megterveztük az architektúrát és nekiláttunk a rendszer összeállításához, a legérdekesebb és legmodernebb technológiákat importáltuk. Olyan technológiai stack jött létre, amely ismerős minden internetes szereplő és a nagyvállalatok számára, akik nagy terhelésű rendszereket készítenek.
A stack hasonló más nagy szereplők stackjeihez: Netflix, Twitter, Viber. Hat alkotóból áll, de szeretnénk csökkenteni és egységesíteni.
A rugalmasság jó dolog, de egy nagyvállalat számára a standardizálás elengedhetetlen.
Nem tervezzük, hogy az Oracle-t Tarantool-ra cseréljük. Nagyvállalati környezetben ez utópia, vagy 5-10 éves keresztény hadjárat egy bizonytalan kimenettel. De a Cassandra és a Couchbase helyett a Tarantool bátran váltható, és ebbe az irányba törekszünk.
Miért Tarantool?
Négy egyszerű indokunk van, amiért ezt az adatbázist választottuk.
Sebesség. Terheléses teszteket végeztünk a MegaFon ipari rendszerein. A Tarantool nyert – a legjobb teljesítményt nyújtotta.
Nem mondhatjuk, hogy más rendszerek nem elégítik ki a MegaFon igényeit. A jelenlegi memória-alapú megoldások annyira teljesítményorientáltak, hogy a cég számára ez bőséges. De minket az érdekel, hogy egy vezetővel dolgozzunk, és ne azzal, aki csak lemarad a terheléses teszt során.
A Tarantool akár hosszú távon is kielégíti a cég igényeit.
TCO költség. A Couchbase támogatása a MegaFon szintjén hihetetlenül drága, míg a Tarantool helyzete sokkal kedvezőbben alakul, és funkcionálisan közel állnak egymáshoz.
Még egy kellemes tulajdonság, ami némileg befolyásolta a választásunkat – a Tarantool a többi adatbázishoz képest jobban bánik a memóriával. Megmutatja a maximális hatékonyságot.
Megbízhatóság. A MegaFon rengeteget fektet a megbízhatóságba, talán másokhoz képest egyedülállóan. Ezért amikor ránéztünk a Tarantool-ra, rájöttünk, hogy úgy kell megoldanunk, hogy megfeleljen a követelményeknek.
Befektettük az időnket és a pénzünket, és a Mail.ru-val közösen létrehoztuk az enterprise verziót, ami már több más cégnél is használt.
A Tarantool-enterprise teljes mértékben megfelelt számunkra biztonság, megbízhatóság és naplózás terén.
Partnerség
A legfontosabb számomra – közvetlen kapcsolat a fejlesztővel. Ez volt az, amivel a Tarantool srácai megnyertek minket.
Ha egy játékoshoz jössz, különösen ahhoz, aki egy nagy ügyfélnél dolgozik, és azt mondod, hogy szükséged van arra, hogy az adatbázis képes legyen erre, arra és amarra, általában így válaszol:
— Rendben, helyezzék el a követelményeket annak az alján, talán egyszer eljutunk odáig.
Sokan van, akiknek van egy ütemtervük a következő 2-3 évre, és abba beépülni gyakorlatilag lehetetlen; a Tarantool fejlesztői viszont nyitottságukkal megnyernek, nemcsak a MegaFon számára, hanem alkalmazkodnak a rendszerüket az ügyfél igényeihez is. Ez nagyszerű, és nagyon tetszik nekünk.
Hol alkalmaztuk a Tarantoolt
Nálunk a Tarantool több elemében is használatban van. Elsőként a pilot projektben, amelyet az címkatalógus rendszerén készítettünk. Korábban azt szerettük volna, ha ez a rendszer hasonlít a Yandex.Maps-re és a Google Maps-re, de kicsit másképp alakult.
Példaként, az címkatalógus az értékesítési interfészen. Az Oracle rendszeren a keresés 12-13 másodpercet vesz igénybe — nem éppen kényelmes számok. Amikor átváltunk a Tarantoolra, és az Oracle-t egy másik adatbázissal helyettesítjük a konzolban, és végrehajtjuk ugyanazt a keresést, akkor 200-szoros gyorsulást kapunk! A város a harmadik betű után ugrik elő. Jelenleg az interfészt úgy alakítjuk, hogy ez már az első betű után történjen. Mindazonáltal a válaszidő teljesen más — már milliszekundumok a másodpercek helyett.
A második alkalmazás — egy divatos téma, amit kétszintű IT-nek neveznek. Mindez azért van, mert a tanácsadók minden sarkon azt mondják, hogy a nagyvállalatoknak ide kell menniük.
Itt van egy infrastrukturális réteg, felette domének, például egy számlázási rendszer, mint a telekommunikációnál, vállalati rendszerek, vállalati jelentés. Ez a mag, amit nem szükséges megérinteni. Tehát persze, mondhatod, hogy lehet, de paranoid szinten kell biztosítani a minőséget, mert ez hoz pénzt a vállalatnak.
Továbbá van egy mikroszolgáltatás réteg — ami megkülönbözteti az operátort vagy más játékost. A mikroszolgáltatásokat gyorsan létrehozhatjuk különböző cache-eken alapulva, adatokat emelve fel a különböző doménekből. Itt van a kísérletezés tere — ha valami nem sikerült, bezártál egy mikroszolgáltatást, és megnyitottál egy másikat. Ez tényleg javítja a time-to-market-t és növeli a vállalat megbízhatóságát és sebességét.
A mikroszolgáltatások valószínűleg a Tarantool fő szerepe a MegaFonban.
Hol tervezzük alkalmazni a Tarantoolt
Ha összehasonlítjuk a mi sikeres számlázási projektünket a Deutsche Telekom, a Svjaztkom és a Vodafone India transzformációs programjaival, meglepően dinamikus és kreatív. A projekt megvalósítása során nemcsak a MegaFon és annak struktúrája alakult át, hanem megjelent a Tarantool-enterprise a Mail.ru-nál, míg a mi beszállítónk, a Nexign (korábban „Péter-Szolgáltatás”) - a BSS Box (dobozos számlázási megoldás).
Ez, bizonyos értelemben, történelmi projekt a orosz piacon. Összehasonlítható azzal, ami Frederick Brooks 'A mítikus ember-hónap' című könyvében szerepel. Akkoriban, az 1960-as években az IBM 5000 embert vonzott az OS/360 új operációs rendszerének kifejlesztéséhez a mainframe számítógépekhez. Nálunk kevesebb - 1800, de a mi fiaink csíkosak, és figyelembe véve a nyílt forrást és új megközelítéseket, hatékonyabban dolgozunk.
Az alábbiakban a számlázási domainek jelennek meg, vagy, szélesebben fogalmazva, az üzleti rendszerek. Az enterprise emberek jól ismerik a CRM-et. A másik rendszereknek már mindenkinek lennie kell: Open API, API Gateway.
Open API
Nézzük meg újra a számokat és hogy jelenleg hogyan működik az Open API. A terhelése - 10 000 tranzakció másodpercenként. Mivel tervezzük, hogy aktívan fejlesztjük a mikroszolgáltatások réteget és nyilvános API-t építünk a MegaFon számára, nagyobb növekedésre számítunk a jövőben éppen ezen a területen. 100 000 tranzakció biztosan lesz.
Nem tudom, hogy össze tudunk-e hasonlítani a Mail.ru-val SSO-ban - nekik úgy tűnik, 1 000 000 tranzakciójuk van másodpercenként. Az ő megoldásuk rendkívül érdekes számunkra, és tervezzük, hogy átveszünk tőlük tapasztalatokat - például funkcionális tartalék SSO-t a Tarantool segítségével. Jelenleg a Mail.ru fejlesztői foglalkoznak ezzel nálunk.
CRM
A CRM azok között a 80 millió előfizető között van, akiket egy milliárdra szeretnénk emelni, mert már létezik 300 millió dokumentum, amely hároméves történetet tartalmaz. Valóban várjuk az új szolgáltatásokat, és itt a növekedés pontja - a csatlakoztatott szolgáltatások. Ez egy szféra, amely növekedni fog, mert egyre több szolgáltatás létezik. Ennek megfelelően szükség lesz történelmi adatokra, nem szeretnénk ezen megbotlani.
Magának a számlázásnak az ügyfelek kintlévőségével foglalkozó részlege átalakult egy külön domainné. A teljesítmény fokozása érdekében, domaine architektúrával alkalmazott tervezési mintát használtunk..
A rendszer domainekre van bontva, a terhelés elosztva van, és a hibatűrés biztosítva van. Továbbá, munkát végeztünk a elosztott architektúrával.
Minden más vállalati szintű megoldás. A hívásraktárban - 2 milliárd naponta, 60 milliárd havonta. Néha újra kell számolni őket egy hónap hosszan, és jobb, ha gyorsan. Pénzügyi monitoring — ezek a 300 millió, amelyek folyamatosan növekednek: az előfizetők gyakran váltanak az operátorok között, így növelve ezt a részesedést.
A legtelekomosabb komponens a mobilkommunikációban - ez online tarifálás. Ezek azok a rendszerek, amelyek lehetővé teszik, hogy hívjanak vagy ne hívjanak, valós időben hoznak döntést. Itt a terhelés 30 000 tranzakció másodpercenként, de figyelembe véve az adatok átviteli növekedését, tervezzük 250 000 tranzakciót, ezért nagyon érdekel minket a Tarantool.
Az előző kép azok a domainek, ahol alkalmazni kívánjuk a Tarantoolt. Maga a CRM természetesen szélesebb, és a magjában is alkalmazni kívánjuk.
A 100 millió előfizetőre vonatkozó számom kicsit aggaszt az építész számára - mi van, ha 101 millió? Újra mindent át kell dolgozni? Ennek elkerülése érdekében cache-eket alkalmazunk, miközben növeljük a rendelkezésre állást.
Összességében két megközelítés létezik a Tarantool alkalmazására. Az első - minden cache-t mikroservizek szintjén kell felépíteni.A tudomásom szerint ezen az úton halad a VimpelCom, létrehozva az ügyfél cache-et.
Mi kevésbé függünk a szolgáltatóktól, váltunk a BSS magján, ezért a már a dobozból kikerülő egyesített ügyfélállományunk van. De szeretnénk ezt kiterjeszteni. Ezért egy kicsit más megközelítést alkalmazunk - a cache-eket a rendszerek belsejében készítjük el..
Így kevesebb az aszinkronitás - egy rendszer felel a cache-ért és az alapvető mesterforrásért.
Ez a módszer jól illeszkedik a Tarantool megközelítéséhez tranzakcionális kerettel, amikor csak azok a részek frissülnek, amelyek az adatok frissítéseire vonatkoznak. Minden mást máshol lehet tárolni. Nincs hatalmas adatló, nem kezelhető globális cache. A cache-eket a rendszerhez, termékekhez vagy az ügyfelekhez tervezik, vagy azért, hogy megkönnyítsék a karbantartást. Amikor egy elégedetlen minőségű előfizető hív, szeretnénk őt megfelelően kiszolgálni.
RTO és RPO
Az IT-ben két kifejezés létezik - RTO és RPO.
Recovery time objective — ez a szolgáltatás helyreállítási ideje hiba esetén. Az RTO = 0 azt jelenti, hogy még ha valami le is áll, a szolgáltatás folytatja a működést.
helyreállítási pont célja — ez az adataink helyreállítási ideje, mennyi adatot veszítünk el egy bizonyos időszak alatt. Az RPO = 0 azt jelenti, hogy nem veszítünk el adatokat.
Feladat Tarantoolról
Próbáljuk meg megoldani a Tarantool feladatát.
Adott: mindenki számára ismert kosár, például az Amazonon vagy máshol. Szükséges hogy a kosár 24 órán keresztül, a hét minden napján működjön, azaz 99,99%-os időpontossággal. Az ide érkező megrendeléseknek meg kell őrizniük a sorrendet, mert nem tudjuk kaotikusan ki-be kapcsolni a felhasználót — mindennek szigorúan következetesnek kell lennie. Az előző előfizetés hatással van a következőre, így az adatok fontosak — semmi nem tűnhet el.
Megoldás. Lehet próbálkozni a közvetlen megoldással, és megkérdezni az adatbázis fejlesztőit, de a feladat matematikailag nem oldható meg. Felidézhetjük a tételeket, a megmaradás törvényeit, a kvantumfizikát, de minek — ezt nem lehet megoldani az adatbázis szintjén.
Itt a régi jó architekturális megközelítés működik — jól kell ismerni a szakterületet, és ennek révén megoldani ezt a rejtvényt.
A mi megoldásunk: egy elosztott igénybejelentő rendszer létrehozása Tarantoolra — földrajzilag elosztott klaszter. A diagramon ez három különböző adatközpont — kettő az Ural előtt, egy az Uralon túl, és az összes igényt ezekbe a központokba osztjuk el.
A Netflixnek, amelyet ma az IT egyik vezetőjének tartanak, 2012-ig csak egy adatközpontja volt. Karácsony előestéjén, december 24-én ez az adatközpont leállt. Kanadai és amerikai felhasználók maradtak a kedvenc filmjeik nélkül, nagyon elkeseredtek, és erről a közösségi médiában írtak. Most a Netflixnek három adatközpontja van a nyugati és keleti parton, és egy Nyugat-Európában.
Kezdetben földrajzilag elosztott megoldást építünk — számunkra fontos a hibatűrés.
Tehát van egy klaszterünk, de mi a helyzet az RPO = 0 és az RTO = 0 esetén? A megoldás egyszerű, és a szakterülettől függ.
Mi a fontos az igénybejelentéseknél? Két rész: a kosár felvázolása AZ ELŐTT a vásárlási döntés meghozatala előtt, és UTÁN. Az ELŐTT részt a telekommunikációban általában megrendelés rögzítésének vagy megrendelés tárgyalásának. A telekommunikációban ez sokkal bonyolultabb lehet, mint egy online boltban, mert ott az ügyfelet ki kell szolgálni, öt lehetőséget kell ajánlani, és ez egy ideig tart, de a kosár megtelik. Ebben a pillanatban hiba lehetséges, de ez nem rémisztő, mert interaktív módon történik egy ember felügyelete alatt.
Ha a Moszkvai adatközpont hirtelen leáll, akkor automatikusan át tudunk kapcsolni egy másik adatközpontra, és folytatjuk a munkát. Elméletben egy termék elveszhet a kosárból, de ezt látja, újra kiegészíti a kosarat, és folytatja a munkát. Ebben az esetben az RTO = 0.
Ugyanakkor van egy másik lehetőség: amikor megnyomtuk a "submit" gombot, szeretnénk, ha az adatok nem vesznének el. Ettől a pillanattól kezdve az automatika működésbe lép — ez már RPO = 0. Ezeknek a két különböző mintázatnak az alkalmazása egy esetben egyszerűen geográfiai elosztású klaszter lehet egy átkapcsolható mesterrel, egy másik esetben valamilyen kvórummal rendelkező feljegyzés. A minták változhatnak, de megoldjuk a problémát.
Továbbá, mivel van egy elosztott kérelmek nyilvántartása, ezt mind skálázhatjuk is — sok diszpécserünk és végrehajtónk lehet, akik ehhez a nyilvántartáshoz fordulnak.
Cassandra és Tarantool együtt
Van még egy eset — "a mérlegvitrin". Itt egy érdekes példa a Cassandra és a Tarantool közös alkalmazására.
A Cassandrát alkalmazzuk, mert napi 2 milliárd hívás — nem határ, és még több lesz. A marketingszakemberek szeretik a források szerint szétválasztani a forgalmat, egyre több részlet jelenik meg a közösségi médiákkal kapcsolatban, például. Ez mind növeli a történetet.
A Cassandra lehetővé teszi a horizontális skálázást bármilyen mennyiségre.
Jól érezzük magunkat a Cassandraval, de van egy problémája — nem jó az olvasásra. A felvétel rendben van, 30 000 másodpercenként nem probléma — a probléma az olvasásban.
Ezért merült fel a cache téma, és egyúttal megoldottuk a következő problémát: van egy régi, hagyományos eset, amikor a szűrőberendezésből a valós idejű tarifálás adatai fájlokként érkeznek, amelyeket a Cassandraba töltünk fel. Megküzdöttünk a fájlok megbízható betöltésének problémájával, még az IBM menedzser fájltranszfer tanácsára is alkalmaztunk olyan megoldásokat, amelyek hatékonyan kezelik a fájlok átvitelét UDP protokollal, például, nem pedig TCP-vel. Ez jó, de azért még mindig percekig eltart, és amíg ezeket nem töltjük fel, a call center operátora nem tudja megválaszolni az ügyfél kérdéseit a mérlegéről – várni kell.
Annak érdekében, hogy ez ne történjen meg, párhuzamos funkcionális tartalékot alkalmazunk. Amikor eseményt küldünk a Kafkán keresztül a Tarantoolba, újraszámolva az aggregátumokat valós időben, például ma, akkor a mérlegek cache-ét, amely bármilyen sebességgel képes visszaadni a mérlegeket, például 100 ezer tranzakció másodpercenként, és ugyanaz a 2 másodperc.
A cél az, hogy a hívás befejezése után már 2 másodpercen belül a felhasználói fiókban ne csak a megváltozott mérleg, hanem az információ is legyen arról, hogy miért változott meg.
Zárás
Ezek voltak a Tarantool használatának példái. Nagyon tetszett nekünk a Mail.ru nyitottsága, és hogy készen álltak különböző esetek megvitatására.
A BCG, McKinsey, Accenture vagy IBM konzultánsait már nehéz megdöbbenteniük újdonságokkal – sok dolog, amit ajánlanak, vagy már csinálunk, vagy megcsináltunk, vagy tervezünk csinálni. Azt gondolom, hogy a Tarantool méltó helyet foglal el a technológiai stackünkben, és sok már meglévő technológiát helyettesíteni fog. Aktívan fejlesztjük ezt a projektet.
Oleg és Andrej előadása az előző évi Tarantool Konferencián az egyik legjobb volt, és június 17-én Oleg Ivlev előadást tart a címmel . A MegaFon részéről Alekszandr Deulin is előadást tart . Megtudjuk, hogy mi változott, milyen terveket sikerült megvalósítani. Csatlakozzatok – a konferencia ingyenes, csak . Minden és a konferencia programja már összeállt: új esetek, új tapasztalatok a Tarantool használatával, architektúra, enterprise, tutorialok és mikroszolgáltatások.
Forrás: habr.com
