如何做到Redis開發規范中的拒絕bigkey

如何做到Redis 開發規范中的拒絕bigkey，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

代碼中的問題，光靠 Code Review 是不夠的。Code Review 主要是解決規范問題，當然也能排查出一些 bug。

Code Review 適合技術驅動型團隊、公共服務型團隊、測試缺失型團隊、新人密集型團隊、任何有主觀意愿的團隊。Code Review 活動主要圍繞下面 4 項工作開展。

說到代碼規范，我們就不得不提阿里云的 Redis 開發規范。這個規范寫的很好，想把我說的都總結了。需要這套規范的可以私信我，我發給你們。

其中有一條寫到：

意思我們都懂，關鍵是這個 bigkey 不好掌握，使用著使用著 key 可能就變大了，不規范了。

那么有沒有大 Key 檢測機制呢？答案當然有。阿里云提供了一個大 Key 搜索工具：https://yq.aliyun.com/articles/117042。原理其實就是和我們下面要將的內容類似。

因為有時候，我們的 BUG 就是無意直接產生的，bigkey 也有可能是你知識欠缺，缺乏考慮等原因造成的。因此，對于生產中的一些問題，我們還需要做到主動出擊，主動去觀察每個服務的健康狀況。下面我們就一起來看看如果提前發現 Redis 中使用不合理的大 Key。

redis-cli -h{ip} -p{port} bigkeys 命令就是干這個事情的。該命令會對 redis 中的 key 進行采樣，尋找較大的 keys。是用的是 scan 方式，不用擔心會阻塞 redis 很長時間不能處理其他的請求。執行的結果可以用于分析 redis 的內存的只用狀態，每種類型 key 的平均大小。

例如當我執行：redis-cli -h 127.0.0.1 -p 7001  –bigkeys 后，會出現如下內容： 

String 就是字符串、Hash 就是哈希、List 就是列表、Set 就是集合、zset(sorted set：有序集合)。

字符串類型：一般認為超過 10k 的就是 bigkey，但是這個值和具體的 OPS 相關。

非字符串類型：體現在哈希，列表，集合類型元素過多。

bigkey 通常會導致內存空間不平衡，超時阻塞，如果 key 較大，redis 又是單線程，操作 bigkey 比較耗時，那么阻塞 redis 的可能性增大。每次獲取 bigKey 的網絡流量較大，假設一個 bigkey 為 1MB,每秒訪問量為 1000，那么每秒產生 1000MB 的流量，對于普通千兆網卡，按照字節算 128M/S 的服務器來說可能扛不住。而且一般服務器采用單機多實例方式來部署，所以還可能對其他實例造成影響。

當你以為你會用 Redis 了，就可以找高薪工作了，但實際上會優化才重要！

關于如何做到Redis 開發規范中的拒絕bigkey問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。