Redis詳解之-叢集方案：高效能（使用原生Redis Cluster）（四）

阿新 • • 發佈：2018-12-23

對以前的內容進行一下總結和複習。

瞭解Redis的基本引數配置和使用。
瞭解事件訂閱和持久化儲存方式（RDB和AOF）。
Redis叢集方案：高可用（使用Redis Sentinel），官網Rdeis3.x推薦三主三從的方式，參考（https://www.cnblogs.com/zhongkaijun/p/4728334.html）。
Redis叢集方案：高效能，Twemproxy和Redis自帶的Cluster方案（一般企業都是使用後者，後面再說明另外一種使用方式：codies+redis，客戶端通過codies代理呼叫redis服務）。

接下來讓我熟知一下：Redis叢集方案：高效能（原生Redis Cluster的使用）。

1、概述

通過上一篇文章的內容，Redis主從複製的基本功能和進行Redis高可用叢集監控的Sentinel基本功能基本呈現給了讀者。從這篇文章開始我們一起來討論Redis中兩種高效能叢集方案，並且在討論過程中將上一篇文章介紹的高可用叢集方案結合進去。這兩種高效能叢集方案是：Twemproxy和Redis自帶的Cluster方案。

2、Redis高效能叢集：Twemproxy

2-1、Twemproxy概要

Twemproxy是一個Twitter開源的一個Redis/Memcache代理伺服器，最早也是Twitter在使用。在Twitter決定開發Twemproxy時，網際網路領域使用最廣泛的快取技術還是Memcache，那個時候Redis並沒有提供原生的Cluster功能，甚至沒有Bate版本。而Twemproxy（也稱為nutcraker）恰恰是為了解決將多個獨立的Redis節點組成叢集，同時提供快取服務的問題。

您可以在GitHub上下載Twemproxy（https://github.com/twitter/twemproxy）。這個地址也可以算作Twemproxy的官網了，其上對Twemproxy的特性進行了簡要描述，包括：輕量級的快速訪問代理、減少客戶端對Redis服務的直連、支援多個Redis節點同時工作、支援資料分片、支援多種Hash演算法、故障檢查和故障節點自動排除、支援多種作業系統Linux, BSD, OS X 以及 Solaris…… 。

但是官網上並沒有明確介紹Twemproxy的缺點，而且細心的朋友可以觀察到官網上的原始碼已經有相當時間沒有更新了，這能說明什麼問題呢？本文後續內容將進行說明。下圖說明了Twemproxy的功能定位：

這裡寫圖片描述

2-2、Twemproxy基本配置

Twemproxy的基本配置非常簡單，直接解壓安裝後就可以執行。它的主要配置檔案在conf目錄下的“nutcracker.yml”檔案。由於Twemproxy的安裝太簡單了，本文就不再進行描述了，這裡給出安裝命令就可以了（CentOS 6.X / 7.X）：

// 先安裝automake、libtool等第三方支援元件
# yum install -y automake libtool
// 然後解壓下載的Twemproxy壓縮包
// 進入解壓的目錄後執行（生成configure ）
# autoreconf -fvi
// 正式開始安裝
# ./configure --prefix=您的安裝目錄
# make && make install安裝後開啟“nutcracker.yml”檔案，這個檔案實際上已經有內容了，相當於一個各種執行場景下的配置示例。各位讀者可以將這些配置資訊註釋掉或者直接刪除。這裡我們給出配置檔案中一些關鍵的配置屬性，大家只需要知道這些配置屬性的意義，就可以進行靈活操作了：

