Sentinel 如何經過勻速請求和冷啓動來保障服務的穩定性

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

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

本期將經過 Sentinel 的勻速請求和冷啓動的特性，處理消息場景中常常會遇到的消息突刺的狀況，經過「削峯填谷」，來打造服務的穩定性。

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

1、需求場景描述

在 RocketMQ 中，當消費者去消費消息的時候，不管是經過 pull 的方式仍是 push 的方式，均可能會出現大批量的消息突刺。若是此時要處理全部消息，極可能會致使系統負載太高，影響穩定性。但其實可能後面幾秒以內都沒有消息投遞，若直接把多餘的消息丟掉則沒有充分利用系統處理消息的能力。

咱們能夠看到消息突刺每每都是瞬時的、不規律的，其後一段時間系統每每都會有空閒資源。咱們但願把紅色的那部分消息平攤到後面空閒時去處理，這樣既能夠保證系統負載處在一個穩定的水位，又能夠儘量地處理更多消息，這時候咱們能夠經過 Sentinel勻速請求的特性 ，來爲 RocketMQ 削峯填谷，保駕護航。

2、Apache RocketMQ 一鍵接入 Sentinel

一、實時監控：

Sentinel 提供 API 用於獲取實時的監控信息，使用時能夠添加如下依賴：

API 接入文檔：

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

爲了便於使用，Sentinel 還提供了一個控制檯（Dashboard）用於配置規則、查看監控、機器發現等功能。咱們只須要按照 Sentinel 控制檯文檔 啓動控制檯，而後給對應的應用程序添加相應參數並啓動便可（注意客戶端須要添加上面的 transport 依賴）。

控制檯文檔：

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

這樣在啓動 Consumer 示例之後，就能夠在 Sentinel 控制檯中找到咱們的應用了。能夠很方便地在控制檯中配置限流規則：

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

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

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

二、一鍵接入

在結合 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 條消息，其他的所有被拒絕，即便後面的時間系統資源充足多餘的請求也沒法被處理，於是浪費了許多空閒資源。

3、Sentinel 基於 Apache RocketMQ 的最佳實踐

一、勻速器

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

勻速器Demo 示例：

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

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

二、冷啓動

除了勻速器，另外一種在面對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，但願對開發者在進行限流產品的技術選型時有所裨益。