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

Mimari tasarım sürecinin dört adımı hakkında konuşmak için "Qianlang Weibo" sahnesini örnek olarak alın

Yazar Li Yunhua

Düzenle He Xiao

Hayali şeyler hakkında konuşmayalım, gerçek bir mücadele yapalım.

Bu makale yetkili teknik uzman Li Yunhua tarafından GeekTime Uygulaması / Mini Programında açılan 50 sayılık ücretli "0'dan Öğrenim Mimarisi" sütunundan alınmıştır. Daha fazla yapısal makale için, lütfen, yeni kullanıcı kaydı 30 yuan azaltılacak, WeChat ödemesini destekleyecektir.

1 Sahne ayarı

Karmaşıklığın kaynağını ve mimari tasarım ilkelerini birleştirelim ve simüle edilmiş bir tasarım senaryosu olan "Qianlang Weibo" aracılığıyla, mimariyi pratikte nasıl tasarlayacağımızı sizinle birlikte görelim.

"Qianlang Weibo" adında bir başlangıç şirketi hayal edelim. Qianlang Weibo'nun işi hızla gelişiyor ve giderek daha fazla sistem var.Sistemler arasındaki işbirliğinin verimliliği çok düşük, örneğin:

Kullanıcı bir Weibo gönderdikten sonra, Weibo alt sisteminin gözden geçirmesi için denetim alt sistemini bilgilendirmesi, ardından istatistikleri gerçekleştirmesi için istatistik alt sistemini bilgilendirmesi, ardından reklam tahminlerinde bulunması için reklam alt sistemini bilgilendirmesi ve ardından mesaj alt sistemine mesaj göndermesi için bildirimde bulunması gerekir. Şu anda sistemler arasındaki arabirimler aracılığıyla çeşitli bildirimler çağrılmaktadır. Her yeni sistem bildirildiğinde, Weibo alt sisteminin arayüzler tasarlaması ve testler yapması gerekir. Verimlilik çok düşüktür ve sorun yeri zahmetlidir. Genellikle diğer alt sistemlerin teknisyenlerinden ayrılır ve Weibo alt sisteminin geliştiricileri sorun yaşar.
Kullanıcı seviyesi VIP'ye ulaştıktan sonra, seviye alt sistemi, refah alt sistemini ödül vermesi için bilgilendirmeli, özel hizmet personeli ayarlaması için müşteri hizmetleri alt sistemini bilgilendirmeli ve ürün indirimleriyle ilgilenmek için ürün alt sistemini bilgilendirmelidir ... Seviye alt sisteminin geliştiricileri de sorunludur.

Yeni mimar bu sorunları kendi tecrübesiyle birleştirdiğinde, bu sorunların kökeninin mimarideki iş alt sistemlerinin güçlü bir şekilde bağlanmasında yattığını ve mesaj kuyruğu sisteminin alt sistemlerin ayrılmasını tamamlayabildiğini şiddetle keşfetti, bu yüzden önerdi. Bir mesaj kuyruk sistemini tanıtmak. Bir analiz, iki tartışma, üç toplantı, dört rapor ve beş onay içeren bir dizi işlemin ardından, mesaj sıralama sistemi nihayet kuruldu. Diğer arka plan bilgileri şunları içerir:

Ara katman ekibi küçük, yaklaşık 6 kişi.
Ara katman yazılımı ekibi Java diline aşinadır, ancak yeni bir meslektaş C / C ++ çok iyidir.
Geliştirme platformu Linux ve veritabanı MySQL'dir.
Şu anda, tüm iş sistemi çift kişilik bir bilgisayar odası yerine tek bir bilgisayar odasına yerleştirilmiştir.

2 Mimari tasarım 1. adım: Karmaşıklığı belirleyin

Mimari tasarımın temel amacı, yazılım sisteminin karmaşıklığını çözmektir, bu nedenle mimariyi tasarlarken, önce sistemin karmaşıklığını analiz etmeliyiz.