listen：這個引數用於設定Twemproxy監控的IP和埠資訊，如果要監控本機的所有IP裝置，則設定為0.0.0.0，例如0.0.0.0:22122。
hash：這個引數非常重要所以多說幾句。Twemproxy可以使用一致性Hash演算法，通過計算Key的Hash值定位這個Key對應的資料儲存在下層Redis節點的哪個位置。注意不是計算Key的資料結構，而是Key對應資料的儲存位置。Twemproxy支援多種Hash演算法，包括：md5、crc16、fnv1_64、fnv1a_64、fnv1_32、fnv1a_32、hsieh、murmur、jenkins等。之前我們介紹過，考慮採用哪種Hash演算法有兩個重要指標：Hash演算法的速度和Hash演算法的碰撞率。例如之前號稱破解了MD5演算法的王小云教授就是依靠Hash碰撞完成的，但實際上這種方式算不算完全破解呢？行業內就有很多種觀點了，這裡筆者經驗有限就不展開討論了。但MD5演算法的兩個事實依然是存在的：MD5任然是不可逆的，同時現成的破解站點也是存在的：http://www.ttmd5.com/。另外兩個事實是MD5演算法的碰撞率確實是各種Hash演算法中碰撞率非常低的，但它確實不是所有Hash演算法中速度最快的。顯然，這裡我們更看重的Hash值的計算速度而不是碰撞率，產生Hash碰撞的兩個Key其後果無非是被分配到同一個Redis節點進行儲存而已。所以這裡我們推薦設定兩種Hash演算法，murmur和fnv1a_64。
hash_tag：為了避免在業務級別有關聯的資料因為Key的Hash值不同而被散落在不用的Redis服務上（原因是當儲存部分相關聯資料的Redis下線，這個完整的業務資料就會受到影響），Redis提供了一個設定引數hash_tag來框定一個Key的部分字串，並對它進行Hash計算。這樣就可以保證有關聯的業務資料在進行Hash計算時得到同一個計算結果，從而被分配到一個Redis節點進行儲存。hash_tag由兩個字元組成，舉個例子，設定hash_tag為”[]”，這時客戶端通過Twemproxy儲存兩個Key：“user[yinwenjie]”、“sex[yinwenjie]”，那麼當Twemproxy計算這兩個Key的Hash值時，就只會採用“[]”中的字串“yinwenjie”進行，所以計算出來的Hash值都是一樣的。最終這兩個Key都會落到同一個Redis節點上進行儲存。
distribution：依據Key的資料分配模式。Twemproxy本身並不儲存資料，它的一個重要功能就是依據客戶端傳來的Key，對儲存資料的真實Redis節點進行定位。定位方式包括三種：ketama，一致性Hash演算法，關於一致性Hash演算法的介紹可以參考這篇文章：http://blog.csdn.net/yinwenjie/article/details/46620711#t1。modula，這種資料分配模式，是根據Key的Hash值取模，模的數量就是下層可工作的Redis節點數量。random，完全隨機分配Key對應的真實Redis節點。
timeout：這是一個超時時間，用來指定等待和Redis建立連線的超時時間，以及從Redis收到響應的超時時間。
backlog：“The TCP backlog argument. Defaults to 512.”這是官網上的解釋，很簡單不是嗎？實際上我們介紹Redis時也出現過類似的引數，這個引數允許當前同時進行連線的有效TCP連線數量，但是請配合Linux系統下的somaxconn的設定進行使用，否則它會失效。
preconnect：這個引數的預設值為false，主要指代當Twemproxy服務啟動時，是否需要預連線到下層的Redis服務上。
redis、redis_auth和redis_db： Twemproxy可以作為Redis和Memcache兩種快取服務的代理，當redis引數設定為false時代表它將作為Memcache的代理。另外如果下層的Redis設定了許可權驗證資訊，則Twemproxy還要通過redis_auth配置項進行相應的設定。最後，由於Redis支援多個數據庫，那麼Twemproxy預設情況下將提供編號為“0”的資料庫的代理，如果要改變請通過redis_db引數進行設定。
server_connections：這個引數設定Twemproxy可以在每一個下層Redis/Memcache服務上同時使用的連線數量，預設的值為1。
auto_eject_hosts、server_failure_limit和server_retry_timeout：Twemproxy支援自動下線（不再代理）失敗的Redis服務，如果要開啟這個功能，請設定auto_eject_hosts引數為true。這時，Twemproxy會在重試server_failure_limit次數後將還沒有連線測試成功的Redis服務從自身代理列表上去掉。而server_retry_timeout設定了每一次測試連線的等待超時時間。
servers：這個引數是一個列表，列出了Twemproxy代理的Redis的IP地址、訪問埠和權重。

