文 / Miro-得物技術

目錄：
一、為什麼要做資源均衡調度
二、為什麼要做自動化資源均衡調度
三、如何合理選擇遷移節點
四、如何保障遷移過程中可靠性
    1. 添加從節點
    2. 檢查同步數據正常
    3. 執行主從切換
    4. 檢查主從切換正常
    5. 刪除待遷移節點
    6. 消息通知
五、遷移任務管理展示
六、總結

一、為什麼要做資源均衡調度得物

Redis 管理平台目前管理着幾百個集羣、數萬個 Redis-server 節點、幾千台 server 宿主機，而且通過精細化運維管理，目前 Redis-server 宿主機平均內存使用率和內存分配率均達到一個合理且較高的水位，資源管理處於業內第一梯隊，使用最低的成本做到最大的支撐業務緩存需求。

同時，隨着業務使用量的持續增長，單台宿主機上的內存使用率越來越高，為了保證宿主機上所有節點的業務日常增長需求或者突發的業務內存上漲，以便能夠做到秒級快速垂直擴容，以及添加節點、RDB 離線分析等功能需要的資源，單台宿主機的內存使用率都需要動態的控制在一個合理水位線以下，於是，Redis 管理平台會每天定期自動巡檢所有宿主機內存使用率，對於超過合理閾值的宿主機，會選擇一部分 server節點進行打散，遷移到其他宿主機上。

二、為什麼要做自動化資源均衡調度

在 Redis 系統承接業務後，資源使用量快速增長的初期，逐步出現需要進行資源均衡調度的需求，一開始也是 DBA 手動進行節點遷移。為此還特意開發了一個批量選擇節點進行添加從節點、主從切換、節點下線等批量操作功能。然而即使提供了批量操作功能，手動遷移依然需要 DBA 每天投入相當多的精力來進行資源均衡調度，並且存在穩定性風險。

• 首先，需要 DBA 每天都要關注資源整體的使用情況，一旦出現內存使用率較高的機器，就需要進行打散遷移；
• 隨着機器增多、Redis 服務承接的業務快速增長，每天需要打散的機器越來越多，每次需要打散的節點也越來越多，操作遷移花費的時間也越來越多，到後期差不多每週需要投入 2 人天的工時專門進行資源打散；
• 另外，由於人工操作，選擇大量節點同時進行，難免出現漏操作、重複操作、誤操作等情況，增加了資源遷移給集羣穩定性帶來的風險。

於是，Redis 管理平台設計並開發了無人值守資源均衡調度功能，為了儘量降低遷移過程對業務的影響，默認選擇在凌晨5點業務低峯期進行執行，並且自動巡檢、選擇機器、選擇節點、節點遷移等整個資源均衡調度過程均是每天定點自動完成。遷移過程中怎麼合理的選擇一部分節點還是無腦隨機選擇幾個節點，怎麼保證遷移的穩定性是核心能力？

三、如何合理選擇遷移節點

遷移過程的第一步是需要挑選內存使用率超過預設閾值的宿主機機器，並且挑選機器上部分節點進行遷移，使得這些節點遷移後，該宿主機內存使用率下降到合理水位線以下。

那麼選擇節點是不是無腦隨機挑選一部分節點呢，理論上來説當然也沒有什麼問題，但是為了保證遷移過程對業務影響最小、且使得遷移後，所有集羣節點分佈更均勻，我們還是設計了一系列最優選擇規則，選擇最優節點原則包含：

• 優先節點數量多的實例節點，這樣可以在資源均衡的同時，可以使得同一集羣節點也更均衡，同一集羣節點儘可能的分散到不同的機器上。
• 優先實例等級為非 P0 的實例。
• 優先從節點：從節點遷移對大部分業務（同城雙活業務除外）都沒有任何影響。
• 優先節點規格中等規格（1-4G）實例、再選擇 1G-5G 規格實例、最後選擇其他規格的節點；如果選擇的節點太小，為了滿足條件需要遷移更多的節點，如果選擇的節點規格太大，遷移時加載數據時間更長，另外如果同時剛好對應節點的寫流量比較大，加載數據時從節點連接池緩衝區寫滿會導致同步過程失敗，也就是大規格節點遷移過程失敗的概率更大。
• 不同時選擇同一個集羣同一個分組的節點。

選擇節點算法流程圖如下：

• 節點列表排序，對機器上所有 server 節點按照所屬同一集羣的數量和內存大小排序，從同一集羣節點數量多的集羣開始選擇滿足條件的合適節點；
• 前兩輪選擇中，均選擇非 P0 集羣節點，第一輪選擇節點規格為 1-4G 的節點、第二輪選擇節點規格為 1-5G 的節點；
• 第三輪選擇則包含所有集羣（即也包含 P0 集羣）、節點規格為 1-4G 的節點；
• 最後如果還不滿足需要遷移的節點內存，則按照遍歷順序直接選擇任意節點；每輪選擇過程中，均避免同一集羣同一個分組的節點同時選中。

節點選擇完成後，按集羣 ID 生成遷移任務，遷移任務默認每天凌晨 5 點定時執行，生成的遷移任務會同步發送給各業務域對應 DBA 確認，確認過程中可選擇取消或者修改執行時間。

四、如何保障遷移過程中可靠性

等待執行的遷移任務到達設置的定時執行時間後，開始執行自動遷移流程，整個遷移過程包含添加從節點、主從切換、刪除遷移節點等步驟。

遷移任務執行過程流程圖如下所示：

遷移過程中，為了節點遷移不出現異常，每一步執行都進行多維度嚴格的校驗，確保正常才進行下一步操作，下面詳細介紹遷移過程中每一步操作是如何進行校驗保障可靠性的。

添加從節點

到達某個節點的遷移任務執行時間時，第一步是先添加一個從節點來替換準備遷移的原有節點。

