Kuru mallar: saniyede 100.000 yüksek eşzamanlı siparişi işleyen bir ödeme sistemi mimarisi
Çeşitli panik satın alma türlerinin sürekli artmasıyla, ödeme talepleri üzerindeki baskı yüz kat hatta bin kat arttı. Mal alımında son halka olarak, kullanıcıların ödemeyi hızlı ve istikrarlı bir şekilde tamamlamasını sağlamak özellikle önemlidir. Saniyede 100.000 siparişi istikrarlı bir şekilde işleyebilmesi için tüm ödeme sisteminde kapsamlı bir yapısal yükseltme gerçekleştirdik. Çeşitli anlık ani hareket etkinlikleri için güçlü destek sağlar.
1. Kitaplık alt tablosu
Redis ve memcached gibi önbelleğe alma sistemlerinin yaygın olduğu İnternet çağında, saniyede 100.000 salt okunuru destekleyen bir sistem oluşturmak karmaşık değildir. Tutarlı hashing ve yatay olarak genişleyen web sunucuları aracılığıyla önbellek düğümlerini genişletmekten başka bir şey değildir. Ödeme sisteminin saniyede 100.000 siparişi işlemesi gerekir ve saniyede yüz binlerce veritabanı güncelleme işlemine (ekleme ve güncelleme) ihtiyaç duyar. Bu, herhangi bir bağımsız veritabanında imkansız bir görevdir, bu nedenle önce yapmalıyız Sipariş tablosunun alt veritabanı ve alt tablosudur (sipariş olarak anılır).
Veritabanı işlemlerini gerçekleştirirken, genellikle bir kullanıcı kimliği (kısaca uid) alanı olacaktır, bu nedenle alt veritabanı ve uid ile tablo yapmayı seçiyoruz.
Veritabanı parçalama stratejisi için "ikili ağaç dallanma" stratejisini seçtik. Sözde "ikili ağaç parçalama" şu anlama gelir: veritabanını genişlettiğimizde, 2'nin katı kadar genişleriz. Örneğin: 1 set 2 set, 2 set 4 set, 4 set 8 set vb. Bu alt veritabanı yönteminin avantajı, kapasiteyi genişlettiğimizde, satır düzeyinde veri senkronizasyonu için komut dosyaları yazmak yerine, verileri tablo düzeyinde senkronize etmek için yalnızca DBA'ya ihtiyacımız olmasıdır.
Alt veri tabanlarına sahip olmak yeterli değildir.Sürekli stres testinden sonra, aynı veri tabanındaki birden çok tabloya yapılan eşzamanlı güncellemelerin verimliliğinin, tek bir tablodaki eşzamanlı güncellemelerin veriminden çok daha fazla olduğunu gördük. Sipariş tablosunu 10 bölüme ayırın: order_0, order_1, ..., order_9.
Son olarak, sipariş tablosunu 8 alt veritabanına (1'den 8'e kadar numaralandırılmış, DB1'den DB8'e karşılık gelir) ve her bir alt veritabanına 10 alt tabloya (sıra_0'dan sıra_9'a karşılık gelen 0'dan 9'a kadar numaralandırılmış) ve dağıtım yapısını koyduk Aşağıda gösterildiği gibi:
Veritabanı numarasını kullanıcı kimliğine göre hesaplayın:
Veritabanı numarası = (uid / 10)% 8 + 1
Tablo numarasını kullanıcı kimliğine göre hesaplayın:
Tablo numarası = uid% 10
Uid = 9527 olduğunda, yukarıdaki algoritmaya göre, uid aslında 952 ve 7 olmak üzere iki kısma bölünür, burada 952 modulo 8 artı 1 eşittir 1 veritabanı numarasıdır ve 7 tablo numarasıdır. Bu nedenle, uid = 9527 olan sipariş bilgilerinin DB1 kitaplığındaki order_7 tablosunda aranması gerekir. Spesifik algoritma akışı aşağıdaki şekilde de görülebilir:
Alt veritabanı ve alt tablonun yapısı ve algoritması ile son adım, alt veritabanı ve alt tablonun gerçekleştirme aracını bulmaktır.Şu anda, piyasada yaklaşık iki tür alt veritabanı ve alt tablo aracı bulunmaktadır:
İstemci alt veritabanı alt tablosu, istemci tarafında tam alt veritabanı alt tablo işlemi, veritabanına doğrudan bağlantı için alt veritabanı alt tablo ara yazılımını kullanma, istemci bağlantısı alt veritabanı alt tablo ara yazılımı ve orta katman alt veritabanı alt tablo işlemi
Bu iki tür araç piyasada mevcuttur, bu yüzden onları tek tek listelemeyeceğim.Genel olarak, her iki tür aracın da artıları ve eksileri vardır. İstemci tarafı alt veritabanı alt tabloları doğrudan veritabanına bağlıdır, bu nedenle performans, alt veritabanı alt tablo ara yazılımını kullanmaya göre% 15 ila% 20 daha yüksektir. Ve birleşik ara yazılım yönetimi nedeniyle alt veritabanı ve alt tablo ara yazılımının kullanılması, alt veritabanı ve alt tablo işlemini istemci tarafından ayırır, modül bölümü daha nettir ve DBA'nın birleşik yönetimi gerçekleştirmesi uygundur.
İstemci tarafında alt veritabanı ve alt tabloyu seçtik, çünkü kendi başımıza bir veri katmanı erişim çerçevesi geliştirdik ve açık kaynaklı. Kod adı "Mango". Mango çerçevesi, alt veritabanı ve tablo alt tablo işlevini yerel olarak destekliyor ve yapılandırması çok basit.
Mango ana sayfası: mango.jfaster.org Mango kaynak kodu: github.com/jfaster/mango
2. Sipariş Kimliği
Sipariş sisteminin kimliği küresel olarak benzersiz olmalıdır. En kolay yol, her işlem için küresel olarak benzersiz bir otomatik artış kimliği elde etmek için veritabanı sırasını kullanmaktır. Saniyede 100.000 sipariş işlemeyi desteklemek istiyorsanız, en azından 100.000 sipariş kimliğinin oluşturulması gerekiyor ve veri tabanı aracılığıyla üretilen kendi kendine artan kimliklerin yukarıdaki gereksinimleri karşılayamayacağı açıktır. Bu nedenle, yalnızca küresel olarak benzersiz sipariş kimliğini bellek hesaplaması yoluyla elde edebiliriz.
JAVA alanındaki en ünlü benzersiz kimlik UUID olarak kabul edilmelidir, ancak UUID çok uzun ve harf içeriyor, bu nedenle sipariş kimliği için uygun değil. Tekrarlanan karşılaştırmalar ve gösterimler sayesinde, küresel olarak benzersiz bir kimlik elde etmek için Twitter'ın Kar Tanesi algoritmasından öğrendik. Aşağıda, sipariş kimliğinin basitleştirilmiş bir yapı diyagramı verilmiştir:
Yukarıdaki resim 3 bölüme ayrılmıştır:
Zaman damgası
Buradaki zaman damgasının ayrıntı düzeyi milisaniyedir. Sipariş kimliğini oluştururken, zaman damgası olarak System.currentTimeMillis () kullanın.
makine kodu
Her sipariş sunucusuna benzersiz bir numara atanacaktır.Sipariş kimliğini oluştururken, benzersiz numarayı doğrudan makine numarası olarak kullanabilirsiniz.
Kendi kendine artan seri numarası
Aynı sunucuda aynı milisaniyede bir sipariş kimliği oluşturmak için birden fazla istek olduğunda, seri numarası geçerli milisaniyede artırılacak ve seri numarası bir sonraki milisaniyede 0'dan başlamaya devam edecektir. Örneğin, aynı sunucuda aynı milisaniyede bir sipariş kimliği oluşturmak için 3 istek vardır ve bu 3 sipariş kimliğinin otomatik artış sıra numarası kısmı sırasıyla 0, 1 ve 2 olacaktır.
Yukarıdaki 3 parçanın birleşimiyle, küresel olarak benzersiz bir sipariş kimliğini hızla oluşturabiliriz. Bununla birlikte, global benzersizlik yeterli değildir.Birçok durumda, sipariş bilgilerini sipariş kimliğine göre doğrudan sorgulayacağız. Şu anda, kullanıcı kimliği olmadığından, hangi alt veritabanını sorgulayacağımızı ve tüm kitaplıkların tüm tablolarını geçeceğimizi bilmiyoruz? Bu açıkça işe yaramıyor. Bu nedenle, alt veritabanı ve alt tablo bilgilerini sipariş kimliğine eklememiz gerekir, aşağıda alt veritabanı ve alt tablo bilgileriyle birlikte sipariş kimliğinin basitleştirilmiş bir yapı diyagramı verilmiştir:
Oluşturulan global sipariş kimliğinin başlığına alt veritabanı ve alt tablo bilgilerini ekledik, böylece karşılık gelen sipariş bilgilerini yalnızca sipariş kimliğine göre hızlı bir şekilde sorgulayabiliyoruz.
Alt veritabanı ve alt tablo bilgileri neleri içerir? İlk bölümde tartışıldığı gibi, sipariş tablosunu uid boyutuna göre 8 veritabanına böldük ve her veritabanında 10 tablo var En basit alt veritabanı alt tablo bilgileri yalnızca 2 uzunluğunda bir diziyle saklanabilir. Bir basamak veritabanı numarasını saklar, değer aralığı 1 ila 8'dir ve ikinci basamak tablo numarasını depolar, değer aralığı 0-9'dur.
Birinci kısımdaki uid baz alınarak veritabanı numarası ve tablo numarası hesaplama algoritmasına göre, uid = 9527, alt veritabanı bilgisi = 1, alt tablo bilgisi = 7, bunları birleştirdiğinde, iki basamaklı alt veritabanı alt tablo bilgisi "17" dir. ". Spesifik algoritma akışı aşağıdaki şekilde gösterilmektedir:
Tablo numarasını alt tablo bilgisi olarak kullanmakta bir sorun yoktur, ancak veritabanı numarasını alt veritabanı bilgisi olarak kullanmanın gizli tehlikeleri vardır.Gelecekteki genişletme gereksinimlerini göz önünde bulundurarak 8 veritabanını 16 veritabanına genişletmemiz gerekir ve değer aralığı 1 ila 8'dir. Kütüphane bilgileri, 1'den 16'ya kadar olan alt kütüphane senaryosunu destekleyemeyecek ve alt kütüphane yönlendirmesi doğru şekilde tamamlanmayacaktır.İtiraz problemine alt kütüphane bilgilerinin doğruluğunun kaybı olarak bahsediyoruz.
Alt veritabanı bilgilerinin doğruluk kaybı sorununu çözmek için, alt veritabanı bilgilerinin doğruluğu üzerinde artıklık yapmamız gerekir, yani şimdi kaydettiğimiz alt veritabanı bilgileri gelecekteki genişlemeyi desteklemelidir. Burada, sonunda 64 veritabanına genişleyeceğimizi varsayıyoruz, bu nedenle yeni alt veritabanı bilgi algoritması:
Alt kütüphane bilgileri = (uid / 10)% 64 + 1
Uid = 9527 olduğunda, yeni algoritmaya göre, alt veritabanı bilgisi = 57 olduğunda, burada 57 gerçek veritabanının numarası değildir, alt veritabanı bilgisinin doğruluğunu, nihayet 64 veritabanına kadar genişletmiştir. Şu anda sadece 8 veritabanımız var ve gerçek veritabanı numarasının aşağıdaki formüle göre hesaplanması gerekiyor:
Gerçek veritabanı numarası = (alt veritabanı bilgileri-1)% 8 + 1
Uid = 9527 olduğunda, alt kitaplık bilgisi = 57, gerçek veritabanı numarası = 1, alt kitaplık ve tablo bilgisi = 577.
Hassas yedeklilikten sonra alt veritabanı bilgilerini saklamak için modulo 64'ü seçtiğimizden, depolanan alt veritabanı bilgilerinin uzunluğu 1'den 2'ye değişti ve son alt veritabanı ve tablo bilgilerinin uzunluğu 3'tür. Spesifik algoritma akışı aşağıdaki şekilde de görülebilir:
Yukarıdaki şekilde gösterildiği gibi, alt veritabanı bilgilerini hesaplarken, alt veritabanı bilgilerinin doğruluğunu yedeklemek için bir modulo 64 yöntemi kullanılır, böylece sistemimizin 16 kitaplık, 32 kitaplık ve 64 kitaplığa genişletilmesi gerektiğinde sorun olmaz.
Yukarıdaki sipariş kimliği yapısı, mevcut ve gelecekteki genişleme ihtiyaçlarımızı çok iyi karşılayabildi, ancak işin belirsizliğini göz önünde bulundurarak, sipariş kimliğinin sürümünü, bu sürüm numarasını belirlemek için sipariş kimliğinin önüne bir rakam ekledik. Gereksiz verilere aittir ve şu anda kullanılmamaktadır. Aşağıda, son sipariş kimliğinin basitleştirilmiş bir yapı diyagramı verilmiştir:
Kar tanesi algoritması: github.com/twitter/snowflake
Üç, son tutarlılık
Şimdiye kadar, sipariş tablosunun uid boyutunun alt veritabanı ve alt tablosu aracılığıyla ultra yüksek eşzamanlı yazımı ve sipariş tablosunu güncellemeyi başardık ve uid ve sipariş kimliği aracılığıyla sipariş bilgilerini sorgulayabiliyoruz. Ancak açık bir grup ödeme sistemi olarak, sipariş bilgilerini iş hattı kimliği aracılığıyla da sorgulamamız gerekir (satıcı kimliği olarak da bilinir, kısaca teklif veririz), bu nedenle uid boyutunun sipariş tablosu kümesini gereksiz hale getirmek için teklif boyutunun sipariş tablosu kümesini kullanıma sunduk Teklif boyutunun sipariş tablosu kümesindeki teklife dayalı olarak sipariş bilgilerini sorgulamak isterseniz, yalnızca teklif boyutunun sipariş tablosu kümesini kontrol etmeniz gerekir.
Yukarıdaki şema basit olmasına rağmen, iki sıra tablosu kümesinin veri tutarlılığını korumak çok zahmetlidir. İki tablo kümesi açıkça farklı veritabanı kümelerindedir.Yazılı olarak ve güncellenirken güçlü bir şekilde tutarlı dağıtılmış bir işlem başlatılırsa, bu şüphesiz sistem verimliliğini büyük ölçüde azaltacak ve bizim için kabul edilemez olan hizmet yanıt süresini artıracaktır. Bu nedenle, verilerin nihai tutarlılığını sağlamak için eşzamansız veri senkronizasyonu için bir mesaj kuyruğu oluşturduk. Elbette, mesaj kuyruğundaki çeşitli anormallikler de veri tutarsızlıklarına neden olacaktır, bu nedenle iki küme arasındaki veri farkını gerçek zamanlı olarak hesaplamak ve tutarlı senkronizasyon gerçekleştirmek için gerçek zamanlı bir izleme hizmeti başlattık.
Aşağıda, tutarlı senkronizasyonun basitleştirilmiş bir diyagramı verilmiştir:
Dördüncüsü, veritabanı yüksek oranda kullanılabilir
Hiçbir makine veya hizmet, çevrimiçi olarak kesintisiz çalışmayı garanti edemez. Örneğin, belirli bir zamanda, belirli bir veritabanının ana veritabanı çalışmıyor. Şu anda veritabanı üzerinde okuma ve yazma işlemleri gerçekleştiremeyeceğiz ve çevrimiçi hizmetler etkilenecek.
Veritabanının yüksek kullanılabilirliği şu anlama gelir: Veritabanında çeşitli nedenlerden dolayı sorunlar olduğunda, veritabanı hizmeti gerçek zamanlı veya hızlı bir şekilde geri yüklenebilir ve veriler onarılabilir.Tüm küme perspektifinden, herhangi bir sorun yokmuş gibi görünüyor. Burada veritabanı hizmetini geri yüklemenin, orijinal veritabanını onarmak anlamına gelmediği, aynı zamanda hizmeti başka bir yedek veritabanına değiştirmeyi de içerdiği unutulmamalıdır.
Veritabanının yüksek kullanılabilirliğinin ana işi, veritabanı kurtarma ve veri onarımdır.Genel olarak, yüksek kullanılabilirliğin bir ölçüsü olarak bu iki görevi tamamlamak için süreyi kullanırız. Burada bir kısır döngü sorunu vardır: Veritabanı kurtarma süresi ne kadar uzun ve tutarsız veriler ne kadar uzun olursa, veri onarım süresi o kadar uzun ve genel onarım süresi o kadar uzun olur. Bu nedenle, hızlı veritabanı kurtarma, veritabanı yüksek kullanılabilirliğinin en önemli önceliği haline geldi.Veritabanı arızasından sonraki 1 saniye içinde veritabanı kurtarmayı tamamlayıp, tutarsız verileri onarmanın ve maliyetin de büyük ölçüde azalacağını hayal edin.
Aşağıdaki şekil en klasik efendi-köle yapısıdır:
Yukarıdaki şekilde, DB1 ana kitaplık ve DB2 ve DB3 bağımlı kitaplıklar olmak üzere 1 web sunucusu ve 3 veritabanı vardır. Burada web sunucusunun proje ekibi tarafından ve veritabanı sunucusunun DBA tarafından tutulduğunu varsayıyoruz.
Veritabanından DB2 ile ilgili bir sorun olduğunda, DBA proje ekibini bilgilendirecek, proje ekibi DB2'yi web hizmeti yapılandırma listesinden silecek, web sunucusunu yeniden başlatacak, böylece hatalı düğüm DB2'ye artık erişilemeyecek ve veritabanı hizmetinin tamamı geri yüklenecektir. DBA'yı bekleyin. DB2'yi onarırken, proje ekibi DB2'yi web hizmetine ekleyecektir.
Ana veritabanı DB1 ile ilgili bir sorun olduğunda, DBA, DB2'yi ana veritabanına geçirecek ve proje ekibini bilgilendirecektir.Proje ekibi, orijinal ana veritabanı DB1'i DB2 ile değiştirir ve web hizmetinin yeni ana veritabanı DB2'yi ve DB1'i kullanması için web sunucusunu yeniden başlatır. Artık ona erişilemez ve tüm veritabanı hizmeti geri yüklenir.DBA, DB1'i onardığında, DB1, DB2'nin bağımlı veritabanı olarak kullanılabilir.
Yukarıdaki klasik yapının büyük bir dezavantajı vardır: Ana kütüphane veya bağımlı kütüphane sorunundan bağımsız olarak, DBA ve proje ekibinin, otomatikleştirilmesi zor olan veritabanı hizmeti kurtarmayı tamamlamak için işbirliği yapması gerekir ve kurtarma projesi çok yavaştır.
Veritabanı işletiminin ve bakımının proje grubundan ayrılması gerektiğine inanıyoruz.Veritabanında sorun olduğunda DBA, otomasyonu kolaylaştıran ve servis kurtarma süresini kısaltan proje grubu operasyon servislerine ihtiyaç duymadan birleşik kurtarma gerçekleştirmelidir.
İlk olarak bağımlı kitaplığın yüksek kullanılabilirlik yapısına bakın:
Yukarıdaki şekilde gösterildiği gibi, web sunucusu artık yedek veritabanı DB2 ve DB3'e doğrudan bağlanmayacak, ancak LVS yük dengelemesine bağlanacak ve LVS, ikincil veritabanına bağlanacaktır. Bunun avantajı, LVS'nin bağımlı veritabanının kullanılabilir olup olmadığını otomatik olarak algılayabilmesidir .. Yedek veritabanı DB2 kapatıldıktan sonra, LVS DB2'ye veri okuma isteklerini yeniden göndermez. Aynı zamanda, DBA'nın bağımlı veritabanı düğümlerini artırması veya azaltması gerektiğinde, yalnızca LVS'yi bağımsız olarak çalıştırması gerekir.Artık proje ekibinin işbirliği için yapılandırma dosyasını güncellemesi ve sunucuyu yeniden başlatması gerekmez.
Ana kütüphanenin yüksek kullanılabilirlik yapısı şemasına bakalım:
Yukarıdaki şekilde gösterildiği gibi, web sunucusu artık ana veritabanı DB1'e doğrudan bağlanmayacak, ancak KeepAlive tarafından sanallaştırılmış bir sanal ip'e bağlanacak ve ardından bu sanal ip'i ana veritabanı DB1 ile eşleştirecek ve DB1'deki verileri gerçek zamanlı olarak senkronize etmek için DB_bak bağımlı kitaplığını ekleyecektir. veri. Normal şartlar altında, web hala DB1'de veri okur ve yazar.DB1 çalışmadığında, betik otomatik olarak DB_bak'ı ana kitaplık olarak ayarlayacak ve sanal ip'i DB_bak'a eşleyecektir. Web hizmeti, okuma ve yazma için ana kitaplık olarak sağlıklı DB_bak'ı kullanacaktır. Giriş. Bu şekilde, ana veritabanı hizmet kurtarma işleminin tamamlanması yalnızca birkaç saniye sürer.
Master-slave yüksek kullanılabilirlik yapısı diyagramını elde etmek için yukarıdaki yapıyı birleştirin:
Veritabanı yüksek kullanılabilirliği, veri yamayı da içerir. Çekirdek verileri çalıştırırken güncellemeleri gerçekleştirmeden önce günlükleri kaydettiğimiz ve veritabanı hizmetlerinin neredeyse gerçek zamanlı olarak hızlı bir şekilde kurtarılmasını sağladığımız için, yamalanmış verilerin miktarı büyük değildir, basit bir kurtarma Komut dosyası, veri onarımını hızla tamamlayabilir.
Beş, veri sınıflandırması
Çekirdek ödeme emri tablosu ve ödeme akış tablosuna ek olarak, ödeme sistemi ayrıca bazı konfigürasyon bilgi tablolarına ve bazı kullanıcıyla ilişkili bilgi tablolarına sahiptir. Veritabanında tüm okuma işlemleri tamamlanırsa, sistem performansı büyük ölçüde azalacaktır, bu nedenle bir veri sınıflandırma mekanizması getirdik.
Ödeme sistemi verilerini basitçe 3 seviyeye ayırıyoruz:
Seviye 1: Sipariş verileri ve ödeme akışı verileri; bu iki veri parçası yüksek gerçek zamanlı ve doğruluk gerektirir, bu nedenle önbellek eklenmez ve okuma ve yazma işlemleri doğrudan veritabanını çalıştırır.
Seviye 2: Kullanıcıyla ilgili veriler; bu veriler kullanıcılarla ilgilidir ve daha fazla okuma ve daha az yazma özelliklerine sahiptir, bu nedenle önbelleğe almak için redis kullanırız.
Seviye 3: Ödeme yapılandırma bilgileri; bu verilerin kullanıcıyla hiçbir ilgisi yoktur, az miktarda veri özelliklerine sahiptir, sık okuma yapar ve neredeyse hiç değişiklik yapılmaz, bu nedenle önbelleğe almak için yerel bellek kullanırız.
Yerel bellek önbelleğini kullanırken bir veri senkronizasyonu sorunu vardır, çünkü yapılandırma bilgileri bellekte önbelleğe alınır ve yerel bellek, veri tabanındaki yapılandırma bilgilerinin değiştirilmesini algılayamaz, bu da veri tabanındaki verilerin ve yerel bellekteki verilerin tutarsız olmasına neden olur.
Bu sorunu çözmek için, yüksek düzeyde kullanılabilir bir mesaj gönderme platformu geliştirdik.Konfigürasyon bilgileri değiştirildiğinde, ödeme sistemindeki tüm sunuculara konfigürasyon dosyası güncelleme mesajlarını göndermek için push platformunu kullanabiliriz.Mesaj alındığında sunucu konfigürasyon bilgilerini otomatik olarak güncelleyecektir. Ve başarı hakkında geri bildirimde bulunun.
Altıncı, kalın ve ince borular
Bilgisayar korsanlığı saldırıları, ön uçta yeniden denemeler ve diğer nedenler, istek hacminin fırlamasına neden olacaktır. Hizmetimiz bir talep dalgası nedeniyle ölürse ve devam ettirmek isterse, çok zahmetli ve külfetli bir süreç olacaktır.
Basit bir örnek olarak, mevcut sipariş işleme kapasitemiz saniyede ortalama 100.000 sipariş ve saniyede en yüksek 140.000 sipariştir.Aynı saniyede 1 milyon sipariş talebi ödeme sistemine girerse, şüphemiz yok ki, Ödeme sistemi çökecek ve sonraki sürekli istekler hizmet kümemizin başlamasını engelleyecektir. Tek yol, tüm trafiği kesmek, tüm kümeyi yeniden başlatmak ve ardından trafiği yavaşça içe aktarmaktır.
Yukarıdaki sorunları çözmek için harici web sunucusuna bir "kalın ve ince borular" katmanı ekleyebiliriz.
Aşağıda, kalın ve ince boru hattının basit bir yapı diyagramı verilmiştir:
Lütfen yukarıdaki yapı şemasına bakın Web kümesine girmeden önce, http istekleri kalın ve ince boru hatları katmanından geçecektir. Giriş tarafı kötü bir dildir, maksimum desteği saniyede 1 milyon istek olarak belirledik ve fazla talepler doğrudan iptal edilecektir. Dışa aktarım ucu ince bir ağız, web kümesine saniyede 100.000 istek belirledik. Kalan 900.000 istek, kaba ve hassas ardışık düzenlerde sıraya alınacaktır.Web kümesi eski istekleri işledikten sonra, yeni istekler ardışık düzenten çıkacak ve web kümesi tarafından işlenecektir. Böylelikle web kümesinin işlediği istek sayısı saniyede 100.000'i asla geçmeyecektir.Bu yük altında kümedeki her hizmet kolejlerde ve üniversitelerde çalışacak ve isteklerdeki artış nedeniyle tüm küme hizmetleri durdurmayacak.
