http://www.infoq.com/cn/articles/analysis-redis

Redis 是互聯(lián)網(wǎng)產(chǎn)品開發(fā)中不可缺少的常備武器，它性能高、數(shù)據(jù)結(jié)構(gòu)豐富、簡(jiǎn)單易用，但同時(shí)也是因?yàn)樘菀子昧?#xff0c;我們的開發(fā)同學(xué)不管什么數(shù)據(jù)、不管這數(shù)據(jù)有多大、不管數(shù)據(jù)有多少通通塞進(jìn)去，最后導(dǎo)致的問題就是 Redis 內(nèi)存使用持續(xù)上升，但是又不知道里面的數(shù)據(jù)是不是有用，是否可以拆分和清理。

為了更好地使用 Redis，除了對(duì) Redis 做一些使用規(guī)范，還需要對(duì)線上使用的 Redis 有充分的了解。那么問題來了：一個(gè) Redis 的實(shí)例用了那么大的內(nèi)存，里邊到底存了啥？都有哪些 key？每個(gè) key 占用了多少空間？

雪球當(dāng)前有幾十個(gè) Redis 集群，近千個(gè) Redis 實(shí)例，5T 的內(nèi)存數(shù)據(jù)，我們也想要分析業(yè)務(wù)是否有誤用，以提高資源利用率。當(dāng)然，曾經(jīng)我們也深深地被這個(gè)問題所困擾，今天我就來和大家分享下我是如何解決這個(gè)問題的，希望能給各位一些啟發(fā)。

那有沒有什么辦法讓我們安全高效的看到 Redis 內(nèi)存消耗的詳細(xì)報(bào)表呢？辦法總比問題多，有需求就有解決方案。雪球 SRE 團(tuán)隊(duì)針對(duì)這個(gè)問題實(shí)現(xiàn)了一個(gè) Redis 數(shù)據(jù)可視化平臺(tái) RDR (Redis Data Reveal)。RDR 可以非常方便的對(duì) Reids 的內(nèi)存進(jìn)行分析，了解一個(gè) Redis 實(shí)例里都有哪些 key，哪類 key 占用的空間是多少，最耗內(nèi)存的 key 有哪些，占比如何，非常直觀。

設(shè)計(jì)思路

我們先梳理下，有什么辦法可以拿到 Redis 的所有數(shù)據(jù)。從我的角度看，大概有以下幾種方法，我們分析一下個(gè)字的優(yōu)缺點(diǎn)：

1. 先通過 keys * 命令，拿到所有的 key，然后根據(jù) key 再獲取所有的內(nèi)容。

• 優(yōu)點(diǎn)：可以不使用 Redis 機(jī)器的硬盤，直接網(wǎng)絡(luò)傳輸
• 缺點(diǎn)：如果 key 數(shù)量特別多，keys 命令可能會(huì)導(dǎo)致 Redis 卡住影響業(yè)務(wù)；需要對(duì) Redis 請(qǐng)求非常多次，資源消耗多；遍歷數(shù)據(jù)太慢

2. 開啟 aof，通過 aof 文件獲取到所有數(shù)據(jù)。

• 優(yōu)點(diǎn)：無需影響 Redis 服務(wù)，完全離線操作，足夠安全；
• 缺點(diǎn)：有一些 Redis 實(shí)例寫入頻繁，不適合開啟 aof，普適性不強(qiáng)；aof 文件有可能特別大，傳輸、解析起來太慢，效率低。

3. 使用 bgsave，獲取 rdb 文件，解析后獲取數(shù)據(jù)。

• 優(yōu)點(diǎn)：機(jī)制成熟，可靠性好；文件相對(duì)小，傳輸、解析效率高；
• 缺點(diǎn)：bgsave 雖然會(huì) fork 子進(jìn)程，但還是有可能導(dǎo)致主進(jìn)程卡住一段時(shí)間，對(duì)業(yè)務(wù)有產(chǎn)生影響的風(fēng)險(xiǎn)；

以上幾種方式我們?cè)u(píng)估之后，決定采用低峰期在從節(jié)點(diǎn)做 bgsave 獲取 rdb 文件，相對(duì)安全可靠，也可以覆蓋所有業(yè)務(wù)的 Redis 集群。也就是說每個(gè)實(shí)例每天在低峰期自動(dòng)生成一個(gè) rdb 文件，即使報(bào)表數(shù)據(jù)有一天的延遲也是可以接受的。