Qianlang Weibo'nun mesaj kuyruk sistemi için, karmaşıklığı analiz etmek için "sorun giderme yöntemi" kullanılır. Spesifik analiz süreci şu şekildedir:

1. Bu mesaj kuyruğunun yüksek performansa ihtiyacı var mı?

Qianlang Weibo sistemi kullanıcılarının her gün 10 milyon Weibo gönderdiğini ve ardından Weibo alt sisteminin günde 10 milyon mesaj oluşturacağını varsayalım. Ortalama bir mesajın 10 alt sistem tarafından okunduğunu varsayalım, bu nedenle diğer alt sistemler tarafından okunan mesajlar yaklaşık olarak 100 milyon kez.

10 milyon ve 100 milyon korkutucu görünüyor, ancak mimarlar için odak noktası bir günlük verilere değil, TPS ve QPS gibi bir saniyelik veriye odaklanıyor. Verileri saniyeler içinde hesaplıyoruz.Bir günde saniyede yazılan ortalama mesaj sayısı 115, saniyede okunan mesaj sayısı 1150'dir. Sistemin okuma ve yazma işlemlerinin tamamen ortalama olmadığı düşünülürse tasarım hedefi zirve olmalıdır. Hesaplamak. En yüksek değer genellikle ortalama değerin 3 katıdır, o zaman mesaj kuyruk sisteminin TPS'si 345 ve QPS 3450'dir. Bu büyüklükteki veri, yüksek performansın gerekli olmadığı anlamına gelir.

Mevcut iş ölçeğine göre hesaplanan performans gereksinimleri yüksek olmasa da iş büyüyecek, bu nedenle sistem tasarımının belirli bir performans marjını dikkate alması gerekiyor. Şimdi düşük taban nedeniyle, sonraki iş geliştirme için belirli bir sistem kapasitesini ayırmak için tasarım hedefini tepe değerin 4 katı olarak belirledik, bu nedenle nihai performans gereksinimleri: TPS 1380, QPS 13.800. 1380'in TPS'si yüksek değildir, ancak 13800'ün QPS'si zaten nispeten yüksektir, bu nedenle yüksek performanslı okuma, karmaşıklıklardan biridir.

Burada tepe değerin 4 katı olarak belirlenen tasarım hedefinin iş geliştirme hızına göre tahmin edildiğini unutmayın. 4 kez sabitlenmez. Farklı işletmeler için 2 veya 8 kez olabilir, ancak genellikle 10 olarak ayarlanmamalıdır. 100 kereden fazla, ortaya çıkar çıkmaz 100 kereden bahsetmiyorum bile.

2. Bu mesaj kuyruğu yüksek kullanılabilirlik gerektiriyor mu?

Weibo alt sistemi için, mesaj kaybolursa, incelemeye neden olmazsa ve ardından ulusal yasaları ve düzenlemeleri ihlal ederse, bu çok ciddi bir konudur; seviye alt sistemi için, kullanıcı ilgili seviyeye ulaşırsa, sistem ona ödül vermez ve Ayrıcalıklı hizmetler, VIP kullanıcılar çok memnun olmayacak, bu da kullanıcı kaybına ve gelir kaybına neden olacaktır.Ayrıca daha kritik olmasına rağmen, denetim alt sistemindeki mesajların kaybı kadar ciddi değildir.

Birlikte ele alındığında, mesaj kuyruğu, mesaj yazma, mesaj saklama ve mesaj okuma dahil olmak üzere yüksek kullanılabilirliğe ihtiyaç duyar.

3. Bu mesaj kuyruğu yüksek ölçeklenebilirlik gerektiriyor mu?

Mesaj kuyruğunun işlevi çok açıktır ve temelde genişletilmesine gerek yoktur, bu nedenle ölçeklenebilirlik bu mesaj kuyruğunun karmaşıklığının anahtarı değildir.

