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

WeChat açık kaynaklı PhxQueue: yüksek düzeyde kullanılabilir, yüksek güvenilirlikli ve yüksek performanslı bir dağıtılmış kuyruk

Yazar | Liang Junjie

Düzenle Xiaozhi

PhxQueue, Paxos protokolüne dayanan yüksek kullanılabilirlik, yüksek verim ve yüksek güvenilirliğe sahip bir WeChat açık kaynak dağıtılmış kuyruğudur.En Az Bir Kez Teslimatı garanti eder ve WeChat ödeme ve genel platformlar gibi çok sayıda önemli hizmeti destekler.

Açık kaynak adresi

https://github.com/Tencent/phxqueue

Mesaj kuyruğuna genel bakış

Olgun bir eşzamansız iletişim modu olarak, ileti kuyrukları, yaygın olarak kullanılan eşzamanlı iletişim modlarına kıyasla aşağıdaki avantajlara sahiptir:

Ayrıştırma: Çok fazla API'nin sistemin kararlılığına riskler getirmesini önleyin; arayan tarafından uygunsuz kullanım, aranan uç sistemi üzerinde baskıya neden olur ve aranan ucun yanlış kullanımı, arayan sistemin yanıt verme yeteneğini azaltacaktır.

Tepe kesme ve akış kontrolü: mesaj üreticileri engellenmez, seri mesajlar kuyrukta önbelleğe alınır ve tüketiciler mesajları gerçek yeteneklerine göre okur.

Yeniden kullanım: Birden çok aboneliği aynı anda yayınlayın.

PhxQueue doğum arka planı

Eski sıra

WeChat tarafından erken aşamada kullanılan dağıtılmış kuyruk (eski kuyruk olarak adlandırılır), WeChat'in kendi geliştirdiği arka planının önemli bir bileşenidir ve çeşitli iş senaryolarında ayırma, önbelleğe alma ve asenkronizasyon gibi hizmetler sağlamak için yaygın olarak kullanılır.

Eski kuyruk, senkronizasyon mekanizması olarak Quorum NRW'yi kullanır; burada N = 3, W = R = 2 ve fırçalama yöntemi, hem performansı hem de kullanılabilirliği hesaba katan asenkron fırçalamayı kullanır.

yeni talep

Hizmetlerin gelişmesiyle birlikte erişim hizmetlerinin türleri artmakta ve eski kuyruklar giderek yetersiz görünmektedir. Başlıca dezavantajlar aşağıdaki gibidir:

Eşzamansız flash disk, veri güvenilirliği endişe vericidir

Ödemeyle ilgili işletmeler için güvenilir verilerin sağlanması birincil gereksinimdir. Şu anda, dağıtılmış kuyruk şemalarının çoğu, veri güvenilirliğini sağlamak için eşzamanlı çoğaltma + eşzamansız yıkama kullanır, ancak veri güvenilirliğini daha da artırmak için eşzamanlı temizlemenin gerekli olduğuna inanıyoruz.

Arıza sorunu

Bazı işletmeler kesinlikle düzenli şartlar öne sürüyorlar, ancak GGS siparişi garanti etmiyor ve gereksinimleri karşılayamıyor.

Buna ek olarak, eski kuyrukta hala iyileştirilmesi gereken kuyruktan çıkarma, yük dengeleme vb. Gibi başka sorunlar vardır. Yukarıdakilerin tümü yeni seçenekleri değerlendirmemizi istedi.

Endüstri çözümlerinin eksikliği

Kafka, büyük veri alanında yaygın olarak kullanılan bir mesaj kuyruğudur. İlk olarak LinkedIn tarafından Scala dili kullanılarak geliştirilmiştir ve LinkedIn'in aktivite akışı takibi ve işletim sistemi veri işleme hattının temeli olarak kullanılmıştır.

Yüksek verim, otomatik felaket kurtarma ve ekibin düzenli giriş ve çıkışları, birçok şirketi kullanmaya çekmiştir.Veri toplama ve iletim senaryolarında önemli bir rol oynamaktadır.Ayrıntılar için Powerd By Kafka'ya bakınız.

Ancak Kafka'yı tamamen araştırdık ve veri güvenilirliği bağlamında aşağıdaki eksikliklere sahip olduğuna inanıyoruz:

Kafka performansı ile senkronize fırçalama arasındaki çelişki

