學習路徑

• 掌握數據類型（分析底層數據結構）和緩存的基本使用? ?(理論+使用)?
• 掌握 redis 實現高性能，高可靠、高可用技術? （理論）
• 學習redis源代碼底層實現? (底層實現)

先來一個引言，比較宏觀的角度，先不考慮細節問題（先不談理論，按照正常的發展思路，看看需要解決哪些問題，于是衍生出哪些技術）：

Redis是一款內存數據庫，這個數據存儲在內存中，如果說突然發生意外，Redis主機斷電了宕機了，那么內存中的數據就丟失掉了。所以我們需要像個辦法解決由于斷電、宕機導致的Redis在內存當中的數據丟失性問題？

你說，我們可以從新從MySQL后端數據庫來恢復，但是這樣太慢了，幾乎就是從頭開始。我們是否可以在 Redis 本機所在機器上永久的保存數據？

所以我們需要持久化的技術來解決。要持久化，就意味著數據必須保存到非易失性存儲介質磁盤上。（AOF寫操作日志、RDB內存快照持久化機制）。

這樣子，就不擔心這個數據丟失了。

但是，如果Redis發生了宕機，我們雖然有持久化，可以進行數據恢復，但是恢復是需要一定時間的，恢復的過程就沒法對外提供服務，這顯然也是不可接受的。

所以，我們需要解決在主要節點數據恢復期間還可以正常對外提供服務的問題？ (主從復制)

我們就可以搞多個服務節點嘛，一個服務節點掛掉了，可以讓其他服務節點繼續提供嘛。如果這些服務節點有一個Boss 節點，其他的服務節點都是從Boss節點這里copy來的。Boss節點同步跟新這些子節點。如果是子節點掛掉，其實影響并不大，如果Boss節點掛掉，這個影響就特別大。

所以，我們需要解決在這個Boss節點掛掉的情況下，從下屬節點中從新選拔一個Boss出來？(手動主從切換? ?---》 自動主從切換)

選這個節點那肯定是跟 Boss 關系最近，最像的。（涉及一個選舉問題）

這些都是單個Redis實例之上的問題，如果說一個Redis實例太大了。會不會出現許多問題？比如說持久化產生的文件AOF，RDB會不會特別大？太大了，這個恢復過程會不會特別緩慢，多個節點從Boss主節點那里copy代價會不會變大？

要解決這個問題，我們是不是可以想到把數據分攤到多個 Redis 實例上面去，做一個分流。當然可以。不過需要考慮很多問題。負載均衡的問題，還有這個數據分片的問題。我們把整個需要緩存的數據切開多份。

每一份如何對應給Redis實例？用什么算法去對應？

我首先可以想到的就是Hash，因為hash天然對應很多槽位。我們可以對數據的key值進行Hash運算、映射到槽位，槽位是固定的。我們可以把槽位分配給Redis主機。

再思考一下，當我們維護多實例的時候，必不可少的需要通信，所以實例與實例之間應該依賴什么來進行通信，來達到一個狀態的同步，一致性。這必然也是需要解決的問題。但是小杰這塊尚且無法理解。所以慢慢沉淀。

如下這些標題，就是小杰之后寫這個博客后續要完成的，現在只是寫出自己的一個規劃目錄。后續再驅動性、方向性的步步完成。

Redis數據類型的使用

Redis底層數據結構

Redis緩存機制和應用

Redis高性能原理

Redis高可靠策略

• 持久化機制

Redis高可用策略

• 主從復制機制
• 故障轉移，自動恢復