一、背景介紹

Redis 集群服務(wù)在互聯(lián)網(wǎng)公司被廣泛使用，眾所周知服務(wù)集群化可以突破單節(jié)點(diǎn)的能力瓶頸，帶來(lái)規(guī)模、可用性、擴(kuò)展性等多方面的收益。在實(shí)際使用 Redis 集群的過(guò)程中，發(fā)現(xiàn)在進(jìn)行涉及集群數(shù)據(jù)遷移的水平擴(kuò)縮容操作時(shí)，業(yè)務(wù)側(cè)多次反饋 Redis 請(qǐng)求的時(shí)延升高問(wèn)題，甚至發(fā)生過(guò)擴(kuò)容操作導(dǎo)致集群節(jié)點(diǎn)下線的可用性故障，并進(jìn)一步引發(fā)遷移流程中斷、節(jié)點(diǎn)間數(shù)據(jù)腦裂等一系列嚴(yán)重影響，給運(yùn)維同事帶來(lái)極大困擾，嚴(yán)重影響線上服務(wù)的穩(wěn)定。

二、問(wèn)題分析

2.1 原生遷移介紹

Redis 集群功能采用無(wú)中心架構(gòu)設(shè)計(jì)，集群中各個(gè)節(jié)點(diǎn)都維護(hù)各自視角的集群拓?fù)洳⒈４孀杂械姆制瑪?shù)據(jù)，集群節(jié)點(diǎn)間通過(guò) gossip 協(xié)議進(jìn)行信息協(xié)調(diào)和變更通知。具體來(lái)說(shuō) Redis 集群數(shù)據(jù)管理上采用虛擬哈希槽分區(qū)機(jī)制，將數(shù)據(jù)的鍵通過(guò)哈希函數(shù)映射到 0~16383 整數(shù)槽內(nèi)，此處的槽位在 Redis 集群設(shè)計(jì)中被稱為 slot。這樣實(shí)際上每一個(gè)節(jié)點(diǎn)只需要負(fù)責(zé)維護(hù)一部分 slot 所映射的鍵值數(shù)據(jù)，slot 就成為 Redis 集群管理數(shù)據(jù)的基本單位，集群擴(kuò)縮容本質(zhì)上就是 slot 信息和 slot 對(duì)應(yīng)數(shù)據(jù)數(shù)據(jù)在節(jié)點(diǎn)之間的轉(zhuǎn)移。Redis 集群水平擴(kuò)展的能力就是基于 slot 維度進(jìn)行實(shí)現(xiàn)，具體流程如下圖所示。

上圖所示的遷移步驟中，步驟1-2是對(duì)待遷移 slot 進(jìn)行狀態(tài)標(biāo)記，方便滿足遷移過(guò)程中數(shù)據(jù)訪問(wèn)，步驟3-4是遷移的核心步驟，這兩個(gè)步驟操作會(huì)在步驟5調(diào)度下持續(xù)不斷進(jìn)行，直到待遷移 slot 的鍵值數(shù)據(jù)完全遷移到了目標(biāo)節(jié)點(diǎn)，步驟6會(huì)在數(shù)據(jù)轉(zhuǎn)移完成后進(jìn)行，主要是發(fā)起集群廣播消息更新集群內(nèi)節(jié)點(diǎn) slot 拓?fù)洹?/p>

由于正常的遷移時(shí)一個(gè)持續(xù)的處理過(guò)程，不可避免地會(huì)出現(xiàn)正在遷移 slot 數(shù)據(jù)分布于遷移兩端地“分裂”狀態(tài)，這種狀態(tài)會(huì)隨著 slot 遷移的流程進(jìn)行而持續(xù)存在。為了保證遷移期間正在遷移的 slot 數(shù)據(jù)能夠正常讀寫(xiě)，Redis 集群實(shí)現(xiàn)了下圖所示的一種 ask-move 機(jī)制，如果請(qǐng)求訪問(wèn)正在遷移的 slot 數(shù)據(jù)，請(qǐng)求首先會(huì)按照集群拓?fù)湔ＴL問(wèn)到遷移的源節(jié)點(diǎn)，如果在源節(jié)點(diǎn)查詢到數(shù)據(jù)則正常處理響應(yīng)請(qǐng)求；如果在源節(jié)點(diǎn)沒(méi)有找到請(qǐng)求所需數(shù)據(jù)，則會(huì)給客戶端回復(fù) ASK {ip}:{port}  消息回包。

