On milyarlarca trafik taşıyan yüksek performanslı bir mimari nasıl tasarlanır?
On milyarlarca trafiğin yüksek eşzamanlı teknik zorlukları
Çeşitli iş sistemlerinin artan sayısı ve karmaşıklığıyla karşı karşıyayız, artan sayıda sistem kullanıcısı ile karşı karşıyayız ve yaklaşan on milyarlarca yüksek eşzamanlı trafikle karşı karşıyayız.
İlk önce o zamanki sistem dağıtımından bahsedeyim. Veritabanında 8 master ve 8 slave konuşlandırılmış, yani 16 veritabanı sunucusu var.Her veritabanı bağımsız bir veritabanı sunucusunda konuşlandırılmış ve hepsi fiziksel makineler. , Makinenin yapılandırması, doğru hatırlıyorsam, 32 çekirdekli + 128G + SSD katı hal sürücüsü olmalı.
Neden bu kadar çok fiziksel makine var ve hepsi yüksek yapılandırmalı? Şu ana kadar en büyük bağımlılığımız MySQL olduğunu öğrendiniz mi bilmiyorum!
Size daha önce, o zamanın bağlamında, yüz milyonlarca büyük verinin akışında gerçek zamanlı olarak yüzlerce ile binlerce satır arasında değişen karmaşıklığa sahip yüzlerce büyük SQL çalıştırmamız gerektiğini ve analiz etmemizin birkaç saniye süreceğini anlatmıştım. sonuç.
Hiçbir açık kaynak sistemi bunu yapamaz, Storm yapamaz ve Spark Streaming yapamaz. Bu nedenle, bu talep senaryosunu desteklemek için MySQL tabanlı tamamen kendi kendine geliştirilmiş bir veri platformu mimarisine dayanmalıdır.
Bu nedenle, yalnızca MySQL bu tür karmaşık SQL ifadelerinin mükemmel çalışmasını destekleyebilir.Bu nedenle, erken aşamada verilerin depolanması ve hesaplanması için MySQL'e büyük ölçüde güvenmeliyiz.Veri akışı MySQL'de depolanır ve ardından veri analizine dayanır. Çip hesaplama mimarisi, MySQL tabanlı hesaplamalar için yüksek performanslı karmaşık ve büyük SQL'i çalıştırmak için kullanılır.
Yani MySQL'in şu ana kadar bu sistemin can damarı olduğunu herkes biliyor. O zamanki senaryoda, her veritabanı sunucusunun saniyede yaklaşık 2000 eşzamanlı isteğe dayanması gerekiyordu.En yoğun dönemdeki CPU yükü ve IO yükü aslında çok yüksekti ve ana kitaplık ve bağımlı kitaplığın gecikmesi en yoğun dönemde biraz ciddiydi. İkinci seviyeye ulaşacak.
Tek bir MySQL veritabanı sunucusu olan üretim sistemimizin gerçek çevrimiçi işleminde, genellikle en yüksek eşzamanlı isteklerinin 2000 / s'yi aşmasına izin vermeyiz, çünkü mevcut satıra göre saniyede birkaç bin isteğe ulaştığında Yukarıdaki kaynak yüküne bakılırsa, yük çok yüksekse MySQL sunucusunun kapanması çok muhtemeldir.
Yani şu anda çok utanç verici bir sorun var Günde 100 milyon seviyeli trafik senaryosunda, bu kadar çok yapılandırılmış veritabanı sunucusuna direnmek için 8 master ve 8 slave kullanmak gerektiği söyleniyorsa, ya milyarlarca trafikse? On milyarlarca trafik olsa bile? Daha fazla yüksek konfigürasyonlu makine eklemeye devam ediyor musunuz?
Biliyorsunuz, bu tür yüksek düzeyde yapılandırılmış bir veritabanı sunucusu, eğer fiziksel bir makineyse, çok pahalıdır!
Size daha önce proje arka planına kısa bir giriş yapmıştım. Bu büyük ölçekli sistemler, N adet çoklu sistemi içeren ticari düzeyde bir platformdan oluşmaktadır. Bu veri ürünü yalnızca bir alt üründür. Böyle bir ürün için çok fazla bütçe ayırmak imkansızdır. Daha yüksek eşzamanlı yazmaları desteklemek için yüksek yapılandırmalı makineleri parçalayın.
Sistem mimarisini yeniden yapılandırmak için teknik araçlar kullanmalı, sınırlı makine kaynaklarını kullanmaya çalışmalı ve eşzamanlı yazmanın yüksek baskısına dayanmak için en iyi mimariyi kullanmalıyız!
Ayrı bilgi işlem ve depolama mimarisi
Bu mimarideki ölümcül sorunlardan biri, veri depolama ve hesaplamanın tek bir yerde, hepsi aynı MySQL veritabanında karıştırılmasıdır!
Bir düşünün, on milyonlarca veriyi tek bir tabloya koyarsınız ve karmaşık bir SQL'i her çalıştırdığınızda, SQL, indeks aracılığıyla hesaplamak istediği tablodaki veri dilimini bulmak için kullanılır. Bu uygun mu?
Cevap apaçık hayır! Tablodaki veri miktarı çok büyük olduğundan, ancak her gerçek SQL işlemi için verilerin yalnızca küçük bir bölümünü hesaplamanız gerekir. Aslında, üretim ortamında pratik yaptıktan sonra, büyük bir tablo çalıştırırsanız Karmaşık SQL, çeşitli dizinlerde bulunan veri miktarının küçük olması garanti edilse bile, tablo verisi miktarı çok büyük olduğu için, aynı zamanda performansta doğrusal bir düşüşe neden olacaktır.
Yani ilk şey verilerin depolanmasını ve hesaplanmasını ayırmaktır.
O zamanki düşüncemiz şöyleydi:
Veriler doğrudan bir depoya yazılır, sadece yazın
Daha sonra hesaplama sırasında, ihtiyaç duyduğunuz veri dilimindeki bir veya iki bin veri parçasını veri deposundan çıkarın ve bunları hesaplamalara ayrılmış başka bir geçici tabloya yazın.Bu geçici tabloda yalnızca iki bin veri vardır.
Ardından çeşitli karmaşık SQL'inizi çalıştırın.
Bingo! Veri depolama ve hesaplamanın iki unsuru birbirinden ayrıldıktan sonra, mimaride kullanılabilecek alan çok daha büyüktür.
Her şeyden önce, veri depolamanızın yalnızca yüksek eşzamanlı yazma işlemlerini desteklemesi gerekir. Günlük trafik on milyarlarca ise, en yüksek eşzamanlılık saniyede yüz binlere ulaşacaktır. Bu yeterlidir. Ardından, basit işlemlerle veri depolamadan az miktarda veri çıkarmak için hesaplama motorunu destekleyin ve sorun değil.
Harika, bu veri depolama MySQL'i geçmek için kullanılabilir. Bu küçük talep için MySQL'i başka ne için kullanıyorsunuz? Kardeşler!
O zamanlar, kapsamlı bir teknik araştırma ve seçimden sonra, şirketin kendi geliştirdiği dağıtılmış KV depolama sistemini seçtik. Bu KV depolama sistemi tam olarak dağıtılmış, yüksek düzeyde kullanılabilir, yüksek performanslı, hafif ve çok büyük miktarda veriyi destekliyor. Daha önce şirketin çevrimiçi trafiği için on milyarlarca talep testini deneyimledim ve bu kesinlikle sorun değil. Esas olarak, ihtiyaçlarımızı tam olarak karşılayan yüksek eşzamanlı yazma verilerini ve basit sorgu işlemlerini destekler.
Burada bahsetmek isterim ki, aslında sektördeki pek çok benzer senaryo hbase'i seçecektir, bu nedenle şirket tarafından geliştirilen mükemmel kv depolamasına sahip değilseniz, hbase'i kullanabilirsiniz. Sadece hbase, üretim ortamında biraz oyuk olabilir. Hbase, makul kaçınma ve optimizasyon konusunda çok yetenekli.
Hafif dağıtılmış kv sistemi, genel tasarım konsepti, bazı basit kv işlemlerini desteklemektir, çok sayıda eşzamanlı yazma ve okumayı desteklemek için bellek önbelleği sıcak verilerine güvenir, çünkü MySQL'de bu işlemleri desteklemesi gerekmez. , Karmaşık SQL ve diğer ağır mekanizmalar.
Bu nedenle, aynı makine kaynağı koşulları altında, yüksek eşzamanlılık için kv depolamanın destek kapasitesi, MySQL'in en az birkaç katı veya hatta düzinelerce katıdır.
Bu, herkesin Redis kullanmış olması gerektiğini söylemek gibidir. Ortak bir Redis konfigürasyonuna sahip tek bir makine saniyede on binlerce eşzamanlılığı desteklemeye uygundur. Aslında, gerçek budur. Çok hafiftir ve yüksek eşzamanlılığa dönüştürülür.
Daha sonra, MySQL'deki bazı geçici tablolara dayalı olarak kv depolamadan çıkarılan veri parçalarını hala depolayabilir ve hesaplamaları gerçekleştirmek için MySQL'in karmaşık SQL sözdizimi desteğini kullanabiliriz. Yani bu mimaride kv sistemini depolama olarak ve MySQL'i az miktarda veri içeren hesaplamalar için kullanıyoruz.
Şu anda, veri depolamamız olarak sistem mimarisine dağıtılmış bir kv sistemi getirdik.Her günün büyük verileri burada depolanabilir.Daha sonra Slave hesaplama motorumuz her seferinde bu verilere göre hesaplar. İlgili verileri kv depolamadan çıkarın ve MySQL'de geçici bir tabloya koyun ve ardından bu geçici tablodaki bir veya iki bin veri parçası üzerinde çeşitli karmaşık SQL hesaplamaları çalıştırın.
Yukarıdaki şekle bakın. Şu anda, bu adımda hesaplama ve depolama mimarisinin ayrılmasıyla, günlük on milyarlarca trafik yazımına dayanacak yüksek eşzamanlılığı desteklemeye uygun bir kv kümesi seçtik. Ardından işlemleri gerçekleştirmek için geçici bir tablo olarak MySQL'e dayalı küçük bir miktar veri koyun. Bu adım, yüksek eşzamanlı isteklere doğrudan direnebilir.
Dahası, dağıtılmış kv depolama talep üzerine genişletilebilir.Eşzamanlılık gittikçe artarsa, sadece kapasiteyi genişletin ve makineyi artırın. Bu noktada, mimarinin önemli bir yeniden düzenleme aşaması tamamlandı.
Kendi geliştirdiği saf bellek SQL bilgi işlem motoru
Bir sonraki adımda, mimaride nihai noktayı takip etmeliyiz! Çünkü şu anda karşılaştığımız sorunlardan biri, aslında MySQL'i hesaplamak için geçici bir tablo olarak kullanmasıdır, özellikle de karmaşık SQL sözdiziminin desteğiyle.
Ancak sorun şu ki, MySQL için eşzamanlılık miktarı büyük ölçüde azaltılmış olsa da, çok düşük değil. Çok sayıda veri parçasının hesaplanması gerektiğinden, MySQL'in yine de sık sık okunması ve yazılması gerekir.
Ek olarak, veriler kv depolamadan her çıkarıldığında, MySQL'de geçici bir tabloya yerleştirilmeli ve SQL, hesaplama için MySQL'e gönderilmelidir ki bu da birkaç adım daha gerektirir.
Çünkü o sırada karşılaşılan bir başka sorun, günlük büyük miktarda istek büyük miktarda veri anlamına geliyordu ve büyük miktarda veri, zaman dilimlerine ayrılmış bilgi işlem görevlerinin yükünün hala ağır olduğu anlamına geliyordu.
Her zaman MySQL'e çok güvenin, ancak aynı zamanda birçok ek geçici tablo, muhtemelen yüzlerce geçici tablo bulundurun, bakımını yapmalı, tablo yapısının değiştirilmesine ve alt veritabanı ile alt tablonun bazı işlemlerine dikkat etmelisiniz. Boyut işlemleri, tüm bunlar MySQL'e güvenmeyi çok gereksiz ve zahmetli hale getiriyor.
Bu nedenle, mimariyi daha sürdürülebilir hale getirmek ve performansı en üst düzeye çıkarmak için kendi saf bellekli SQL bilgi işlem motorumuzu geliştirmemiz gerektiğine karar verdik.
Aslında, MySQL'in karmaşık SQL sözdizimini destekleyebilecek bir bellek içi SQL bilgi işlem motoru geliştirmek istiyorsanız, bu yine de biraz zor ve zahmetlidir. Ancak işletmenin ihtiyaç duyduğu yüzlerce SQL'i dikkatlice inceledikten sonra, sorunun aslında o kadar da karmaşık olmadığını gördük.
Çünkü aslında genel veri analizi SQL, esas olarak bazı ortak fonksiyonlar, pek çok garip, zor, kısmi SQL sözdizimi değil.
Bu nedenle, tüm çevrimiçi SQL'i analiz ettikten sonra, iç içe geçmiş sorgu bileşenleri, çoklu tablo ilişkilendirme bileşenleri, gruplama toplama bileşenleri, çok alanlı sıralama bileşenleri dahil olmak üzere yalnızca birkaç belirli grameri destekleyen hedeflenen bir SQL motoru geliştirdik. Yaygın olarak kullanılan birkaç işlev, vb.
Daha sonra sistem, MySQL'e artık dayanmayacak şekilde tamamen yeniden düzenlenmiştir.Her bir veri dilimi kv depolamadan çıkarıldıktan sonra, doğrudan belleğe yerleştirilir ve daha sonra, bir veriyi saf bellekte bölmek için kendi geliştirdiğimiz SQL hesaplama motorumuzu kullanırız. Dilim, çeşitli karmaşık SQL'i yürütür.
Söylemeye gerek yok, bu saf bellek işleminin performansı düşünülebilir.Temel olarak, saf bellek SQL yürütmesi milisaniye seviyesindedir.Kısa olarak, bir zaman diliminin çalışması milisaniye seviyesine indirgenmiştir. Performans büyük ölçüde iyileştirildi ve MySQL artık ona bağlı değil ve karmaşık alt veritabanları, alt tablolar vb. Bulundurmaya gerek yok.
Bu mimari çevrimiçi hale geldikten sonra, MySQL'e olan bağımlılığı tamamen ortadan kaldırır Teorik olarak, ne kadar trafik gelirse gelsin, hemen kv kümesini genişleterek ve Slave hesaplama kümesini genişleterek çözülebilir.MySQL'in alt veri tabanlarına ve tablolarına güvenmeye gerek yoktur. Geçici saatler daha emek yoğun, zahmetli ve hile planlarıdır. Ve bu saf bellek bilgi işlem mimarisi, bilgi işlem performansını doğrudan milisaniye düzeyine yükseltir.
Ve MySQL'e olan bağımlılığı ortadan kaldırmanın başka bir avantajı daha vardır: Veritabanı makinesinin her zaman yüksek düzeyde yapılandırılması gerekir, ancak Slave makine esas olarak 4 çekirdekli 8G sıradan sanal makine yeterlidir.Dağıtılmış sistemin özü, olabildiğince çok sayıda ucuz sıradan makine kullanmaktır. Verimli depolama ve hesaplamayı tamamlayabilir.
Bu nedenle, on milyarlarca trafik yükü altında, Slave makinemizin düzinelerce makineyi dağıtması yeterlidir; bu, düzinelerce pahalı yüksek yapılandırmalı MySQL fiziksel makineyi dağıtmaktan daha uygun maliyetlidir!
MQ tepe kırpma ve akış kontrolü
Aslında, yüksek eşzamanlılık mimarisi hakkında biraz bilginiz varsa, öğrenciler bu sistemin mimarisinde yüksek eşzamanlı yazma için eklenmesi gereken başka bir anahtar bileşen olduğunu göreceklerdir: MQ.
Çünkü yüksek eşzamanlılık ve gerçek zamanlı olmayan yanıtla yazma talepleriyle uğraşıyorsak, önce büyük taleplere direnmek için MQ ara yazılımını kullanabilir ve ardından trafiği eşzamansız olarak kv depolamaya iletmek için bir ara trafik dağıtım sistemi oluşturabiliriz. Aynı zamanda, bu trafik dağıtım sistemi yüksek eşzamanlı trafiği kontrol edebilir.
Örneğin, anlık yüksek eşzamanlı yazma gerçekten arka plan sistemi üzerinde aşırı baskıya neden oluyorsa, trafik dağıtım sistemi, yüksek eşzamanlılığın arka plan sistemini ezip geçmesini önlemek için belirlediğimiz eşiğe göre akışı otomatik olarak kontrol edebilir.
Ve bu akış kontrol sisteminde, aslında veri doğrulama, geçersiz verileri filtreleme, veri parçalama, veri senkronizasyonu için idempotent mekanizması ve verilerin kv'ye ulaşacağını% 100 garanti etme gibi birçok ayrıntılı optimizasyon yaptık. Küme mekanizması garanti eder, vb.
Şirketin MQ kümesi, aşırı büyük trafik yazımlarını ve yüksek eşzamanlı istekleri doğal olarak destekler. Bu nedenle, MQ küme düzeyinin yüksek eşzamanlılığa direnç göstermesi bir sorun değildir. Eşzamanlılık ne kadar yüksek olursa olsun, isteğe bağlı genişletme yeterlidir ve sonra kendi akış kontrol sistemimiz de Küme dağıtımı için, çevrimiçi olarak 4 çekirdekli bir 8G sanal makine kullanılır, çünkü bu makine çok yüksek yapılandırma gerektirmez.
Akış kontrol sisteminde, genellikle her makinenin saniyede yaklaşık üç bin eşzamanlı istek taşıdığını düşünüyoruz. On milyarlarca trafik senaryosunda, saniyede en yüksek eşzamanlılık saniyede yüzbinlerce düzeydedir. Bu nedenle, bu akış kontrol kümesi Onlarca makineye konuşlandırmak yeterlidir.
Şirketin kv kümesi de doğal olarak aşırı büyük trafiği ve yüksek eşzamanlı yazma işlemlerini desteklemektedir.Bu nedenle, kv kümesi talep üzerine genişletilebilir ve trafikle yüksek eşzamanlı yazımlara direnmek sorun değildir.Aslında kendi mimarimiz düzeyinde çok şey yaptık. Optimizasyon (depolama ve bilgi işlemin birbirinden ayrılmasının kilit noktası), bu nedenle kv kümesinin konumlandırılması, temelde çevrimiçi depolamadan başka bir şey olmayan çevrimiçi depolamadır.
Anahtar ve değer veri türlerinin makul ve ustaca tasarımı sayesinde, kv kümesine yönelik okuma ve yazma taleplerimiz, doğal olarak yüksek eşzamanlı okuma ve yazmayı garanti eden en basit anahtar-değer okuma ve yazma işlemlerine göre optimize edilir.
Ek olarak, size biraz spoiler vereceğim. Daha sonra tam bağlantının% 99,99 yüksek kullanılabilirlikli mimarisinden bahsettiğimizde, bu akış kontrol kümesi büyük bir rol oynayacak.Bu, önceki ve sonrakini bağlamanın bir etkisidir, ön MQ kümesi arızasının yüksek kullanılabilirliği Garantinin yanı sıra arka KV kümesinin arızalanması için yüksek kullanılabilirlik garantisi, akış kontrol kümesi tarafından gerçekleştirilir.
Veri ayırma mimarisi
Yukarıdaki yeniden yapılandırmayı tamamladıktan sonra, kendi geliştirdiği çekirdek içi SQL hesaplama motorunu daha da optimize ettik. Çünkü gerçek üretim ortamında bir sorun bulduk: her seferinde bağımlı düğüm bir veri dilimiyle ilişkili çeşitli verileri çıkarsa ve ardından hesaplamalar yaparsa, aslında bu gereksizdir!
Size bir örnek vermek gerekirse, SQL'iniz bazı tablolarda ilişkili hesaplamalar yapacaksa, çoğu zaman statik ve değişmeyen bazı verileri içerir.Bu tabloların verileri genellikle nadiren değişir, bu nedenle her seferinde ağ talebinden geçmeye gerek yoktur. Verinin bu kısmını kv depolamadan çıkarın.
Aslında Slave düğümünde bu statik veriler için hafif bir önbellek oluşturabiliriz ve daha sonra yalnızca veri parçalarındaki dinamik olarak değiştirilen veriler kv depolamadan verileri çıkarabilir.
Bu verilerin dinamik ve statik ayırma mimarisi sayesinde, temelde Slave düğümünün ağ talebini kv kümesine en aza indirir ve performansı en yükseğe çıkarırız. Aşağıdaki resme bakın.
Aşama özeti
Şimdiye kadar, bu mimari temelde oldukça iyi bir şekilde gelişti, çünkü ultra yüksek eşzamanlı yazma, son derece hızlı yüksek performanslı bilgi işlem, isteğe bağlı isteğe bağlı genişleme ve diğer özellikler desteklenebilir. Temel olarak, yazıdan hesaplamaya, Bu iki adım çok büyük bir darboğaz değildir.
Ve kendi geliştirdiği bellek içi SQL hesaplama motoru sayesinde, gerçek zamanlı bilgi işlem performansımız, temelde en uç noktaya ulaşan milisaniye düzeyine yükseltildi.
Sıradaki ne
Sonra, bu mimarinin sol tarafına bakacağız, bir de MySQL var!
Birincisi, gerçek zamanlı hesaplama bağlantısı ve çok sayıda hesaplama sonucunu o MySQL'e aktaracak olan çevrimdışı hesaplama bağlantısıdır.
İkinci olarak, yüz binlerce hatta milyonlarca B-tarafı satıcıyla karşılaşıldığında, veri analizi sonuçları gerçek zamanlı olarak görüntüleniyorsa, genel sayfada düzenli JS komut dosyaları olacak ve en son veri hesaplama sonuçlarını yüklemek için birkaç saniyede bir istek gönderilecektir. .
Bu nedenle, özellikle son kullanıcılar için olan MySQL, aynı zamanda büyük miktarda verinin baskısını, yüksek eşzamanlı yazma baskısını ve yüksek eşzamanlı sorguların baskısını da taşıyacaktır.
