Redis叢集架構概述

• 單例項Redis問題分析
  首先Redis是一個快取資料庫，而且可以承受每秒10w的訪問量，同時Redis資料庫還可以將資料進行持久化儲存，這樣即使在Redis關閉之後資料也可以被儲存下來。
  但是除了這些基本知識之外，在整個系統的開發架構之中，Redis也有著非常重要的地位。

應用場景：

在進行web專案開發的時候，為了保證效能高效，往往會使用大量的web伺服器來一起共同承擔起使用者的高併發訪問，而在這種處理環境之中就會產生一個Session跨域的問題。

在你去X東或者X寶購買商品的時候會推薦同類商品，或者你去看一些X條的新聞資訊，會發現它也會自動推薦你感興趣的內容，所以這樣的操作都是基於大資料的分析統計結果來得來的。

秒殺活動等

那麼有了Redis之後，這些Web伺服器上的Session的記憶體資料將不再單獨儲存，而是集中儲存在了Redis資料庫裡面，這樣即便有了再多的web容器，也可以區分唯一的的使用者的Session。

或者

另外的核心就在於大資料的一個分析框架，Strom。

總結：在很多的開發之中Redis很重要，也就是說如果專案裡沒有了Redis，那麼對於整個專案而言就會出現一個癱瘓。那麼現在一個最為明確的問題出現了，如果在專案執行之中，Redis突然損壞了。

對於Redis的叢集不一定是主機的當機，也可能是因為網路問題、機房斷電等問題。所以單例項的Redis開發操作是不能夠被簡單應用的，尤其是在一些高可用的環境下，比如：你是一個跨國公司的架構師，你必須保證及時你的某一臺網路節點主機出現了問題之後，可以在很短的時間內進行有效的切換，以保證服務的持續提供。

所以本次的內容就是圍繞如何搭建高可用的Redis叢集服務為主，以避免由於某一個節點出現問題而導致整體的專案的癱瘓。實現Redis叢集，以保證整個程式的高可用性。

• Redis叢集設計方案
  叢集的核心意義：實際上所謂叢集的核心意義就是：保證一個節點出現了問題之後，其它的節點可以可以繼續供服務使用。那麼在Redis基礎部分講解過主從配置 ，一共有兩類：一主二僕，層級關係，不過從實際開發的角度來講，一主二僕是一種比較常用的手段。
  一主二僕的配置的核心意義在於：一個Master節點，而後配置兩個Slave節點，並且這個兩個slave節點的資料與Master節點的資料同步，及時master節點出現了問題之後，slave節點也可以保證資料的存在。

Redis主從配置是所有Redis叢集的基礎。但是隻是依靠主從依然無法實現高可用配置。
Redis雖然提供有簡單的主從配置，但是這樣給我們帶來的自動的幫助是非常少的，我們更多的情況下是希望：如果某一個Redis出現了問題，那麼對於專案可以自動進行可用的Redis恢復，那麼這個時候就需要在主從的基礎上使用更多的叢集配置。

對於Redis叢集而言，首先在主從的基礎上發展出了一個哨兵的處理機制，所謂的哨兵的處理機制指的是:當三臺主機之中的master節點出現了問題之後，會自動的在兩個slave節點裡面重新選舉出新的master節點。這樣就可以保證原始的Master節點出現問題之後，Redis資料依然存在有主從的配置。

但是哨兵機制也只是針對於單主機的一種配置形式。你現在如果只有一臺Redis主機，那麼即使你的電腦效能再好，面對廣大人民群眾的力量也可能招架不住，所以很明顯不可能只使用一臺主機來實現Redis配置。

而推特網站釋出了一個代理機制，而已有效的實現資料的分片儲存，即根據不同的演算法實現不同主機的分片儲存，以保證負載均衡，同時可以結合keepalived元件實現twemproxy的高可用。
Redis在後來的版本發展之中也推出了一個redis-cluster叢集配置，利用這樣的配置可以不用自己來通過配置檔案實現主從關係的實現，而直接通過命令完成。但是它有一個問題，所有的主機不能夠動態擴充。

叢集之中最好的方案：codis

如果從可擴充套件的角度來講，codis是整個Redis實現叢集最好的一套方案。因為它的可擴充套件性非常強悍。（動態）
國內開源元件。

Redis哨兵機制

• 哨兵機制簡介
  只要是進行高可用的架構部署，那麼就必須保證多節點，在Redis裡面使用了主從模式可以可以實現多節點配置，傳統的主從模式設計有一個缺陷：一旦Master主機出現了問題之後，兩臺slave主機將無法提供正常的工作支援，例如：slave主機為只讀主機，而且如果要想繼續提供支援，那麼你至少應該通過剩餘的slave裡面去推選出一個新的master，並且最為重要的是，這個新的Master還必須能被使用者的程式找到。

通過以上的解釋實際上就可以發現，如果先要進行哨兵機制的實現，一定需要具備有如下的幾個特點：

