MegaFon gibi bir şirketin faturalandırmada neden Tarantool'a ihtiyacı var? Dışarıdan bakıldığında satıcının genellikle geldiği, büyük bir kutu getirdiği, fişi prize taktığı görülüyor - ve bu da fatura! Bir zamanlar durum böyleydi ama artık arkaiktir ve bu tür dinozorların nesli çoktan tükenmiştir veya tükenmek üzeredir. Başlangıçta faturalandırma, fatura düzenlemeye yönelik bir sistemdir - bir sayma makinesi veya hesap makinesi. Modern telekomünikasyonda bu Bir sözleşmenin imzalanmasından fesih aşamasına kadar bir aboneyle etkileşimin tüm yaşam döngüsü için otomasyon sistemigerçek zamanlı faturalandırma, ödeme kabulü ve çok daha fazlasını içerir. Telekom şirketlerinde faturalandırma bir savaş robotuna benzer; büyük, güçlü ve silahlarla dolu.
Tarantool'un bununla ne ilgisi var? Bunun hakkında konuşacaklar Oleg Ivlev и Andrey Knyazev. Oleg şirketin baş mimarıdır Yabancı şirketlerde geniş deneyime sahip olan Andrey, iş sistemleri direktörüdür. Raporlarının transkriptinden şirketlerde Ar-Ge'ye neden ihtiyaç duyulduğunu, Tarantool'un ne olduğunu, dikey ölçeklendirme ve küreselleşme çıkmazının şirkette bu veritabanının ortaya çıkması için nasıl ön koşul haline geldiğini, teknolojik zorlukları, mimari dönüşümü ve MegaFon'un teknoloji yığınının Netflix'e nasıl benzediğini öğreneceksiniz. , Google ve Amazon.
"Birleşik Faturalandırma" Projesi
Söz konusu projenin adı “Birleşik Faturalandırma”. Tarantool en iyi özelliklerini burada gösterdi.
Hi-End ekipmanın üretkenliğindeki artış, abone bazındaki büyümeye ve hizmet sayısındaki büyümeye ayak uyduramadı; M2M, IoT ve şube özelliklerinin yol açtığı abone ve hizmet sayısında daha fazla büyüme bekleniyordu. pazara sunma süresinde bir bozulmaya neden olabilir. Şirket, mevcut 8 farklı faturalandırma sistemi yerine, dünya standartlarında benzersiz modüler mimariye sahip birleşik bir iş sistemi oluşturmaya karar verdi.
MegaFon bir arada sekiz şirketten oluşuyor. 2009 yılında yeniden yapılanma tamamlandı: Rusya'daki şubeler tek bir şirket olan MegaFon OJSC'de (şimdi PJSC) birleşti. Böylece şirketin kendi “özel” çözümleri, şube özellikleri ve farklı organizasyon yapıları, BT ve pazarlaması olan 8 faturalandırma sistemi bulunmaktadır.
Ortak bir federal ürünü piyasaya sürmek zorunda kalana kadar her şey yolundaydı. Burada pek çok zorluk ortaya çıktı: Bazıları için tarifeler yukarı yuvarlanıyor, diğerleri için aşağı yuvarlanıyor ve diğerleri için aritmetik ortalamaya göre. Böyle binlerce an var.
Faturalandırma sisteminin tek bir versiyonu, tek tedarikçi olmasına rağmen ayarlar o kadar farklıydı ki bir araya getirilmesi uzun zaman aldı. Sayılarını azaltmaya çalıştık ve birçok kurumun aşina olduğu ikinci bir sorunla karşılaştık.
Dikey ölçeklendirme. O zamanın en havalı donanımı bile ihtiyaçları karşılayamıyordu. Superdome Hi-End serisinden Hewlett-Packard ekipmanlarını kullandık ancak iki şubenin bile ihtiyacını karşılayamadı. Büyük işletme maliyetleri ve sermaye yatırımları olmadan yatay ölçeklendirme istedim.
Abone ve hizmet sayısında artış beklentisi. Danışmanlar uzun zamandır telekom dünyasına IoT ve M2M ile ilgili hikayeler aktarıyor: Her telefonun ve ütünün bir SIM kartına sahip olacağı ve buzdolabında da iki tane olacağı bir zaman gelecek. Bugün bir sayıda abonemiz var, ancak yakın gelecekte çok daha fazlası olacak.
teknolojik zorluklar
Bu dört neden bizi ciddi değişiklikler yapmaya itti. Sistemi yükseltmekle sıfırdan tasarlamak arasında bir seçim vardı. Uzun süre düşündük, ciddi kararlar aldık, ihalelere çıktık. Sonuç olarak, en başından itibaren tasarım yapmaya karar verdik ve ilginç zorlukların, teknolojik zorlukların üstesinden geldik.
ölçeklenebilirlik
Daha önce olsaydı diyelim, diyelim 8 milyon aboneye 15 faturave şimdi işe yaraması gerekirdi 100 milyon abone ve üzeri - yük bir kat daha yüksektir.
Mail.ru veya Netflix gibi büyük İnternet oynatıcılarıyla ölçek olarak karşılaştırılabilir hale geldik.
Ancak yükü ve abone tabanını artırmaya yönelik daha fazla hareket bizim için ciddi zorluklar yarattı.
Geniş ülkemizin coğrafyası
Kaliningrad ve Vladivostok arasında 7500 km ve 10 zaman dilimi. Işığın hızı sonludur ve bu mesafelerde gecikmeler zaten önemlidir. En havalı modern optik kanallarda 150 ms, gerçek zamanlı faturalandırma için çok fazla, özellikle de şu anda Rusya'da telekomda olduğu gibi. Ayrıca bir iş günü içinde güncelleme yapmanız gerekiyor ve farklı saat dilimlerinde bu bir sorun.
Yalnızca abonelik ücreti karşılığında hizmet sunmuyoruz; karmaşık tarifelerimiz, paketlerimiz ve çeşitli değiştiricilerimiz var. Abonenin yalnızca konuşmasına izin vermek veya reddetmekle kalmayıp, aynı zamanda ona belirli bir kota vermemiz - çağrıları ve eylemleri fark etmemesi için gerçek zamanlı olarak hesaplamamız gerekir.
hata toleransı
Bu da merkezileşmenin diğer yüzüdür.
Tüm aboneleri tek bir sistemde toplarsak, herhangi bir acil durum ve felaket iş için felaket olur. Bu nedenle sistemi, kazaların tüm abone tabanına etkisini ortadan kaldıracak şekilde tasarlıyoruz.
Bu yine dikey ölçeklendirmeyi reddetmenin bir sonucudur. Yatay ölçeklendirdiğimizde sunucu sayısını yüzlerden binlere çıkardık. Yönetilmeleri ve değiştirilebilir olmaları, BT altyapısının otomatik olarak yedeklenmesi ve dağıtılmış sistemin geri yüklenmesi gerekir.
Çok ilginç zorluklarla karşılaştık. Sistemi tasarladık ve o anda ne kadar trendde olduğumuzu, ileri teknolojileri ne kadar takip ettiğimizi kontrol etmek için küresel en iyi uygulamaları bulmaya çalıştık.
Dünya deneyimi
Şaşırtıcı bir şekilde küresel telekomda tek bir referans bulamadık.
Avrupa, abone sayısı ve ölçek açısından, ABD ise tarifelerinin sabitliği açısından geriledi. Bazılarına Çin'de baktık, bazılarını Hindistan'da bulduk ve Vodafone Hindistan'dan uzmanlar kiraladık.
Mimariyi analiz etmek için farklı alanlardan mimarlardan oluşan IBM'in liderliğinde bir Rüya Takımı oluşturduk. Bu insanlar ne yaptığımızı yeterince değerlendirebilir ve mimarimize belirli bilgileri getirebilirler.
ölçek
Örnek olması açısından birkaç sayı.
Sistemi buna göre tasarlıyoruz Bir milyar rezervle 80 milyon abone. Gelecekteki eşikleri bu şekilde kaldırıyoruz. Bunun nedeni Çin'i ele geçireceğimiz değil, IoT ve M2M'nin saldırısıdır.
Gerçek zamanlı olarak işlenen 300 milyon belge. 80 milyon abonemiz olmasına rağmen alacaklarımızı tahsil etmemiz gerekiyorsa hem potansiyel müşterilerimizle hem de aramızdan ayrılanlarla çalışıyoruz. Bu nedenle gerçek hacimler belirgin şekilde daha büyüktür.
2 milyar işlem Bakiye günlük olarak değişir; bunlar ödemeler, masraflar, aramalar ve diğer olaylardır. 200 TB veri aktif olarak değişiyor, biraz daha yavaş değiş 8 PB verive bu bir arşiv değil, tek bir faturalandırmadaki canlı verilerdir. Veri merkezine göre ölçeklendirme - 5 sitede 14 bin sunucu.
Teknoloji yığını
Mimariyi planlayıp sistemi kurmaya başladığımızda en ilginç ve ileri teknolojileri ithal ettik. Sonuç, yüksek yüklü sistemler üreten tüm İnternet oynatıcılarının ve şirketlerin aşina olduğu bir teknoloji yığınıdır.
Yığın diğer büyük oyuncuların yığınlarına benzer: Netflix, Twitter, Viber. 6 bileşenden oluşuyor ama biz onu kısaltıp birleştirmek istiyoruz.
Esneklik iyidir ama büyük bir şirkette birleşme olmadan hiçbir yol yoktur.
Aynı Oracle'ı Tarantool'a değiştirmeyeceğiz. Büyük şirketlerin gerçekliğinde bu bir ütopyadır ya da 5-10 yıllık, sonucu belirsiz bir haçlı seferidir. Ancak Cassandra ve Couchbase kolayca Tarantool ile değiştirilebilir ve biz de bunun için çabalıyoruz.
Neden Tarantool?
Bu veritabanını seçmemizin 4 basit kriteri var.
hız. MegaFon endüstriyel sistemleri üzerinde yük testleri yaptık. Tarantool kazandı - en iyi performansı gösterdi.
Bu, diğer sistemlerin MegaFon'un ihtiyaçlarını karşılamadığı anlamına gelmez. Mevcut bellek çözümleri o kadar verimli ki şirketin rezervleri fazlasıyla yeterli. Ancak biz bir liderle uğraşmak istiyoruz, yük testi de dahil olmak üzere geride kalan biriyle değil.
Tarantool, uzun vadede bile şirketin ihtiyaçlarını karşılıyor.
TCO maliyeti. MegaFon hacimlerinde Couchbase desteği astronomik miktarlarda paraya mal oluyor, ancak Tarantool ile durum çok daha keyifli ve işlevsellik açısından benzerler.
Seçimimizi biraz etkileyen bir diğer güzel özellik ise Tarantool'un hafızayla diğer veritabanlarına göre daha iyi çalışmasıdır. Gösterir maksimum verimlilik.
Güvenilirlik. MegaFon güvenilirliğe muhtemelen herkesten daha fazla yatırım yapıyor. Tarantool'a baktığımızda onu gereksinimlerimize uygun hale getirmemiz gerektiğini fark ettik.
Zamanımızı ve mali kaynaklarımızı harcadık ve Mail.ru ile birlikte şu anda başka birçok şirkette kullanılan kurumsal bir sürüm oluşturduk.
Tarantool-enterprise güvenlik, güvenilirlik ve günlük kaydı açısından bizi tamamen memnun etti.
Ortaklık
Benim için en önemli şey geliştiriciyle doğrudan iletişim. Tarantool'daki adamların rüşvet verdiği şey de tam olarak bu.
Bir oyuncuya, özellikle de bir çapa istemcisiyle çalışan birine gelip bunu, şunu ve bunu yapabilmek için veritabanına ihtiyacınız olduğunu söylerseniz, genellikle şöyle cevap verir:
- Tamam, gereksinimleri bu yığının en altına koy; bir gün muhtemelen onlara ulaşacağız.
Birçoğunun önümüzdeki 2-3 yıl için bir yol haritası var ve oraya entegre olmak neredeyse imkansız, ancak Tarantool geliştiricileri sadece MegaFon'dan değil, açıklıklarıyla da büyülüyor ve sistemlerini müşteriye uyarlıyor. Çok hoş ve gerçekten hoşumuza gidiyor.
Tarantool'u nerede kullandık?
Tarantool'u çeşitli unsurlarda kullanıyoruz. İlki pilottaAdres dizini sisteminde yaptığımız. Bir zamanlar Yandex.Haritalar ve Google Haritalar'a benzer bir sistem olmasını istemiştim ama biraz farklı çıktı.
Örneğin satış arayüzündeki adres kataloğu. Oracle'da istenilen adresin aranması 12-13 saniye sürer. - rahatsız edici sayılar. Tarantool'a geçip Oracle'ı konsolda başka bir veritabanıyla değiştirdiğimizde ve aynı aramayı yaptığımızda 200 kat hızlanma elde ediyoruz! Üçüncü harften sonra şehir ortaya çıkıyor. Şimdi arayüzü, bu ilkinden sonra olacak şekilde uyarlıyoruz. Ancak tepki hızı tamamen farklıdır; saniye yerine milisaniyedir.
İkinci uygulama, iki hızlı BT adı verilen modaya uygun bir temadır.. Çünkü her köşedeki danışmanlar şirketlerin oraya gitmesi gerektiğini söylüyor.
Bir altyapı katmanı var, onun üstünde etki alanları var, örneğin telekom gibi faturalandırma sistemi, kurumsal sistemler, kurumsal raporlama. Bu, dokunulmasına gerek olmayan çekirdektir. Yani elbette mümkün ama paranoyakça kaliteyi sağlamak çünkü kuruma para getiriyor.
Daha sonra, operatörü veya diğer oyuncuyu farklılaştıran mikro hizmetler katmanı gelir. Mikro hizmetler, belirli önbelleklere dayalı olarak hızlı bir şekilde oluşturulabilir ve farklı alanlardan veriler buraya getirilebilir. Burada deneyler için alan — Bir şeyler yolunda gitmezse bir mikro hizmeti kapatıp diğerini açtım. Bu, pazara sunma süresinin gerçek anlamda artmasını sağlar ve şirketin güvenilirliğini ve hızını artırır.
Mikro hizmetler Tarantool'un MegaFon'daki ana rolü olabilir.
Tarantool'u nerede kullanmayı planlıyoruz?
Başarılı faturalandırma projemizi Deutsche Telekom, Svyazcom, Vodafone Hindistan'daki dönüşüm programlarıyla karşılaştırırsak şaşırtıcı derecede dinamik ve yaratıcı olduğunu görüyoruz. Bu projenin uygulanması sürecinde sadece MegaFon ve yapısı dönüştürülmekle kalmadı, aynı zamanda Mail.ru'da Tarantool-enterprise ve satıcımız Nexign (eski adıyla Peter-Service) - BSS Box (kutulu bir faturalandırma çözümü) ortaya çıktı.
Bu bir anlamda Rusya pazarı için tarihi bir proje. Frederick Brooks'un "Efsanevi Adam-Ayı" kitabında anlatılanlarla karşılaştırılabilir. Daha sonra 60'lı yıllarda IBM, ana bilgisayarlar için yeni OS/360 işletim sistemini geliştirmek üzere 5 kişiyi işe aldı. Bizde daha az var - 000, ama bizimkiler yelekli ve açık kaynak kullanımını ve yeni yaklaşımları hesaba katarak daha verimli çalışıyoruz.
Aşağıda faturalandırmanın veya daha genel anlamda iş sistemlerinin alanları verilmiştir. Kurumsal insanlar CRM'i çok iyi biliyor. Herkesin zaten başka sistemleri olması gerekir: Açık API, API Ağ Geçidi.
Açık API
Rakamlara tekrar bakalım ve Open API'nin şu anda nasıl çalıştığına bakalım. Onun yükü Saniyede 10 işlem. Mikro hizmetler katmanını aktif olarak geliştirmeyi ve MegaFon genel API'sini oluşturmayı planladığımızdan, bu bölümde gelecekte daha fazla büyüme bekliyoruz. Kesinlikle 100 işlem olacak.
SSO'da Mail.ru ile karşılaştırabilir miyiz bilmiyorum - adamların saniyede 1 işlemi var gibi görünüyor. Çözümleri bizim için son derece ilgi çekici ve biz de onların deneyimlerini benimsemeyi planlıyoruz (örneğin, Tarantool kullanarak işlevsel bir SSO yedeklemesi yapmak). Artık Mail.ru'nun geliştiricileri bunu bizim için yapıyor.
CRM
CRM, bir milyara çıkarmak istediğimiz 80 milyon abonenin aynısı çünkü halihazırda üç yıllık geçmişi olan 300 milyon belge var. Gerçekten yeni hizmetleri sabırsızlıkla bekliyoruz ve burada büyüme noktası bağlantılı hizmetlerdir. Bu büyüyecek bir top çünkü giderek daha fazla hizmet olacak. Buna göre bir hikayeye ihtiyacımız olacak, buna rastlamak istemiyoruz.
Fatura düzenleme açısından kendini faturalandırma, müşteri alacakları ile çalışma ayrı bir alana dönüştürüldü. Performansı artırmak için, uygulamalı etki alanı mimarisi mimari modeli.
Sistem alanlara bölünür, yük dağıtılır ve hata toleransı sağlanır. Ayrıca dağıtık mimariyle de çalıştık.
Geriye kalan her şey kurumsal düzeyde çözümlerdir. Çağrı depolama alanında - Günde 2 milyarAyda 60 milyar. Bazen onları bir ay içinde saymanız gerekir ve çabuk olması daha iyidir. Finansal izleme - bu, sürekli büyüyen ve büyüyen tam olarak aynı 300 milyon: aboneler genellikle operatörler arasında koşuyor ve bu kısmı artırıyor.
Mobil iletişimin en telekom bileşeni çevrimiçi faturalandırma. Gerçek zamanlı olarak aramanızı veya aramamanızı, karar vermenizi sağlayan sistemlerdir. Burada yük saniyede 30 işlem ama veri aktarımındaki büyümeyi de hesaba katarak planlıyoruz 250 işlemve bu nedenle Tarantool ile çok ilgileniyoruz.
Bir önceki resim Tarantool kullanacağımız domainleri gösteriyor. CRM'in kendisi elbette daha geniştir ve biz onu çekirdeğin kendisinde kullanacağız.
Tahmini TTX rakamımız olan 100 milyon abone, bir mimar olarak kafamı karıştırıyor; peki ya 101 milyonsa? Her şeyi yeniden yapmak zorunda mısın? Bunun olmasını önlemek için önbellekleri kullanır, aynı zamanda erişilebilirliği artırırız.
Genel olarak Tarantool'u kullanmanın iki yaklaşımı vardır. Birinci - tüm önbellekleri mikro hizmet düzeyinde oluşturun. Anladığım kadarıyla VimpelCom bu yolu izleyerek istemcilerin önbelleğini oluşturuyor.
Satıcılara daha az bağımlıyız, BSS çekirdeğini değiştiriyoruz, böylece tek bir istemci dosyamız var. Ama biz bunu genişletmek istiyoruz. Bu nedenle biraz farklı bir yaklaşım benimsiyoruz - sistemlerin içinde önbellek oluştur.
Bu şekilde daha az senkronizasyon olur; hem önbellekten hem de ana ana kaynaktan tek bir sistem sorumludur.
Yöntem, yalnızca güncellemelerle, yani veri değişiklikleriyle ilgili parçaların güncellendiği bir işlem iskeletine sahip Tarantool yaklaşımıyla iyi uyum sağlar. Geriye kalan her şey başka bir yerde saklanabilir. Büyük bir veri gölü, yönetilmeyen küresel önbellek yoktur. Önbellekler sistem için, ürünler için, istemciler için veya bakım açısından hayatı kolaylaştırmak için tasarlanmıştır. Bir abone arayıp hizmetinizin kalitesinden rahatsız olduğunda, kaliteli hizmet sunmak istersiniz.
RTO ve RPO
BT'de iki terim vardır - OTR и RPO.
İyileşme süresi hedefi Bir arızadan sonra hizmeti geri yüklemek için gereken süredir. RTO = 0, bir şeyler arızalansa bile hizmetin çalışmaya devam ettiği anlamına gelir.
Kurtarma noktası hedefi - bu, veri kurtarma süresidir, belirli bir süre içinde ne kadar veri kaybedebileceğimizdir. RPO = 0, veri kaybetmediğimiz anlamına gelir.
Tarantool görevi
Tarantool için bir sorunu çözmeye çalışalım.
Dano: Amazon'da veya başka bir yerde herkesin anlayabileceği bir uygulama sepeti. Gereken böylece alışveriş sepeti haftanın 24 günü 7 saat, yani zamanın %99,99'unda çalışır. Bize gelen siparişler düzenli kalmalıdır çünkü abonenin bağlantısını rastgele açıp kapatamayız - her şey kesinlikle tutarlı olmalıdır. Önceki abonelik bir sonrakini etkiler, dolayısıyla veriler önemlidir; hiçbir şey kaybolmamalıdır.
karar. Sorunu doğrudan çözmeye çalışabilir ve veritabanı geliştiricilerine sorabilirsiniz ancak sorun matematiksel olarak çözülemez. Teoremleri, korunum yasalarını, kuantum fiziğini hatırlayabilirsiniz, ancak bunun nedeni DB düzeyinde çözülemez.
Eski güzel mimari yaklaşım burada işe yarıyor; konu alanını iyi bilmeniz ve bu bulmacayı çözmek için onu kullanmanız gerekiyor.
Çözümümüz: coğrafi olarak dağıtılmış bir küme olan Tarantool'da dağıtılmış bir uygulama kaydı oluşturmak. Diyagramda bunlar üç farklı veri işleme merkezidir - ikisi Urallardan önce, biri Uralların ötesinde ve biz tüm talepleri bu merkezler arasında dağıtıyoruz.
Artık BT sektörünün liderlerinden biri olarak kabul edilen Netflix'in 2012 yılına kadar tek bir veri merkezi vardı. 24 Aralık Katolik Noeli arifesinde bu veri merkezi çöktü. Kanada ve ABD'deki kullanıcılar en sevdikleri filmlerden mahrum kaldı, çok üzüldü ve bunu sosyal ağlarda yazdı. Netflix'in şu anda batı-doğu kıyısında üç ve Batı Avrupa'da bir veri merkezi var.
Başlangıçta coğrafi olarak dağıtılmış bir çözüm oluşturuyoruz; hata toleransı bizim için önemlidir.
Yani bir kümemiz var, peki ya RPO = 0 ve RTO = 0? Konuya göre çözüm basittir.
Başvurularda neler önemlidir? İki Bölüm: Sepet Atma ÖNCE satın alma kararı vermek ve SONRA. Telekomünikasyondaki DO kısmına genellikle denir sipariş yakalama veya sipariş müzakeresi. Telekomda bu, çevrimiçi bir mağazadan çok daha zor olabilir, çünkü orada müşteriye hizmet verilmesi, 5 seçenek sunulması gerekir ve bunların hepsi bir süre için olur, ancak sepet doludur. Şu anda bir başarısızlık mümkündür, ancak bu korkutucu değildir çünkü etkileşimli olarak insan gözetiminde gerçekleşir.
Moskova veri merkezi aniden arızalanırsa otomatik olarak başka bir veri merkezine geçerek çalışmaya devam edeceğiz. Teorik olarak sepette bir ürün kaybolabilir ama siz onu gördüğünüzde tekrar sepete ekleyin ve çalışmaya devam edin. Bu durumda RTO = 0.
Aynı zamanda ikinci bir seçenek daha var: “Gönder”e tıkladığımızda verilerin kaybolmamasını istiyoruz. Bu andan itibaren otomasyon çalışmaya başlar - bu RPO = 0'dır. Bu iki farklı modeli kullanarak, bir durumda, tek bir değiştirilebilir yöneticiye sahip coğrafi olarak dağıtılmış bir küme, diğer durumda ise bir tür çekirdek kaydı olabilir. Desenler değişebilir ama sorunu çözüyoruz.
Ayrıca, dağıtılmış bir uygulama kayıt defterine sahip olarak, hepsini ölçeklendirebiliriz; bu kayıt defterine erişen çok sayıda dağıtıcı ve yürütücü bulunur.
Cassandra ve Tarantool birlikte
Başka bir durum daha var - "dengelerin vitrini". İşte Cassandra ve Tarantool'un ortak kullanımına ilişkin ilginç bir örnek.
Cassandra'yı kullanıyoruz çünkü günde 2 milyar çağrı sınır değil ve daha fazlası da olacak. Pazarlamacılar trafiği kaynağa göre renklendirmeyi seviyor; örneğin sosyal ağlarda giderek daha fazla ayrıntı ortaya çıkıyor. Hepsi hikayeye katkıda bulunuyor.
Cassandra yatay olarak herhangi bir boyuta ölçeklendirmenize olanak tanır.
Cassandra'nın yanında kendimizi rahat hissediyoruz ama onun bir sorunu var; okuması pek iyi değil. Kayıtta her şey yolunda, saniyede 30 hız sorun değil - okuma problemi.
Bu nedenle, önbellekli bir konu ortaya çıktı ve aynı zamanda şu sorunu da çözdük: Cassandra'ya yüklediğimiz dosyalara çevrimiçi faturalandırmadaki bir anahtardan gelen ekipmanın geldiği eski bir geleneksel durum var. IBM dosya aktarımı yöneticisinin tavsiyelerini kullanarak bile bu dosyaların güvenilir bir şekilde indirilmesi sorunuyla mücadele ettik - örneğin TCP yerine UDP protokolünü kullanarak dosya aktarımını verimli bir şekilde yöneten çözümler var. Bu iyi, ancak hala dakikalar var ve henüz hepsini yüklemedik, çağrı merkezindeki operatör müşteriye bakiyesine ne olduğunu cevaplayamıyor - beklemek zorundayız.
Bunun olmasını önlemek için biz paralel fonksiyonel rezerv kullanıyoruz. Toplamaları örneğin bugün için gerçek zamanlı olarak yeniden hesaplayarak Kafka aracılığıyla Tarantool'a bir olay gönderdiğimizde, şunu elde ederiz: nakit bakiyeleriBakiyeleri herhangi bir hızda, örneğin saniyede 100 bin işlem ve aynı 2 saniyede aktarabilen.
Amaç, bir arama yaptıktan sonra 2 saniye içinde kişisel hesabınızda yalnızca değişen bakiyenin değil, neden değiştiğine dair bilginin de bulunmasıdır.
Sonuç
Bunlar Tarantool kullanmanın örnekleriydi. Mail.ru'nun açıklığını ve farklı durumları değerlendirme istekliliğini gerçekten beğendik.
BCG veya McKinsey, Accenture veya IBM'den danışmanların bizi yeni bir şeyle şaşırtması zaten zor; onların sunduklarının çoğunu ya zaten yaptık, yaptık ya da yapmayı planlıyoruz. Tarantool'un teknoloji yığınımızda hak ettiği yeri alacağını ve mevcut birçok teknolojinin yerini alacağını düşünüyorum. Bu projenin aktif geliştirme aşamasındayız.
Oleg ve Andrey'in raporu geçen yıl Tarantool Konferansı'nın en iyilerinden biri ve 17 Haziran'da Oleg Ivlev konferansta konuşacak. bir raporla . Alexander Deulin ayrıca MegaFon'dan sunum yapacak . Nelerin değiştiğini, hangi planların uygulandığını öğrenelim. Katılın - konferans ücretsizdir, tek yapmanız gereken . Tüm ve konferans programı oluşturuldu: yeni vakalar, Tarantool kullanımında yeni deneyimler, mimari, işletme, eğitimler ve mikro hizmetler.
Kaynak: habr.com