拿到了 rdb 文件就相當(dāng)于拿到了 Redis 實(shí)例的所有數(shù)據(jù)，接下來就是生成報(bào)表的過程了：

解析 rdb 文件，獲取到 Key 和 Value 的內(nèi)容；

根據(jù)相對(duì)應(yīng)的數(shù)據(jù)結(jié)構(gòu)及內(nèi)容，估算內(nèi)存消耗等；

統(tǒng)計(jì)并生成報(bào)表；

邏輯很簡(jiǎn)單，所以設(shè)計(jì)思路很清晰。數(shù)據(jù)流圖如下：

我們?cè)倏聪戮唧w該如何實(shí)現(xiàn)，首先是語言選型，雪球 SRE 自研的組件基本都是用 Go 語言做的后端，所以語言選型沒什么糾結(jié)，直接用 Go。然后就是剛剛說的那幾個(gè)流程。

1. 解析 RDB

按照 Redis 的協(xié)議來做就可以了，這個(gè)在 GitHub 上搜索 parse rdb 就可以找到許多解析 rdb 文件的庫(kù)，拿過來使用即可。我們使用了 https://github.com/cupcake/rdb 。

2. 估算內(nèi)存消耗

一條記錄會(huì)有哪些內(nèi)存使用呢？

我們知道 Redis 的實(shí)現(xiàn)里面有一些基礎(chǔ)的數(shù)據(jù)結(jié)構(gòu)，就是用這些結(jié)構(gòu)來實(shí)現(xiàn)了對(duì)外暴露的各種數(shù)據(jù)類型：比如 sds、dict、intset、zipmap、adlist、ziplist、quicklist、skiplist 等等。只要根據(jù)這條記錄的數(shù)據(jù)類型，找出使用了哪些數(shù)據(jù)結(jié)構(gòu)，再計(jì)算出這些基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)的內(nèi)存消耗，再加上數(shù)據(jù)的內(nèi)存使用，以及一些額外開銷比如過期時(shí)間等，就可以估算出一條記錄到底使用了多少內(nèi)存。

但是由于 Redis 做了非常多的優(yōu)化，同樣的一種數(shù)據(jù)類型，在不同場(chǎng)景下使用的數(shù)據(jù)結(jié)構(gòu)有可能是不同的。比如 List ，比較老版本的 Redis，會(huì)根據(jù) list 元素的數(shù)量來決定來使用哪種結(jié)構(gòu)，較短的時(shí)候使用 adlist，長(zhǎng)之后使用 ziplist，數(shù)值可以通過 list-max-ziplist-entries 來配置。

3.2 版本以后全都使用了 quicklist。而不同結(jié)構(gòu)對(duì)于內(nèi)存的使用其實(shí)是有區(qū)別的，我們計(jì)算的時(shí)候也沒辦法拿到具體的配置，所以都按默認(rèn)配置來計(jì)算，最后得出的值是一個(gè)估算的值，不過也基本可以反應(yīng)使用情況了。如果大家對(duì)于 Redis 使用的各種數(shù)據(jù)結(jié)構(gòu)感興趣，想了解其設(shè)計(jì)及適用場(chǎng)景，可以多搜索一下相關(guān)的資料以及閱讀 Redis 源碼。

舉個(gè)計(jì)算內(nèi)存使用的例子：

假如我們通過解析 rdb，獲取到了一個(gè) key 為 hello，value 為 world，類型為 string ，ttl 為 1440 的一條記錄，它的內(nèi)存使用是這樣的：

• 一個(gè) dictEntry 的消耗，Redis db 就是一個(gè)大 dict，每對(duì) kv 都是其中的一個(gè) entry ；
• 一 個(gè) robj 的消耗，robj 是為了在同一個(gè) dict 內(nèi)能夠存儲(chǔ)不同類型的 value，而使用的一個(gè)通用的數(shù)據(jù)結(jié)構(gòu)，全名是 Redis Object；
• 存儲(chǔ) key 的 sds 消耗，sds 是 Redis 中存儲(chǔ)字符串使用的數(shù)據(jù)結(jié)構(gòu)；
• 存儲(chǔ)過期時(shí)間消耗；
• 存儲(chǔ) value 的 sds 消耗；

前四項(xiàng)基本是存儲(chǔ)任何一個(gè) key 都需要消耗的，最后一項(xiàng)根據(jù) value 的數(shù)據(jù)結(jié)構(gòu)不同而不同。