Redis 集群智能客戶端收到該回包后會(huì)按照包內(nèi)節(jié)點(diǎn)信息找到新節(jié)點(diǎn)重試命令，但是由于此時(shí)目標(biāo)節(jié)點(diǎn)還沒(méi)有遷移中 slot 的所屬權(quán)，所以在重試具體命令之前智能客戶端會(huì)首先向目的節(jié)點(diǎn)發(fā)送一個(gè) asking 命令，以此保證接下來(lái)訪問(wèn)遷移中 slot 數(shù)據(jù)的請(qǐng)求能被接受處理。由于原生遷移時(shí)按照 key 粒度進(jìn)行的，一個(gè) key 的數(shù)據(jù)要不存在源節(jié)點(diǎn)，要不存在目的節(jié)點(diǎn)，所以Redis 集群可以通過(guò)實(shí)現(xiàn)上述 ask-move 機(jī)制，保證遷移期間數(shù)據(jù)訪問(wèn)的一致性和完整性。

2.2 遷移問(wèn)題分析

（1）時(shí)延分析

根據(jù)上述原生 Redis 集群遷移操作步驟的了解，可以總結(jié)出原生遷移功能按照 key 粒度進(jìn)行的，即不斷掃描源節(jié)點(diǎn)上正在遷移的 slot 數(shù)據(jù)并發(fā)送數(shù)據(jù)給目的節(jié)點(diǎn)，這是集群數(shù)據(jù)遷移的核心邏輯。微觀來(lái)說(shuō)遷移單個(gè) key 數(shù)據(jù)對(duì)于服務(wù)端來(lái)說(shuō)包含以下操作：

• 序列化待遷移鍵值對(duì)數(shù)據(jù)；
• 通過(guò)網(wǎng)絡(luò)連接發(fā)送序列化的數(shù)據(jù)包；
• 等待回復(fù)（目標(biāo)端接收完包并加載成功才會(huì)返回）；
• 刪除本地殘留的副本，釋放內(nèi)存。

上述操作中涉及多個(gè)耗費(fèi)線程處理時(shí)長(zhǎng)的操作，首先序列化數(shù)據(jù)是非常耗費(fèi) CPU 時(shí)間的操作，如果遇到待遷移 key 比較大線程占用時(shí)長(zhǎng)也會(huì)隨之惡化，這對(duì)于單工作線程的 Redis 服務(wù)來(lái)說(shuō)是不可接受的，進(jìn)一步地網(wǎng)絡(luò)發(fā)送數(shù)據(jù)到目標(biāo)節(jié)點(diǎn)時(shí)會(huì)同步等待結(jié)果返回，而遷移目的端又會(huì)在進(jìn)行數(shù)據(jù)反序列化和入庫(kù)操作后才會(huì)向源節(jié)點(diǎn)進(jìn)行結(jié)果返回。需要注意的是在遷移期間會(huì)不斷循環(huán)進(jìn)行以上步驟的操作，而且這些步驟是在工作線程上連續(xù)處理的，期間無(wú)法對(duì)正常請(qǐng)求進(jìn)行處理，所以此處就會(huì)導(dǎo)致服務(wù)響應(yīng)時(shí)延持續(xù)突刺，這一點(diǎn)可以通過(guò) slowlog 的監(jiān)控?cái)?shù)據(jù)得到驗(yàn)證，遷移期間會(huì)在 slowlog 抓取到大量的 migrate 和 restore 命令。

（2）ask-move 開(kāi)銷(xiāo)

正常情況下每個(gè)正在遷移的 slot 數(shù)據(jù)都會(huì)一段時(shí)間內(nèi)存在數(shù)據(jù)分布在遷移的兩端的情況，遷移期間該 slot 數(shù)據(jù)訪問(wèn)請(qǐng)求可以通過(guò) ask-move 機(jī)制來(lái)保證數(shù)據(jù)一致性，但是不難看出這樣的機(jī)制會(huì)導(dǎo)致單個(gè)請(qǐng)求網(wǎng)絡(luò)訪問(wèn)次數(shù)出現(xiàn)成倍的增加，對(duì)客戶端也存在一定的開(kāi)銷(xiāo)壓力。另外，對(duì)于可能存在的用戶采用 Lua 或者 Pipline 這種需要對(duì)單個(gè) slot 內(nèi)多 key 連續(xù)訪問(wèn)的場(chǎng)景，目前大部分集群智能客戶端支持有限，可能會(huì)遇到遷移期間相關(guān)請(qǐng)求不能正常執(zhí)行的報(bào)錯(cuò)。另外需要說(shuō)明的是，由于 ask-move 機(jī)制的只在遷移兩端的主節(jié)點(diǎn)上能觸發(fā)，所以遷移期間從節(jié)點(diǎn)是不能保證數(shù)據(jù)請(qǐng)求結(jié)果一致性的，這對(duì)于采用讀寫(xiě)分離方式訪問(wèn)集群數(shù)據(jù)的用戶也非常不友好。

