News
您的位置：
傳統處理方法用戶注冊后，一般系統需要發送注冊郵件和短信通知，以告知用戶注冊成功。通常的做法為：只有以上三個任務(注冊+郵件通知+短信通知)全部完成后，才返回注冊結果到客戶端，用戶才能使用賬號登錄。假設每個任務耗時分別為50ms，則用戶需要在注冊頁面等待總共150ms才能登錄。同時由于注冊系統強依賴于郵件和短信發送系統，一旦發送系統異常，注冊系統將受到連鎖影響，降低了系統的可用性。使用了消息隊列的異步解耦的處理方法對于用戶來說，注冊功能實際只需要注冊系統存儲用戶的賬戶信息后，該用戶便可以登錄，后續的注冊短信和郵件不是即時需要關注的步驟。對于注冊系統而言，發送注冊成功的短信和郵件通知并不一定要綁定在一起同步完成，所以實際當數據寫入注冊系統后，注冊系統就可以把其他的操作放入對應的消息隊列中然后馬上返回用戶結果，由消息隊列MQ異步地進行這些操作。由此，用戶只需在注冊頁面等待注冊數據寫入注冊系統和消息隊列的時間，等待55ms即可登錄。同時注冊流程也不會受郵件系統和短信系統的可用性影響，從而提升了整體的穩定性。穩定性提升實踐消息隊列的應用場景非常豐富，在支持順序消息、事務消息、延時消息，在削峰填谷、海量消息存儲等方面都能起到重要的作用。但是往往越底層的應用，其穩定性要求也越高，作為應用之間連接的橋梁，一旦消息隊列發生故障，整個業務系統都可能會癱瘓。首先看下WhaleDI-MQ的高可用部署架構，其包含服務端組件和客戶端組件兩大部分，其中服務端組件包含Namesrv、Broker和Zookeeper，客戶端組件包含生產組producer和消費者Consumer，架構如下圖所示：Namesrv為無狀態服務，是WhaleDI-MQ的注冊中心，用于收集和更新路由信息；WhaleDI-MQ通過部署多個Namesrv節點保障高可用，當一個Namesrv異常退出后，客戶端能夠自動重連到其他的Namesrv節點。Broker為實際對外提供消息發送和消費服務的節點，消息會輪詢發送到各個主節點Broker中，主備之間通過同步雙寫保障數據的可靠性；單個Broker master節點異常時，備節點會自動切換為master節點，繼續提供服務；當一組Broker的master、slave節點全部異常時，其他的Broker節點仍然可以提供服務，保證了服務的可用性。WhaleDI-MQ利用ZK特性監控Broker的主備狀態，實現了Broker的自動切換功能。Zookeeper自身采用多節點（奇數個）部署的方式，利用ZAB協議特性保證自身組件的高可用。Producer為生產者客戶端，采用多節點集群部署模式，具備極強的擴展能力，某個Producer異常，不影響其它Producer節點發送消息。Consumer為消費者客戶端，和Producer一樣采用多節點集群部署模式，當某個Consumer節點異常時，WhaleDI-MQ根據負載策略動態再平衡，重新調整隊列路由。下面，我們將從Namesrv、Broker、異地容災等幾個方面給大家講解穩定性提升實踐。01Namesrv穩定性提升Namesrv是Rocketmq的無狀態注冊服務，主要作用為：作為Broker的注冊中心，維護Broker的服務地址和路由信息客戶端通過Namesrv獲取以及更新路由信息Rocketmq是通過部署多個Namesrv節點來保證高可用，每個Namesrv的節點維護的數據都是相同的，客戶端初始化時僅會選擇其中的一個Namesrv節點建立網絡鏈接，若建鏈失敗，則根據異常條件重新選擇其他的Namesrv節點。>>>>故障場景：若連接的Namesrv節點cpu hang死，由于客戶端已經和故障的Namesrv節點建立連接，因而不會再選擇其他的Namesrv節點連接，由于當前的Namesrv故障，導致后續的路由更新、狀態通知等全部超時失敗，進而無法進行正常發送和消費消息，導致業務應用異常。>>>>解決方案：WhaleDI-MQ增加了Namesrv鏈接自我檢測機制，對于netty異常鏈接定期檢測，若發現鏈接不可用則進行異常斷鏈，重新選擇其他的Namesrv進行連接。>>>>應用成果：即便客戶端已經和故障的Namesrv節點建立了連接，但是若后續的路由獲取、心跳上報等服務在一定時間內異常次數超過閾值，客戶端依然會和當前的故障節點主動斷鏈，重新選擇其他正常的Namesrv節點。02Broker支持主備模式自動切換Rocketmq4.5之前的版本Broker采用的是M-S的部署模式，主節點異常后，程序缺乏狀態調度手段，必須人工介入才能進行主備切換，無法滿足電信行業的高可用要求。傳統M-S部署方式消息寫入模式如下：Producer客戶端發送消息到Broker master節點 Master節點同步寫入到Slave從節點Slave通知Maser節點消息寫入成功Master節點返回成功寫入狀態至消息客戶端Rocketmq自4.5版本起引入了Dledger多副本框架，基于raft共識算法（分布式數據一致性協議paxos），是一種強一致性、去中心化、高可用的分布式協議，確保集群中的每個節點都同意一系列相同的狀態轉換。Leader選舉：Leader異?；蛘叻粘跗趩?，通過多數派共識算法，決策出主節點；數據同步：領導者確認后，由Leader接受客戶端的請求，寫入node log（此時數據沒有提交，因而不會更新節點數據），并同步到從節點，當收到多數的從節點應答后，更新本地數據，響應客戶端數據寫入成功，并通知其他的節點更新數據。>>>>痛點描述：利用raft的特性，Dledger天然支持自動選主和切換，但是也正是由于多數派原則，防止腦裂風險，Broker節點至少需要3副本，相較于原來的主備模式，至少需要額外增加一個Broker節點，增大了部署硬件資源的成本。>>>>解決方案：浩鯨科技WhaleDI-MQ引入Zookeeper協同主備狀態控制，仍采用一主一備模式實現主從自動切換的能力，減少了部署的節點數，又滿足了電信行業的高可用的要求。由于ZK的作用僅僅為Broker主備狀態控制，其資源占用非常少，可以和Dubbo或者其他的業務應用共用zk，甚至可以將zk部署到WhaleDI-MQ的服務器上，從而節省了硬件部署資源。>>>>應用成果：WhaleDI-MQ部署時仍采用一主一備的模式，利用zk做狀態控制，就可以實現主備自動切換的功能，降低了消息組件部署的主機數量，給客戶節省了成本。03異地容災>>>>痛點描述：一般的消息隊列只支持主備部署模式，即便采用異地部署，主備節點仍在一個大集群中，若異地距離比較遠網絡時延較大時，將極大的影響消息發送的性能，不滿足浩鯨科技電信級商用項目的要求。若MQ部署在同一個機房中，一旦遭遇火災、地震等不可抗力的災難時，難以快速恢復消息服務，導致業務長時間中斷，并可能丟失大量的業務消息。>>>>解決方案：WhaleDI-MQ通過異地構建一套消息容災集群，不間斷地從主站點同步消息數據，當主節點遭受意外情況且系統無法恢復時，可以在兩分鐘之內將容災集群切換為主站點集群，快速恢復業務，減少中斷時長，從而降低客戶的損失。異地消息容災集群能夠自動感知主站點的Broker節點狀態，并建立數據復制通道，即便主站點發生主備切換或者同步鏈路斷開，容災節點也能夠根據名服務重新獲取路由信息，建鏈續傳。容災消息復制支持同步和異步兩種數據復制模式，業務可以根據實際需要配置復制模式：同步復制：保證數據零丟失；異步復制：容災復制對主站點自身的消息寫入服務影響比較小，數據復制會有稍許的延時（秒級）。應用成果：WhaleDI-MQ容災站點可以在主站點異常不可用時，進行一鍵容災切換，將容災站點切換為主站點，快速地恢復服務。04消息發送穩定性提升Producer發送消息的時候，默認會輪詢所有的message queue發送，以達到讓消息平均落在不同的queue上。由于queue散落在不同的Broker，所以消息就發送到不同的Broker上，如下圖：>>>>故障場景：當BrokerA出現以下情況時：BrokerA磁盤阻塞或寫入超時生產者和BrokerA之間網絡超時、丟包等BrokerA cpu、內存等使用率超過100%由于發生上述故障時，BrokerA的進程正常，并不會使namesrv剔除BrokerA的路由數據，導致每當消息發送輪詢到故障BrokerA節點時便會發生超時(默認5秒)，超時后客戶端輪詢到BrokerB節點則又正常發送消息，等下次再輪詢到BrokerA節點時，又會觸發5秒的超時，導致tps驟降，引起業務異常。>>>>解決方案：發送客戶端引入故障熔斷機制資源隔離：單個Broker的異常不會影響其他Broker的消息發送超時熔斷：當前的Broker在一定的時間內超時達到了一定的次數，并執行服務降級，并使用異步的機制探測恢復的情況失敗熔斷：當發送失敗的調用次數達到一定閾值，如system busy、io滿載等則自動降級，并使用進行異步機制探測恢復的情況>>>>應用成果：BrokerA故障期間，消息不再往故障節點發送消息，而是轉而路由到其他正常的Broker節點，保證了消息發送的成功率。同時異步的檢測故障節點的恢復情況，若節點恢復，則消息會重新往此節點發送。05服務節點自愈>>>>痛點描述：一般的消息服務組件不具備應用自愈的能力，當MQ部署主機異常重啟時，需要人工介入，手動重啟服務組件。從異常發生，到告警系統捕獲到集群異常信息通知到運維人員，再到運維人員上線分析告警原因，逐個登錄到MQ的各個主機上重啟Namesrv和Broker，往往至少需要耗費一個小時修復周期，導致在分秒必爭的電信級生產環境中，給客戶造成極大的損失。>>>>方案描述：WhaleDI-MQ提供統一的健康狀態監控+調度的功能，定時檢查各個服務節點的運行情況，當檢測到節點異常時，統一調度將會自動拉起故障節點。>>>>應用成果：利用統一調度功能，WhaleDI-MQ的Namesrv、Broker和ZK皆具備了服務自愈的能力，進程異常退出后，無需人工介入，自動恢復消息服務組件，修復的時間由原來的至少1小時降低到2分鐘；同時程序自愈的能力也降低了人工介入誤操作的概率，保障了生產系統的安全。實踐總結浩鯨科技具有數百個行業穩定落地的實踐經驗，同時基于HATT混沌工程，我們從網絡、內存、IO、磁盤、cpu等多個維度，編寫了上百個測試用例，充分驗證了WhaleDI-MQ穩定性能力，并對相關的不足點進行了優化提升，使得SLA可用性達到了99.99%。WhaleDI分布式消息產品已經有效支撐了浩鯨科技眾多電信級的項目平穩運行，全面助力客戶應用數字化轉型。隨著業務應用云原生化的不斷深入，需要MQ進一步加強產品的穩定性，如故障數據檢查同步算法、磁盤壞道數據mock、主容站點數據同步壓縮加速、主備切換時長、客戶端縮短感知等方面，針對這些場景，我們會繼續深入技術研究，力爭在未來企業應用的各種復雜場景下，更好地保障系統應用高效平穩運行。
傳統處理方法
使用了消息隊列的異步解耦的處理方法
Namesrv為無狀態服務，是WhaleDI-MQ的注冊中心，用于收集和更新路由信息；WhaleDI-MQ通過部署多個Namesrv節點保障高可用，當一個Namesrv異常退出后，客戶端能夠自動重連到其他的Namesrv節點。
Broker為實際對外提供消息發送和消費服務的節點，消息會輪詢發送到各個主節點Broker中，主備之間通過同步雙寫保障數據的可靠性；單個Broker master節點異常時，備節點會自動切換為master節點，繼續提供服務；當一組Broker的master、slave節點全部異常時，其他的Broker節點仍然可以提供服務，保證了服務的可用性。
WhaleDI-MQ利用ZK特性監控Broker的主備狀態，實現了Broker的自動切換功能。Zookeeper自身采用多節點（奇數個）部署的方式，利用ZAB協議特性保證自身組件的高可用。
Producer為生產者客戶端，采用多節點集群部署模式，具備極強的擴展能力，某個Producer異常，不影響其它Producer節點發送消息。
Consumer為消費者客戶端，和Producer一樣采用多節點集群部署模式，當某個Consumer節點異常時，WhaleDI-MQ根據負載策略動態再平衡，重新調整隊列路由。
作為Broker的注冊中心，維護Broker的服務地址和路由信息
客戶端通過Namesrv獲取以及更新路由信息
故障場景：
解決方案：
應用成果：
Producer客戶端發送消息到Broker master節點
Master節點同步寫入到Slave從節點
Slave通知Maser節點消息寫入成功
Master節點返回成功寫入狀態至消息客戶端
痛點描述：
同步復制：保證數據零丟失；異步復制：容災復制對主站點自身的消息寫入服務影響比較小，數據復制會有稍許的延時（秒級）。
應用成果：WhaleDI-MQ容災站點可以在主站點異常不可用時，進行一鍵容災切換，將容災站點切換為主站點，快速地恢復服務。
BrokerA磁盤阻塞或寫入超時
生產者和BrokerA之間網絡超時、丟包等
BrokerA cpu、內存等使用率超過100%
資源隔離：單個Broker的異常不會影響其他Broker的消息發送
超時熔斷：當前的Broker在一定的時間內超時達到了一定的次數，并執行服務降級，并使用異步的機制探測恢復的情況
失敗熔斷：當發送失敗的調用次數達到一定閾值，如system busy、io滿載等則自動降級，并使用進行異步機制探測恢復的情況
方案描述：
浩鯨云計算科技股份有限公司 版權所有 2003-2023
蘇ICP備10224443號-6 蘇公網安備 32011402011374號