Kafka, log.flush.interval.messages = 1 yapılandırmasını ve eşzamanlı yanıp sönme özelliğini etkinleştirdiğinde, iş hacmi keskin bir şekilde düşecektir. Bu fenomen aşağıdaki faktörlerden kaynaklanır:

SSD yazma büyütme

İş mesajlarının ortalama boyutu yaklaşık 1 k'dir. Yanıp sönen en küçük SSD birimi, 4k olan bir sayfa boyutudur. Kafka, boyutu 4k'den küçük bir mesajı temizlediğinde, yazılan gerçek fiziksel veri miktarı, mesajın boyutunun birkaç katıdır. Sonuç olarak, sabit disk yazma bant genişliği kaynakları boşa harcanır.

Üretici grubu, iş senaryolarında iyi çalışmıyor

Basit bir ifadeyle Kafka Producer grubu, birden fazla mesajı bir arada paketlemek ve bunları büyük veri senaryolarında yaygın olarak kullanılan Broker'a göndermektir. Mantıksal olarak, toplu iş efekti, yazma amplifikasyonunun etkisini dengelemek için yeterlidir. Bununla birlikte, iş senaryosundaki mesaj üretimi, büyük veri senaryosundaki günlük üretiminden farklıdır Sıraya alınması gereken her iş talebinin iş sisteminde bağımsız bir bağlamı vardır ve gruplama zordur. İşletme ile Broker arasına bir aracı katmanı eklense ve Üretici, aracı katmanındaki çok sayıda düğüm nedeniyle toplu işlem için aracı katmanına aktarılsa bile, toplu iş efektinin iyileştirilmesi zordur ve bu da ofset edilemeyen yazma büyütmesine neden olur.

Kafka replika senkronizasyon tasarımının olmaması

Kafka replika senkronizasyon tasarım özeti:

Kafka Broker lideri, kendisiyle senkronize tutulan takipçi listesini takip edecektir.Bu listeye ISR (in-sync Replica) adı verilir. Bir takipçi düşerse veya çok geride kalırsa, lider onu ISR'den çıkaracaktır.

Bu senkronizasyon yöntemi, senkronizasyon verimliliğine odaklanır, ancak kullanılabilirlik açısından biraz yetersizdir:

Broker yük devretme süreci başarı oranı ciddi şekilde düşüyor

3 replika senaryosunda, lider her Broker'a eşit olarak dağıtılır.Bir Broker hatası, liderin ve takipçilerin 1 / 3'ünün çevrimdışı olduğu ve okuma ve yazma başarı oranının düştüğü anlamına gelir:

Liderin çevrimdışı olduğu bölümler için, geçici olarak okuyamaz veya yazamaz ve geri yüklenmeden önce Denetleyicinin yeni bir lider seçmesini beklemesi gerekir;
Follower'in çevrimdışı bölümü geçici olarak okuyamıyor ve yazamıyor. Lider, başarısız olan follower'ı kurtarmak için ISR'den kaldırmadan önce belirli bir süre beklemesi gerekir (replica.lag.time.max.ms'ye bağlı olarak, varsayılan 10s).

Başka bir deyişle, herhangi bir Broker başarısız olduğunda, okuma ve yazma başarı oranı bir süre içinde 0'a düşecektir.

Senkronizasyon gecikmesi en yavaş düğüme bağlıdır

Eşzamanlı çoğaltma senaryosunda, tüm düğümlerin ack döndürmesini beklemeniz gerekir.

Kafka replikası ve Paxos'un performansını karşılaştırarak, Paxos'un senkronizasyon açısından daha iyi bir seçim olduğuna inanıyoruz:

Bu nedenle, eski kuyruğa dayanarak, senkronizasyon mantığını dönüştürmek için Paxos protokolünü kullandık ve senkronizasyon fırçası da dahil olmak üzere bir dizi optimizasyon gerçekleştirdik ve PhxQueue'yu tamamladık.

PhxQueue tanıtımı

PhxQueue şu anda WeChat ödemesi ve WeChat içindeki herkese açık platformlar gibi çok sayıda önemli işletmeyi desteklemektedir, günlük ortalama 100 milyar kayıt ve dakikada 100 milyon en yüksek kayıt ile.

Tasarımının başlangıç noktası, çeşitli ortak kuyruk özelliklerini desteklerken yüksek kullanılabilirlik ve yüksek verimden ödün vermeden yüksek veri güvenilirliğidir.

PhxQueue tarafından desteklenen özellikler aşağıdaki gibidir:

Senkronize yanıp sönme, gelen verileri asla kaybetmez, dahili gerçek zamanlı mutabakatla birlikte gelir
Sıkı ve düzenli giriş ve çıkış
Çoklu abone
Kalkış hız limiti
Tekrar oynatma sırasını kaldır
Tüm modüller paralel olarak genişletilebilir
Yüksek verim sağlamak için toplu yanıp sönme ve depolama katmanının senkronizasyonu
Depolama katmanı, aynı şehirde çok merkezli dağıtımı destekler
Depolama katmanında otomatik olağanüstü durum kurtarma / erişim dengesi
Tüketici otomatik olağanüstü durum kurtarma / yük dengeleme

PhxQueue tasarımı

Genel yapı

PhxQueue aşağıdaki 5 modülden oluşur.

Mağaza kuyruğu depolama

Mağaza, bir kuyruk depolama işlevi görür ve kopya senkronizasyonu için Paxos protokolünü kullanan PhxPaxos kitaplığını sunar. Çoğunluk düğüm çalıştığı ve birbirine bağlı olduğu sürece, doğrusal tutarlı okuma ve yazma hizmetleri sağlanabilir.

Veri güvenilirliğini artırmak için, senkronize yanıp sönme varsayılan özelliktir ve performans, eşzamansız yanıp sönmeden daha az değildir.

Kullanılabilirlik açısından, Mağazada birden fazla bağımsız paxos grubu vardır.Her paxos grubu yalnızca ana bilgisayar için okuma ve yazma hizmetleri sağlar.Genellikle ana makine, erişim basıncını dengelemek için Mağazadaki düğümler arasında dinamik ve eşit bir şekilde dağıtılır ve düğüm bir felaket meydana geldiğinde ana bilgisayarı otomatik olarak diğerine geçirir. Kullanılabilir düğümler.

Yapımcı-Yapımcı

Üretici, mesaj üreticisi olarak anahtara göre mesaj saklama yoluna karar verir. Aynı anahtara sahip mesajlar, varsayılan olarak aynı kuyruğa yönlendirilerek, kuyruktan çıkarma sırasının kuyruk girişi sırası ile tutarlı olması sağlanır.

Tüketici-Tüketici

Tüketici olarak, Tüketici Mağazadan mesajları toplu çekme modunda çeker ve mesajların toplu işlenmesini çoklu yolla destekler.

Tüketici, hizmetleri bir hizmet çerçevesi biçiminde sağlar ve kullanıcılar, geri aramaları uygulayarak farklı konulara (Konu) ve farklı işleme türlerine (İşleyici) göre belirli ileti işleme mantığını tanımlar.

Zamanlayıcı-Tüketici Yöneticisi (isteğe bağlı dağıtım)

Zamanlayıcının rolü, tüketici küresel yük bilgilerini toplamak ve Tüketici için olağanüstü durum kurtarma ve yük dengeleme gerçekleştirmektir. Kullanıcılar bu gereksinime sahip olmadığında, Zamanlayıcının dağıtımını atlayabilirler.Şu anda, her Tüketici, yapılandırma ağırlığına göre kuyrukla işleme ilişkisini belirler.

Zamanlayıcı konuşlandırıldıktan sonra, Zamanlayıcı lideri tüm Conusmer'larla bir kalp atışını sürdürür.Tüketicinin yük bilgilerini toplarken, Tüketici ile kuyruk arasındaki işlem ilişkisini tersine ayarlar.

Zamanlayıcı lideri düştüğünde, Zamanlayıcı yeni bir lider seçmek için aşağıdaki dağıtılmış kilit hizmetine güvenir Kullanılamayan dönem yalnızca Tüketicinin olağanüstü durumdan kurtarılmasını ve yük dengelemesini etkiler ve Tüketicinin normal tüketimini etkilemez.

Kilitle Dağıtılmış kilit (isteğe bağlı dağıtım)

Kilit dağıtılmış bir kilittir. Arayüz tasarımı çok geneldir.Kullanıcılar genel dağıtılmış kilit hizmetleri sağlamak için Lock'u bağımsız olarak dağıtmayı seçebilirler.

PhxQueue'da Lock'un rolü aşağıdaki gibidir:

Planlayıcı için bir lider seçin;

Birden fazla Tüketicinin bir kuyruğu aynı anda işlemesini önleyin.

Lock ayrıca isteğe bağlı bir dağıtım modülüdür:

Zamanlayıcı konuşlandırılmışsa, Zamanlayıcı için bir lider seçmek için Kilit konuşlandırılmalıdır;
Aksi takdirde, işletme tekrarlanan tüketime duyarlı değilse, Lock'u dağıtmamayı seçebilirsiniz.

Burada atıfta bulunulan tekrarlanan tüketim senaryosu şudur: Zamanlayıcının dağıtımı atlanırsa, Tüketicinin yapılandırmayı okuyarak işlenebilecek kuyruk kümesini bilmesi gerekir; kuyruk değiştiğinde (kuyruk küçültülmesi ve genişletilmesi gibi) önce her Tüketici makinesindeki yapılandırma önce değişir Daha sonra, bu zamanda, her bir Tüketicinin aynı anda gördüğü konfigürasyon durumu farklı olabilir ve iki Tüketicinin bir süre aynı kuyruğu tüketmeleri gerektiğini düşünmelerine neden olarak tekrarlanan tüketim ile sonuçlanır. Lock'un konuşlandırılması, bu senaryoda tekrarlanan tüketimi önleyebilir. (Lock konuşlandırması atlansa bile, bu senaryonun yalnızca tekrarlanan tüketime neden olacağını ve arızalı tüketime neden olmayacağını unutmayın)

Mağaza kopyalama işlemi

PhxQueue Store, kopyaları PhxPaxos protokolü aracılığıyla çoğaltır.

PhxPaxos'un mühendislik uygulaması üç katmana bölünmüştür: uygulama katmanı iş taleplerinin işlenmesinden sorumludur, paxos katmanı paxos senkronizasyon sürecini gerçekleştirir ve durum makine katmanı iş durumunu günceller.

Bunlar arasında, uygulama katmanı paxos teklifini başlatır ve paxos katmanının her bir düğümü, paxos protokolü aracılığıyla birlikte bir paxos günlüğü onayını tamamlar.Bundan sonra, durum makinesi paxos günlüğünü durum aktarımı için girdi olarak kullanır, işletmenin durumunu günceller ve son olarak durum aktarım sonucunu uygulama katmanına döndürür. Tutarlı durum makine katmanı, artı paxos katmanından gelen tutarlı girdi, tutarlı bir durum geçişi üretir ve böylece birden çok düğüm arasında güçlü tutarlılık sağlar.

Burada PhxPaxos'a dayalı durum makine katmanında bir kuyruk oluşturmak istiyoruz, aşağıdaki kavramsal eşleştirmeyi yapmamız gerekiyor:

Kuyruk modeli veri modifikasyonunu içermez, sıralı bir veri toplamadır ve paxos günlüğünün tanımına çok benzer, bu nedenle sıraya alınan veriler doğrudan paxos günlüğü olarak kullanılabilir ve durum makinesinin yalnızca paxos günlük sırasını kaydetmesi gerekir.
Örnek kimliğinin kesin olarak artan yapısı, bir kuyruk ofseti olarak kullanılmasını kolaylaştırır.
Kuyrukta okunan ofsetten önceki veriler, kontrol noktasının tanımıyla tutarlı olan silinebilecek veriler olarak kabul edilir.

Genel olarak, kuyruk durumu makinesi ve paxolar iyi uyuyor.

Grup Taahhüdü-Verimli temizleme ve kopyalama senkronizasyonu

Optimize edilmemiş Paxos protokolü, senkron yanıp sönmenin yazma büyütme problemini çözmez. Dahası, replika senkronizasyon verimliliği Kafka kadar iyi değil.

Bunun nedeni, Kafka'nın replika senkronizasyonunun toplu olarak akış halinde yayınlanması, Paxos protokolünün ise seri senkronizasyon için birim olarak paxos günlüğünü kullanmasıdır.Her paxos günlüğünün senkronizasyon ek yükü 1 RTT + 1 floştur.

Bir çoklu DC dağıtım senaryosunda, ping gecikmesi 4 ms'ye ulaşabilir, bu da tek bir paxos grubu için teorik olarak maksimum TPS yalnızca 250 ile sonuçlanır.

Eşzamanlı yanıp sönmenin yazma büyütme problemini ve Paxos verim problemini aynı anda çözmek için çoklu paxos grup dağıtımı ve Grup İşlem yöntemlerini kullanıyoruz.