以下展示了一個完整的可以使用的Twemproxy代理的配置檔案：

beta:
  listen: 0.0.0.0:22122
  hash: fnv1a_64
  hash_tag: "{}"
  distribution: ketama
  auto_eject_hosts: false
  timeout: 400
  redis: true
  servers:
   - 192.168.61.140:6379:1 server1
   - 192.168.61.145:6379:1 server2

#原有配置檔案中的其它配置資訊如果不使用則可以註釋掉

以上配置資訊中的各個屬性已經在前文詳細介紹，這裡就不再贅述了。以下是Twemproxy的啟動指令，記得要首先設定Linux下的環境變數：

# nutcracker -c ./nutcracker.yml
// 您還可以通過以下命令測試配置檔案的正確性
# nutcracker -c ./nutcracker.yml -t
// 還有更多引數可選
Usage: nutcracker [-?hVdDt] [-v verbosity level] [-o output file]
[-c conf file] [-s stats port] [-a stats addr]
[-i stats interval] [-p pid file] [-m mbuf size]

// 關於這些引數更詳細的使用說明，可以參考官方文件中的說明

2-3、LVS + Twemproxy + Keepalived + Redis + Redis Sentinel + Sentinel Agent

在生產環境下搭建Redis高效能叢集，如果其中只使用一個Twemproxy節點，那肯定是不合理的。因為那樣做會存在Twemproxy單節點故障問題，所以至少應該使用兩個Twemproxy節點。又因為Twemproxy服務的工作相對獨立，為了增加訪問效能可以使用兩個甚至多個Twemproxy節點同時提供服務，其上統一使用LVS服務進行負載分發。根據這樣的描述，我們可以構建一種在生產環境下使用的Redis高效能叢集方案：

這裡寫圖片描述

上圖中我們使用了兩組Twemproxy節點，每一組都有兩個Twemproxy節點在同一時間分別處於Active狀態和Standby狀態，在使用Keepalived元件進行狀態監控和浮動IP切換。這四個Twemproxy節點的配合資訊完全一樣，保證了無論資料讀寫請求通過LVS到達哪一個Twemproxy節點，最終計算出來的目標Redis節點都是一樣的。

但是以上方案還是有問題，就是單個Redis節點的高可用性無法保證。雖然在這樣的Redis叢集中，每一個活動的Redis節點在宕機後都可以被Twemproxy自動下線，造成的資料丟失情況也因為使用了一致性Hash演算法而被限制到了一個可控制的範圍。但是畢竟會丟失一部分資料，而且丟失的資料規模會和叢集中Redis節點數量成反比關係。所以我們還需要在上一個叢集方案的設計上再進行調整，加入我們在上一篇文章中介紹的Redis主從同步方案和Sentinel監控功能，形成第二種方案。

這裡寫圖片描述

Twemproxy提供了一個配合使用的擴充套件元件：Redis_Twemproxy_Agent，它的作用是監控Sentinel中Master節點的情況，並且將最新的Master節點情況通知Twemproxy。這樣一來當下層某組Redis高可用叢集發生Master—Slave狀態切換時，Twemproxy就會適時對其下層代理配置情況作出調整。

另外，上圖中給出的第二種生產環境下的Redis叢集方案，一共有5組獨立執行的Redis高可用叢集組，每組Redis高可用叢集都有一個Master節點和至少一個Slave節點，它們之間使用Redis原生提供的資料複製功能保持資料同步。最後這些Redis高可用叢集組通過一組Sentinel進行狀態監控，而這組Sentinel也是同時擁有一個Master節點和兩個Slave節點的高可用叢集。