Anlamayı kolaylaştırmak için, burada sadece "yüksek performans", "yüksek kullanılabilirlik" ve "ölçeklenebilirlik" üç karmaşıklığını kontrol ediyorum. Gerçek uygulamalarda, farklı şirketler veya ekipler bazı başka karmaşıklık analizlerine sahip olabilir. Örneğin, finansal sistemin güvenliği dikkate alması gerekebilir ve bazı şirketler maliyeti dikkate alacaktır.

Kapsamlı bir analizden sonra, Mesaj kuyruğunun karmaşıklığı esas olarak şu açılardan yansır: yüksek performanslı mesaj okuma, yüksek kullanılabilirlikli mesaj yazma, yüksek kullanılabilirlikli mesaj depolama ve yüksek kullanılabilirlikli mesaj okuma.

3 Mimari Tasarım Adım 2: Tasarım Alternatifleri

Sistemin karşılaştığı temel karmaşıklık problemlerini belirledikten sonra program tasarımının net bir amacı vardır ve gerçek mimari program tasarımına başlayabiliriz.

1. Alternatif 1: Açık kaynak Kafka kullanın

Kafka, güçlü işlevlere ve çok yüksek performansa sahip olgun bir açık kaynak ileti kuyruğu çözümüdür.Görece olgundur ve birçok büyük şirket tarafından kullanılmaktadır.

2. Alternatif 2: Küme + MySQL depolama

Önce tek sunuculu yüksek performansı düşünün. Yüksek performanslı mesaj okuma, "yüksek kullanılabilirliği hesaplama" kategorisine aittir ve birçok tek sunuculu yüksek performanslı alternatifler vardır. Ekibin geliştirme dilinin Java olduğu düşünüldüğünde, bazı insanlar C / C ++ dilinin yüksek performanslı ara katman sistemleri yazmak için daha uygun olduğunu düşünse de, mimarlar kapsamlı bir şekilde tüm ekibin dilin performans avantajları için dil değiştirmesine gerek olmadığını düşünüyor. Mesaj kuyruk sistemi Java'da geliştirmeye devam edin. Netty, Java alanında olgunlaşmış bir yüksek performanslı ağ kitaplığı olduğundan, mimar, Netty'ye dayalı bir ileti kuyruğu sistemi geliştirmeyi seçti.

Sistem tasarımının QPS'si 13800 olduğundan, tek bir makine yüksek performanslı bir sistem oluşturmak için Netty'yi kullansa bile, tek bir sunucunun böylesine yüksek bir QPS'yi desteklemesi için hala büyük bir risk vardır.Bu nedenle, mimar, yüksek performanslı mesaj okumayı karşılamak için bir küme yöntemi benimsemeyi seçer. Yük dengeleme algoritması basit sorgulama kullanır.

Aynı şekilde, "yüksek kullanılabilirlikli yazma", bir kümede karşılanabilen "yüksek performanslı okuma" ile aynıdır. İleti, kümedeki bir sunucuya yazıldığı sürece başarıyla yazıldığından, "yüksek kullanılabilirlikli yazma" ve "yüksek performanslı okuma" küme ayırma algoritması da yoklamayı kullanır, yani normal koşullar altında istemci iletileri sırayla yazar Farklı bir sunucuya; anormal bir sunucu olması durumunda, istemci mesajı doğrudan bir sonraki normal sunucuya yazabilir.

Sistemin tamamında en karmaşık olanı, "yüksek düzeyde kullanılabilir depolama" ve "yüksek düzeyde kullanılabilir okuma" dır. "Yüksek düzeyde kullanılabilir depolama", tek bir sunucu çalışmadığında yazılı mesajların kaybolmamasını gerektirir; Yazılan mesajlar, tek bir sunucu arızalandığında okunmaya devam edebilir. Mimarların düşündüğü ilk şey, MySQL'in ana yedekleme çoğaltma işlevini "yüksek kullanılabilirlikli depolama" amacına ulaşmak ve sunucunun ana yedekleme çözümü aracılığıyla "yüksek oranda kullanılabilir okuma" hedefine ulaşmak için kullanabilecekleriydi.

