g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Spike sistem mimarisinin kapsamlı analizi ve gerçek mücadelesi

1. Ani yükselişin analizi

Normal e-ticaret süreci

(1) Ürünü sorgulayın;

(2) Bir sipariş oluşturun;

(3) Envanterin düşülmesi;

(4) Siparişi güncelleyin;

(5) Ödeme;

(6) Satıcı tarafından sevkiyat;

Başak işinin özellikleri

(1) Düşük fiyat;

(2) Önemli tanıtım;

(3) Anında kısa satış;

(4) Genellikle raflara düzenli olarak konur;

(5) Kısa süre ve yüksek anlık eşzamanlılık;

2. Spike teknik zorluk

Bir web sitesindeki ani artış kampanyasının yalnızca bir ürün başlattığını varsayarsak, etkinliğe katılmak için 10.000 kişiyi çekmesi beklenir. Diğer bir deyişle, eşzamanlı maksimum istek sayısı 10.000'dir. Spike sisteminin karşılaşması gereken teknik zorluklar şunlardır:

1. Mevcut web sitesi işleri üzerindeki etkisi

Spike etkinliği, web sitesi pazarlamasının ek bir faaliyetidir. Bu etkinlik, kısa süreli ve büyük eşzamanlı ziyaretlerin özelliklerine sahiptir.

Web sitesinin orijinal uygulamasıyla birlikte kullanılırsa, kaçınılmaz olarak mevcut iş üzerinde bir etkisi olacaktır ve biraz dikkatsizlik tüm web sitesinin felç olmasına neden olabilir.

Çözüm: Spike sistemini bağımsız olarak dağıtın veya hatta web sitesinden tamamen izole etmek için bağımsız bir alan adı kullanın.

2. Yüksek eşzamanlılık altında uygulama ve veritabanı yükü

Ani artış başlamadan önce, kullanıcı, ani artışları kaçırmamalarını sağlamak için tarayıcı sayfasını yenilemeye devam eder.Bu istekler, uygulama sunucusuna erişmek ve veritabanına bağlanmak için genel web sitesi uygulama mimarisini izlerse, uygulama sunucusunda ve veritabanı sunucusunda yük baskısına neden olur.

Çözüm: Spike ürün sayfasını yeniden tasarlayın, web sitesinin orijinal ürün detay sayfasını kullanmayın, sayfa içeriği statiktir ve kullanıcı isteklerinin uygulama hizmetinden geçmesine gerek yoktur.

3. Ağ ve sunucu bant genişliğinde ani artış

Ürün sayfası boyutunun 200K (esas olarak ürün resim boyutu) olduğunu varsayarsak, gereken ağ ve sunucu bant genişliği 2G (200K × 10000)

Bu ağ bant genişlikleri, ani artış etkinliği nedeniyle yeni eklenir ve normalde web sitesi tarafından kullanılan bant genişliğini aşar.

Çözüm: Seckill'de yeni eklenen ağ bant genişliği nedeniyle, yeniden satın alınmalı veya operatörle birlikte kiralanmalıdır.

Web sitesi sunucusundaki baskıyı azaltmak için, spike ürün sayfalarının CDN'de önbelleğe alınması ve yeni dışa aktarma bant genişliğinin geçici olarak CDN servis sağlayıcısından kiralanması gerekir.

4. Doğrudan sipariş verin

Spike oyununun kuralı, ürün için zirveye ulaşılıncaya kadar sipariş vermeye başlamaktır.Bu süreden önce sipariş veremez, sadece ürün bilgilerine göz atabilirsiniz.

Sipariş sayfası da sıradan bir URL'dir. Bu URL'yi alırsanız, ani artışları beklemeden sipariş verebilirsiniz.

Çözüm: Kullanıcıların sipariş sayfasının URL'sine doğrudan erişmesini önlemek için URL'nin dinamik olması gerekir Spike sisteminin geliştiricileri bile ani artış başlamadan önce sipariş sayfasının URL'sine erişemez.

Yöntem, sunucu tarafından oluşturulan rastgele bir sayıyı, sipariş sayfasının URL'sine bir parametre olarak eklemektir ve bu, ani artış başlangıcında elde edilebilir.

5. Spike ürün sayfasındaki satın alma düğmesinin aydınlatması nasıl kontrol edilir?

Satın alma düğmesi yalnızca ani artış başladığında yanabilir ve bundan önce grileşir.

Sayfa dinamik olarak oluşturulmuşsa, elbette, düğmenin gri mi yoksa açık mı olduğunu kontrol etmek için sunucu tarafında bir yanıt sayfası çıktısı oluşturabilirsiniz.

Bununla birlikte, sunucu tarafındaki yük baskısını azaltmak ve CDN ve ters proxy gibi performans optimizasyon yöntemlerinden daha iyi yararlanmak için sayfa statik bir sayfa olarak tasarlanmış, CDN'de, ters proxy sunucusunda ve hatta kullanıcının tarayıcısında önbelleğe alınmıştır.

Ani artış başladığında, kullanıcı sayfayı yeniler ve istek hiçbir zaman uygulama sunucusuna ulaşmaz.

Çözüm: Spike ürününün statik sayfasına bir JavaScript dosyası referansı eklemek için JavaScript komut dosyası kontrolünü kullanın ve JavaScript dosyası, Hayır olan başak başlatma işaretini içerir;

Spike başladığında, yeni bir JavaScript dosyası oluşturulur (dosya adı aynı kalır, ancak içerik farklıdır), başak başlama işaretini evet olarak güncelleyin ve sipariş sayfasının URL ve rastgele sayı parametrelerini ekleyin

(Bu rastgele sayı yalnızca bir tane oluşturur, yani herkesin gördüğü URL aynıdır ve sunucu rastgele sayıyı depolamak için redis gibi dağıtılmış bir önbellek sunucusu kullanabilir)

Daha sonra, spike ürün sayfasının görüntüsünü kontrol etmek için kullanıcının tarayıcısı tarafından yüklenir. Bu JavaScript dosyası, tarayıcılar, CDN'ler ve ters proxy sunucuları tarafından önbelleğe alınmaması için rastgele bir sürüm numarasıyla (xx.js? V = 32353823 gibi) yüklenebilir.