（3）拓?fù)渥兏_(kāi)銷(xiāo)

為了降低遷移期間數(shù)據(jù) ask-move 的機(jī)制對(duì)請(qǐng)求的影響，正常情況下原生遷移每次只會(huì)操作一個(gè) slot 遷移，這就導(dǎo)致對(duì)每一個(gè)遷移完成的 slot 都會(huì)觸發(fā)集群內(nèi)節(jié)點(diǎn)進(jìn)行一次拓?fù)涓?，而每次集群拓?fù)涞母露紩?huì)觸發(fā)正在執(zhí)行指令的業(yè)務(wù)客戶端幾乎同時(shí)發(fā)送請(qǐng)求尋求更新集群拓?fù)洌負(fù)渌⑿抡?qǐng)求結(jié)果計(jì)算開(kāi)銷(xiāo)高、結(jié)果集大，大大增加了節(jié)點(diǎn)的處理開(kāi)銷(xiāo)，也會(huì)造成正常服務(wù)請(qǐng)求時(shí)延的突刺，尤其對(duì)于連接數(shù)較大、集群節(jié)點(diǎn)多的集群，集中的拓?fù)渌⑿抡?qǐng)求很容易造成節(jié)點(diǎn)計(jì)算資源緊張和網(wǎng)絡(luò)擁塞，容易觸發(fā)出各種服務(wù)異常告警。

（4）遷移無(wú)高可用

原生的遷移的 slot 標(biāo)記狀態(tài)只存在于遷移雙端的主節(jié)點(diǎn)，其對(duì)應(yīng)的從節(jié)點(diǎn)并不知道遷移狀態(tài)，這也就導(dǎo)致一旦在遷移期間發(fā)生節(jié)點(diǎn)的 failover，遷移流程將會(huì)中斷和出現(xiàn) slot 狀態(tài)殘留，也將進(jìn)一步導(dǎo)致遷移 slot 數(shù)據(jù)的訪問(wèn)請(qǐng)求無(wú)法正常觸發(fā) ask-move 機(jī)制而發(fā)生異常。例如遷移源節(jié)點(diǎn)異常，那么其 slave 節(jié)點(diǎn) failover 上線，由于新主節(jié)點(diǎn)并不能同步到遷移狀態(tài)信息，那么對(duì)于遷移中 slot 的請(qǐng)求就不能觸發(fā) ask 回復(fù)，如果是一個(gè)對(duì)已經(jīng)遷移至目標(biāo)節(jié)點(diǎn)的數(shù)據(jù)的寫(xiě)請(qǐng)求，新主節(jié)點(diǎn)會(huì)直接在本節(jié)點(diǎn)新增 key，導(dǎo)致數(shù)據(jù)出現(xiàn)腦裂，類(lèi)似地如果處理的是已經(jīng)遷移數(shù)據(jù)的讀取請(qǐng)求也無(wú)法保證返回正確結(jié)果。

三、優(yōu)化方案

3.1 優(yōu)化方向思考

通過(guò)原生數(shù)據(jù)遷移機(jī)制分析，可以發(fā)現(xiàn)由于遷移操作涉及大量的同步阻塞操作會(huì)長(zhǎng)時(shí)間占用工作線程，以及頻繁的拓?fù)渌⑿虏僮?，?huì)導(dǎo)致請(qǐng)求時(shí)延不斷出現(xiàn)上升。那么是否可以考慮將阻塞工作線程的同步操作改造成為異步線程處理呢？這樣改造有非常大的風(fēng)險(xiǎn)，因?yàn)樵w移之所以能夠保證遷移期間數(shù)據(jù)訪問(wèn)的正確性，正是這些同步接口進(jìn)行了一致性保證，如果改為異步操作將需要引入并發(fā)控制，還要考慮遷移數(shù)據(jù)請(qǐng)求與 slave 節(jié)點(diǎn)的同步協(xié)調(diào)問(wèn)題，此方案也無(wú)法解決拓?fù)渥儎?dòng)開(kāi)銷(xiāo)問(wèn)題。所以 vivo 自研 Redis 放棄了原生按照 key 粒度進(jìn)行遷移的邏輯，結(jié)合線上真實(shí)擴(kuò)容需求，采用了類(lèi)似主從同步的數(shù)據(jù)遷移邏輯，將遷移目標(biāo)節(jié)點(diǎn)偽裝成遷移源節(jié)點(diǎn)的從節(jié)點(diǎn)，通過(guò)主從協(xié)議來(lái)轉(zhuǎn)移數(shù)據(jù)。