özel plan:

Programı kısaca açıklayın:

Merkezi olmayan bir veri küme mimarisi benimseyerek, kümedeki sunucular gruplandırılır ve her grup mesaj verilerinin bir kısmını depolar.
Her grup bir ana MySQL ve bir yedek MySQL içerir Gruptaki ana ve yedek veriler kopyalanır ve gruplar arasındaki veriler senkronize edilmez.
Normal koşullar altında, gruptaki ana sunucu harici mesaj yazma ve mesaj okuma hizmetleri sağlarken, bekleme sunucusu harici hizmetler sağlamaz; ana sunucu çalışmadığında, bekleme sunucusu harici mesaj okuma hizmetleri sağlar.
Müşteri, mesaj yazmak ve okumak için bir anket stratejisi benimser.

3. Alternatif 3: Küme + kendi geliştirdiği depolama çözümü

Seçenek 2 temelinde, MySQL depolamayı kendi geliştirdiğiniz bir depolama çözümüyle değiştirin, çünkü MySQL'in ilişkisel veritabanının özellikleri mesaj kuyruklarının veri özelliklerine uymuyor.Kafka'nın yaklaşımına bakın, kendiniz bir dizi dosya depolama uygulayabilirsiniz Ve planı kopyalayın (özel plan açıklaması burada atlanmıştır, planın gerçek tasarımda verilmesi gerekir).

Tek başına yüksek performanslı bir mesaj okuma sistemi tasarlarken birden fazla alternatifin olmadığı görülmektedir.Alternatif 2 ve Alternatif 3'ün her ikisi de Netty tabanlı ağ kitaplıklarını benimser ve Java dilinde gelişir. Ekibin Java geçmişi, aday aralığını kısıtladı. Normal şartlar altında, olgun ekipler teknoloji yığınını kolayca değiştirmeyecektir, ancak yeni kurulan teknik ekipler yeni teknolojileri benimsemeye daha meyillidir.

Üç alternatif, nasıl çalıştırılacağını göstermek için yukarıda kısaca verilmiştir: Uygulamada, yukarıdaki şemadan daha karmaşıktır. Mimarın teknik rezervleri ve deneyimi ne kadar zenginse, alternatifleri daha iyi tasarlamak için alternatifler o kadar fazla olur. Örneğin, açık kaynaklı çözümler Kafka, ActiveMQ, RabbitMQ içerebilir; küme çözümünün depolanmasının MySQL, HBase veya Redis ve MySQL kombinasyonunu kullandığı düşünülebilir; kendi geliştirdiği dosya sistemlerinde birden fazla, Kafka, LevelDB ve HBase'e başvurabilirsiniz. Alan kısıtlamaları nedeniyle burada tek tek genişletmeyeceğim.

4 Adım 3: Alternatiflerin değerlendirilmesi ve seçimi

Alternatif tasarımı tamamladıktan sonra, nihai planın nasıl seçileceği de büyük bir zorluktur. Bazen en basit çözümü seçmemiz, bazen en iyi çözümü seçmemiz, bazen en tanıdık çözümü seçmemiz, bazen de gerçekten karar vermemiz gerekir. Öyleyse anahtar soru şudur: Buradaki "bazen" nasıl yargılanır?

Cevabım "360 derece çevresel değerlendirme"! Spesifik çalışma yöntemi şudur: dikkat etmemiz gereken kalite öznitelik noktalarını listeleyin ve ardından her bir planı bu kalite özelliklerinin boyutlarından değerlendirin ve ardından mevcut duruma uygun en iyi planı kapsamlı bir şekilde seçin.

Önceki sayıda önerilen üç alternatife yanıt olarak, mimar alternatif bir gözden geçirme toplantısı düzenledi.Katılımcılar arasında Ar-Ge, test, işletim ve bakım ve birkaç temel iş denetçisi vardı.

1. Alternatif 1: Açık kaynak Kafka çözümünü kullanın

