一、引言
在通信系統(tǒng)或者多系統(tǒng)協(xié)同的軟件系統(tǒng)里，網(wǎng)元或系統(tǒng)之間經(jīng)常需要進(jìn)行信息同步或者信息查詢。系統(tǒng)間的消息查詢一般為長(zhǎng)鏈接，如果遇到網(wǎng)絡(luò)異常或者對(duì)端系統(tǒng)處理不過(guò)來(lái)的情況，會(huì)在短時(shí)間內(nèi)產(chǎn)生大量的查詢消息。反復(fù)查詢反復(fù)失敗，前面失敗的消息以及新到達(dá)的查詢消息大量積壓，反復(fù)的查詢和大量的消息處理使得系統(tǒng)性能急劇下降，甚至影響到其他無(wú)關(guān)的業(yè)務(wù)。因此，為保障系統(tǒng)的穩(wěn)定可靠，對(duì)于異常情況的處理至關(guān)重要。尤其是適用“5個(gè)9”要求的通信系統(tǒng)，導(dǎo)致服務(wù)出問(wèn)題的往往是一些異常情況，需要有充足的邏輯來(lái)保障出現(xiàn)異常情況時(shí)，系統(tǒng)仍然能夠穩(wěn)定、可靠地處理業(yè)務(wù)。
下面我們就沿著是什么，怎么做，為什么這樣做的思路逐步討論分析。
二、是什么產(chǎn)生網(wǎng)絡(luò)信息波動(dòng)
如上圖，我們看到大部分業(yè)務(wù)的開展都是三方系統(tǒng)之間的服務(wù)應(yīng)用在交互，這樣在很大程度上就有多種因素會(huì)導(dǎo)致消息傳輸?shù)牟▌?dòng)，以上業(yè)務(wù)的邏輯，我將它歸納為兩點(diǎn)一線。
兩點(diǎn)指的是起始端和目的端，一線指的是傳輸介質(zhì)：
1）兩點(diǎn)間的服務(wù)中斷或者異常就會(huì)導(dǎo)致信息傳輸?shù)牟豢蛇_(dá)，直接導(dǎo)致信息的丟失，造成業(yè)務(wù)失敗。
2）傳輸介質(zhì)的網(wǎng)絡(luò)質(zhì)量不行，例如丟包率過(guò)大，也會(huì)導(dǎo)致信息傳輸異常，造成業(yè)務(wù)失敗。
基于以上兩點(diǎn)，讓我們大致了解業(yè)務(wù)中網(wǎng)絡(luò)信息波動(dòng)產(chǎn)生的原因，接下來(lái)我們闡述一下該如何應(yīng)對(duì)。
三、怎么做降低信息傳輸失敗的概率
1）設(shè)計(jì)方案
針對(duì)系統(tǒng)間信息同步時(shí)的異常情況，基于消息隊(duì)列+Redis緩存，采用退避算法，實(shí)現(xiàn)了消息延遲消費(fèi)。當(dāng)出現(xiàn)網(wǎng)絡(luò)波動(dòng)或者對(duì)端網(wǎng)元響應(yīng)緩慢時(shí)，失敗的消息按照退避算法進(jìn)行合理退讓。這樣，不僅減少了消息的無(wú)效嘗試，降低了無(wú)效的系統(tǒng)開銷，而且保障了其他正常業(yè)務(wù)的順利運(yùn)行，確保了即使在網(wǎng)絡(luò)波動(dòng)或者對(duì)端系統(tǒng)回復(fù)延遲的異常情況下，也不會(huì)因?yàn)榇罅慷逊e的查詢消息消耗過(guò)多的系統(tǒng)資源，系統(tǒng)性能的穩(wěn)定可靠得到保障。
2）技術(shù)架構(gòu)
（1）消息通過(guò)Kafka或其他消息中間件進(jìn)入正常的消費(fèi)隊(duì)列進(jìn)行生產(chǎn)和消費(fèi)，如果都成功，則完成信息處理。
（2）消息如果在經(jīng)過(guò)Kafka等消息中間件發(fā)生異常，根據(jù)消息失敗的情況，根據(jù)規(guī)避算法，計(jì)算出該消息需要延遲的時(shí)間，寫入消息的延遲時(shí)間里，將消息按照一定的格式（sortedSet）存儲(chǔ)到Redis中。
（3）通過(guò)每秒級(jí)別的定時(shí)輪詢，通過(guò)reverseRangeByScore獲取到消息。根據(jù)消息的延遲時(shí)間判斷該消息是否達(dá)到消費(fèi)時(shí)間，如果達(dá)到消費(fèi)時(shí)間，將再次進(jìn)入kafka的中間件進(jìn)入重試消費(fèi)隊(duì)列進(jìn)行生產(chǎn)和消費(fèi)。如果沒(méi)有達(dá)到消費(fèi)時(shí)間，繼續(xù)排隊(duì)，優(yōu)先處理其他延遲時(shí)間已到的消息。這樣的機(jī)制減少了無(wú)效的消息重試，保障了隊(duì)列中其他消息能夠得到及時(shí)處理。
（4）此外，系統(tǒng)在高并發(fā)的情況下，會(huì)繼續(xù)產(chǎn)生大量查詢消息。為避免隊(duì)列中的消息堆積，消息的重復(fù)消費(fèi)具有次數(shù)限制。根據(jù)測(cè)試，3次重試是一個(gè)有效的保障值，如果3次重試還是沒(méi)有響應(yīng)，該消息將落庫(kù)DB數(shù)據(jù)庫(kù)，不再占用隊(duì)列資源。最后定時(shí)任務(wù)會(huì)每小時(shí)對(duì)DB里的堆積消息進(jìn)行輪詢，輪詢到的消息會(huì)再次進(jìn)入Kafka的重試隊(duì)列進(jìn)行消費(fèi)。
四、為什么這樣做，好處是什么？
（1）從業(yè)務(wù)上講：
從圖一，我們可知我們對(duì)接的業(yè)務(wù)都是彼此分離的三方業(yè)務(wù)系統(tǒng)，在產(chǎn)生網(wǎng)絡(luò)信息波動(dòng)的情況下，我們從兩點(diǎn)一線中能盡快解決的就是屬于自己業(yè)務(wù)服務(wù)側(cè)的一點(diǎn)，其他的一點(diǎn)和傳輸介質(zhì)都需要耗費(fèi)較大的人力去溝通解決。我們需要盡可能地將消費(fèi)失敗的信息傳輸?shù)饺剑瑫r(shí)也要保證自己服務(wù)的消息不被積壓，致使自己系統(tǒng)的服務(wù)崩潰，以上架構(gòu)很好地解決了磁力問(wèn)題
（2）從先進(jìn)性上講：
本方案的消息中間件探索了一條在高并發(fā)場(chǎng)景下，減少堆積消息的有效路徑。在傳統(tǒng)設(shè)計(jì)模式下，系統(tǒng)間的查詢消息均是等間隔地進(jìn)行查詢，在網(wǎng)絡(luò)穩(wěn)定和并發(fā)量低的情況下，這樣的技術(shù)方案可以表現(xiàn)穩(wěn)定。但是一旦網(wǎng)絡(luò)波動(dòng)或者并發(fā)量加大，等間隔的消息查詢會(huì)造成大量的堆積消息，從而影響到系統(tǒng)的穩(wěn)定性和可靠性。在解決堆積消息方面，網(wǎng)上較多的方案是進(jìn)行隊(duì)列的消息預(yù)警，這樣的解決方案相當(dāng)于一種事后補(bǔ)救方案。但是本方案消息中間件從消息的源頭進(jìn)行有效的算法設(shè)計(jì)，保障了從源頭上減少無(wú)效的重復(fù)消息。這樣的解決方案彌補(bǔ)了主流技術(shù)設(shè)計(jì)上的不足，是一種比較先進(jìn)的設(shè)計(jì)思路，填補(bǔ)了公司在處理高并發(fā)、高穩(wěn)定性要求的業(yè)務(wù)上的技術(shù)空白。
（3）從兼容性上講：
在本架構(gòu)中，采用了多種技術(shù)的組合設(shè)計(jì)，不拘泥于某一種特定的技術(shù)。現(xiàn)在市場(chǎng)上流行的消息中間件如：ActiveMQ、RabbitMQ、Kafka、RocketMQ、ZeroMQ等，都可以在架構(gòu)中使用。本方案消息中間件的架構(gòu)設(shè)計(jì)具有很強(qiáng)大的兼容性。
（4）從靈活性上講：
在本架構(gòu)中，消息的延時(shí)消費(fèi)等級(jí)可以根據(jù)自己項(xiàng)目的需要自由設(shè)定，消息的延時(shí)消費(fèi)次數(shù)也可以根據(jù)自己項(xiàng)目的需要自由設(shè)定，系統(tǒng)靈活性強(qiáng)。
（5）從可復(fù)用性上講：
本消息中間件采用常用的消息隊(duì)列+Redis緩存，是一種可復(fù)用性很強(qiáng)的消息中間件，可廣泛應(yīng)用于各類高并發(fā)、高可靠性要求的業(yè)務(wù)系統(tǒng)。
（6）從性能的角度講：
redis可以作為一個(gè)高性能的存儲(chǔ)db，性能要比MySQL好很多，并且支持持久化，穩(wěn)定性好。redis SortedSet隊(duì)列天然支持以時(shí)間作為條件排序，完美滿足我們選出要推送記錄的需要。為保障消息均能得到及時(shí)處理，一次從隊(duì)列中取出執(zhí)行的數(shù)量可以設(shè)置得大一點(diǎn)或啟動(dòng)多個(gè)推送的服務(wù)。假設(shè)一次從隊(duì)列中取出執(zhí)行的數(shù)量設(shè)置為：2000，推送的服務(wù)節(jié)點(diǎn)為：3個(gè)，定時(shí)任務(wù)執(zhí)行間隔為：1秒，一分鐘內(nèi)可以實(shí)際推送的數(shù)量為：2000 * 60 * 3 = 360000(理想情況下：多個(gè)推送隊(duì)列subscribe-queue的推送任務(wù)分布均勻)。這個(gè)數(shù)量已經(jīng)可以滿足絕大部分的需求。
五、總結(jié)
本文探討的方案是從三方系統(tǒng)的消息穩(wěn)定性出發(fā)設(shè)計(jì)的，其實(shí)這一套設(shè)計(jì)也可適用于本系統(tǒng)多個(gè)模塊的營(yíng)運(yùn)服務(wù)，隨著技術(shù)的迭代更新，相信會(huì)有更好、更加完善的解決方案問(wèn)世。本文方案僅做拋磚引玉，希望相關(guān)問(wèn)題能夠得到大家更多的關(guān)注和討論，期待各位提供更好的思路和建議，謝謝大家。
