摘要：?這是圍繞 Sentinel 的使用場景、技術對比和實現、開發者實踐等維度推出的系列文章的第二篇。 第一篇：Dubbo 的流量防衛兵 | Sentinel如何通過限流實現服務的高可用性 - 鏈接 本期將通過 Sentinel 的勻速請求和冷啟動的特性，處理消息場景中經常會遇到的消息突刺的情況，通過“削峰填谷”，來打造服務的穩定性。

這是圍繞 Sentinel 的使用場景、技術對比和實現、開發者實踐等維度推出的系列文章的第二篇。

第一篇：Dubbo 的流量防衛兵 | Sentinel如何通過限流實現服務的高可用性 -?鏈接

本期將通過 Sentinel 的勻速請求和冷啟動的特性，處理消息場景中經常會遇到的消息突刺的情況，通過“削峰填谷”，來打造服務的穩定性。

? 8月26日，Aliware Open Source 將首次在成都舉辦 Apache Dubbo 的meetup活動，Dubbo 、Sentinel和 Nacos 的小哥哥和小姐姐都會在現場進行技術分享，歡迎成都的朋友報名參加我們的活動喔，公眾號后臺發送“成都meetup”，獲取報名鏈接。

一、需求場景描述

在 RocketMQ 中，當消費者去消費消息的時候，無論是通過 pull 的方式還是 push 的方式，都可能會出現大批量的消息突刺。如果此時要處理所有消息，很可能會導致系統負載過高，影響穩定性。但其實可能后面幾秒之內都沒有消息投遞，若直接把多余的消息丟掉則沒有充分利用系統處理消息的能力。

我們可以看到消息突刺往往都是瞬時的、不規律的，其后一段時間系統往往都會有空閑資源。我們希望把紅色的那部分消息平攤到后面空閑時去處理，這樣既可以保證系統負載處在一個穩定的水位，又可以盡可能地處理更多消息，這時候我們可以通過 Sentinel勻速請求的特性 ，來為 RocketMQ 削峰填谷，保駕護航。

二、Apache RocketMQ 一鍵接入 Sentinel

1、實時監控：

Sentinel 提供 API 用于獲取實時的監控信息，使用時可以添加以下依賴：

API 接入文檔：

https://github.com/alibaba/Sentinel/wiki/實時監控

為了便于使用，Sentinel 還提供了一個控制臺（Dashboard）用于配置規則、查看監控、機器發現等功能。我們只需要按照 Sentinel 控制臺文檔 啟動控制臺，然后給對應的應用程序添加相應參數并啟動即可（注意客戶端需要添加上面的 transport 依賴）。

控制臺文檔：

https://github.com/alibaba/Sentinel/wiki/控制臺

這樣在啟動 Consumer 示例以后，就可以在 Sentinel 控制臺中找到我們的應用了。可以很方便地在控制臺中配置限流規則：

或者查看實時監控（這里對應勻速模式，圖中標注的 b_qps 代表每秒被 block 的數目，下同）：

對比普通限流模式下的監控圖線：

可以看到普通限流模式下每次流量突刺都只能在一瞬間處理少量消息，其它請求都會立即被限掉。而勻速模式下可以把突刺的部分平滑到后面的時間中處理，每次消息量激增時都可以處理更多的消息。兩種模式對比說明勻速模式下消息處理能力得到了更好的利用。

2、一鍵接入

在結合 RocketMQ Client 使用 Sentinel 時，用戶首先需要引入 sentinel-core 依賴，由于 RocketMQ Client 未提供相應攔截機制，而且每次收到都可能是批量的消息，因此用戶在處理消息時需要手動進行埋點。在 RocketMQ 的場景中，用戶可以根據不同的 group 和不同的 topic 分別設置限流規則，開啟勻速器模式，并在處理消息時埋點，即可以以固定的速率處理消息。然后在處理消息的時候手動埋點（以 pull consumer 為例）：

PullConsumerDemo地址：
https://github.com/alibaba/Sentinel/blob/master/sentinel-demo/sentinel-demo-rocketmq/src/main/java/com/alibaba/csp/sentinel/demo/rocketmq/PullConsumerDemo.java

下面我們來看一下具體的運行效果。首先根據 RocketMQ 的文檔來在本地啟動 RocketMQ，然后向對應 group 的對應 topic 發送 1000 條消息，然后按上面的例子配限流規則，啟動消費者應用。可以看到消息消費的速率是勻速的，大約每 200 ms 消費一條消息。同時不斷有排隊的處理任務完成，超出等待時長的處理請求直接被拒絕。注意在處理請求被拒絕的時候，需要根據需求決定是否需要重新消費消息。

如果不開啟勻速模式，只是普通的限流模式，則只會同時處理 5 條消息，其余的全部被拒絕，即使后面的時間系統資源充足多余的請求也無法被處理，因而浪費了許多空閑資源。

三、Sentinel 基于 Apache RocketMQ 的最佳實踐

1、勻速器

借助 Sentinel 勻速請求的特性，可以把突然到來的大量請求以勻速的形式均攤，以固定的間隔時間讓請求通過，以穩定的速度逐步處理這些請求，從而避免流量突刺造成系統負載過高。同時堆積的請求將會排隊，逐步進行處理；當請求排隊預計超過最大超時時長的時候則直接拒絕，而不是拒絕全部請求。

勻速器Demo 示例：

https://github.com/alibaba/Sentinel/wikii/限流---勻速器

比如在 RocketMQ 的場景下配置了勻速模式下請求 QPS 為 5，則會每 200 ms 處理一條消息，多余的處理任務將排隊；同時設置了超時時間為 5s，預計排隊時長超過 5s 的處理任務將會直接被拒絕。示意圖如下：

2、冷啟動

除了勻速器，另一種在面對RocketMQ 場景下流量突增時來保障系統穩定性的的方式是冷啟動。該方式主要用于系統長期處于低水位的情況下，當流量突然增加時，直接把系統拉升到高水位可能瞬間把系統壓垮。通過"冷啟動"，讓通過的流量緩慢增加，在一定時間內逐漸增加到閾值上限，給冷系統一個預熱的時間，避免冷系統被壓垮的情況。具體的例子參見 WarmUpFlowDemo。

勻速器Demo 示例：
https://github.com/alibaba/Sentinel/blob/master/sentinel-demo/sentinel-demo-basic/src/main/java/com/alibaba/csp/sentinel/demo/flow/WarmUpFlowDemo.java

通常冷啟動的過程系統允許通過的 QPS 曲線如下圖所示：

通過前兩期的分享，我們已經理解了 Sentinel 在 Dubbo和RocketMQ 這兩個體系中的使用場景和實踐方法，在下一周的第三期中，我們將對比Sentinel和傳統的限流產品Hystrix，希望對開發者在進行限流產品的技術選型時有所裨益。

原文鏈接

本文為云棲社區原創內容，未經允許不得轉載。