İşletme yöneticileri Kafka çözümünü benimseme eğilimindedir, çünkü Kafka nispeten olgunlaşmıştır ve her iş ekibi Kafka hakkında az çok bilgiye sahiptir.
Ara yazılım ekibindeki bazı geliştiriciler de Kafka'nın kullanımını destekliyor çünkü Kafka'yı kullanmak çok fazla geliştirme yatırımı tasarrufu sağlayabilir; ancak bazı insanlar Kafka'nın iş senaryolarımız için uygun olmayabileceğini düşünüyor çünkü Kafka büyük kapasiteli günlük mesajı iletimini desteklemek için tasarlandı. Mesaj kuyruğumuz, iş verilerinin güvenilir bir şekilde iletilmesi içindir.
İşletme ve bakım temsilcileri güçlü itirazlar ileri sürüyorlar: Birincisi, Kafka'nın Scala dilinde yazılmış olması ve operasyon ve bakım ekibinin Scala dilinde geliştirilen sistemin bakımında hiçbir tecrübesi yoktur ve problemler ortaya çıktığında problemlerle hızlı bir şekilde ilgilenmek zordur; ikincisi, mevcut operasyon ve bakım ekibinin olgun bir Kafka'nın dağıtım, izleme, acil durum müdahalesi vb. Dahil olmak üzere işletme ve bakım sistemi, Kafka kullanılarak bu sisteme entegre edilemez ve ayrı işletme ve bakım insan gücü gerektirir.
Test temsilcileri de Kafka'yı tanıtma eğilimindedir, çünkü Kafka nispeten olgundur ve fazla test yatırımı gerektirmez.

2. Alternatif 2: Küme + MySQL depolama

Ara yazılım ekibinin Ar-Ge personeli, bu çözümün nispeten basit olduğunu düşünüyor, ancak bazı Ar-Ge personeli bu çözümün performansı konusunda şüpheli. Sonuçta, mesaj verilerini depolamak için MySQL kullanmak, performans kesinlikle dosya sistemini kullanmak kadar iyi değil; ve bazı geliştiriciler böyle bir çözüm yapmaktan endişe ediyor Ara yazılım ekibinin teknik itibarını etkileyecek mi? Sonuçta, MySQL'i mesaj kuyruğu olarak kullanmak daha "dünyevi" ve alternatif görünüyor.
İşletme ve bakım temsilcisi, mevcut işletim ve bakım sistemine entegre edilebildiği ve MySQL veri depolamak için kullanıldığı, güvenilirliği garanti edildiği ve işletim ve bakım ekibinin de zengin MySQL işletim ve bakım deneyimine sahip olduğu için bu plana katılıyor; ancak işletme ve bakım ekibi bu çözümün olduğuna inanıyor. Maliyet nispeten yüksektir ve bir veri grubu 4 makine gerektirir (2 sunucu + 2 veritabanı).
Test temsilcisi, bu programın fonksiyonel test, performans testi ve güvenilirlik testi dahil olmak üzere insan gücünü test etmeye büyük bir yatırımı olduğuna inanmaktadır.
İş yöneticisi bu plan hakkında ne olumlu ne de olumsuz, çünkü zaten onu geliştirmek için insan gücüne yatırım yapan iş ekibi değildir.Sistem bakımı aynı zamanda ara katman ekibinin sorumluluğundadır.İş ekibi için sadece mesaj kuyruk sisteminin istikrarlı ve güvenilir olmasını sağlamak gerekir.

3. Alternatif 3: Küme + kendi geliştirdiği depolama sistemi