Yukarıdaki şekilde gösterildiği gibi, Grup Teslimi birimi olarak paxos grubu, bir paxos grubu birden çok kuyruğa karşılık gelen ve birden fazla kuyruğun belirli bir süre içinde sıraya koyduğu veriler, zaman alıcı veya birikimi beklerken bir araya getirilerek birden çok paxos grubu yerleştiriyoruz. Veri sayısı eşiğe ulaştığında, Paxos senkronizasyonu ve senkronizasyon yanıp sönmesi bir kez tetiklenecek ve bekleme süresi boyunca ön uç bloke edilecektir.

Kafka'nın Üretici batch mantığı ile karşılaştırıldığında, depolama katmanında Group Commit ile toplu birleştirmenin avantajları aşağıdaki gibidir:

İş katmanının, isteklerin gruplar halinde nasıl organize edileceğine dikkat etmesi gerekmez;

Depolama katmanında, paxos grubunun agregasyon etkisi, üst katman agregasyonundan daha iyidir.

PhxQueue ve Kafka karşılaştırması

Aşağıdaki, PhxQueue ve Kafka'yı üç açıdan karşılaştırmaktadır: tasarım, performans ve depolama katmanı yük devretme süreci.

Tasarım karşılaştırması

PhxQueue mimarisi, Kafka gibi yaygın dağıtılmış kuyruklara benzer olsa da, tasarımında hala birçok benzersiz özellik vardır. Kafka hakkında biraz bilgisi olan okuyucuların PhxQueue'yu anlamasını kolaylaştırmak için, ikisinin karşılaştırması aşağıda listelenmiştir.

Not: Aşağıdaki karşılaştırma aynı veri güvenilirliği senaryosuna dayanmaktadır: azınlık düğümü başarısız olur, veri kaybına neden olmaz ve tümü hala mevcuttur.

Performans karşılaştırması

test ortamı

Test karşılaştırması ve konfigürasyonu

Test sonuçları

Üretici Grubunu Başlat:

Üretici Grubunu Kapat:

Yukarıdaki senaryoda, PhxQueue darboğazı cpu'da yatıyor ve kullanım oranı% 70 ~% 80'e ulaşıyor.

özet

PhxQueue'nun performansı Kafka ile aynıdır;

Aynı QPS altında, en yavaş düğümün dönmesini beklemeye gerek olmadığından, PhxQueue'nun ortalama zaman tüketimi Kafka'nınkinden biraz daha iyidir;

Producer Batch'i kapattıktan sonra, PhxQueue'nun performansı eşzamanlı flashing senaryosunda Kafka'nın iki katı olabilir. Bunun nedeni, PhxQueue depolama katmanının diske yazmadan önce toplu işlem yapması, ancak Kafka'nın yapmamasıdır, bu nedenle ikincisi yazma amplifikasyonuna sahip olacaktır.

Depolama katmanı yük devretme süreci karşılaştırması

Depolama katmanının bir düğümünü öldürdükten sonra genel çıktı üzerindeki etkiyi esas olarak karşılaştırın.

Kafka

hangi gerçekleştirildi:

Yük Devretme süresi boyunca, derece farklı aşamalarda farklıdır ve takıma katılmanın başarı oranı% 0 ~% 33'tür;
Yük Devretme süresi kira sözleşmesiyle belirlenir ve varsayılan kira süresi 10 saniyedir.

Test süreci:

Replica.lag.time.max.ms'yi 10 saniyeden 60 saniyeye ayarlayın (gözlemi kolaylaştırmak için süreyi uzatın), ardından Broker 0'ı kapatın, 3 bölüm seçin ve aşağıdaki gibi ISR değişikliklerini izleyin:

Bunlar arasında ikinci ve üçüncü aşamalarda takıma katılmanın başarı oranı bozulmuştur:

İkinci aşamada 96/97/98 numaralı bölüm yazılamadı ve takıma katılma başarı oranı% 0'a düştü.
Üçüncü aşama sırasında, Bölüm 96 yazmaya devam edebilir, ancak Bölüm 97/98 yazamaz çünkü yazma, Broker 0'ın geri dönmesini beklemek zorundadır, ancak Broker 0 öldürülmüştür ve takıma katılma başarı oranı% 33'e düşer.

Gerçek gözlemlere göre, ikinci ve üçüncü aşamalarda verim yoktu Bunun nedeni, stres testi aracının bağlantı arızalarını rapor etmeye devam etmesi ve yazmayı durdurmasıydı.

Basınç testi aracı çıktısı:

Broker'a bağlanan stres testi aracının arıza kaydı:

Sebep analizi:

Kafka Broker lideri Kontrolör aracılığıyla seçilir ve ISR listesi lider tarafından tutulur.

Birincisinin kirası, Denetleyici tarafından tanımlanır ve ikincisinin kirası, aracı yapılandırma replica.lag.time.max.ms tarafından belirlenir.

Bu nedenle, ikinci aşama daha kısa bir süreye sahiptir ve kontrolörün kiralama süresi ile belirlenir ve üçüncü aşama daha uzun bir süreye sahiptir ve replica.lag.time.max.ms tarafından belirlenir.

Broker 0 öldürüldüğünde, ilki, Broker 0'ın lider olduğu 1/3 bölümlük kuyruğa alma başarı oranını etkiler ve ikincisi, takipçi olarak Broker 0'ın 2/3 bölümlerinin kuyruğa alma başarı oranını etkiler.

PhxQueue

hangi gerçekleştirildi:

Yük Devretme döneminde, takıma katılmanın başarı oranı yalnızca% 66'ya düştü;
Yük Devretme süresi kira sözleşmesiyle belirlenir ve varsayılan kira süresi 5 saniyedir.
Sıra değiştiren yeniden deneme özelliğini etkinleştirdikten sonra (kullanılabilirliği iyileştirmek için mutlak sıralı gereksinimleri olmayan işletmeler için uygundur), yük devretme süresi boyunca hala% 90 + bir kuyruğa alma başarı oranı vardır.

Test süreci:

Mağaza ana kiralama süresini 10 saniyeden 60 saniyeye ayarlayın (gözlemi kolaylaştırmak için süreyi uzatın), ardından 0 mağazasını kapatın ve ekipteki belirli bir Üreticinin başarı oranını gözlemleyin:

Değişiklik kuyruğu yeniden deneme özelliğini kapatın:

Sırayı yeniden deneme özelliğini açın:

özet

Depolama katmanının yük devretme sürecinde, PhxQueue ve Kafka'nın başarı oranı belli bir süre düşmüştür.PhxQueue'nun başarı oranı% 66 ~% 100 ve Kafka'nın başarı oranı% 0 ~% 33;

PhxQueue kuyruk değiştiren yeniden deneme özelliğini etkinleştirdikten sonra, yük devretme işlemi sırasında kuyruğa katılmanın başarı oranı% 90 + olarak kalır;

Hem PhxQueue hem de Kafka, masterları otomatik olarak değiştirebilir ve sonunda kuyruğa katılmanın başarı oranı tamamen geri yüklenir.

Sonuna yaz

PhxQueue, depolama katmanında çok çaba sarf etti: otomatik ana anahtarlamayı gerçekleştirir ve yine de doğrusal tutarlılığı garanti eder ve anahtarlama sırasında hala yüksek oranda kullanılabilir; Senkronize yanıp sönmenin verimini garanti eder ve performansı, eşzamansız yanıp sönmeden daha az değildir.

Ayrıca, çeşitli iş senaryoları için uygun olan tutarlı giriş ve çıkış sırası, çoklu abonelik, hız sınırı, mesaj tekrarı vb. Gibi kuyruğun pratik özelliklerinin çoğunu gerçekleştirir.

Şu anda, PhxQueue WeChat içinde büyük ölçekte kullanılmaktadır ve resmi olarak açık kaynaklıdır.

PhxQueue'nun açık kaynak sürümünü dahili sürümle tutarlı tutacağız.Okuyucular bunu deneyebilir ve geri bildirimde bulunabilir.

Açık kaynak adresi:

https://github.com/Tencent/phxqueue

yazar hakkında

WeChat kıdemli mühendisi Liang Junjie, şu anda WeChat mesajlaşma sisteminin ve mesajlaşma ara yazılımlarının geliştirilmesinden ve optimizasyonundan sorumludur. 2011 yılında Güney Çin Normal Üniversitesi'nden mezun oldu, Weibo özel mesajlaşma, anti-spam sistemi ve WeChat çoklu sistem mimarisi optimizasyon projelerine katıldı ve yönetti. Geçen yıl, PhxQueue'nun ana yaratıcı üyelerinden biri olarak, WeChat dağıtılmış kuyruklarında büyük yapısal dönüşümler gerçekleştirdi ve yüksek kullanılabilirlik, yüksek verimli ve son derece güvenilir mesajlaşma ara yazılım hizmetleri sağlamayı taahhüt etti.

Bugünün Tavsiyesi

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