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