Ara yazılım ekibinin bazı geliştiricileri, ara yazılım ekibinin teknik gücünü gösterebilecek iyi bir çözüm olduğunu ve performansının MySQL'inkinden daha yüksek olduğunu düşünüyor; ancak diğer geliştiriciler bu çözümün karmaşıklığının çok yüksek olduğunu düşünüyor. Ekip insan gücü ve teknik gücü, istikrarlı ve güvenilir bir depolama sistemi elde etmek için, yinelemesi uzun zaman alır.Bu süreçte, mesaj sıralama sistemi dosya hasarı gibi ciddi depolama sorunları yaşayabilir ve bu da büyük miktarda veri kaybına neden olabilir.
İşletme ve bakım temsilcisi bu planı onaylamadı, çünkü işletim ve bakım veri kaybına neden olmadan önce birkaç benzer depolama sistemi arızasıyla karşılaştı ve ağır kayıplara maruz kaldı. Örneğin, MongoDB veri kaybetti, Tokyo Tyrant veri kaybetti ve kurtarılamaz. Operasyon ve bakım ekibi, mevcut ara katman yazılım ekibinin teknik gücünün bir depolama sisteminin geliştirilmesini desteklemek için yeterli olduğuna inanmıyor (bu, ara katman ekibini biraz rahatsız ediyor).
Test temsilcisi, işletme ve bakım temsilcisinin görüşüne katılıyor ve kendi geliştirdiği depolama sisteminin testi de çok zor ve yatırım da yüksek.
İşletme yöneticilerinin de kendi geliştirdikleri depolama sistemi hakkında çekinceleri vardır, çünkü tarihsel deneyimlerden yola çıkarak, yeni sistemde çevrimiçi olan hatalar olması gerekir ve depolama sistemi hataları en ciddi olanlardır. Hatalar çok sayıda mesajın kaybolmasına neden olduğunda, sistem üzerindeki etki ciddi olacaktır. .

Üç alternatifle ilgili ön tartışma tamamlandıktan sonra, mimar, üç seçenek için 360 derecelik çevresel değerlendirme formunu listeledi:

Bu tabloyu listeledikten sonra, hangi çözümün daha uygun olduğunu bir bakışta görmek imkansızdır, bu nedenle herkes dikkatini mimara çevirir ve karar verme baskısı artık mimarda yoğunlaşır.

Mimar, düşündükten sonra aşağıdaki nedenlerle son alternatif 2'yi verdi:

1. seçeneği hariç tutmanın ana sebebi çalışabilirliktir çünkü sistem ne kadar olgun olursa olsun internete girdikten sonra problemler olabilir.Sorun hızlı bir şekilde çözülemezse işletmenin ihtiyaçlarını karşılayamaz ve Kafka'nın ana tasarım hedefi yüksek performans Günlük aktarımı ve mesaj kuyruğu tasarımımızın temel amacı, iş mesajlarının güvenilir bir şekilde iletilmesidir.
3. seçeneği hariç tutmanın ana nedeni karmaşıklıktır. Mevcut ekibin teknik gücü ve personel boyutu (toplam 6 kişi ve diğer ara katman sistemlerinin geliştirilmesi ve sürdürülmesi gerekir) kendi geliştirdiği depolama sistemini destekleyemez (referans mimari tasarım ilkesi 2: basit ilke ).
Seçenek 2'nin avantajı, karmaşıklığın yüksek olmaması, mevcut işletim ve bakım sistemine iyi bir şekilde entegre edilebilmesi ve güvenilirliğin garanti edilmesidir.

Mimar, Seçenek 2'nin eksiklikleriyle ilgili olarak şunları açıkladı:

Seçenek 2'nin ilk eksiği performanstır. İşletmenin şu anda ihtiyaç duyduğu performans çok yüksek değildir. Seçenek 2 bunu karşılayabilir. Performans gereksinimleri daha sonra artsa bile, Seçenek 2'nin veri paketi çözümü, onu desteklemek için paralel olarak genişletilebilir (Mimari Tasarım İlkelerine bakın) 3: Evrim ilkesi).
Seçenek 2'nin ikinci dezavantajı maliyettir.Bir grup 4 makine gerektirir. Mevcut iş ihtiyaçlarını desteklemek için 12 sunucu gerekebilir, ancak aslında yedekleme makineleri (sunucular ve veritabanları dahil) esas olarak yedekleme için kullanılır ve diğerleriyle birlikte kullanılabilir. Sistem aynı makinede paralel olarak konuşlandırılır.
Seçenek 2'nin üçüncü dezavantajı, teknik olarak üstün görünmemesidir, ancak tasarım amacımız kendimizi kanıtlamak (referans mimari tasarım ilkesi 1: uygunluk ilkesi) değil, iş ihtiyaçlarını daha hızlı ve daha iyi karşılamaktır.