Bu JavaScript dosyası çok küçüktür, tarayıcı her yenilendiğinde JavaScript dosya sunucusuna erişilse bile, sunucu kümesi ve ağ bant genişliği üzerinde çok fazla baskıya neden olmaz.

6. Yalnızca ilk gönderilen siparişin sipariş alt sistemine gönderilmesine nasıl izin verilir?

Sonunda ürünü başarıyla öldürebilecek tek bir kullanıcı olduğu için, kullanıcı siparişi verdiğinde sipariş verilip verilmediğini kontrol etmek gerekir.

Bir sipariş başarıyla gönderildiyse, JavaScript dosyasını güncellemeniz, flaş başlatma işaretini Hayır olarak güncellemeniz gerekir; satın alma düğmesi grileşir.

Aslında sonunda sipariş verebilecek tek bir kullanıcı olduğu için sipariş sayfası sunucusunun yük baskısını azaltmak için sipariş sayfasına giriş kontrol edilebilir.Sipariş sayfasına sadece birkaç kullanıcı girebilir, diğer kullanıcılar ise doğrudan spike son sayfasına girebilir.

Çözüm: Sipariş sunucusu kümesinde 10 sunucu olduğunu ve her sunucunun en fazla 10 sipariş isteğini kabul ettiğini varsayın.

Hiç kimse siparişi başarılı bir şekilde göndermeden önce, bir sunucuda on sipariş varsa ve bazı siparişler işlenmezse, olası bir kötü kullanıcı deneyimi senaryosu, kullanıcının kapalı sayfaya girmek için ilk kez satın alma düğmesine tıklamasıdır. Sayfayı tekrar yenileyin.Siparişi işleme koymamış bir sunucu tarafından işlenebilir.Siparişi doldurmak için sayfaya girdiğinizde, tutarlılık ilkesine uygun olarak yanıt vermek için çerezleri kullanmayı düşünebilirsiniz.

Tabii ki, en az bağlantıya sahip yük dengeleme algoritması kullanılabilir ve yukarıdaki durumun olasılığı büyük ölçüde azalır.

7. Ön sipariş denetimi nasıl yapılır

Sipariş sunucusu, makine tarafından işlenen sipariş taleplerinin sayısını kontrol eder:

10'dan fazla öğe varsa, doğrudan kullanıcıya son sayfaya dönün;
10'dan fazla giriş yoksa kullanıcı sipariş doldurma ve onay sayfasına girebilir;

Global olarak gönderilen siparişlerin sayısını kontrol edin:

Toplam başak ürün sayısı aşıldı ve bitmiş sayfa kullanıcıya iade edilecek;
Toplam seckill ürünü sayısı aşılmazsa, alt sipariş sistemine gönderin;

8. Başak genellikle raflarda düzenli olarak durur

Bu işlevi uygulamanın birçok yolu vardır. Bununla birlikte, mevcut daha iyi yol, ürünün raf süresini önceden ayarlamaktır ve kullanıcı ürünü ön masada görebilir, ancak "Şimdi Satın Al" düğmesini tıklayamaz.

Ancak dikkate alınması gereken şey, birisinin ön uç kısıtlamalarını atlayıp doğrudan URL aracılığıyla bir satın alma işlemi başlatabilmesidir. Bu, ön uç ürün sayfası ile hata sayfası arasında arka uç veritabanına saat senkronizasyonu gerektirir. Arka uçta ne kadar çok kontrol ederseniz, güvenlik o kadar yüksek olur.

Zamanlama ani yükselmesi durumunda, ani artıştan önce satıcının ürünü düzenlemesinin öngörülemeyen etkilerinden kaçınmak gerekir. Bu belirli değişiklik, birden çok değerlendirme gerektirir. Düzenleme genellikle yasaktır. Değiştirmeniz gerekirse, veri düzeltme sürecinden geçebilirsiniz.

9. Envanter azaltma operasyonu

İki seçenek var, biri envanteri azaltmak için fotoğraf çekmek, diğeri envanteri azaltmak için ödeme yapmak, mevcut "envanteri azaltmak için fotoğraflandı" yöntemi sadece bir an ve kullanıcı deneyimi daha iyi olacak.

10. Envanter "aşırı satım" sorununu ortaya çıkaracaktır: satılan miktar stoktaki miktardan fazladır

Eşzamanlı envanter güncellemeleri sorunu nedeniyle, fiili envanter zaten yetersiz olduğunda bile envanter hala düşüyor ve satıcının beklenenden daha fazla ürün satmasına neden oluyor. Çözüm: İyimser kilitleme kullanın

auction_auctions setini güncelle miktar = # inQuantity # burada auction_id = # itemId # ve miktar = # dbQuantity #

Envanteri düşürmeye çalışmanın başka bir yolu daha var. Yalnızca envanter başarıyla düşüldüğünde sipariş mantığı yürütülür:

auction_auctions setini güncelle miktar = miktar- # sayım # auction_id = # itemId # ve miktar > = # sayım #

11. Spike cihazına yanıt

Spike cihazları genellikle tek tek ve hızlı bir şekilde satın alınır ve satın alma kaydına göre bir parça tanımlanabilir. Doğrulama kodunun yeterince güvenli olmasını ve kırılamamasını gerektiren doğrulama kodu aracılığıyla belirli bir yöntem elde edilebilir.Kullanılan yöntemler şunlardır: ani artışlar için özel bir doğrulama kodu, TV'de yayınlanan bir doğrulama kodu ve ani artışlar için cevaplar.

3. Spike mimarisi ilkesi

1. Sistemin yukarı akışındaki istekleri yakalamaya çalışın

Geleneksel spike sisteminin kilitlenmesinin nedeni, taleplerin arka uç veri katmanını ezmesi, veri okuma-yazma kilidi çakışmasının ciddi olması, eşzamanlılığın yüksek olması ve yanıtın yavaş olması, neredeyse tüm taleplerin zaman aşımına uğraması, trafik büyük olmasına rağmen başarılı siparişin etkili trafiğinin çok küçük olmasıdır.