• 一個(gè) dictEntry 有 2 個(gè)指針，一個(gè) int64 的內(nèi)存消耗；
• 一個(gè) robj 有 1 指針，一個(gè) int，以及幾個(gè)使用位域的字段共消耗 4 字節(jié)；
• 過期時(shí)間也是存儲(chǔ)為一個(gè) dictEntry，時(shí)間戳為 int64；
• 存儲(chǔ) sds 需要存儲(chǔ) header 以及字符串長(zhǎng)度 +1 的空間，header 長(zhǎng)度根據(jù)字符串長(zhǎng)度不同也會(huì)有所不同；

我們根據(jù)以上信息可以算出，向操作系統(tǒng)申請(qǐng)這些內(nèi)存，真正需要多少內(nèi)存。由于 Redis 支持多種 malloc 算法，我們就按 jemalloc 的分配方式算，這里也是可能存在誤差的點(diǎn)。

所以最后 key 為 hello 的這條記錄在 64 位操作系統(tǒng)上一共會(huì)消耗 92 字節(jié)。

其他類型的計(jì)算也大致是同樣的思路，只不過根據(jù)不同的數(shù)據(jù)結(jié)構(gòu)需要計(jì)算不同的內(nèi)存消耗，計(jì)算的時(shí)候要記得考慮內(nèi)存對(duì)齊的情況。還有由于 zset 的算法涉及到了隨機(jī)生成層數(shù)，我們也使用同樣的算法來隨機(jī)，但是算出來的值肯定不是精確的，也是一個(gè)誤差點(diǎn)。

3. 統(tǒng)計(jì)計(jì)數(shù)

終于可以拿到任何一個(gè) key 的內(nèi)存使用了，哪些是最有意義最有價(jià)值的數(shù)據(jù)呢？

• top N，毫無疑問最大的前 N 個(gè) key 一定是要關(guān)注的；
• 不同數(shù)據(jù)類型的 key 數(shù)量元素?cái)?shù)量分布以及內(nèi)存使用情況；
• 按照前綴分類，統(tǒng)一的前綴一般意味著某個(gè)特定的業(yè)務(wù)在使用，計(jì)算各個(gè)分類的 key 數(shù)量及內(nèi)存使用情況；

這幾個(gè)需求實(shí)現(xiàn)起來也都很容易：

維護(hù)一個(gè)小頂堆來存儲(chǔ)前 N 個(gè)最大的即可，最后取出堆中的數(shù)據(jù)即可；

計(jì)數(shù)即可；

一般都會(huì)有特定的分隔符，比如 :|._ 等字符，按照這些字符切出公共前綴再統(tǒng)計(jì)，同時(shí)把所有的數(shù)字都替換為 0，便于分類；

4. 報(bào)表數(shù)據(jù)

可以每天打開個(gè)網(wǎng)頁就可以看到某個(gè) Redis 實(shí)例的內(nèi)存使用的詳細(xì)情況，是件非常幸福的事情，Redis 的內(nèi)存使用再也不是黑盒。

這個(gè)系統(tǒng)上線一年以來對(duì)我們優(yōu)化 Redis 資源使用、提高效率、節(jié)約成本提供了非常重要的數(shù)據(jù)支撐，而且在內(nèi)部完全自動(dòng)化，開發(fā)同學(xué)自己就可以看到當(dāng)前 Redis 的使用情況是否符合預(yù)期，對(duì)于保障業(yè)務(wù)穩(wěn)定也起到了非常重要的作用。這也是雪球的工程師團(tuán)隊(duì)一貫的做法，SRE 提供高效的工具，開發(fā)工程師可以自己運(yùn)維自己的業(yè)務(wù)系統(tǒng)，可以極大的提高生產(chǎn)效率。

這個(gè)項(xiàng)目參考了 redis-rdb-tool 這個(gè)開源項(xiàng)目，但是性能上比它高效幾倍，為了回饋社區(qū)，也希望有機(jī)會(huì)幫到大家，所以我們決定開源出來。

雪球的內(nèi)部系統(tǒng)根據(jù)自己的特殊場(chǎng)景做了自動(dòng)化獲取 rdb 文件并備份的邏輯，開源出來的版本去除了定制化，只保留了獲取到 rdb 之后的分析邏輯以及頁面。

項(xiàng)目地址為 https://github.com/xueqiu/rdr。有任何問題可以提 issue，也可以直接郵件聯(lián)系我：dongmx@xueqiu.com。

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/9311363.html

總結(jié)

以上是生活随笔為你收集整理的如何优雅的分析 Redis 里存了啥？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。