快手基於 RocketMQ 的在線消息系統建設實踐

原創

2021-03-22 18:35

發送成功

成功

刷盤超時

Slave 超時

Slave 不可用

發送失敗

具體錯誤碼"}}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"生產者只對這些結果進行打點，不判斷是否正常，具體到監控（或者演練）場景可以配置不同的報警規則。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"消費者收到了消息會通過 TCP 旁路 ACK 生產者，生產者這邊會做分佈式對賬，將對賬結果打點："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"收到消息"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"消息丟失（或超時未收到消息）"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"重複收到消息"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"消息生成到最終消費的時間差"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"ACK 生產者失敗（由消費者打點）"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"同樣監控程序只負責打點，報警規則可另外配置。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"這套機制也可以用於分佈式性能壓測和故障演練"},{"type":"text","text":"。在做壓測的時候，每個消息都 ACK 的話，對生產者的內存壓力很大，因爲它發出去的消息，需要在內存中保留一段時間（直到到達這個消息的對賬時間），這段時間消費者 ACK 或者重複 ACK 都需要記錄。所以我們實現了按比例抽樣對賬的功能，開啓以後只有需要對賬的消息纔會在內存中保留一段時間。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"順便說一下，我們做壓測時，合格的標準是異步生產不失敗、消費不延遲、每一個消息都不丟失。這樣做是爲了保證壓測時能給出更加準確的，可供線上系統參考的性能數字，而不是製造理想條件，追求一個大的數字。比如異步生產比同步生產更脆弱（壓測 Client 如果同步生產，Broker 抖動的時候，同步 Client 會被堵塞導致發送速度降低，於是降低了 Broker 壓力，消息發送不容易失敗，但是會看到發送速率在波動），更貼近生產環境的實際情況，我們就選擇異步生產來評估。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"性能優化"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"Broker 默認的參數在我們的場景下（SSD、同步複製、異步刷盤）不是最優的，有的參數也許在大多數場景下都不是最優的。我們列出一些重要的參數，供大家參考："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"embedcomp","attrs":{"type":"table","data":{"content":"

參數	默認值	說明
flushCommitLogTimed	False	默認值不合理，異步刷盤這個參數應該設置成 true，導致頻繁刷盤，對性能影響極大。
deleteWhen	04	幾點刪除過期文件的時間，刪除文件時有很多磁盤讀，這個默認值是合理的，有條件的話還是建議低峯刪除。
sendMessageThreadPoolNums	1	處理生產消息的線程數，這個線程乾的事情很多，建議設置爲 2～4，但太多也沒有什麼用。因爲最終寫 commit log 的時候只有一個線程能拿到鎖。
useReentrantLockWhenPutMessage	False	如果前一個參數設置比較大，這個最好設置爲 true，避免高負載下自旋鎖空轉消耗 CPU。
sendThreadPoolQueueCapacity	10000	處理生產消息的隊列大小，默認值可能有點小，比如 5 萬 TPS（異步發送）的情況下，卡 200ms 就會爆。設置比較小的數字可能是擔心有大量大消息撐爆內存（比如 100K 的話， 1 萬個的消息大概佔用 1G 內存，也還好），具體可以自己算，如果都是小消息，可以把這個數字改大。可以修改 Broker 參數限制 Client 發送大消息。
brokerFastFailureEnable	True	Broker 端快速失敗（限流），和下面兩個參數配合。這個機制可能有爭議，client 設置了超時時間，如果 client 還願意等，並且 sendThreadPoolQueue 還沒有滿，不應該失敗，sendThreadPoolQueue 滿了自然會拒絕新的請求。但如果 Client 設置的超時時間很短，沒有這個機制可能導致消息重複。可以自行決定是否開啓。理想情況下，能根據 Client 設置的超時時間來清理隊列是最好的。
waitTimeMillsInSendQueue	200	200ms 很容易導致發送失敗，建議改大，比如 1000ms。
osPageCacheBusyTimeOutMills	1000	Page cache 超時時間，如果內存比較多，比如 32G 以上，建議改大點。"}}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"總結"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"得益於簡單、幾乎 0 依賴的部署模式，使得我們部署小集羣的成本非常低；不對社區版本進行魔改，保證我們可以及時升級；統一 SDK 入口方便集羣維護和功能升級；通過複合小集羣+自動負載均衡實現多機房多活；充分利用 RocketMQ 的功能，比如事務消息、延遲消息（增強）來滿足業務的多樣性需求；通過自動的分佈式對賬，對每一個 Broker 以及我們的 SDK 進行正確性監控。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"本文也進行了一些性能參數的分享，但寫的比較簡單，基本只說了怎麼調，但沒能細說爲什麼，以後我們會另寫文章詳述。目前 RocketMQ 已經應用在公司在大多數業務線，期待將來會有更好的發展！"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"作者介紹："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"黃理，10 多年軟件開發和架構經驗，熱衷於代碼和性能優化，開發和參與過多個開源項目。曾在淘寶任業務架構師多年，當前在快手負責在線消息系統建設工作。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"本文轉載自：阿里巴巴中間件（ID：Aliware_2018）"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"原文鏈接："},{"type":"link","attrs":{"href":"https:\/\/mp.weixin.qq.com\/s\/ljSktiZYh_5W93m3yB4M-g","title":"xxx","type":null},"content":[{"type":"text","text":"快手基於 RocketMQ 的在線消息系統建設實踐"}]}]}]}