3、Redis高效能叢集：Redis Cluster

3-1、Twemproxy的生產環境問題

可維護性上的問題：

LVS + Twemproxy + Keepalived + Redis + Sentinel + Sentinel Agent 的架構方案應該是筆者迄今為止介紹的層次最多，且每層元件最多的單一系統架構。Keepalived在LVS和Twemproxy都有使用，所以在不將Keepalived單獨算作一層的情況下就是4層結構（這裡說的層次都限於指本公司/機構的運維團隊需要進行維護的系統元件）。而我們介紹過的Nginx叢集方案是兩層架構（LVS+Nginx），由於智慧DNS路由一般是購買所以不參與計算；介紹過的ActiveMQ生產叢集可以是三層架構（Zookeeper + ActiveMQ + LevelDB），也可以是兩層架構（ActiveMQ + KahaBD/關係型資料庫）；介紹過的MySQL分庫分表叢集是三層架構（LVS + MyCAT + MySQL節點）。架構層次越多、每一層使用的元件越多，給運維團隊帶來的維護壓力就越大，給生產環境帶來的不穩定因素也越大。很顯然從運維角度出發，為了解決單一功能而使用四層架構的情況是不太多見的——除非業務功能不能改變且系統架構層面又沒有替代方案。
執行效能和設計思路問題：

Twemproxy並不是目前執行速度最快的Redis Proxy產品，例如豌豆莢在2014年開源的一款產品Codis就可以當做Twemproxy的替代方案。Codis對下層Redis節點的組織方式個人認為要優於Twemproxy，例如它將下層的Redis節點明確分為多個組，每個組中有一個Master和至少一個Slave節點，並且採用了類似隨後要介紹的Redis Cluster那樣的預分片方式（Slot），另外它還採用了ZK對各節點的工作狀態進行協調。要知道Twemproxy雖然支援健康檢查，也支援宕機節點的自動刪除，但是Twemproxy並不支援資料轉移。也就是說當某個Redis節點下線後，其上的資料也不會轉移到其它節點上，而且Twemproxy中使用一致性Hash演算法的基點或者取模運算所使用的基數也會發生變化。而如果引入的組的概念後，就可以減輕這個問題產生的風險，因為在一個組中的Master節點一旦出現問題，就會有Slave節點來接替它，而不會出現資料丟失問題。最後，根據豌豆莢自己的測試和廣大網友自行測試的結果看，Codis對下層Redis節點的代理效能也要優於Twemproxy。
其它問題：

Redis的資料結構中，我們可以使用Set結構進行交併補運算。但是Twemproxy代理不支援這樣的運算。另外Twemproxy也不對事務功能提供支援。

3-2、Redis原生的Cluster支援

可以說Twemproxy是早期Redis原生的Cluster沒有成熟時的替代方案，而後Redis官方推薦的高效能叢集方案還是基於其原生的Redis Cluster功能。Redis Cluster從Redis 3.0開始引入，實際上那個時候還是一個Bate版本，光放也不建議在生產環境下使用。但是到了目前最新的Version 3.2版本，Redis Cluster已經非常穩定了。

這裡寫圖片描述

（上圖來源於網路）

3-3、Redis Cluster基本配置示例

這裡我們給出一個Redis Cluster的安裝示例，首先介紹一下這個Redis Cluster的配置示例要達到的部署效果，這樣才便於各位讀者繼續閱讀。在這個示例場景中我們有兩臺物理機，每臺物理機上啟動了三個Redis節點，一共六個節點，並讓它們按照Cluster模式工作起來。如下表所示：

