緣由
Redis 是網際網路產品開發中不可缺少的常備武器，它效能高、資料結構豐富、簡單易用，但同時也是因為太容易用了，開發同學不管什麼資料、不管這資料有多大、不管資料有多少，通通塞進去，最後導致的問題就是 Redis 記憶體使用持續上升，但是又不知道里面的資料是不是有用，是否可以拆分和清理。
為了更好地使用 Redis，除了對 Redis 做一些使用規範，還需要對線上使用的 Redis 有充分的瞭解。 那麼問題來了：
- 一個 Redis 的例項用了那麼大的記憶體，裡邊到底存了啥？
- 都有哪些 key？
- 每個 key 佔用了多少空間？
思路
一、 先通過 keys * 命令，拿到所有的 key，然後根據 key 再獲取所有的內容。
- 優點：可以不使用 Redis 機器的硬碟，直接網路傳輸。
- 缺點：如果 key 數量特別多，keys 命令可能會導致 Redis 卡住影響業務；需要對 Redis 請求非常多次，資源消耗多；遍歷資料太慢。
二、開啟 aof，通過 aof 檔案獲取到所有資料。
- 優點：無需影響 Redis 服務，完全離線操作，足夠安全。
- 缺點：有一些 Redis 例項寫入頻繁，不適合開啟 aof，普適性不強；aof 檔案有可能特別大，傳輸、解析起來太慢，效率低。
三、使用 bgsave，獲取 rdb 檔案，解析後獲取資料。
- 優點：機制成熟，可靠性好；檔案相對小，傳輸、解析效率高。
- 缺點：bgsave 雖然會 fork 子程式，但還是有可能導致主程式卡住一段時間，對業務有產生影響的風險。
評估後，決定採用低峰期在從節點做 bgsave 獲取 rdb 檔案，相對安全可靠，也可以覆蓋所有業務的 Redis 叢集。也就是說每個例項每天在低峰期自動生成一個 rdb 檔案，即使報表資料有一天的延遲也是可以接受的。
拿到了 rdb 檔案就相當於拿到了 Redis 例項的所有資料，接下來就是生成報表的過程了：
- 解析 rdb 檔案，獲取到 Key 和 Value 的內容；
- 根據相對應的資料結構及內容，估算記憶體消耗等；
- 統計並生成報表；
Redis 例項 -> rdb 檔案 -> 解析 rdb -> 估算記憶體消耗 -> 統計計數 -> 報表資料
參考地址
聯想
1、制定開發團隊的Redis Key使用規範，通過Key可以獲得到：
- 屬於什麼域名（加域名標示）；
- 屬於什麼資料型別（加資料型別標識）；
- 是否設定過期時間；
- ...
2、統一平臺進行redis key的申請，只有申請了才能進行使用。
- 申請人；
- 申請時間；
- ...