• *哨兵機制實現
  1.如果想要進行哨兵機制配置及使用，請確保你的主機上已經準備好了Redis服務，本次將在一臺主機上模擬哨兵機制，
  原則：一臺主機執行三個哨兵，並且該哨兵執行埠不同，但是這三個哨兵都要去監控同一個master的地址。

啟動三臺redis服務：

/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis-6379.conf
/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis-6380.conf
/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis-6381.conf

2.通過Redis原始碼拷貝出哨兵的執行程式。
cp /usr/local/src/redis-4.0.9/src/redis-sentinel /usr/local/redis/bin/
3.所有的哨兵如果要想執行一定要準備出一個配置檔案：
sentinel.conf
sentinel的預設埠——-26379

對於此配置檔案已經給出了一個參考模板/usr/local/src/redis-4.0.9/sentinel.conf

4.建立sentinel-26379的配置檔案：
建立一個哨兵的配置檔案目錄
mkdir -p /usr/data/redis/{sentinel-26379,sentinel-26380,sentinel-26381} 做一個數據目錄

vim /usr/local/redis/conf/sentinel-26379.conf

配置哨兵監聽埠：port 26379
配置哨兵的工作目錄：dir /usr/data/redis/sentinel-26379
設定監控的master：sentinel monitor mymaster 192.168.231.128 6379 2
設定的mymaster只是一個代表名稱，如果你配置了多個哨兵，一個哨兵監控多個master，則這個名稱一定要有所不同，而後的2表示如果有兩個哨兵認為你出現了問題，則你應該下線，選舉出新的master。

設定master的認證資訊：sentinel auth-pass mymaster wanghaoxin
設定master不活躍的時間：sentinel down-after-milliseconds mymaster 30000
選舉新的master失敗時間：sentinel failover-timeout mymaster 180000
只有一個master同步：sentinel parallel-syncs mymaster 1
撤銷Redis的保護模式：redis.conf中有一個屬性：
protected-mode yes
在sentinel-26379.conf配置中新增：
protected-mode no
如果不設定最後一項：則哨兵不會做所謂的選舉操作，哨兵不具備操作redis的能力。

隨後按照這樣的配置建立sentinel-26380.conf和sentinel-26381.conf兩個配置檔案。

cp /usr/local/redis/conf/sentinel-26379.conf /usr/local/redis/conf/sentinel-26380.conf
cp /usr/local/redis/conf/sentinel-26379.conf /usr/local/redis/conf/sentinel-26381.conf

強烈建議將此時的配置做一個副本
mkdir /usr/local/redis/backup/
cp /usr/local/redis/conf/* /usr/local/redis/backup/

5.啟動三個哨兵程序。
/usr/local/redis/bin/redis-sentinel /usr/local/redis/conf/sentinel-26379.conf
/usr/local/redis/bin/redis-sentinel /usr/local/redis/conf/sentinel-26380.conf
/usr/local/redis/bin/redis-sentinel /usr/local/redis/conf/sentinel-26381.conf

通過哨兵的資訊輸出可以發現如下特點：
1.+slave 當一個哨兵啟動之後已經確定了可以連線到master節點，則自動追加所有節點
2.+sentinel 每當啟動一個新的哨兵程序後會自動進行哨兵增加的資訊提示。
三個哨兵都會監控master和它對應的子結點。但是如果master一旦掛掉。
6.直接kill掉當前監控的master主機：
隨後會發現有如下提示資訊：

23：30之後的資訊：

“+sdown master 192.168.231.128 6379 ”：當前master主機下線了
“+vote-for-leader”：進行了重新的投票選舉，
“+slave-reconf-sent slave 192.168.231.128 6381”:從主機會自動修改redis.conf配置檔案，
“switch-master mymaster 192.168.231.128 6379 192.168.231.128 6380”:切換新的master 為6380
6381變成6380的從主機

8.如果此時6379的程序又重新啟動成功了：那麼這個時候可以考慮通過命令做一個從的設定，一定要求設定好redis-6379.conf檔案中的master-auth屬性，如果不進行此項配置則無法連線到msater主機，6380 下的master只有一個節點，6381 而沒有6379

同時發現哨兵檔案對應的配置內容已經發生了改變，證明在整個哨兵執行機制裡面，所有的配置檔案都有可能出現更改。
—-配置檔案更改可能導致風險，會導致配置檔案維護起來比較麻煩。

• Jedis訪問哨兵機制
  現在為止已經成功的實現了哨兵處理機制，但是對於程式的編寫依然需要注意一點：如果要進行哨兵的處理操作，那麼一定要求通過哨兵來取得可用的master的地址。
  此處採用6379作為master主機來操作
  範例：使用jredis進行資料操作。
  如果要通過哨兵機制進行Redis訪問，那麼必須要明確設定出所有可以使用的哨兵的地址與埠

取消

不是直接連線redis的。而是通過哨兵連線的
如果這個時候主機的master被幹掉了，那麼也可以通過同樣的模式獲取一個可用的master的地址。
自動切換主機