IP和埠	配置檔名
192.168.61.140:6379	redis.conf.140_6379
192.168.61.140:6380	redis.conf.140_6380
192.168.61.140:6381	redis.conf.140_6381
192.168.61.145:6379	redis.conf.145_6379
192.168.61.145:6380	redis.conf.145_6380
192.168.61.145:6381	redis.conf.145_6381

請注意，在生產環境中筆者並不建議在一臺物理機上/虛擬機器上部署多個Redis節點，因為這樣大大增加了多個Redis節點同時不可用的風險，但這是示例場景所以無所謂啦。

3-3-1、Redis安裝和配置檔案部署

由於有六個節點參與到叢集中，所以我們需要準備六份不同的配置檔案。讀者可以將這6個檔案存放到不同的資料夾下：

========== 192.168.61.145:6379 ==========
######### NETWORK #########
bind 192.168.61.145
port 6379
######### GENERAL #########
pidfile "/var/run/redis_6379.pid"
######### REDIS CLUSTER #########
cluster-enabled yes
cluster-config-file nodes.145_6379
cluster-node-timeout 15000
######### APPEND ONLY MODE #########
appendonly yes

========== 192.168.61.145:6380 ==========
######### NETWORK #########
bind 192.168.61.145
port 6380
######### GENERAL #########
pidfile "/var/run/redis_6380.pid"
######### REDIS CLUSTER #########
cluster-enabled yes
cluster-config-file nodes.145_6380
cluster-node-timeout 15000
######### APPEND ONLY MODE #########
appendonly yes

========== 192.168.61.145:6381 ==========
######### NETWORK #########
bind 192.168.61.145
port 6381
######### GENERAL #########
pidfile "/var/run/redis_6381.pid"
######### REDIS CLUSTER #########
cluster-enabled yes
cluster-config-file nodes.145_6381
cluster-node-timeout 15000
######### APPEND ONLY MODE #########
appendonly yes

========== 192.168.61.140:6379 ==========
######### NETWORK #########
bind 192.168.61.140
port 6379
######### GENERAL #########
pidfile "/var/run/redis_6379.pid"
######### REDIS CLUSTER #########
cluster-enabled yes
cluster-config-file nodes.140_6379
cluster-node-timeout 15000
######### APPEND ONLY MODE #########
appendonly yes

========== 192.168.61.140:6380 ==========
######### NETWORK #########
bind 192.168.61.140
port 6380
######### GENERAL #########
pidfile "/var/run/redis_6380.pid"
######### REDIS CLUSTER #########
cluster-enabled yes
cluster-config-file nodes.140_6380
cluster-node-timeout 15000
######### APPEND ONLY MODE #########
appendonly yes

========== 192.168.61.140:6381 ==========
######### NETWORK #########
bind 192.168.61.140
port 6381
######### GENERAL #########
pidfile "/var/run/redis_6381.pid"
######### REDIS CLUSTER #########
cluster-enabled yes
cluster-config-file nodes.140_6381
cluster-node-timeout 15000
######### APPEND ONLY MODE #########
appendonly yes

以上只是列舉了要參與Redis Cluster的六個節點中和本節內容相關的重點配置項，包括網路配置、一般性配置和叢集部分的配置。其它的配置項可以根據讀者所處技術環境的自行決定，例如是否開啟主動SNAPSHOTTING的策略問題，因為Cluster中的Master都會有一個或者多個Slave節點，所以基本上一組高可用叢集的資料不會同時丟失，而Master和Slave間的資料同步還是依靠Redis原生的主從同步方案完成的，所以Redis Master節點還是會做被動作SNAPSHOTTING動作。以下是六個節點的啟動命令：

// 啟動145上的三個redis節點
# redis-server ./redis.conf.145_6379 &
# redis-server ./redis.conf.145_6380 &
# redis-server ./redis.conf.145_6381 &
// 啟動140上的三個redis節點 
# redis-server ./redis.conf.140_6379 &
# redis-server ./redis.conf.140_6380 &
# redis-server ./redis.conf.140_6381 &