一個緩存實例或節點的部署非常複雜，涉及機器選擇、端口分配、配置文件準備、節點安裝與啓動、槽位分配、主從關係設置、SLB 分配與綁定、以及相關組件的部署等一系列動作，目前 Redis 集羣部署、以及單個節點部署都是自動化部署完成。

為了保證遷移過程中節點的高可用，遷移節點自動化部署過程中包含一些必要的部署規則：

• 新分配節點保持與待遷移的原節點在同一個可用區
• 新分配節點不能分配到待遷移的原有節點同一台宿主機上
• 新分配節點分配的宿主機保持在原節點所在同一資源分組
• 新分配節點的規格、版本與待遷移的原節點保持一致
• 避免同一個集羣實例的多個 Redis-Server、Redis-Proxy 節點部署在相同的宿主機上
• 每個宿主機最多分配總內存容量的 90%，預留一定的數據增長空間
• 根據宿主機可用內存，優先推薦剩餘可用內存多的機器

檢查同步數據正常

完成添加從節點動作後，需要檢查新節點是否分配正常、以及新節點同步數據是否正常，只有新節點同步數據正常才能可靠的執行主從切換或者刪除原節點。

在 Redis 中，可以通過 info replication 命令查看主從節點同步狀態，在自動遷移過程中，會分別從主節點和從節點的視角多維度綜合判斷當前主從同步是否正常。

一個狀態正常的主從同步，從主節點視角通過 info replication 命令查看顯示如下所示：

從主節點視角，自動遷移過程中，會判斷連上主節點的從節點中是否包含了新增的從節點、並且新增從節點的同步狀態 state=online 且 offset != 0

一個狀態正常的主從同步，在從節點視角通過 info replication 命令查看顯示如下所示：

在新增的從節點視角，自動遷移過程中，會判斷節點角色為 slave、且當前同步的主節點信息與節點所在分組的主節點信息（ip 和 port）一致、並且與主節點的同步狀態 master_link_status:up 且 master_repl_offset != 0

而且，自動遷移過程中，第一次檢查新增節點主從同步成功後，會間隔一分鐘後，再次檢查一遍，確保節點的同步正常。

執行主從切換

如果待遷移的原節點角色是從節點，新增從節點成功後，直接進入刪除待遷移節點流程即可。但是，如果待遷移的原節點角色是主節點，則需要先對新增的節點執行主從切換，將新增的從節點選舉為新主節點後，才能刪除待遷移原節點。

獲取新增從節點，發起主從切換選舉操作，也即對從節點執行 slaveof no one 命令，將從節點選舉為新主節點，對分組中原主節點和原其他從節點執行 slaveof 命令，設置為新主節點的從節點，同步新主節點。

檢查主從切換正常

檢查主從切換是否正常，與前面介紹的檢查同步數據是否正常邏輯基本一樣。分別從新主節點和所有從節點的視角，通過 info replication 命令查看主從節點同步狀態。

從主節點視角，查看新主節點角色是否為 master，包含的從節點數量是否不為 0，所有從節點的同步狀態是否state=online 且 offset != 0

逐個檢查每個從節點，通過從節點視角，判斷節點角色為 slave、且當前同步的主節點與新主節點信息（ip 和 port）一致、並且與主節點的同步狀態 master_link_status:up 且 master_repl_offset != 0

只有通過主從節點視角分別確認都正常，才認為整個遷移過程是正常的。

刪除待遷移節點

待主從切換完成（或者待遷移節點本來就是一個從節點）且同步狀態檢查正常後，進入刪除節點流程，下線待遷移節點。

下線節點前，仍然會二次確認做一些必要的檢查，包括分組的主節點是否正常、從節點同步是否正常等。

調用節點下線邏輯對待遷移節點進行下線操作，下線節點操作本身也會有一些必要檢查，比如如果有業務連接訪問 Proxy 和節點有數據的情況下，不允許刪除主節點。

消息通知

如果節點遷移因為宿主機不足導致新節點分配失敗等原因失敗後，會發送一個消息通知，方便DBA瞭解遷移結果情況。

五、遷移任務管理展示

等待遷移和遷移中的任務管理展示，等待遷移的任務可以取消、修改執行時間、或者立即執行。

遷移任務可以查看生成的待遷移節點詳情列表。

查看已完成的歷史任務

六、總結

目前，得物 Redis 管理平台管理着幾千台 Redis-server 宿主機，通過每日智能自動化均衡資源遷移，宿主機內存資源平均使用率和內存分配率均達到一個合理且較高的水位，所有宿主機內存使用率都動態控制在設置的閾值以下，保持宿主機內存資源處於一個高使用率水平的同時，給每台宿主機也預留有充足的內存餘量，支持我們的業務突發的內存增長從而快速垂直擴容。

自動遷移過程中會優先選擇同一集羣在同一宿主機上節點數較多的節點，新節點分配挑選機器過程中會盡量分散同一集羣的節點，有些集羣由於早期資源較小可能分配的機器比較集中，隨着自動遷移過程，也會逐步打散到儘可能多的不同機器上，減少機器故障時對單個集羣的影響。

節點自動遷移功能也可以用於機器下線中，提高機器下線效率。機器下線前也需要遷移上面所有節點，Redis 管理平台也提供了運維選中節點後，生成遷移任務功能。

Redis 管理平台一直在優化和完善系統的自動化運維水平，提高自動化運維程度，儘量減少運維工作的人力投入，除了本文中提到的自動化資源均衡調度外，已經支持或者在規劃開發中的自動化運維操作還包括有自動部署集羣、節點自動垂直擴容、宿主機宕機自動啓動節點、宿主機宕機自動恢復節點主可用區等，敬請期待後續更詳細的介紹。