[Aslında bir tren için sadece 2000 bilet var, 200 w kişi onu almaya geliyor, temelde kimse başarılı bir şekilde satın alamıyor, talebin efektif oranı 0'dır]

2. Yaygın olarak kullanılan ve sık kullanılan önbellek

Bu, daha fazla okuyan ve daha az yazan tipik bir uygulama senaryosudur [Aslında, bir tren için yalnızca 2.000 bilet vardır, 200 w kişi onu satın almak için gelir ve 2.000'e kadar kişi başarıyla sipariş verir. Diğerleri envanteri kontrol eder. Yazma oranı yalnızca% 0,1'dir ve okuma oranı % 99.9], önbelleğe almak için çok uygundur.

4. Spike mimari tasarımı

Başak sistemi, genel çevrimiçi alışveriş davranışlarından farklı olarak ani artışlar için tasarlanmıştır. Ani artışlara katılan kullanıcılar, ürün sayfasını hızlı bir şekilde nasıl yenileyecekleri konusunda daha endişelidir.

Spike başlangıcında ürün detayları gibi kullanıcı deneyimi detayları yerine sipariş sayfasına giriniz, böylece spike sisteminin sayfa tasarımı olabildiğince basit olmalıdır.

Ürün sayfasındaki satın alma butonu sadece ani artış aktivitesi başladığında yanar, ürün satılmadan önce ve satıldıktan sonra buton gridir ve tıklanamaz.

Sipariş formu olabildiğince basittir.Satın alma miktarı yalnızca bir olabilir ve değiştirilemez. Teslimat adresi ve ödeme yönteminin her ikisi de kullanıcının varsayılan ayarlarıyla belirlenir ve varsayılan bir ayar yoktur veya hiçbir varsayılan ayar yoktur.Sipariş gönderildikten sonra değiştirilmesine izin verilir;

Web sitesinin sipariş alt sistemine yalnızca ilk gönderilen sipariş gönderilir ve kalan kullanıcılar yalnızca siparişi gönderdikten sonra ani artış son sayfasını görebilir.

Böyle bir yükselme sistemi yapmak için işletme iki aşamaya ayrılacaktır:

İlk aşama, başak başlangıcından belli bir zamandır, bu aşama hazırlık aşaması olarak adlandırılabilir.Kullanıcı hazırlık aşamasında ani yükselmeyi bekler;
İkinci aşama, ani yükselişin başlangıcından ani artışa katılan tüm kullanıcılar ani yükselişin sonucunu alana kadardır. Buna ani artış aşaması denir.

4.1 Ön uç katman tasarımı

Öncelikle spike ürününü gösteren bir sayfa olmalıdır Bu sayfada spike aktivitesinin başlangıcına kadar geri sayım yapın.Hazırlık aşamasında kullanıcılar spike sayfasını arka arkaya açacak ve sayfayı sürekli yenileyebilecektir. Burada dikkate alınması gereken iki konu var:

İlki, başak sayfasının görüntüsüdür

Bir html sayfasının hala nispeten büyük olduğunu biliyoruz, sıkıştırılmış olsa bile, http başlığının boyutu ve içeriği onlarca K kadar yüksek olabilir.

Css, js, pictures vb. Gibi diğer kaynaklara ek olarak, on milyonlarca kişi aynı anda bir ürün satın alma telaşına katılırsa, genel bilgisayar odası bant genişliği sadece 1G10G'dir.

Ağ bant genişliğinin bir darboğaz haline gelme olasılığı çok yüksektir, bu nedenle bu sayfadaki her tür statik kaynak ayrı ayrı depolanmalı ve ardından baskıyı dağıtmak için cdn düğümüne yerleştirilmelidir.

CDN düğümleri tüm ülkeye yayıldığından, baskının çoğunu tamponlayabilir ve ayrıca bilgisayar odası bant genişliğinden daha ucuzdur.

İkincisi geri sayım

Performans nedenleriyle, istemcinin yerel saati genellikle js tarafından çağrılır ve istemci saati ile sunucu saati arasında tutarsızlıklar olabilir ve sunucular arasında saat tutarsızlıkları da olabilir.

İstemci ve sunucunun saatleri tutarsızsa, istemci zamanlaması ve sunucu senkronizasyon süresi benimsenebilir.

Buradaki performans sorununu düşünün: Zamanı senkronize etmek için kullanılan arayüz arka uç mantığını içermediğinden, sadece mevcut web sunucusu saatini istemciye göndermesi gerekir, bu nedenle hız çok hızlıdır.

Önceki testlerimin sonuçlarına göre, standart bir web sunucusu 2W + QPS sorun olmayacak. 100W kişi aynı anda kullanıyorsa, 100W QPS sadece 50 ağa ihtiyaç duyuyor ve bir donanım LB'si yeterli ~.

Ve web sunucusu grubu yatay olarak kolayca genişletilebilir (LB + DNS yoklaması), bu arayüz sadece json formatında küçük bir veri parçası döndürebilir

Ve gereksiz çerezleri ve diğer http başlık bilgilerini azaltmak için optimize edilebilir, böylece veri miktarı büyük olmaz

Genel olarak konuşursak, ağ bir darboğaz haline gelmeyecektir, darboğaz haline gelse bile, çok bilgisayarlı odaya ayrılmış hat bağlantısı ve akıllı DNS çözümünü düşünebilirsiniz;

Web sunucuları arasındaki zaman senkronizasyonu, birleşik bir zaman sunucusu aracılığıyla gerçekleştirilebilir.Örneğin, her 1 dakikada bir, ani artış etkinliğine katılan tüm web sunucuları, zamanı zaman sunucusuyla senkronize edecektir.

Tarayıcı katmanı isteğine müdahale

Ürün düzeyinde, kullanıcı "Sorgu" veya "Bilet Satın Al" ı tıkladıktan sonra, kullanıcıların tekrarlanan istekler göndermesini engellemek için düğme gri renkte görünür;
JS düzeyinde, kullanıcılar x saniye içinde yalnızca bir istek gönderebilir;

4.2 Site düzeyinde tasarım

Ön uç katmanın istek ele geçirilmesi, yalnızca Xiaobai kullanıcılarını durdurabilir (ancak bu, kullanıcıların% 99'u). Üst düzey programcılar bu seti hiç yemiyor. Bir for döngüsü yazın ve doğrudan arka uç http isteğinizi arayın. Nasıl düzeltilir?

Aynı kullanıcı kimliği, erişim sıklığını sınırlama, sayfa önbelleğe alma, x saniye içinde site düzeyine ulaşan istekler, hepsi aynı sayfayı döndürür
Cep telefonu gezileri, sayfa önbelleğe alma, x saniye içinde site düzeyine ulaşan istekler gibi aynı öğeye ilişkin sorguların tümü aynı sayfayı döndürür

Bu tür akış kısıtlamasıyla, site düzeyinde trafiğin% 99'u engellenecektir.

4.3 Hizmet katmanı tasarımı

Site düzeyinde müdahale isteme yalnızca sıradan programcıları ve ileri düzey bilgisayar korsanlarını durdurabilir. 10w piliçleri kontrol ettiğini varsayarsak (ve bilet satın almak için gerçek ad kimlik doğrulamasının gerekli olmadığını varsayarsak), kullanıcı kimliği kısıtlaması yeterli değildir, değil mi? Nasıl düzeltilir?

Kardeşim, ben hizmet katmanıyım, Xiaomi'nin sadece 10.000 cep telefonu olduğunu biliyorum.Bir tren için sadece 2.000 bilet olduğunu biliyorum Veritabanına 10w istek göndermenin anlamı nedir?
Yazma istekleri için, bir istek kuyruğu oluşturun, veri katmanına yalnızca sınırlı sayıda yazma isteği gittiğinde, tümü başarılıysa, bir grup bırakın, envanter yeterli değilse, kuyruktaki tüm yazma istekleri "tükendi" olarak dönecektir;
Okuma talepleri için söylenecek başka bir şey var mı? Direnmek için önbellek, ister memcached ister redis olsun, tek bir makinenin saniyede 10w'a direnmesi sorun olmamalıdır;

Böyle bir güncel sınırla, veri katmanına yalnızca çok az yazma isteği ve çok az önbellek yanlış okuma isteği geçecek ve isteklerin% 99,9'u engellenecektir.

Kullanıcı talebi dağıtım modülü: Kullanıcı isteklerini farklı makinelere dağıtmak için Nginx veya Apache kullanın.
Kullanıcı talebi ön işleme modülü: Talebin işlenip işlenmeyeceğini belirlemek için ürünün bırakılıp bırakılmayacağına karar verilir.
Kullanıcı talebi işleme modülü: Önceden işlenmiş talebi bir işlem olarak kapsülleyin ve veritabanına gönderin ve başarılı olup olmadığını geri döndürün.
Veritabanı arayüz modülü: Bu modül, veritabanıyla etkileşimden sorumlu olan veritabanının tek arabirimidir ve ani yükselmenin, kalan miktarın ve diğer bilgilerin olup olmadığını sorgulamak için bir RPC arabirimi sağlar.

Kullanıcı talebi ön işleme modülü

HTTP sunucusu dağıtıldıktan sonra, tek bir sunucunun yükü nispeten düşüktür, ancak toplam miktar yine de büyük olabilir

Arka plan ürünü incelendiyse, seckill'in arızasını doğrudan sonraki talebe iade edin ve başka işlem gerekmez.

Örnek kod şöyle görünebilir:

paket seckill; import org.apache.http.HttpRequest; / ** * Ön işleme aşamasında gereksiz istekler doğrudan reddedilir ve bir sonraki aşamaya geçmek için gerekli istekler kuyruğa eklenir. * / public class PreProcessor { // Kalan mal var mı? private static boolean reminds = true; özel statik geçersizlik yasak () { // Bir şey yap. } public static boolean checkReminds () { eğer (hatırlatır) { // Herhangi bir uzaktan algılama kalsa da, RPC arabirimi veritabanı sunucusu tarafından sağlanmalıdır, sıkı bir şekilde kontrol edilmesine gerek yoktur. eğer (! RPC.checkReminds ()) { hatırlatır = yanlış; } } dönüş hatırlatır; } / ** * Her HTTP isteği bu ön işlemden geçmelidir. * / public static void preProcess (HttpRequest isteği) { eğer (checkReminds ()) { // Eşzamanlı bir kuyruk RequestQueue.queue.add (istek); } Başka { // Başka ürün yoksa, talebi reddetmeniz yeterlidir. yasak (); } } }

Eşzamanlı sıra seçimi

Java'nın eşzamanlılık paketi, yaygın olarak kullanılan üç eşzamanlı kuyruk uygulaması sağlar, yani:

ConcurrentLinkedQueue

LinkedBlockingQueue

ArrayBlockingQueue

ArrayBlockingQueue, sabit bir başlangıç kapasitesine sahip bir engelleme kuyruğudur.Bunu veritabanı modülünün başarılı bir şekilde teklif vermesi için bir kuyruk olarak kullanabiliriz.Örneğin, 10 ürün varsa, 10 boyutunda bir dizi kuyruğu oluşturacağız.
ConcurrentLinkedQueue, CAS ilkel kilitsiz kuyruk uygulamasını kullanır. Zaman uyumsuz bir kuyruktur. Kuyruğa girme hızı çok hızlıdır. Kuyruğun performansı kilitlidir ve performans biraz yavaştır.
LinkedBlockingQueue aynı zamanda bir engelleme kuyruğudur.Kilitleme kuyruğa hem giriş hem de çıkış için kullanılır.Sıra boş olduğunda, iş parçacığı geçici olarak bloke olur.

Sistemimiz bir kuyruktan çıkarma gereksiniminden çok daha büyük bir kuyruğa alma gereksinimine sahip olduğundan, genellikle boş bir kuyruk yoktur, bu nedenle istek kuyruğu uygulamamız olarak ConcurrentLinkedQueue'yu seçebiliriz:

paket seckill; import java.util.concurrent.ArrayBlockingQueue; import java.util.concurrent.ConcurrentLinkedQueue; import org.apache.http.HttpRequest; public class RequestQueue { public static ConcurrentLinkedQueue queue = new ConcurrentLinkedQueue (); }

Kullanıcı istek modülü

paket seckill; import org.apache.http.HttpRequest; public class İşlemci { / ** * Spike işlemini veritabanı kuyruğuna gönderin. * / public static void kill (BidInfo bilgileri) { DB.bids.add (bilgi); } public static void process () { BidInfo bilgisi = yeni BidInfo (RequestQueue.queue.poll ()); eğer (bilgi! = null) { öldür (bilgi); } } } sınıf BidInfo { BidInfo (HttpRequest isteği) { // Bir şey yap. } }

Veritabanı modülü

Veritabanı, başarılı olabilecek kullanıcı isteklerini geçici olarak depolamak için çoğunlukla bir ArrayBlockingQueue kullanır.

paket seckill; import java.util.concurrent.ArrayBlockingQueue; / ** * DB, veritabanının tek arayüzü olmalıdır. * / public class DB { public static int sayısı = 10; genel statik ArrayBlockingQueue teklifleri = new ArrayBlockingQueue (10); public static boolean checkReminds () { // YAPMAK doğruya dön; } // Tek iş parçacığı işlemi genel statik geçersiz teklif () { BidInfo bilgisi = bids.poll (); while (count-- > 0) { // Teklif değerlerini tabloya ekleyin (item_id, user_id, bid_date, diğer) // Tekliflerden sayım (kimlik) seçin, burada item_id =? // Veritabanı ürünlerinin sayısı yaklaşık olarak toplam sayı ise, ani yükselişin tamamlandığını işaretleyecek ve anımsatır = false bayrağı ayarlayacaktır. info = bids.poll (); } } }

4.4 Veritabanı tasarımı

4.4.1 Temel kavramlar

Konsept bir "tek kitaplık"

Kavram iki "parçalama"

Parçalama, genellikle "yatay bölümleme" olarak adlandırılan "çok fazla veri" sorununu çözer.

Parçalama tanıtıldıktan sonra, hangi veritabanının hangi verilere eriştiği "veri yönlendirme" kavramı olacaktır. Yönlendirme kuralları için genellikle 3 yöntem vardır:

1. Aralık: aralık

Avantajlar: basit ve genişletmesi kolay

Dezavantajlar: her kitaplıkta eşit olmayan basınç (yeni sayı bölümü daha aktiftir)

2. Hash: hash [Çoğu internet şirketi tarafından benimsenen ikinci şema: hash sub-database, hash routing]

Avantajlar: basit, dengeli veriler, eşit yük

Dezavantajlar: Geçiş zahmetlidir (2 veritabanından 3 veritabanına verilerin taşınması gerekir)

3. Yönlendirme hizmeti: yönlendirici-yapılandırma-sunucusu

Avantajlar: güçlü esneklik, ayrıştırma iş ve yönlendirme algoritmaları

Dezavantajlar: veritabanına her erişimden önce bir sorgu daha

Kavram üç "gruplama"

Gruplama, "kullanılabilirlik" sorununu çözer ve gruplama genellikle ana-bağımlı çoğaltma yoluyla gerçekleştirilir.

İnternet şirketi veritabanının gerçek yazılım mimarisi: parçalanmış ve gruplandırılmıştır (aşağıda gösterildiği gibi)

4.4.2 Tasarım Fikirleri

Veritabanı yazılım mimarları genellikle ne tasarlar? En az dört nokta dikkate alınmalıdır:

Veri kullanılabilirliği nasıl sağlanır;
Veritabanı okuma performansı nasıl iyileştirilir (çoğu uygulama daha fazla okur ve daha az yazar ve okuma önce darboğaz haline gelir);
Tutarlılık nasıl sağlanır;
Ölçeklenebilirlik nasıl geliştirilir;

1. Verilerin kullanılabilirliği nasıl sağlanır?

Kullanılabilirlik problemini çözme fikri = > fazlalık

Sitenin kullanılabilirliği nasıl sağlanır? Çoğaltma sitesi

Hizmet kullanılabilirliği nasıl sağlanır? Çoğaltma hizmeti

Verilerin kullanılabilirliği nasıl sağlanır? Yinelenen veriler

Veri fazlalığı bir yan etki getirecek = > Tutarlılık sorunlarına neden olun (tutarlılık sorunları hakkında konuşmayın, önce kullanılabilirlik hakkında konuşun).

2. Veritabanının "okunması" nın yüksek kullanılabilirliği nasıl sağlanır?

Yedekli Okuma Kitaplığı

Gereksiz okuma kütüphanesinin yan etkileri?

Okuma ve yazma gecikir ve tutarsız olabilir.

Yukarıdaki resim birçok İnternet şirketinin mysql mimarisidir, yazma hala tek bir noktadır ve yüksek kullanılabilirlik garanti edilemez.

3. Veritabanı "yazma" nın yüksek oranda erişilebilir olduğundan nasıl emin olunur?

Yedekli yazma kitaplığı

Çift ana bilgisayar ve karşılıklı yedekleme kullanarak, kitaplığa gereksiz yazmanın yan etkileri nelerdir? Çift yazma senkronizasyonu, veriler çakışabilir (örneğin, "artış kimliği" senkronizasyon çakışması), senkronizasyon çakışmasının nasıl çözüleceği, iki ortak çözüm vardır:

İki yazma kitaplığı kimliği artırmak için farklı başlangıç değerleri ve aynı adım uzunluğu kullanır: 1 yazma kitaplığının kimliği 0, 2, 4, 6 ...; 2 yazma kitaplığının kimliği 1, 3, 5, 7 ...;

Verilerin kimliği kullanılmaz ve iş katmanı, verilerin çakışmamasını sağlamak için kendi benzersiz kimliğini oluşturur;

Uygulamada, yukarıdaki iki mimari okuma ve yazmanın "yüksek kullanılabilirliği" için kullanılmaz ve "ana ve bağımlı olarak çift ana" yöntemi benimsenir:

Hala bir çift ana bilgisayardır, ancak yalnızca bir ana birim hizmet sağlar (okuma + yazma) ve diğer ana birim, yalnızca yüksek kullanılabilirliği sağlamak için kullanılan ve genellikle hizmet sağlamayan "gölge ana birimdir".

Yönetici telefonu kapatır ve gölge yöneticisi en üsttedir (vip sürüklenir, iş katmanına şeffaftır, manuel müdahale gerekmez).

Bu yaklaşımın faydaları:

Okuma ve yazmada gecikme yaşanmaz;
Yüksek kullanılabilirlik okuma ve yazma;

yetersiz:

Okuma performansı, bağımlı kitaplıklar eklenerek genişletilemez;
Kaynak kullanım oranı% 50'dir ve yedek bir ana birim hizmet sağlamaz;

Okuma performansı nasıl geliştirilir? Okuma performansının nasıl sağlanacağı olan ikinci konuya girin.

4. Okuma performansı nasıl artırılır

Okuma performansını artırmanın kabaca üç yolu vardır:

Birincisi, bir dizin oluşturmaktır. Bu yöntem genişlemiyor, belirtilmesi gereken nokta, farklı kütüphanelerin farklı indeksler oluşturabilmesidir.

İndekslemeden kitaplık yazın;

Uid gibi çevrimiçi erişim indeksi oluşturmak için çevrimiçi okuma kütüphanesi;

Zaman gibi çevrimdışı erişim indeksi oluşturmak için çevrimdışı okuma kitaplığı;

Okuma performansını genişletmenin ikinci yolu, bağımlı kitaplığı artırmaktır. Bu yöntem daha sık kullanılır, ancak iki dezavantajı vardır:

Bağımlı kitaplıklar ne kadar çoksa, senkronizasyon o kadar yavaş olur;
Senkronizasyon ne kadar yavaş olursa, veri tutarsızlığı penceresi o kadar büyük olur (tutarsızlık daha sonra tartışılacaktır veya önce okuma performansının iyileştirilmesi tartışılacaktır);

Pratikte, bu yöntem veritabanı okuma performansını iyileştirmek için (bağımlı veritabanı yok) değil, önbelleği artırmak için kullanılır. Yaygın önbellek mimarileri aşağıdaki gibidir:

Yukarı akış iş uygulaması, aşağı akış ana kitaplık, bağımlı kitaplık (okuma-yazma ayrımı) ve önbellektir. Gerçek oyun: bir dizi hizmet + veritabanı + önbellek.

İş katmanı, doğrudan db ve önbelleğe bakmaz ve hizmet katmanı, temeldeki veritabanı ve önbelleğin karmaşıklığını korur.

Neden hizmet katmanını tanıtmak gerekiyor? Bugün onu genişletmeyeceğiz. Veri erişimini sağlamak için "hizmet + veritabanı + önbellek" yöntemi benimseniyor ve okuma performansını artırmak için önbellek kullanılıyor.

Okuma performansını genişletmek için master-slave yaklaşımının mı yoksa okuma performansını artırmak için önbellek yaklaşımının mı kullanıldığına bakılmaksızın, verilerin birden fazla kopyada (master + slave, db + cache) kopyalanması gerekir ki bu kesinlikle tutarlılık sorunlarına neden olacaktır.

5. Tutarlılık nasıl sağlanır?

Master-slave veritabanının tutarlılığı için genellikle iki çözüm vardır:

1. Ara yazılım

Bir anahtarın yazma işlemi varsa, ara yazılım da bu anahtarın okuma işlemini tutarsız zaman penceresi içinde ana kitaplığa yönlendirecektir.

Bu çözümün dezavantajı, veritabanı ara yazılımı eşiğinin yüksek olmasıdır (Baidu, Tencent, Ali, 360 ve diğer şirketler)

2. Zorunlu okuma ustası

Aslında yukarıda kullanılan "master-slave olarak dual master" mimarisi, master ve slave arasında tutarsızlık problemine sahip değildir. İkinci tutarsızlık türü, db ve önbellek arasındaki tutarsızlıktır:

Ortak önbellek mimarisi yukarıdaki gibidir, şu anda yazma işlemlerinin sırası şöyledir:

(1) Önbelleği ortadan kaldırın;

(2) Veritabanını yazın;

Okuma işlemlerinin sırası şöyledir:

(1) Önbelleği okuyun ve önbellek isabet ederse geri dönün;

(2) Eksik bir önbellek varsa, kütüphaneden okuyun;

(3) Kitaplıktan okuduktan sonra verileri önbelleğe geri koyun;

Bazı anormal zamanlama durumlarında, verilerin [eski veriler önbellekte kaldıktan sonra kütüphaneden eski verileri okuyun (senkronizasyon tamamlanmadı)] 'den itibaren uzun bir süre tutarsız kalması mümkündür. Çözüm, "çift eliminasyonu önbelleğe almaktır" ve yazma işlemi sırası şu şekilde yükseltilir:

(1) Önbelleği ortadan kaldırın;

(2) Veritabanını yazın;

(3) "Ana-bağımlı senkronizasyon gecikme penceresi süresi" geçtikten sonra, eşzamansız önbellek eliminasyon talebini tekrar başlatın;

Bu şekilde önbellek gibi kirli veriler olsa bile, küçük bir zaman aralığından sonra kirli veriler yine de ortadan kalkacaktır. Maliyet, bir okuma kaçırma daha ortaya çıkmasıdır (maliyet göz ardı edilebilir).

Ek olarak, en iyi uygulamalardan biri şudur: Önbellekteki tüm öğeler için bir zaman aşımı süresi ayarlamanız önerilir.

3. Veritabanının ölçeklenebilirliği nasıl geliştirilir?

Başlangıçta, yönlendirme, hash yöntemi kullanılarak 2 veritabanına bölünmüştü. Veri miktarı hala çok fazlaydı. 3 veritabanına bölünmüşse, veri geçişi gerekliydi. Çok yakışıklı bir "saniyeler içinde veritabanı genişletme" çözümü var.

Saniyeler içinde nasıl genişletilir?

Öncelikle, 2 kütüphanenin kapasitesini 3 kütüphaneye genişletmiyoruz, 2 kütüphaneyi 4 kütüphaneye genişletiyoruz (kütüphaneyi ikiye katlıyoruz) (gelecek 4- > 8- > 16)

Servis + veritabanı bir kümedir (önbelleksiz) ve veritabanı "çift ana" modeli benimser.

Genişletme adımları:

İlk adım, bir ana kitaplığı yükseltmektir;
İkinci adım, yapılandırmayı değiştirmek, 2 kitaplıktan 4 kitaplığa geçmek (orijinal MOD2, şimdi değiştirilmiş MOD4), genişletme tamamlandı;

Orijinal MOD2 çift parçadır, şimdi MOD40 veya 2 olarak kalacaktır; orijinal MOD2 tek parça, şimdi MOD41 veya 3 olarak kalacak; verilerin taşınmasına gerek yok

Aynı zamanda, iki yönetici birbiriyle senkronize edilir, bir kez kalan 0, bir taraf 2 kaldığında ve her iki taraftaki veri senkronizasyonu çakışmaz ve genişletme saniyeler içinde tamamlanır!

Son olarak, bazı bitirme işleri yapın:

Eski dual master senkronizasyonunu kaldırın;
Yeni bir çift ana bilgisayar ekleyin (çift ana bilgisayar kullanılabilirliği sağlamak içindir, gölge ana genellikle hizmet sağlamaz);
Gereksiz verileri silin (kalan 0'ın ana verileri, kalan 2'nin verileri silinebilir);

Böylelikle 2 kütüphanenin 4 kütüphaneye genişlemesini saniyeler içinde tamamlamış olduk.

5. Eş Zamanlılığın Getirdiği Zorluklar

5.1. Talep arayüzünün makul tasarımı

Bir flash veya snap-up sayfası genellikle iki bölüme ayrılır; biri statik HTML ve diğer içerik, diğeri ise flash'a katılan web arka plan istek arabirimidir.

Genellikle statik HTML ve diğer içerik CDN aracılığıyla dağıtılır ve baskı genellikle çok büyük değildir. Çekirdek darboğaz aslında arka plan istek arayüzündedir.

Bu arka uç arayüzü aynı anda yüksek istekleri destekleyebilmelidir.Aynı zamanda olabildiğince "hızlı" olması ve kullanıcının istek sonuçlarını en kısa sürede döndürmesi çok önemlidir.

Bunu olabildiğince hızlı bir şekilde başarmak için, arabirimin arka uç depolaması için bellek düzeyinde işlemlerin kullanılması daha iyidir.

MySQL gibi doğrudan depolama ile yüzleşmek hala uygun değildir. Bu kadar karmaşık bir iş gereksinimi varsa, zaman uyumsuz yazma önerilir.

Elbette, "gecikmeli geri bildirim" kullanan bazı ani artışlar da vardır; bu, ani artışın sonucu şu anda bilmediği ve bir süre sonra artışın başarılı olup olmadığını sayfadan görebilirsiniz.

Ancak, bu tür davranışlar "tembeldir" ve kullanıcı deneyimi iyi değildir ve kullanıcılar tarafından "kara kutu işlemi" olarak kabul edilmesi kolaydır.

5.2 Yüksek eşzamanlılığın zorluğu: "hızlı" olmalıdır

Genellikle bir Web sisteminin verim oranını ölçüyoruz QPS (Saniyedeki Sorgu, saniyedeki istek sayısı)

Bu gösterge, yüksek eşzamanlılık senaryolarını saniyede on binlerce kez çözmek için çok önemlidir.

Örneğin, bir iş talebini işlemek için ortalama yanıt süresinin 100 ms olduğunu varsayalım Aynı zamanda, sistemde 20 Apache Web sunucusu vardır ve MaxClients 500 olarak yapılandırılmıştır (Apache bağlantılarının maksimum sayısını temsil eder).

Ardından, Web sistemimizin teorik zirve QPS'si (idealleştirilmiş hesaplama yöntemi):

20 * 500 / 0,1 = 100000 (100.000 QPS)

Huh? Sistemimiz çok güçlü görünüyor. Bir saniyede 100.000 isteği işleyebiliyor. 5 w / sn'lik artış "kağıt kaplan" gibi görünüyor.

Gerçek durum kesinlikle o kadar ideal değil. Gerçek yüksek eşzamanlılık senaryosunda, makineler yüksek yük durumundadır, bu sırada ortalama yanıt süresi büyük ölçüde artacaktır.

Web sunucusu söz konusu olduğunda, Apache ne kadar çok bağlantı işlemi açarsa, CPU'nun işlemesi gereken bağlam anahtarı o kadar fazla olur, bu da CPU tüketimini artırır ve doğrudan ortalama yanıt süresinde bir artışa yol açar.

Bu nedenle, yukarıda bahsedilen MaxClients sayısı, CPU ve bellek gibi donanım faktörlerine göre kapsamlı bir şekilde düşünülmelidir ve kesinlikle daha iyi değildir. Apache ile birlikte gelen abench aracılığıyla test edebilir ve uygun bir değer alabilirsiniz.

Daha sonra, bellek işlem seviyesinin depolama Redis'ini seçiyoruz.Yüksek eşzamanlılık durumunda, depolamanın yanıt süresi çok önemlidir.

Ağ bant genişliği de bir faktör olsa da, bu tür istek paketleri genellikle nispeten küçüktür ve nadiren isteklerin darboğazı haline gelir. Yük dengeleme nadiren bir sistem darboğazı haline geldi, bu yüzden burada tartışmayacağım.

O zaman sorun geliyor, varsayalım ki sistemimiz yüksek eşzamanlılık durumunda, 100 ms'den 250 ms'ye (gerçek durum veya daha fazlası) ortalama yanıt süresi:

20 * 500 / 0,25 = 40000 (40.000 QPS)

Sonuç olarak sistemimiz 4w QPS ile kalmıştır.Saniyede 5w istekle karşı karşıya kaldığında 1w fark vardır.

O zaman bu gerçek kabusun başlangıcıdır.

Örneğin, bir otoyol kavşağında, 1 saniyede 5 araba gelir ve her saniye 5 araba geçer.Otoban kavşağı normal çalışır. Birden bir saniyede bu kavşaktan sadece 4 araba geçebilir ve trafik akışı hala aynıdır, sonuç olarak büyük bir trafik sıkışıklığı olması gerekir. (5 şerit aniden 4 şerit haline gelir).

Benzer şekilde, belirli bir saniye içinde, 20 * 500 kullanılabilir bağlantı işlemlerinin tümü tam kapasitede çalışıyor, ancak yine de 10.000 yeni istek var, hiçbir bağlantı işlemi mevcut değil ve sistem anormal bir durumda.

Aslında eş zamanlı olmayan normal iş senaryolarında benzer durumlar vardır.

Belirli bir hizmet isteği arabiriminde bir sorun vardır ve yanıt süresi son derece yavaştır, bu da tüm Web isteğinin yanıt süresini çok uzun süre uzatır ve Web sunucusunun mevcut bağlantılarını kademeli olarak doldurur.Diğer normal hizmet isteklerinde hiçbir bağlantı işlemi yoktur.

Daha korkutucu olan sorun, kullanıcının davranış özellikleri olmasıdır. Sistem ne kadar kullanılamazsa, kullanıcının tıklamaları o kadar sık olur ve kısır döngü sonunda bir "çığ" a yol açar.

(Web makinelerinden biri kapandı, trafiğin diğer normal çalışan makinelere yayılmasına neden oldu ve ardından normal makinelerin aşağı inmesine ve ardından bir kısır döngüye neden oldu), tüm Web sistemini aşağıya sürükledi.

5.3 Yeniden başlatma ve aşırı yük koruması

Sistemde bir "çığ" varsa, servisi aceleyle yeniden başlatmak sorunu çözmeyecektir.

En yaygın fenomen, başladıktan hemen sonra telefonu kapatmasıdır. Şu anda, giriş katmanındaki trafiği reddetmek ve ardından yeniden başlatmak en iyisidir.

Redis / memcache gibi hizmet de kilitleniyorsa, yeniden başlatırken "ısınmaya" dikkat etmeniz gerekir ve bu uzun sürebilir.

Ani yükselme ve kopma senaryolarında, trafik genellikle sistemimizin hazırlık ve hayal gücünün ötesinde.

Şu anda aşırı yük koruması gereklidir. Sistem tamamen yüklenmişse, talebin reddedilmesi de koruyucu bir önlemdir.

Ön uçta filtrelemeyi ayarlamak en kolay yoldur, ancak bu yaklaşım kullanıcılar tarafından "işaret edilen" bir davranıştır.

Müşterinin doğrudan talebini hızlı bir şekilde geri döndürmek için aşırı yük korumasını CGI giriş katmanında ayarlamak daha uygundur.

6. Hile yolları: saldırı ve savunma

Başak ve satın almak için acele "büyük" talepler aldı, aslında, içindeki su çok büyük.

Pek çok kullanıcı, ürünleri "kapmak" için, sunucuya olabildiğince çok istek göndermelerine yardımcı olacak "biletleme aracı" gibi yardımcı araçlar kullanır.

Güçlü otomatik istek komut dosyaları oluşturan bazı gelişmiş kullanıcılar da vardır. Bu yaklaşımın nedeni de çok basittir, yani ani artışlara ve anlık çekimlere katılım taleplerinde, ne kadar çok istek yaparsanız, başarı olasılığı o kadar yüksek olur.

Bunların hepsi "hile yöntemleri" ama "saldırı" ve "savunma" var Bu barutsuz bir savaş.

6.1. Aynı hesap için aynı anda birden fazla istek gönderin

Bazı kullanıcılar, ani artış başladığı sırada kendi hesaplarıyla yüzlerce veya daha fazla istek göndermek için tarayıcı eklentilerini veya diğer araçları kullanır. Aslında, bu tür kullanıcılar ani yükselişin ve panik satın almanın adilliğini zayıflatıyor.

Bu tür bir talep, veri güvenliği işlemi yapmamış bazı sistemlerde başka bir tür hasara da yol açarak belirli yargı koşullarının atlanmasına neden olabilir.

Örneğin basit bir talep mantığı, önce kullanıcının bir katılım kaydına sahip olup olmadığını, yoksa talep başarılı olup olmadığını belirlemek ve son olarak katılım kaydına yazmaktır.

Bu çok basit bir mantıktır, ancak yüksek eşzamanlılık senaryolarında derin boşluklar vardır.

Birden çok eşzamanlı istek, yük dengeleme sunucusu aracılığıyla intranetteki birden çok web sunucusuna dağıtılır ve önce depoya sorgu istekleri gönderir

Daha sonra katılım kaydına belirli bir talebin başarıyla yazıldığı zaman farkı içerisinde diğer taleplerden elde edilen sonuçlar "katılım kaydı yok" olur. Burada mantıksal muhakemenin atlanma riski vardır.

Müdahale planı:

Programın girişinde, bir hesabın yalnızca 1 isteği kabul etmesine izin verilir ve diğer istekler filtrelenir.

Bu sadece aynı hesap için N istek gönderme sorununu çözmekle kalmaz, aynı zamanda sonraki mantık sürecinin güvenliğini de sağlar.

Çözüme ulaşmak için Redis'in bellek önbellek hizmeti üzerinden bir bayrak biti yazabilirsiniz (saatin iyimser kilit özelliği ile birlikte yalnızca 1 isteğin başarıyla yazılmasına izin verilir) ve başarılı bir şekilde yazanlar katılmaya devam edebilir.

Veya bir hizmeti kendiniz uygulayın, aynı hesabın isteklerini sıraya koyun, birini işleyin ve ardından bir sonrakini işleyin.

6.2. Birden çok hesap, aynı anda birden çok istek gönderin

Birçok şirketin hesap kayıt işlevi, geliştirmenin ilk aşamalarında neredeyse sınırsızdır ve birçok hesabı kaydetmek kolaydır.

Bu nedenle, bazı özel stüdyoların ortaya çıkmasına da yol açmıştır. Otomatik kayıt komut dosyaları yazarak, çeşitli fırçalama davranışlarında uzmanlaşmış, on binlerce ile yüzbinler arasında değişen çok sayıda hesapla çok sayıda "zombi hesabı" biriktirilmiştir ( Bu, Weibo'daki "zombi hayranlarının" kaynağıdır).

Örneğin, karıştırmak ve ilerletmek için on binlerce "zombi hesabı" kullanırsak, bir piyango kazanma olasılığını büyük ölçüde artırabiliriz.

Bu tür bir hesap flash ve snap-up alımlarında kullanılır ve aynı sebepten ötürüdür. Örneğin, iPhoneun resmi web sitesi açıldı ve tren bileti hazırlama partisi.

Müdahale planı:

Bu tür bir senaryo, belirtilen makinenin IP istek sıklığını tespit ederek çözülebilir. Bir IP istek sıklığının çok yüksek olduğunu fark ederseniz, bunun için bir doğrulama kodu açabilir veya isteğini doğrudan yasaklayabilirsiniz:

Pop-up doğrulama kodu, asıl amaç gerçek kullanıcıları ayırt etmektir.

Bu nedenle, web sitesinde görünen doğrulama kodlarından bazılarının "dans eden hayaletler" olduğunu sık sık görebilirsiniz ve bazen onları net bir şekilde göremeyiz.

IPIP

6.3IP

IPIP