以上啟動命令和您放置配置檔案具體位置有關、和您是否設定了環境變數有關，還和您準備如何檢視命令執行日誌有關。所以具體執行引數肯定是有差異的。請注意，在第一次單獨啟動某個Redis節點時，您可能會看到類似以下的提示：

//============= redis.conf.145_6380節點
......
18449:M 29 Dec 18:32:52.036 # I have keys for unassigned slot 95. Taking responsibility for it.
18449:M 29 Dec 18:32:52.036 # I have keys for unassigned slot 219. Taking responsibility for it.
18449:M 29 Dec 18:32:52.038 # I have keys for unassigned slot 641. Taking responsibility for it.
......

//============= redis.conf.145_6381節點
......
9582:M 29 Dec 18:43:49.048 # I have keys for unassigned slot 95. Taking responsibility for it.
9582:M 29 Dec 18:43:49.048 # I have keys for unassigned slot 219. Taking responsibility for it.
9582:M 29 Dec 18:43:49.048 # I have keys for unassigned slot 641. Taking responsibility for it.
......

這是因為Redis啟動時，會自動建立技術人員在cluster-config-file配置項設定的叢集配置檔案，例如nodes.140_6380、nodes.140_6381這些檔案，並且會預設託管一些slots。但細心的讀者可以發現，這六個節點獨立啟動時預設託管的slots資訊都是一樣的。這是因為這些節點還沒有建立通訊機制，並不能協調slot的管理資訊。而且這些cluster-config-file中都會預設自身節點是一個Master節點。

經過以上過程我們啟動了六個節點，但是到目前為止這六個節點還是獨立工作的並沒有形成叢集。這是因為各個cluster-config-file中並沒有明確協調哪些節點將成為Master節點，哪些節點將成為Slave節點並且他們的主從對映關係，也沒有協調任何和節點發現有關的資訊，同樣也沒有協調各個節點的ID資訊或者節點所對映的Master的ID資訊，更沒有協調各個節點分別負責的slot資訊。那麼以上這些協調動作都是通過下一個操作步驟。

這裡寫圖片描述

（上圖說明了各個Redis節點單獨啟動後的Redis Cluster狀態）

3-3-2、Ruby安裝和叢集命令執行

Redis Cluster通過執行一個Ruby指令碼進行初始化和啟動，如果您的作業系統還沒有安裝Ruby，請進行安裝（以下示例的安裝命令適用於CentOS）：

# yum install -y ruby rubygems
......
# gem install redis
Successfully installed redis-3.3.2
1 gem installed
Installing ri documentation for redis-3.3.2...
Installing RDoc documentation for redis-3.3.2...
......

在Redis的原始檔目錄的src目錄中，有一個Ruby指令碼檔案“redis-trib.rb”，通過執行這個指令碼檔案可以完成Redis Cluster的初始化和啟動操作。如果各位讀者希望以後都能方便的執行這個指令碼檔案，可以先將這個指令碼檔案Copy到Redis的執行目錄下：

# cp 你的原始碼路徑/redis-trib.rb /usr/local/bin/redis-trib.rb
//或者
# cp 你的原始碼路徑/redis-trib.rb /usr/redis/bin/redis-trib.rb
......

接下來就可以執行這個指令碼了：

# redis-trib.rb create --replicas 1 192.168.61.140:6379 192.168.61.140:6380 192.168.61.140:6381 192.168.61.145:6379 192.168.61.145:6380 192.168.61.145:6381
>>> Creating cluster
>>> Performing hash slots allocation on 6 nodes...
Using 3 masters:
192.168.61.145:6379
192.168.61.140:6379
192.168.61.145:6380
Adding replica 192.168.61.140:6380 to 192.168.61.145:6379
Adding replica 192.168.61.145:6381 to 192.168.61.140:6379
Adding replica 192.168.61.140:6381 to 192.168.61.145:6380
M: 1cf10fb6d7c0ad4d936b1c061a99d370bda07757 192.168.61.140:6379
   slots:5461-10922 (5462 slots) master