Son olarak bazı ayrıntıları tekrar tartıştıktan sonra 2. seçeneği seçmeye karar verdik.

"Qianlang Weibo" örneğinden, alternatiflerin seçiminin, yalnızca performans seviyesi ve üstün teknoloji gibi saf teknik faktörlerle değil, birçok faktöre bağlı olduğunu görebiliriz. İşletmenin ihtiyaçları, işletme ve bakım ekibinin tecrübesi, mevcut teknik sistem ve ekip üyelerinin teknik seviyesi, alternatiflerin seçimini etkileyecektir. Bu nedenle, yukarıda bahsedilen aynı üç alternatif, bazı ekipler Kafka'yı tanıtmayı seçecek ve bazıları kendi geliştirdiği depolama sistemlerini seçecek.

5 Mimari Tasarım Adım 4: Ayrıntılı Şema Tasarımı

Alternatiflerin tasarımını ve seçimini tamamladıktan sonra nihayet rahat bir nefes alabiliriz çünkü tüm mimari tasarımın en zor adımı tamamlandı, ancak genel plan tamamlanmadı ve mimarın hala çok çalışmaya devam etmesi gerekiyor. Daha sonra, alternatiflerin uygulanabilecek bir tasarım haline gelmesi için nihai alternatifleri iyileştirmek için ısrarlı çaba sarf etmemiz gerekiyor.

"Qianlang Weibo" mesaj kuyruğunun mimari tasarımında nihai çözüm olarak Alternatif 2'yi seçmiş olsak da, alternatif çözüm tasarım aşamasının ayrıntı düzeyi hala nispeten kabadır ve sonraki tasarım ve geliştirmede geliştiricilere gerçekten rehberlik edemez. Alternatifler temelinde daha fazla iyileştirme.

Aşağıda bazı alternatifleri listeliyorum 2 Referans için iyileştirilmesi gereken tipik noktalar İlgilenen öğrenciler kendi başlarına daha fazla tasarım noktası geliştirmeyi deneyebilirler.

1. Ayrıntılı tasarım noktası 1: Veritabanı tablosu nasıl tasarlanır?

Veritabanı iki tür tabloyla tasarlanmıştır; biri mesaj yazarken mesajları MySQL'de hızlı bir şekilde depolamak için kullanılan bir günlük tablosu; diğeri bir mesaj tablosu, her mesaj kuyruğu için bir tablo.
İş sistemi bir mesaj yayınladığında, önce günlük tablosuna yazılır.Günlük tablosu başarılı bir şekilde yazılırsa, mesaj başarıyla yazılır; arka plan iş parçacığı, günlük tablosundan mesaj yazma kaydını okur ve mesaj içeriğini mesaj tablosuna yazar.
İş sistemi bir mesajı okuduğunda, onu mesaj tablosundan okur.
Günlük tablosu MQ_LOG olarak adlandırılır ve şu alanları içerir: günlük kimliği, yayıncı bilgileri, yayın zamanı, kuyruk adı ve mesaj içeriği.
Mesaj tablosunun adı kuyruğun adıdır ve şu alanları içerir: mesaj kimliği (artımlı olarak oluşturulan), mesaj içeriği, mesaj yayınlanma zamanı ve mesaj yayıncısı.
Günlük tablosunun, mesaj tablosuna yazılan günlük verilerini zamanında temizlemesi gerekir.Mesaj tablosu, 30 güne kadar mesaj verisi kaydeder.

2. Ayrıntılı tasarım noktası 2: Veriler nasıl kopyalanır?