3.2 功能實(shí)現(xiàn)原理

Redis 主從同步機(jī)制是指在 Redis 主節(jié)點(diǎn)（Master）和從節(jié)點(diǎn)（Slave）之間進(jìn)行數(shù)據(jù)同步和復(fù)制的過(guò)程，主從同步機(jī)制可以提高 Redis 集群的可用性，避免單點(diǎn)故障和數(shù)據(jù)丟失等問(wèn)題。Redis 目前主從同步有全量同步和部分同步兩種方式，從節(jié)點(diǎn)發(fā)送同步位點(diǎn)給主節(jié)點(diǎn)，如果是首次同步則需要走全量同步邏輯，主節(jié)點(diǎn)通過(guò)發(fā)送 RDB 基礎(chǔ)數(shù)據(jù)文件和傳播增量命令方式將數(shù)據(jù)同步給從節(jié)點(diǎn)；如果不是首次同步，主節(jié)點(diǎn)則會(huì)通過(guò)從節(jié)點(diǎn)同步請(qǐng)求中的位點(diǎn)等信息判斷是否滿足增量同步條件，優(yōu)先進(jìn)行增量同步以控制同步開(kāi)銷(xiāo)。由于主節(jié)點(diǎn)在同步期間也在持續(xù)處理新的命令請(qǐng)求，所以從節(jié)點(diǎn)對(duì)主節(jié)點(diǎn)的數(shù)據(jù)同步是一個(gè)動(dòng)態(tài)追齊的過(guò)程，正常情況下，主節(jié)點(diǎn)會(huì)持續(xù)發(fā)送寫(xiě)命令給從節(jié)點(diǎn)。

基于同步機(jī)制，我們?cè)O(shè)計(jì)實(shí)現(xiàn)了一套如下圖所示的 Redis 集群數(shù)據(jù)遷移的功能。遷移數(shù)據(jù)邏輯主要走的全量同步邏輯，遷移數(shù)據(jù)和同步數(shù)據(jù)最大的區(qū)別在于，正常情況下需要遷移的是源節(jié)點(diǎn)部分 slot 數(shù)據(jù)，目標(biāo)節(jié)點(diǎn)并不需要復(fù)制源節(jié)點(diǎn)的全量數(shù)據(jù)，完全復(fù)用同步機(jī)制會(huì)產(chǎn)生不必要的開(kāi)銷(xiāo)，需要對(duì)主從同步邏輯進(jìn)行修改適配。為了解決該問(wèn)題，我們對(duì)相關(guān)邏輯做了一些針對(duì)性的改造。首先在同步命令交互上，針對(duì)遷移場(chǎng)景增加了遷移節(jié)點(diǎn)間 slot 信息交互，從而讓遷移源節(jié)點(diǎn)獲知需要遷移哪些 slot 到哪個(gè)節(jié)點(diǎn)。另外，我們還對(duì) RDB 文件文件結(jié)構(gòu)按照 slot 順序進(jìn)行了調(diào)整改造，并且將各個(gè) slot 數(shù)據(jù)的文件起始偏移量數(shù)據(jù)作為元數(shù)據(jù)記錄到 RDB 文件尾部固定位置，這樣在進(jìn)行遷移操作的 RDB 傳輸步驟時(shí)就可以方便地索引到 RDB 文件中目標(biāo) slot 數(shù)據(jù)片段。

3.3 改造效果分析

（1）時(shí)延影響小