S: 8749db7b6a5860be63f592e94388239a7467cbb1 192.168.61.140:6380
   replicates 3ee2a9f173ccbee3a5a79b082af2910be7d22e57
S: 33f9ee49963a32220984122278105cdda7761517 192.168.61.140:6381
   replicates 120bc340ed1b24ba8e07368cf18d433094644e6e
M: 3ee2a9f173ccbee3a5a79b082af2910be7d22e57 192.168.61.145:6379
   slots:0-5460 (5461 slots) master
M: 120bc340ed1b24ba8e07368cf18d433094644e6e 192.168.61.145:6380
   slots:10923-16383 (5461 slots) master
S: 0b107150f7c075fe7ba701b64a9f7bf9f7896ead 192.168.61.145:6381
   replicates 1cf10fb6d7c0ad4d936b1c061a99d370bda07757
Can I set the above configuration? (type 'yes' to accept): yes

以上命令中，create引數代表建立一個新的新的Redis Cluster，然後我們後給出了一個replicas引數，這個引數代表叢集中的每一個Master節點對應多少個Slave節點，這裡給出的數值是1，就代表每一個Master節點會對應一個Slave節點。需要注意，這裡並不需要明確指定哪些節點將成為Master節點，哪些節點將成為Slave節點，而redis-trib會參考replicas引數的值自行計算得出。在命令的最後我們還給出了參與這個新的Redis Cluster的所有Redis節點的資訊。

redis-trib會根據以上這些引數預計一個可能的配置資訊，特別是初始化的Master和Slave節點的預計情況、每個節點的ID編號以及每個Master節點負責的Slot。接著redis-trib會將這份報告呈現給技術人員，由後者最終確定是否執行初始化。輸入“yes”，redis-trib就將按照這份計劃執行Redis Cluster的建立工作了：

......
>>> Performing Cluster Check (using node 192.168.61.140:6379)
M: 1cf10fb6d7c0ad4d936b1c061a99d370bda07757 192.168.61.140:6379
   slots:5461-10922 (5462 slots) master
   1 additional replica(s)
S: 33f9ee49963a32220984122278105cdda7761517 192.168.61.140:6381
   slots: (0 slots) slave
   replicates 120bc340ed1b24ba8e07368cf18d433094644e6e
S: 0b107150f7c075fe7ba701b64a9f7bf9f7896ead 192.168.61.145:6381
   slots: (0 slots) slave
   replicates 1cf10fb6d7c0ad4d936b1c061a99d370bda07757
M: 3ee2a9f173ccbee3a5a79b082af2910be7d22e57 192.168.61.145:6379
   slots:0-5460 (5461 slots) master
   1 additional replica(s)
S: 8749db7b6a5860be63f592e94388239a7467cbb1 192.168.61.140:6380
   slots: (0 slots) slave
   replicates 3ee2a9f173ccbee3a5a79b082af2910be7d22e57
M: 120bc340ed1b24ba8e07368cf18d433094644e6e 192.168.61.145:6380
   slots:10923-16383 (5461 slots) master
   1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

到此為止6個節點的Redis Cluster就建立完成了，除了初始化建立Redis Cluster外，您還可以參考官方網站上的介紹完成Redis Cluster中的節點新增、刪除或者其它操作：https://redis.io/topics/cluster-tutorial。

3-3-3、使用客戶端進行連線

客戶端進行叢集環境的連線，就是一個更簡單的工作了。實際上Redis的客戶端並不需要連線到Redis Cluster中的所有節點，就可以完整操作Redis Cluster中的資料。這是因為每個Redis Cluster中的節點都清楚整個叢集的全域性情況，特別是Slot存在的位置。以下示例程式碼展示瞭如何通過Java程式碼連線到Redis Cluster：

