使用過 Redis，我竟然還不知道 Rdb
使用過Redis，那就先說說使用過那些場景吧
字串快取
佇列
釋出訂閱
計數器
排行榜
集合間操作
悲觀鎖
解釋：悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀。
每次去拿資料的時候都認為別人會修改，所以每次在拿資料的時候都會上鎖。
場景：如果專案中使用了快取且對快取設定了超時時間。
當併發量比較大的時候，如果沒有鎖機制，那麼快取過期的瞬間，
大量併發請求會穿透快取直接查詢資料庫，造成雪崩效應。
樂觀鎖
解釋：樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀。
每次去拿資料的時候都認為別人不會修改，所以不會上鎖。
watch命令會監視給定的key，當exec時候如果監視的key從呼叫watch後發生過變化，則整個事務會失敗。
也可以呼叫watch多次監視多個key。這樣就可以對指定的key加樂觀鎖了。
注意watch的key是對整個連線有效的，事務也一樣。
如果連線斷開，監視和事務都會被自動清除。
當然了exec，discard，unwatch命令都會清除連線中的所有監視。
上面的一些場景，咱們大部分都使用過，卻還沒有提及到Rdb檔案。
“對吧，使用過Redis，卻不知道Rdb檔案，你中槍了嗎？”
Rdb檔案是什麼，它是幹什麼的
Redis 作為網際網路產品開發中不可缺少的常備武器，它效能高、資料結構豐富、簡單易用，但同時也是因為太容易用了，不管什麼資料、不管這資料有多大、不管資料有多少，通通塞進去，最後導致的問題就是 Redis 記憶體使用持續上升，但是又不知道里面的資料是不是有用，是否可以拆分和清理，最可怕的是伺服器發生宕機後，Redis 資料庫裡的所有資料將會全部丟失。
比如當記憶體上升，效能慢時，我們進行效能調優的時候，我們想知道：
-
哪些Key佔用了大量的記憶體？
-
想知道每個Key的佔用空間？
-
想知道佔用空間大的Key都存了啥？
-
想知道佔用空間大的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 的持久化。
Redis 支援兩種方式的持久化，一種是RDB方式，一種是AOF方式。
RDB 是 Redis 用來進行持久化的一種方式，是把當前記憶體中的資料集，快照寫入磁碟。
RDB - 自動
RDB（Redis DataBase）方式是通過快照完成的，當符合一定條件時Redis會自動將記憶體中的所有資料進行快照，並且儲存到硬碟上，RDB是Redis的預設持久化方式。
還可以通過命令列的方式進行配置：
RDB - 手動
-
save
該命令會阻塞當前Redis伺服器，執行save命令期間，Redis不能處理其他命令，直到RDB過程完成為止。
顯然該命令對於記憶體比較大的例項會造成長時間阻塞，這是致命的缺陷。
-
bgsave
執行該命令時，Redis會在後臺非同步進行快照操作，快照同時還可以響應客戶端請求。
具體操作是Redis程序執行fork操作建立子程序，RDB持久化過程由子程序負責，完成後自動結束。阻塞只發生在fork階段。
AOF
AOF（APPEND ONLY MODE）是通過儲存對redis服務端的寫命令（如set、sadd、rpush）來記錄資料庫狀態的，即儲存你對redis資料庫的寫操作。
配置日誌檔案如下：
RDB 與 AOF 的優缺點，見上面的即可。
至此，我們瞭解了 Redis 持久化的一些配置，裡面的細節建議查詢相關資料進行研究。
接下來繼續，通過上一步我們拿到了 rdb 檔案，就相當於拿到了Redis例項的資料。
-
解析 rdb 檔案，獲取key和value的值。
-
根據相應的資料結構及內容，估算記憶體消耗。
-
統計並生成報表。
分析工具
-
雪球 rdr：
https://github.com/xueqiu/rdr
-
redis-rdb-tools：
https://github.com/sripathikrishnan/redis-rdb-tools
小結
-
講解了工作中常用的 redis 使用場景。
-
講解了 redis 持久化的兩個方式（RDB、AOF）。
-
推薦了兩個分析rdb的工具。
通過對 redis 的使用 到 瞭解到伺服器上如何對redis資料做持久化快照，再到如何利用工具進行分析rdb檔案，最後通過分析後的資料，可以反過來對 redis 的使用提出一些建議。
其他知識點也是這樣，我們不能只停留在方法的簡單呼叫，就覺得理解了這門技術！
聯想
其實上面分析出來的資料，是不可能定位到這個key是哪個業務方的，哪個開發建立的，是否重要等等，那我們應該怎麼做呢？
-
制定開發團隊的Redis Key的使用規範，通過key的命名可以得到：
-
屬於什麼業務（加域名錶示）
-
屬於什麼資料型別（加資料型別標示）
-
是否設定過期時間
-
...
-
統一平臺進行Redis Key的申請，只有申請了才能進行使用：
-
填寫申請人
-
填寫申請時間
-
填寫申請業務方
-
填寫資料型別
-
填寫Key的重要性
-
填寫Key是否存在過期時間
-
根據填寫項生成規範的key名稱
-
...(等等需要標記的)
-
上面我們已經能分析出某個redis例項rdb檔案的內容，通過分析出來的內容 與 統一平臺申請的資料，進行整合，分析key的合格率、記憶體使用量、不同資料型別的分佈、記憶體佔用量Top 100的值 等等。
-
我們可以通過運維瞭解到，每個伺服器與例項之間的配置關係，就可以瞭解到某臺伺服器（N個例項）上的 key的合格率、記憶體使用量、不同資料型別的分佈、記憶體佔用量Top 100的值等等。
這樣，在後臺系統中就可以看到哪臺伺服器，哪個例項的使用情況，解決了Redis濫用並無法進行監控的問題。