對(duì)于 slot 遷移操作而言，主要涉及遷移源和目的兩端的開(kāi)銷(xiāo)，對(duì)于基于主從同步機(jī)制實(shí)現(xiàn)的新 slot 遷移，其源節(jié)點(diǎn)主要開(kāi)銷(xiāo)在于生成 RDB 和傳送網(wǎng)絡(luò)包，正常對(duì)于請(qǐng)求時(shí)延影響不大。但是因?yàn)槟康墓?jié)點(diǎn)需要對(duì)較大的 RDB 文件片段數(shù)據(jù)進(jìn)行接收、加載，由于目的節(jié)點(diǎn)遷移時(shí)也需要對(duì)正常服務(wù)請(qǐng)求響應(yīng)，此時(shí)不再能采用類(lèi)似 slave 節(jié)點(diǎn)將所有數(shù)據(jù)收取完以后保存本地文件，然后進(jìn)行阻塞式數(shù)據(jù)加載的方案，所以新 slot 遷移功能對(duì)遷移目的節(jié)點(diǎn)的數(shù)據(jù)加載流程進(jìn)行了針對(duì)性改造，目的節(jié)點(diǎn)會(huì)按照接收到的網(wǎng)絡(luò)包粒度將數(shù)據(jù)按照下圖所示進(jìn)行遞進(jìn)式加載，即 slot 遷移目標(biāo)節(jié)點(diǎn)每接收完一個(gè) RDB 數(shù)據(jù)網(wǎng)絡(luò)包就會(huì)嘗試加載，每次只加載本次網(wǎng)絡(luò)包內(nèi)包含的完整元素，這樣復(fù)合類(lèi)型數(shù)據(jù)就可以按照 field 粒度加載，從而降低多元素大 key 數(shù)據(jù)遷移對(duì)訪問(wèn)時(shí)延的劇烈影響。通過(guò)這樣的設(shè)計(jì)保持原來(lái)單線程簡(jiǎn)潔架構(gòu)的同時(shí)，有效地控制了時(shí)延影響，所有數(shù)據(jù)變更操作都保持在工作線程進(jìn)行，不需要進(jìn)行并發(fā)控制。通過(guò)以上改造，基本消除了遷移大 key 對(duì)遷移目的節(jié)點(diǎn)時(shí)延影響。

（2）數(shù)據(jù)訪問(wèn)穩(wěn)定

新 slot 遷移操作期間，正在遷移的數(shù)據(jù)還是存儲(chǔ)在源節(jié)點(diǎn)上沒(méi)有變，請(qǐng)求繼續(xù)在源節(jié)點(diǎn)上正常處理，用戶側(cè)的請(qǐng)求不會(huì)觸發(fā) ask-move 轉(zhuǎn)發(fā)機(jī)制。這樣用戶就不需要擔(dān)心讀寫(xiě)分離會(huì)出現(xiàn)數(shù)據(jù)不一致現(xiàn)象，在進(jìn)行事務(wù)、pipeline 等方式封裝執(zhí)行命令時(shí)也不會(huì)出現(xiàn)大量請(qǐng)求報(bào)錯(cuò)的問(wèn)題。遷移動(dòng)作一旦完成，殘留在源端的已遷移 slot 數(shù)據(jù)將成為節(jié)點(diǎn)的殘留數(shù)據(jù)，這部分?jǐn)?shù)據(jù)不會(huì)再被訪問(wèn)，對(duì)上述殘留數(shù)據(jù)的清理被設(shè)計(jì)在 serverCron 中逐步進(jìn)行，這樣每一次清理多少數(shù)據(jù)可以參數(shù)化控制，可以根據(jù)需要進(jìn)行個(gè)性化設(shè)置，保證數(shù)據(jù)清理對(duì)正常服務(wù)請(qǐng)求影響完全可控。

（3）拓?fù)渥兏?/strong>

原生的遷移功能為了降低 ask-move 機(jī)制對(duì)正常服務(wù)請(qǐng)求的影響，每次僅會(huì)對(duì)一個(gè) slot 進(jìn)行數(shù)據(jù)遷移，遷移完了會(huì)立即發(fā)起拓?fù)渥兏ㄖ獊?lái)集群節(jié)點(diǎn)轉(zhuǎn)換 slot 的屬主，這就導(dǎo)致拓?fù)渥兓拇螖?shù)隨著遷移 slot 的數(shù)量增加而變多，客戶端也會(huì)在每一次感知到拓?fù)渥兓蟀l(fā)送命令請(qǐng)求進(jìn)行拓?fù)涓?。更新拓?fù)湫畔⒌拿钣?jì)算開(kāi)銷(xiāo)較大，如果多條查詢拓?fù)涞拿罴刑幚?，就?huì)導(dǎo)致節(jié)點(diǎn)資源的緊張。新的 slot 遷移按照節(jié)點(diǎn)進(jìn)行數(shù)據(jù)同步，可以支持同時(shí)遷移源節(jié)點(diǎn)的多個(gè) slot 甚至全部數(shù)據(jù)，最后可以通過(guò)一次拓?fù)渥兏D(zhuǎn)換多個(gè) slot 的屬主，大大降低了拓?fù)渌⑿碌挠绊憽?/p>