MySQL master-slave replikasyonunu doğrudan kullanabilirsiniz, sadece mesaj saklama tablosu replike edilir, log tablosu değil.

3. Ayrıntılı tasarım noktası 3: Etkin ve yedek sunucular arasında nasıl geçiş yapılır?

ZooKeeper, ana ve yedekleme kararları vermek için kullanılır. Hem ana hem de yedekleme sunucuları, kendi düğümlerini oluşturmak için ZooKeeper'a bağlanır. Ana sunucunun yol kuralı "/ MQ / sunucu / bölüm numarası / ana" ve yedekleme makinesi "/ MQ / sunucu / bölüm numarası / köle" dir. ", düğüm türü EPHEMERAL'dir.

Bekleme makinesi, ana bilgisayarın düğüm mesajlarını izler Ana sunucu düğümünün bağlantısının kesildiği tespit edildiğinde, bekleme sunucusu durumunu değiştirir ve harici mesaj okuma hizmetleri sağlar.

4. Ayrıntılı tasarım noktası 4: İşletme sunucusu mesajları nasıl yazıyor?

Mesaj sıralama sistemi, her biri benzersiz bir ada sahip üretici ve tüketici olmak üzere iki rolle tasarlanmıştır.
Mesaj sıralama sistemi, çeşitli iş sistemlerinin çağrılması için SDK sağlar SDK, mesaj sıralama sisteminin tüm sunucu bilgilerini yapılandırmadan okur ve SDK, ana sunucuya bir mesaj yazma talebini başlatmak için bir sorgulama algoritması kullanır. Bir ana sunucu yanıt vermezse veya bir hata döndürürse, SDK bir istek başlatır ve bir sonraki sunucuya gönderir.

5. Ayrıntılı tasarım noktası 5: İşletme sunucusu mesajı nasıl okur?

Mesaj sıralama sistemi, çeşitli iş sistemlerinin çağrılması için SDK sağlar SDK, tüm mesaj kuyruklama sistemlerinin sunucu bilgilerini konfigürasyondan okur ve sırayla tüm sunuculara mesaj okuma isteklerini başlatır.
Mesaj kuyruğu sunucusunun, her tüketicinin tüketim durumunu, yani mevcut tüketicinin okuduğu mesajı kaydetmesi gerekir ve bir mesaj okuma talebi aldığında, tüketiciye bir sonraki okunmamış mesajı geri gönderir.

6. Ayrıntılı tasarım noktası 6: İş sunucusu ile mesaj kuyruğu sunucusu arasındaki iletişim protokolü nasıl tasarlanır?

Uyumluluğu geliştirmek için, mesaj sıralama sisteminin gelecekte çok sayıda farklı programlama dilinde yazılmış sistemlere bağlanabileceği düşünüldüğünde, iletim protokolü TCP kullanır ve veri formatı ProtocolBuffer'dır.

Elbette, tek tek listelenmeyecek daha fazla tasarım detayı var, bu yüzden bu tam bir tasarım planı değil.Umarım bu spesifik örnekler, detaylı planın nasıl yapılacağını gösterebilir.

Not: Bu makale, sütunun yalnızca kısmi bir özetidir.Yukarıdaki dört tam makaleyi okumak istiyorsanız, lütfen "0'dan Öğrenim Mimarisi" yazar sütununa abone olun.

Geek Time Mini Programına, WeChat Pay'e girmek ve hemen abone olmak için aşağıdaki resme tıklayın

[Avantajlar] Bir arkadaşınızı satın almaya her davet ettiğinizde, 16 ¥ para iadesi alabilir ve arkadaşlarınız da 8 ¥, daha fazla davetiye, daha fazla ödül, sınır yok, anında WeChat para çekme alabilir.

[Orijinal metni okuyun] 'a tıklayın, abone olduktan sonra GeekTime Uygulamasında / PC'de de okuyabilirsiniz

Bugünün Tavsiyesi

Okumak için aşağıdaki resme tıklayın