建站
咨詢
售后
建站咨詢
新聞中心
問題的嚴重性
首先，要申明一下，問題的嚴重性。
創(chuàng)新互聯(lián)建站是一家專注于網(wǎng)站設(shè)計制作、網(wǎng)站制作與策劃設(shè)計,淮上網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)建站做網(wǎng)站,專注于網(wǎng)站建設(shè)10多年,網(wǎng)設(shè)計領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:淮上等地區(qū)?；瓷献鼍W(wǎng)站價格咨詢:18980820575
BigKey（大key）和HotKey（熱key）的問題是較常見。
這類問題不止會使服務(wù)的性能下降，還會影響用戶正常使用功能，
甚至?xí)斐纱蠓秶姆?wù)故障，故障有時還會發(fā)生連環(huán)效應(yīng)，導(dǎo)致更加嚴重的后果，發(fā)生系統(tǒng)的雪崩，造成巨大的經(jīng)濟損失，巨大的品牌損傷。
所以，在 Redis 運維過程中，由于 Bigkey 的存在，DBA 也一直和業(yè)務(wù)開發(fā)方強調(diào) Bigkey 的規(guī)避方法以及危害。
在開發(fā)的過程中，開發(fā)同學(xué)，也需要十分重視和預(yù)防這個問題。
一、什么是BigKey、HotKey？
什么是BigKey
俗稱“大key”，是指redis在日常生產(chǎn)的過程中，某些key所占內(nèi)存空間過大。
通俗來說，redis是key-value的存儲方式，當(dāng)一個key所對應(yīng)的存儲數(shù)值達到一定程度，就會出現(xiàn)大key的情況。
redis里有多種數(shù)據(jù)存儲結(jié)構(gòu)，如String、List、Hash等，每種存儲結(jié)構(gòu)都有能夠承載的數(shù)據(jù)限值。當(dāng)一個key包含的內(nèi)容接近限制，或者高于平均值，大key就產(chǎn)生了。關(guān)注公眾號：碼猿技術(shù)專欄，回復(fù)關(guān)鍵詞：1111 獲取阿里內(nèi)部Java性能調(diào)優(yōu)手冊
在 Redis 中，一個字符串類型最大可以到 512MB，一個二級數(shù)據(jù)結(jié)構(gòu)（比如 hash、list、set、zset 等）可以存儲大約 40 億個(2^32-1)個元素，
但實際上不會達到這么大的值，一般情況下如果達到下面的情況，就可以認為它是 Bigkey 了。
- 【字符串類型】：單個 string 類型的 value 值超過 1MB，就可以認為是 Bigkey。
- 【非字符串類型】：哈希、列表、集合、有序集合等， 它們的元素個數(shù)超過 2000 個，就可以認為是 Bigkey。
什么是HotKey
俗稱“熱key”，一個key對應(yīng)在一個redis分片上，當(dāng)短時間內(nèi)大量的請求打到該分片上，key被頻繁訪問，該key就是熱key。
當(dāng)大量的請求，經(jīng)過分發(fā)和計算，最終集中于同一個redis實例下的某個key時，該key由于被請求頻率過高，而占用掉了大量資源。
而其他分片，由于key的不合理分配導(dǎo)致請求量較少。
整個redis集群呈現(xiàn)出了資源使用不均衡的現(xiàn)象。
舉個例子：一線女明星官宣領(lǐng)證結(jié)婚，短時間內(nèi)該女星微博賬號被訪問量激增（假設(shè)該賬號內(nèi)容被同步在緩存，賬號id作為key），微博服務(wù)癱瘓（不具備任何實時參考性，僅作為虛擬的例子）。
在該場景下，上述key被大量訪問，造成熱key。
總之，在某個Key接收到的訪問次數(shù)、顯著高于其它Key時，我們可以將其稱之為HotKey，
從訪問量上來說，常見的HotKey如：
- 某Redis實例的每秒總訪問量為10000，而其中一個Key的每秒訪問量達到了7000（訪問次數(shù)顯著高于其它Key）
- 對一個擁有上千個成員且總大小為1MB的HASH Key每秒發(fā)送大量的HGETALL（帶寬占用顯著高于其它Key）
- 對一個擁有數(shù)萬個成員的ZSET Key每秒發(fā)送大量的ZRANGE（CPU時間占用顯著高于其它Key）
二、服務(wù)中的bigkey和hotkey
會導(dǎo)致什么問題
我們可以通過上述兩種key的特性，來簡單分析可能出現(xiàn)的幾種問題。
第1：bigkey的問題
主要的問題是一個key所占空間太大，內(nèi)存空間分配不均衡（小tips：redis是內(nèi)存型key-value數(shù)據(jù)庫）。那就可能引發(fā)以下問題：
1.數(shù)據(jù)請求大量超時：
redis是單線程的，當(dāng)一個key數(shù)據(jù)響應(yīng)的久一點，就會造成后續(xù)請求頻繁超時。如果服務(wù)容災(zāi)措施考慮得不夠，會引發(fā)更大的問題。
2.侵占帶寬網(wǎng)絡(luò)擁堵：
當(dāng)一個key所占空間過大，多次請求就會占用較大的帶寬，直接影響服務(wù)的正常運行。
3.內(nèi)存溢出或處理阻塞：
當(dāng)一個較大的key存在時，持續(xù)新增，key所占內(nèi)存會越來越大，嚴重時會導(dǎo)致內(nèi)存數(shù)據(jù)溢出；當(dāng)key過期需要刪除時，由于數(shù)據(jù)量過大，可能發(fā)生主庫較響應(yīng)時間過長，主從數(shù)據(jù)同步異常（刪除掉的數(shù)據(jù)，從庫還在使用）。
第2：hotkey的問題
熱key，熱key的問題是單點訪問頻率過高。那就可能引發(fā)以下問題：
1.分片服務(wù)癱瘓：
redis集群會分很多個分片，每個分片有其要處理的數(shù)據(jù)范圍。當(dāng)某一個分片被頻繁請求，該分片服務(wù)就可能會癱瘓。
2.Redis 分布式集群優(yōu)勢弱化：
如果請求不夠均衡，過于單點，那么redis分布式集群的優(yōu)勢也必然被弱化。
3.可能造成資損：
在極端場景下，容易發(fā)生邊界數(shù)據(jù)處理不及時，在訂單等場景下，可能造成資損。
4.引發(fā)緩存擊穿：
我們都知道，當(dāng)緩存請求不到，就會去請求數(shù)據(jù)庫。如果請求過于集中，redis承載不了，就會有大量請求打到數(shù)據(jù)庫。此時，可能引發(fā)數(shù)據(jù)庫服務(wù)癱瘓。進而引發(fā)系統(tǒng)雪崩。
5.cpu占用高，影響其他服務(wù)：
單個分片cpu占用率過高，其他分片無法擁有cpu資源，從而被影響。
三、如何發(fā)現(xiàn)bigkey和hotkey
1.業(yè)務(wù)分析結(jié)合技術(shù)方案：
通常需要對業(yè)務(wù)場景做分析，結(jié)合技術(shù)方案去判斷是否會出現(xiàn)大key、熱key的問題。
比如說：
（1）購物車場景，當(dāng)一個購物車的key設(shè)計，沒有上限，沒有其他隨機值約束，僅使用了mid。這個時候就要注意，如果有個購物狂，一次加購5w件商品怎么辦？
（2）活動資格列表場景，當(dāng)一個活動的資格查詢list被放入一個key，活動期間頻繁的查詢和操作。這個時候就要注意，list的數(shù)據(jù)量有多少？查詢資格的操作是否集中？如果集中，qps是多少？
2.借助redis命令來發(fā)現(xiàn)：
Redis4.0 及以上版本提供了--Bigkeys, --hotkeys 命令，可以分析出實例中每種數(shù)據(jù)結(jié)構(gòu)的 top 1 的 Bigkey，同時給出了每種數(shù)據(jù)類型的鍵值個數(shù)以及平均大小。
查看bigkey：redis-cli -a 登錄密碼 --bigkeys
查看hotkey：redis-cli -a 登錄密碼 --hotkeys
--bigkey 的使用示例
3.借助工具：
(1)可使用redis可視化工具進行查看（例如：another redis desktop manager）
可視化的工具可以明確給出redis集群當(dāng)下的信息，經(jīng)過簡要數(shù)據(jù)分析，便可觀測異常。
(2)借助市面上的開源工具（本文暫不對此深入探討）
redis-rdb-tools（附：https://github.com/sripathikrishnan/redis-rdb-tools）
（3）借助公司的自研工具
如果 vivo內(nèi)部的 DaaS（數(shù)據(jù)即服務(wù)）平臺。
4.RDB 文件分析法
通過 RDB 文件，分析 big key
四、如何解決bigkey和hotkey問題
解決方案
bigkey的解決方案
主要的方法：對 big key 進行拆分
對 big key 存儲的數(shù)據(jù) （big value）進行拆分，變成value1，value2… valueN,
如果big value 是個大json 通過 mset 的方式，將這個 key 的內(nèi)容打散到各個實例中，減小big key 對數(shù)據(jù)量傾斜造成的影響。關(guān)注公眾號：碼猿技術(shù)專欄，回復(fù)關(guān)鍵詞：1111 獲取阿里內(nèi)部Java性能調(diào)優(yōu)手冊
如果big value 是個大list，可以拆成將list拆成。= list_1， list_2, list3, listN
其他數(shù)據(jù)類型同理
hotkey的解決方案
主要的方法：使用本地緩存
在 client 端使用本地緩存，從而降低了redis集群對hot key的訪問量，
但是本地緩存 ，帶來兩個問題：1、如果對可能成為 hot key 的 key 都進行本地緩存，那么本地緩存是否會過大，從而影響應(yīng)用程序本身所需的緩存開銷。
2、如何保證本地緩存和redis集群數(shù)據(jù)的有效期的一致性。
以上兩個問題，具體看：聊聊 Redis+Caffeine 兩級緩存
五、生產(chǎn)實例：
以下是vivo團隊Bigkey問題的解決方案
此生產(chǎn)實例，非常寶貴，是珍貴的一線工業(yè)級實操案例，來源于 vivo 互聯(lián)網(wǎng)數(shù)據(jù)庫團隊- Du Ting
陳某僅僅是將其結(jié)構(gòu)，做進一步的梳理，方便大家學(xué)習(xí)。
vivo 團隊運維的Redis集群的介紹
全網(wǎng) Redis 集群有 2200 個以上，實例數(shù)量達到 4.5 萬以上，
進行一次全網(wǎng) Bigkey 檢查，估計需要以年為時間單位，非常耗時。
Bigkey的來源
Bigkey 一般都是由于程序設(shè)計不當(dāng)、或者對于數(shù)據(jù)規(guī)模 預(yù)估 失策，比如以下的情況。
- 【統(tǒng)計】場景遇到一個統(tǒng)計類 key 記錄訪問用戶的 IP，隨著網(wǎng)站訪問的用戶越來越多，這個 key 的元素會越來越大，形成 Bigkey。
- 【緩存】場景CacheAside 模式，業(yè)務(wù)程序 將數(shù)據(jù)從數(shù)據(jù)庫查詢出來序列化放到 Redis 里，就會查詢數(shù)據(jù)庫并將查詢到的數(shù)據(jù)追加到 Redis 緩存中，短時間內(nèi)會緩存大量的數(shù)據(jù)到 Redis 的 key 中，形成 Bigkey。
- 【隊列】場景把 Redis 當(dāng)做隊列使用場景，如果消費不及時，將導(dǎo)致隊列越來越大，出現(xiàn) Bigkey。
問題1：內(nèi)存空間不均勻
內(nèi)存空間不均勻會不利于集群對內(nèi)存的統(tǒng)一管理，有數(shù)據(jù)丟失風(fēng)險。
下圖中的三個節(jié)點是同屬于一個集群，它們的 key 的數(shù)量比較接近，但內(nèi)存容量相差比較多，存在 Bigkey 的實例占用的內(nèi)存多了 4G 以上了。
可以使用 Daas 平臺“工具集-操作項管理”，選擇對應(yīng)的 slave 實例執(zhí)行分析，找出具體的 Bigkey。
問題2：超時阻塞
Redis 是單線程工作的，通俗點講就是同一時間只能處理一個 Redis 的訪問命令，
操作 Bigkey 的命令通常比較耗時，這段時間 Redis 不能處理其他命令，其他命令只能阻塞等待，這樣會造成客戶端阻塞，導(dǎo)致客戶端訪問超時，更嚴重的會造成 master-slave 的故障切換。
當(dāng)然，造成阻塞的操作不僅僅是業(yè)務(wù)程序的訪問，還有 key 的自動過期的刪除、del 刪除命令，對于 Bigkey，這些操作也需要謹慎使用。
來一個生產(chǎn)上的超時阻塞案例
我們遇到一個這樣超時阻塞的案例，業(yè)務(wù)方反映：程序訪問 Redis 集群出現(xiàn)超時現(xiàn)象，hkeys 訪問 Redis 的平均響應(yīng)時間在 200 毫秒左右，最大響應(yīng)時間達到了 500 毫秒以上，如下圖。
hkeys 是獲取所有哈希表中的字段的命令，分析應(yīng)該是集群中某些實例存在 hash 類型的 Bigkey，導(dǎo)致 hkeys 命令執(zhí)行時間過長，發(fā)生了阻塞現(xiàn)象。
1.使用 Daas 平臺“服務(wù)監(jiān)控-數(shù)據(jù)庫實例監(jiān)控”，選擇 master 節(jié)點，選擇 Redis 響應(yīng)時間監(jiān)控指標“redis.instance.latency.max”，如下圖所示，從監(jiān)控圖中我們可以看到
（1）正常情況下，該實例的響應(yīng)時間在 0.1 毫秒左右。
（2）監(jiān)控指標上面有很多突刺，該實例的響應(yīng)時間到了 70 毫秒左右，最大到了 100 毫秒左右，這種情況就是該實例會有 100 毫秒都在處理 Bigkey 的訪問命令，不能處理其他命令。
通過查看監(jiān)控指標，驗證了我們分析是正確的，是這些監(jiān)控指標的突刺造成了 hkeys 命令的響應(yīng)時間比較大，我們找到了具體的 master 實例，然后使用 master 實例的 slave 去分析下 Bigkey 情況。
2.使用 Daas 平臺“工具集-操作項管理”，選擇 slave 實例執(zhí)行分析，分析結(jié)果如下圖，有一個 hash 類型 key 有 12102218 個 fields。
- 和業(yè)務(wù)溝通，進行Bigkey 拆分這個 Bigkey 是連續(xù)存放了 30 天的業(yè)務(wù)數(shù)據(jù)了，建議根據(jù)二次 hash 方式拆分成多個 key，也可把 30 天的數(shù)據(jù)根據(jù)分鐘級別拆分成多個 key，把每個 key 的元素數(shù)量控制在 5000 以內(nèi)。優(yōu)化后，監(jiān)控指標的響應(yīng)時間的突刺就會消失了。
問題3：網(wǎng)絡(luò)阻塞
Bigkey 的 value 比較大，也意味著每次獲取要產(chǎn)生的網(wǎng)絡(luò)流量較大，假設(shè)一個 Bigkey 為 10MB，客戶端每秒訪問量為 100，那么每秒產(chǎn)生 1000MB 的流量，對于普通的千兆網(wǎng)卡(按照字節(jié)算是 128MB/s)的服務(wù)器來說簡直是滅頂之災(zāi)。
而且我們現(xiàn)在的 Redis 服務(wù)器是采用單機多實例的方式來部署 Redis 實例的，也就是說一個 Bigkey 可能會對同一個服務(wù)器上的其他 Redis 集群實例造成影響，影響到其他的業(yè)務(wù)。
問題4：遷移困難
我們在運維中經(jīng)常做的變更操作是水平擴容，就是增加 Redis 集群的節(jié)點數(shù)量來達到擴容的目的，這個水平擴容操作就會涉及到 key 的遷移，把原實例上的 key 遷移到新擴容的實例上。
當(dāng)要對 key 進行遷移時，是通過 migrate 命令來完成的，migrate 實際上是通過 dump + restore + del 三個命令組合成原子命令完成，它在執(zhí)行的時候會阻塞進行遷移的兩個實例，直到以下任意結(jié)果發(fā)生才會釋放：遷移成功，遷移失敗，等待超時。
如果 key 的遷移過程中遇到 Bigkey，會長時間阻塞進行遷移的兩個實例，可能造成客戶端阻塞，導(dǎo)致客戶端訪問超時；也可能遷移時間太長，造成遷移超時導(dǎo)致遷移失敗，水平擴容失敗。
來一個生產(chǎn)上的遷移失敗案例
我們也遇到過一些因為 Bigkey 擴容遷移失敗的案例，如下圖所示，
這是一個 Redis 集群水平擴容的工單，需要進行 key 的遷移，當(dāng)工單執(zhí)行到 60%的時候，遷移失敗了。
如何解決呢？
大概的解決流程，如下：
- 進入工單找到失敗的實例，使用失敗實例的 slave 節(jié)點，在 Daas 平臺的“工具集-操作項管理”進行 Bigkey 分析。
- 經(jīng)過分析找出了 hash 類型的 Bigkey 有 8421874 個 fields，正是這個 Bigkey 導(dǎo)致遷移時間太長，超過了遷移時間限制，導(dǎo)致工單失敗了。
3.和業(yè)務(wù)溝通，這些 key 是記錄用戶訪問系統(tǒng)的某個功能模塊的 ip 地址的，訪問該功能模塊的所有 ip 都會記錄到給 key 里面，隨著時間的積累，這個 key 變的越來越大。同樣是采用拆分的方式進行優(yōu)化，可以考慮按照時間日期維度來拆分，就是一段時間段的訪問 ip 記錄到一個 key 中。
4.Bigkey 優(yōu)化后，擴容的工單可以重試，完成集群擴容操作。
生產(chǎn)上如何進行Bigkey 的發(fā)現(xiàn)
- 首先需要重源頭治理，防止 Bigkey 的產(chǎn)生；
- 其次是需要能夠及時的發(fā)現(xiàn)，發(fā)現(xiàn)后及時處理。
分析 Bigkey 的方法不少，這里介紹兩種比較常用的方法，也是 Daas 平臺分析 Bigkey 使用的兩種方式，分別是 Bigkeys 命令分析法、RDB 文件分析法。
1.Bigkeys 命令分析
Redis4.0 及以上版本提供了--Bigkeys 命令，可以分析出實例中每種數(shù)據(jù)結(jié)構(gòu)的 top 1 的 Bigkey，同時給出了每種數(shù)據(jù)類型的鍵值個數(shù)以及平均大小。
執(zhí)行--Bigkeys 命令時候需要注意以下幾點：
- 建議在 slave 節(jié)點執(zhí)行，因為--Bigkeys 也是通過 scan 完成的，可能會對節(jié)點造成阻塞。
- 建議在節(jié)點本機執(zhí)行，這樣可以減少網(wǎng)絡(luò)開銷。
- 如果沒有從節(jié)點，可以使用--i 參數(shù)，例如(--i 0.1 代表 100 毫秒執(zhí)行一次)。
- --Bigkeys 只能計算每種數(shù)據(jù)結(jié)構(gòu)的 top1，如果有些數(shù)據(jù)結(jié)構(gòu)有比較多的 Bigkey，是查找不出來的。
Daas 平臺集成了基于原生--Bigkeys 代碼實現(xiàn)的查詢 Bigkey 的方式，這個方式的缺點是只能計算每種數(shù)據(jù)結(jié)構(gòu)的 top1，如果有些數(shù)據(jù)結(jié)構(gòu)有比較多的 Bigkey，是查找不出來的。該方式相對比較安全，已經(jīng)開放出來給業(yè)務(wù)開發(fā)同學(xué)使用。
2. RDB 文件分析
借助開源的工具，比如 rdb-tools，分析 Redis 實例的 RDB 文件，找出其中的 Bigkey，這種方式需要生成 RDB 文件，需要注意以下幾點：
- 建議在 slave 節(jié)點執(zhí)行，因為生成 RDB 文件會影響節(jié)點性能。
- 需要生成 RDB 文件，會影響節(jié)點性能，雖然在 slave 節(jié)點執(zhí)行，但是也是有可能造成主從中斷，進而影響到 master 節(jié)點。
Daas 平臺集成了基于 RDB 文件分析代碼實現(xiàn)的查詢 Bigkey 的方式，可以根據(jù)實際需求自定義填寫 N，分析的 top N 個 Bigkey。該方式相對有一定風(fēng)險，只有 DBA 有權(quán)限執(zhí)行分析。
3.Bigkey 巡檢
通過巡檢，可以暴露出隱患，提前解決，避免故障的發(fā)生，進行全網(wǎng) Bigkey 的巡檢，是避免 Bigkey 故障的比較好的方法。
由于全網(wǎng) Redis 實例數(shù)量非常大，分析的速度比較慢，使用當(dāng)前的分析方法很難完成。
為了解決這個問題，存儲研發(fā)組分布式數(shù)據(jù)庫同學(xué)計劃開發(fā)一個高效的 RDB 解析工具，然后通過大規(guī)模解析 RDB 文件來分析 Bigkey，可以提高分析速度，實現(xiàn) Bigkey 的巡檢。
生產(chǎn)上 Bigkey 處理優(yōu)化
1. Bigkey 拆分
優(yōu)化 Bigkey 的原則就是 string 減少字符串長度，list、hash、set、zset 等減少元素數(shù)量。當(dāng)我們知道哪些 key 是 Bigkey 時，可以把單個 key 拆分成多個 key，比如以下拆分方式可以參考。
- big list：list1、list2、...listN
- big hash：可以做二次的 hash，例如 hash%100
- 按照日期拆分多個：key20220310、key20220311、key202203212
2. Bigkey 分析工具優(yōu)化
我們?nèi)W(wǎng) Redis 集群有 2200 以上，實例數(shù)量達到 4.5 萬以上，有的比較大的集群的實例數(shù)量達到了 1000 以上，前面提到的兩種 Bigkey 分析工具還都是實例維度分析，對于實例數(shù)量比較大的集群，進行全集群分析也是比較耗時的，為了提高分析效率，從以下幾個方面進行優(yōu)化：
- 可以從集群維度選擇全部 slave 進行分析。
- 同一個集群的相同服務(wù)器 slave 實例串行分析，不同服務(wù)器的 slave 實例并行分析，最大并發(fā)度默認 10，同時可以分析 10 個實例，并且可以自定義輸入執(zhí)行分析的并發(fā)度。
- 分析出符合 Bigkey 規(guī)定標準的所有 key 信息：大于 1MB 的 string 類型的所有 key，如果不存在就列出最大的 50 個 key；hash、list、set、zset 等類型元素個數(shù)大于 2000 的所有 key，如不存在就給出每種類型最大的 50 個 key。
- 增加暫停、重新開始、結(jié)束功能，暫停分析后可以重新開始。
水平擴容遷移優(yōu)化
目前情況，我們有一些 Bigkey 的發(fā)現(xiàn)是被動的，一些是在水平擴容時候發(fā)現(xiàn)的，由于 Bigkey 的存在導(dǎo)致擴容失敗了，嚴重的還觸發(fā)了 master-slave 的故障切換，這個時候可能已經(jīng)造成業(yè)務(wù)程序訪問超時，導(dǎo)致了可用性下降。
我們分析了 Daas 平臺的水平擴容時遷移 key 的過程及影響參數(shù)，內(nèi)容如下：
（1）【cluster-node-timeout】：控制集群的節(jié)點切換參數(shù)，
master 堵塞超過 cluster-node-timeout/2 這個時間，就會主觀判定該節(jié)點下線 pfail 狀態(tài)，如果遷移 Bigkey 阻塞時間超過 cluster-node-timeout/2，就可能會導(dǎo)致 master-slave 發(fā)生切換。
（2）【migrate timeout】：控制遷移 io 的超時時間
超過這個時間遷移沒有完成，遷移就會中斷。
（3）【遷移重試周期】：遷移的重試周期是由水平擴容的節(jié)點數(shù)決定的，
比如一個集群擴容 10 個節(jié)點，遷移失敗后的重試周期就是 10 次。
（4）【一個遷移重試周期內(nèi)的重試次數(shù)】：在一個起遷移重試周期內(nèi)，會有 3 次重試遷移，
每一次的 migrate timeout 的時間分別是 10 秒、20 秒、30 秒，每次重試之間無間隔。
比如一個集群擴容 10 個節(jié)點，遷移時候遇到一個 Bigkey，第一次遷移的 migrate timeout 是 10 秒，10 秒后沒有完成遷移，就會設(shè)置 migrate timeout 為 20 秒重試，如果再次失敗，會設(shè)置 migrate timeout 為 30 秒重試，
如果還是失敗，程序會遷移其他新 9 個的節(jié)點，但是每次在遷移其他新的節(jié)點之前還會分別設(shè)置 migrate timeout 為 10 秒、20 秒、30 秒重試遷移那個遷移失敗的 Bigkey。
這個重試過程，每個重試周期阻塞（10+20+30）秒，會重試 10 個周期，共阻塞 600 秒。其實后面的 9 個重試周期都是無用的，每次重試之間沒有間隔，會連續(xù)阻塞了 Redis 實例。
（5）【遷移失敗日志】：日志的缺失
遷移失敗后，記錄的日志沒有包括遷移節(jié)點、solt、key 信息，不能根據(jù)日志立即定位到問題 key。
我們對這個遷移過程做了優(yōu)化，具體如下：
（1）【cluster-node-timeout】：延長超時時間
默認是 60 秒，在遷移之前設(shè)置為 15 分鐘，防止由于遷移 Bigkey 阻塞導(dǎo)致 master-slave 故障切換。
（2）【migrate timeout】：減少阻塞時間
為了最大限度減少實例阻塞時間，每次重試的超時時間都是 10 秒，3 次重試之間間隔 30 秒，這樣最多只會連續(xù)阻塞 Redis 實例 10 秒。
（3）【重試次數(shù)】：去掉了其他節(jié)點遷移的重試
遷移失敗后，只重試 3 次（重試是為了避免網(wǎng)絡(luò)抖動等原因造成的遷移失?。看沃卦囬g隔 30 秒，重試 3 次后都失敗了，會暫停遷移，日志記錄下 Bigkey，去掉了其他節(jié)點遷移的重試。
（4）【優(yōu)化日志記錄】：日志記錄
遷移失敗日志記錄遷移節(jié)點、solt、key 信息，可以立即定位到問題節(jié)點及 key。
關(guān)于BigKey、Hotkey的總結(jié)
首先是需要從源頭治理，防止 Bigkey 、Hotkey形成，加強對業(yè)務(wù)開發(fā)同學(xué) bigkey 相關(guān)問題的宣導(dǎo)；
其次，提升及時發(fā)現(xiàn)的能力，實現(xiàn) Bigkey 、Hotkey 及時探測能力。
參考資料：
Github：rdb-tools：https://github.com/sripathikrishnan/redis-rdb-tools
(1) redis命令：Redis 命令參考 — Redis 命令參考
(2) Github: https://github.com/sripathikrishnan/redis-rdb-tools
(3) another redis desktop manager下載地址AnotherRedisDesktopManager 發(fā)行版：https://gitee.com/qishibo/AnotherRedisDesktopManager/releases
當(dāng)前題目：Redis的BigKey、HotKey又引發(fā)了線上事故！
標題網(wǎng)址：http://m.5511xx.com/article/dpsijoi.html
