在高可用這條路上你知道Redis有多努力嗎

原創：花括號MC(微信公衆號：huakuohao-mc)。關注JAVA基礎編程及大數據，注重經驗分享及我的成長。

自我介紹

我，Redis,內存數據庫，有着比memcached更強大的功能。如今已是這個領域的頭把金交椅。

常規數據庫

這裏所說的常規數據庫是指基於硬盤讀寫的數據庫，好比Oracle，Mysql，Mongodb等。基於硬盤讀寫的數據庫能夠有效的保證數據的高可用性。這裏的高可用性指的是操做系統或者數據庫崩潰以後，不會形成數據丟失，這也是對數據庫的最基本要求。

內存數據庫

基於硬盤讀寫的數據庫雖然能夠保證數據的高可用性，可是讀寫速度比較慢，這也是磁盤I/O的自然屬性。雖然切換固態硬盤以後，性能會有顯著提高，可是經濟成本也會隨之升高，並且固態硬盤使用壽命偏低。爲了解決這個問題，Redis作出了改變。Redis是基於內存進行讀寫的數據庫，把數據所有存儲在內存中，這樣就能夠大幅提升數據的讀寫速度。

memcached

說到內存數據庫，不得不提memcached，memcached比Redis出現的更早，也是基於內存進行數據存儲。在十幾年前，你們通用的緩存方案就是memcached。memcached支持Key-Value形式的數據存儲，可是隻支持String類型的數據結構，不支持更復雜的數據結構，也不支持集羣。 操做系統或者memcached重啓後數據就會丟失。這也是基於內存進行數據存儲的最大缺點。

Redis

Redis繼承了memcached全部的優勢，並改進了不少缺點。好比Redis也是基於內存進行數據操做，而且支持更多的數據類型，好比List，Set等。最最主要的，也是這篇文章的重點，Redis支持數據高可用，也就是說Redis或者操做系統重啓以後，數據不會丟失。

Redis在高可用這條路上所付出的努力，就像一個不斷努力進取的勵志青年。

單機持久化

衆所周知，放在內存中的數據是不穩定的。爲了解決由於系統或者Redis重啓形成的數據丟失問題。Redis提供了兩種數據持久化方案。

1. 快照備份 把Redis數據庫中的數據，定時備份到磁盤中。當數據庫重啓的時候，能夠經過定時備份到磁盤文件中的快照文件進行數據恢復。這樣Redis既保證了數據的讀寫速度，又保證了數據的高可用。
2. AOF同步寫 快照備份有個缺點，就是會丟失一部分數據。好比在新的快照文件生成以前，系統發生了問題，那麼最近一次快照以後的數據將丟失。Redis爲了解決這個問題，提出了AOF解決方案。 所謂的AOF就是將每次寫入數據的命令都以追加的方式記錄到文件中。這樣在系統出問題的時候，只要將這個文件中的命令所有重放一下就OK了。這樣就能夠作到不丟數了。

可是若是數據寫入操做太多的話，會形成AOF文件過大，爲了解決這個問題Redis提供了AOF自動壓縮功能，以及去重功能，這樣能夠達到對文件體積大小進行優化的目的。

主從複製

上面的兩種持久化方案，對於單節點Redis來講，基本已經夠用了。可是咱們的系統老是越作越大，要求愈來愈多。有的時候單節點Redis每每撐不住系統的訪問量。這種狀況下Redis提供了主從模式。

所謂的主從模式就是一個主節點，負責讀和寫，一個從節點，負責將主節點的數據同步到從節點，這樣主從節點信息就是一致的。 注意：從節點不支持寫操做，可是能夠支持讀操做。當其中任意一個點掛掉以後，數據不會損失。並且能夠將讀的壓力分散到多個節點，支持更大的訪問量。

哨兵模式

對於主從模式，這裏有個最大的痛點。當主節點掛掉後，從節點是不會自動升級爲主節點的。也就是負責往Redis寫入的程序會報錯，可是讀操做不會有問題。這一點不太符合高可用的要求。爲了解決發生故障，主節點自動切換的問題，Redis又給你們提供了哨兵模式。

所謂的哨兵模式就是，提供三個哨兵節點（一樣是Redis實例，只不過不存儲數據），來監控主從模式下的全部Redis節點（真正存儲數據的節點）。客戶端程序經過哨兵節點獲取主節點信息。當主節點掛掉後，哨兵節點會自動將其中一個從節點升級爲主節點，提供給客戶端程序執行寫入操做。當發生故障的主節點恢復後，會自動變爲新的主節點的從節點。

集羣模式

你們可能發現了，不管是主從複製模式，仍是哨兵模式都沒有解決分佈式寫的問題，也就是說到目前爲止，全部的方案都只能往一個節點寫數據，數據存儲能力受單節點限制。哨兵模式僅僅解決了主從複製模式下，發生故障後不能自動切換的問題。 爲了解決分佈式寫的問題，Redis提供了集羣功能。

Redis集羣能夠實現分佈式寫。集羣中的節點分爲主節點和從節點。主節點負責數據的讀寫以及集羣信息的維護，從節點負責同步主節點的信息。

Redis集羣利用數據分片的概念，將要操做的Key進行哈希計算，根據獲得的結果決定這個Key應該存儲到那個主節點。這樣就能夠利用多個主節點進行分佈式寫操做。進行讀操做的時候也會先計算Key的哈希值，而後找到對應的主節點。

很遺憾的是，集羣模式也不是百分百完美，好比key的批量操做會受限制，只有當操做的key都位於一個槽位時才能進行操做。還有Keys操做，只能在任一節點發生，不能跨節點。其實這些全部缺點，都是由於分佈式寫形成的，由於你把數據分別存到了不一樣的Redis節點。

總結

Redis由單節點的持久化，到主從複製模式，再到哨兵模式，再到最後的集羣模式。一路打怪升級，不斷的完善本身。

---

推薦閱讀

1. Java併發編程那些事兒(十)——最後的總結

2. Java8的Stream流真香，沒體驗過的永遠不知道

3. Awk這件上古神兵你會用了嗎

4. 手把手教你搭建一套ELK日誌搜索運維平臺

·END·
 

花括號MC

Java·大數據·我的成長

微信號：huakuohao-mc