（4）支持高可用

集群的數(shù)據(jù)遷移是一個(gè)持續(xù)的過(guò)程，這個(gè)過(guò)程可能長(zhǎng)達(dá)幾個(gè)小時(shí)，期間服務(wù)可能發(fā)生各種異常情況。正常情況下的 Redis 集群具有 failover 機(jī)制，從節(jié)點(diǎn)可感知節(jié)點(diǎn)異常以代替舊主節(jié)點(diǎn)進(jìn)行服務(wù)。新 slot 遷移功能為了應(yīng)對(duì)這樣的可用性問(wèn)題，將 slot 遷移狀態(tài)同步給從節(jié)點(diǎn)，這樣遷移期間如果集群遷移節(jié)點(diǎn)發(fā)生 failover，其從節(jié)點(diǎn)就可以代替舊主節(jié)點(diǎn)繼續(xù)推進(jìn)數(shù)據(jù)遷移流程，保證了遷移流程的高可用能力，避免人工干預(yù)，大大簡(jiǎn)化運(yùn)維操作復(fù)雜度。

四、功能測(cè)試對(duì)比

為了驗(yàn)證改造后遷移功能的效果，對(duì)比自研遷移和原生遷移對(duì)請(qǐng)求響應(yīng)的影響，在三臺(tái)同樣配置物理機(jī)上部署了原生和自研兩套相同拓?fù)涞募海x擇后對(duì) hash 數(shù)據(jù)類(lèi)型的 100k 和 1MB 兩種大小數(shù)據(jù)分別進(jìn)行了遷移測(cè)試，每輪在節(jié)點(diǎn)間遷移內(nèi)存用量 5G 左右的數(shù)據(jù)。測(cè)試主要目的是對(duì)比改造前后數(shù)轉(zhuǎn)移對(duì)節(jié)點(diǎn)服務(wù)時(shí)延影響，所以在實(shí)際測(cè)試時(shí)沒(méi)有對(duì)集群節(jié)點(diǎn)進(jìn)行背景流量操作，節(jié)點(diǎn)的時(shí)延數(shù)據(jù)采用每秒鐘 ping 10次節(jié)點(diǎn)的方式進(jìn)行采集，遷移期間源節(jié)點(diǎn)和目的節(jié)點(diǎn)的時(shí)延監(jiān)控?cái)?shù)據(jù)入下表所示（縱軸數(shù)值單位：ms）。

通過(guò)對(duì)比以上原生和自研集群 slot 遷移期間的時(shí)延監(jiān)控?cái)?shù)據(jù)，可以看出自研 slot 遷移功能遷移數(shù)據(jù)期間遷移兩端節(jié)點(diǎn)的請(qǐng)求響應(yīng)時(shí)延表現(xiàn)非常平穩(wěn)，也可以表現(xiàn)出經(jīng)過(guò)主從復(fù)制原理改造的 Redis 集群 slot 遷移功能具備的優(yōu)勢(shì)和價(jià)值。

五、總結(jié)和展望

原生 Redis 集群的擴(kuò)縮容功能按照 key 粒度進(jìn)行數(shù)據(jù)轉(zhuǎn)移，較大的 key 會(huì)造成工作線程的長(zhǎng)時(shí)間占用，進(jìn)而引起正常服務(wù)請(qǐng)求時(shí)延飆高問(wèn)題，甚至導(dǎo)致節(jié)點(diǎn)長(zhǎng)時(shí)間無(wú)法回復(fù)心跳包而被判定下線的情況，存在穩(wěn)定性風(fēng)險(xiǎn)。通過(guò)同步機(jī)制改造實(shí)現(xiàn)的新 slot 遷移功能，能顯著降低數(shù)據(jù)遷移對(duì)用戶訪問(wèn)時(shí)延的影響，提升線上 Redis 集群穩(wěn)定性和運(yùn)維效率，同時(shí)新的 slot 遷移功能還存在一些問(wèn)題，例如新的遷移造成節(jié)點(diǎn)頻繁的 bgsave 壓力，遷移期間節(jié)點(diǎn)內(nèi)存占用增加等問(wèn)題，未來(lái)我們將圍繞這些具體問(wèn)題，繼續(xù)不斷優(yōu)化總結(jié)。