......
JedisPoolConfig config = new JedisPoolConfig();
config.setMaxTotal(10);
config.setMaxIdle(2);

// 這裡新增叢集節點。可以新增多個節點，但並不是需要新增Cluster的所有節點
HostAndPort node0 = new HostAndPort("192.168.61.140", 6379);
HostAndPort node1 = new HostAndPort("192.168.61.145", 6379);
Set<HostAndPort> nodes = new HashSet<HostAndPort>();
nodes.add(node0);
nodes.add(node1);

// 建立和連線到叢集
JedisCluster jedisCluster = new JedisCluster(nodes, 5000, 10, config);  

//==============================
// 做你要做的Redis操作吧，少年
//==============================

jedisCluster.close();
......來源：http://blog.csdn.net/yinwenjie（未經允許嚴禁用於商業用途！

Redis詳解之-叢集方案：高效能（使用原生Redis Cluster）（四）

對以前的內容進行一下總結和複習。

1、概述

2、Redis高效能叢集：Twemproxy

2-1、Twemproxy概要

2-2、Twemproxy基本配置

2-3、LVS + Twemproxy + Keepalived + Redis + Redis Sentinel + Sentinel Agent

3、Redis高效能叢集：Redis Cluster

3-1、Twemproxy的生產環境問題

3-2、Redis原生的Cluster支援

3-3、Redis Cluster基本配置示例

3-3-1、Redis安裝和配置檔案部署

3-3-2、Ruby安裝和叢集命令執行

3-3-3、使用客戶端進行連線

Redis詳解之-叢集方案：高效能（使用原生Redis Cluster）（四）

Redis詳解之-叢集方案：高效能（Codis3.2+Redis Cluster）（五）

Redis詳解之-叢集方案：高可用（使用Redis Sentinel）（三）

架構設計：系統儲存（18）——Redis叢集方案：高效能

.Net使用Redis詳解之ServiceStack.Redis（七）

OSPF詳解之三：OSPF LSA詳解

小程序學習筆記二：頁面文件詳解之 .json文件

spring-data詳解之spring-data-jpa：簡單三步快速上手spring-data-jpa開發

[轉]javaCV開發詳解之5：錄製音訊(錄製麥克風)到本地檔案/流媒體伺服器(基於javax.sound、javaCV-FFMPEG)

ALSA音效卡驅動中的DAPM詳解之二：widget-具備路徑和電源管理資訊的kcontrol

ALSA音效卡驅動中的DAPM詳解之七：dapm事件機制（dapm event）

Java單元測試工具：JUnit4（三）——JUnit詳解之執行流程及常用註解

大資料之hdfs詳解之三：put許可權剖析與常用命令

kafka配置檔案詳解之：server.properties

redis詳解——redis叢集搭建和使用（二）

redis詳解（四）-- 高可用分散式叢集

作業系統：程序排程演算法詳解之FCFS和SPF篇

各種音視訊編解碼學習詳解之編解碼學習筆記（一）：基本概念

各種音視訊編解碼學習詳解之編解碼學習筆記（三）：Mpeg系列——Mpeg 1和Mpeg 2

各種音視訊編解碼學習詳解之編解碼學習筆記（二）：codec型別

Redis詳解之-叢集方案：高效能（使用原生Redis Cluster）（四）

對以前的內容進行一下總結和複習。

1、概述

2、Redis高效能叢集：Twemproxy

2-1、Twemproxy概要

2-2、Twemproxy基本配置

2-3、LVS + Twemproxy + Keepalived + Redis + Redis Sentinel + Sentinel Agent

3、Redis高效能叢集：Redis Cluster

3-1、Twemproxy的生產環境問題

3-2、Redis原生的Cluster支援

3-3、Redis Cluster基本配置示例

3-3-1、Redis安裝和配置檔案部署

3-3-2、Ruby安裝和叢集命令執行

3-3-3、使用客戶端進行連線

相關推薦