Redis 單例、主從模式、sentinel 以及集群的配置方式及優缺點對比（轉）
摘要: redis作為一種NoSql數據庫，其提供了一種高效的緩存方案，本文則主要對其單例，主從模式，sentinel以及集群的配置方式進行說明，對比其優缺點，闡述redis作為一種緩存框架的高可用性。
redis作為一種高效的緩存框架，使用是非常廣泛的，在數據存儲上，在運行時其將數據存儲在內存中，以實現數據的高效讀寫，並且根據定制的持久化規則不同，其會不定期的將數據持久化到硬盤中。
另外相較於其他的NoSql數據庫，redis提供了非常豐富的數據結構，如dict，sds，linkedlist，ziplist，set，quicklist，geometry。
在這些存儲結構的基礎上，redis為用戶提供了非常豐富的操作選擇，如通過zskiplist來達到對某種類型的數據的排序目的，而排序在數據庫中是一個非常耗時的操作。
Redis 單例的安裝和使用
redis相對於其他的緩存框架安裝非常的方便，只需要從https://redis.io/download下載後解壓，進入redis目錄之後執行如下命令即安裝完成：
make install
這裏需要註意的是make是gcc中的一個命令，安裝之前請確保機器安裝了gcc。redis中所有的命令都在redis安裝目錄中的src子目錄下，其中比較重要的是redis-server，redis-sentinel，redis-cli。
編譯完成之後在src目錄下執行./redis-server啟動redis（啟動後可關閉該窗口），然後新開一個窗口，在命令行中執行./redis-cli即可連接啟動的redis服務。在其中執行如下命令即可看到編譯安裝成功了：
127.0.0.1:6379> set hello world 127.0.0.1:6379> OK 127.0.0.1:6379> get hello 127.0.0.1:6379> "world"
這裏需要說明的是，按照上述方式啟動redis，其使用的ip為本機ip 127.0.0.1，端口為6379，並且其余的配置采用的都是默認配置，相關配置可在redis安裝目錄下的redis.conf文件中查看。如果需要按照指定的配置文件來啟動，可在redis-server後接上配置文件名，如：
./src/redis-server redis.conf
另外，上述使用redis-cli連接redis客戶端時如果不帶任何參數，那麽其連接的默認ip和端口為127.0.0.1:6379。如果需要連接指定ip和端口的客戶端，可以使用如下方式：
./src/redis-cli -h 127.0.0.1 -p 6379
這裏-h參數表示連接的ip，-p則表示連接的端口。
配置好redis之後，我們就可以在redis中執行相關命令來操作數據，關於redis的常用命令，可查看本人的另一篇博客《redis常用命令大全》，其中有比較詳細的講解。
Redis 主從模式的配置
redis單例提供了一種數據緩存方式和豐富的數據操作api，但是將數據完全存儲在單個redis中主要存在兩個問題：數據備份和數據體量較大造成的性能降低。
這裏redis的主從模式為這兩個問題提供了一個較好的解決方案。主從模式指的是使用一個redis實例作為主機，其余的實例作為備份機。
主機和從機的數據完全一致，主機支持數據的寫入和讀取等各項操作，而從機則只支持與主機數據的同步和讀取，也就是說，客戶端可以將數據寫入到主機，由主機自動將數據的寫入操作同步到從機。
主從模式很好的解決了數據備份問題，並且由於主從服務數據幾乎是一致的，因而可以將寫入數據的命令發送給主機執行，而讀取數據的命令發送給不同的從機執行，從而達到讀寫分離的目的。
如下所示主機redis-A分別有redis-B、redis-C、redis-D、redis-E四個從機：
前面第1點中我們已經介紹了redis單例的配置方式，而上面我們也介紹了主從模式其實也是多個redis實例組成的，因而redis主從模式的配置可以理解為多個不同的redis實例通過一定的配置告知其相互之間的主從關系。
而前面已經介紹，每個redis實例都會占用一個本機的端口號，主從模式的配置主要的配置點有兩個：當前實例端口號和當前實例是主機還是從機，是從機的話其主機的ip和端口是什麽。
一般的redis目錄下的redis.conf保存的是默認配置，盡量不要對其進行修改，這裏我們復制三份redis.conf文件，分別命名為6379.conf，6380.conf和6381.conf，如下是端口為6379的主機的主要配置：
bind 127.0.0.1 port 6379 logfile "6379.log" dbfilename "dump-6379.rdb"
如下是端口為6380和6381的從機的配置：
bind 127.0.0.1 port 6380 logfile "6380.log" dbfilename "dump-6380.rdb" slaveof 127.0.0.1 6379
bind 127.0.0.1 port 6381 logfile "6381.log" dbfilename "dump-6381.rdb" slaveof 127.0.0.1 6379
可以看到，端口為6380和6381的實例被配置為端口為6379的實例的從機。配置完成後使用redis-server分別執行如下命令啟動三個實例：
./src/redis-server 6379.conf ./src/redis-server 6380.conf ./src/redis-server 6381.conf
啟動之後分別開啟開啟三個命令行工具分別執行以下命令連接redis實例：
./src/redis-cli -p 6379 ./src/redis-cli -p 6380 ./src/redis-cli -p 6381
分別在三個命令行工具中執行一個get命令，獲取鍵名為msg的數據，如下所示：
127.0.0.1:6379> get msg
(nil)
127.0.0.1:6380> get msg
(nil)
127.0.0.1:6381> get msg
(nil)
可以看到，在三個redis實例中都不存在鍵為msg的數據，現在我們在主機6379上設置一個鍵為msg的數據，如下所示：
127.0.0.1:6379> set msg "hello"
OK
可以看到設置成功了，此時我們在6380和6381的實例上執行get msg的命令，如下所示：
127.0.0.1:6380> get msg
"hello"
127.0.0.1:6381> get msg
"hello"
可以看到，雖然我們只是在6379的實例上設置了msg這條數據，但是在6380和6381的實例上也存有了相應的數據，說明我們成功配置了redis的主從模式。
另外，如果不在配置文件中指定主從節點的關系，也可以在啟動相關redis實例之後使用slaveof命令來指定當前節點稱為某個節點的從節點，如：
127.0.0.1:6380> slaveof 127.0.0.1 6379
Redis 中 sentinel 配置
redis主從模式解決了數據備份和單例可能存在的性能問題，但是其也引入了新的問題。
由於主從模式配置了三個redis實例，並且每個實例都使用不同的ip（如果在不同的機器上）和端口號。
根據前面所述，主從模式下可以將讀寫操作分配給不同的實例進行從而達到提高系統吞吐量的目的，但也正是因為這種方式造成了使用上的不便，因為每個客戶端連接redis實例的時候都是指定了ip和端口號的，如果所連接的redis實例因為故障下線了，而主從模式也沒有提供一定的手段通知客戶端另外可連接的客戶端地址，因而需要手動更改客戶端配置重新連接。
另外，主從模式下，如果主節點由於故障下線了，那麽從節點因為沒有主節點而同步中斷，因而需要人工進行故障轉移工作。
為了解決這兩個問題，在2.8版本之後redis正式提供了sentinel（哨兵）架構。關於sentinel，這裏需要說明幾個概念：
每個sentinel節點其實就是一個redis實例，與主從節點不同的是sentinel節點作用是用於監控redis數據節點的，而sentinel節點集合則表示監控一組主從redis實例多個sentinel監控節點的集合，比如有主節點master和從節點slave-1、slave-2。
為了監控這三個主從節點，這裏配置N個sentinel節點sentinel-1，sentinel-2，...，sentinel-N。
如下圖是sentinel監控主從節點的示例圖：
從圖中可以看出，對於一組主從節點，sentinel只是在其外部額外添加的一組用於監控作用的redis實例。
在主從節點和sentinel節點集合配置好之後，sentinel節點之間會相互發送消息，以檢測其余sentinel節點是否正常工作，並且sentinel節點也會向主從節點發送消息，以檢測監控的主從節點是否正常工作。
前面講到，sentinel架構的主要作用是解決主從模式下主節點的故障轉移工作的。
這裏如果主節點因為故障下線，那麽某個sentinel節點發送檢測消息給主節點時；
1.如果在指定時間內收不到回復，那麽該sentinel就會主觀的判斷該主節點已經下線，那麽其會發送消息給其余的sentinel節點，詢問其是否“認為”該主節點已下線，其余的sentinel收到消息後也會發送檢測消息給主節點；
2.如果其認為該主節點已經下線，那麽其會回復向其詢問的sentinel節點，告知其也認為主節點已經下線，當該sentinel節點最先收到超過指定數目（配置文件中配置的數目和當前sentinel節點集合數的一半，這裏兩個數目的較大值）的sentinel節點回復說當前主節點已下線，那麽其就會對主節點進行故障轉移工作。
故障轉移的基本思路是在從節點中選取某個從節點向其發送slaveof no one（假設選取的從節點為127.0.0.1:6380），使其稱為獨立的節點（也就是新的主節點），然後sentinel向其余的從節點發送slaveof 127.0.0.1 6380命令使它們重新成為新的主節點的從節點。
3.重新分配之後sentinel節點集合還會繼續監控已經下線的主節點（假設為127.0.0.1:6379），如果其重新上線，那麽sentinel會向其發送slaveof命令，使其成為新的主機點的從節點，如此故障轉移工作完成。
上面我們講到了，每個sentinel節點在本質上還是一個redis實例，只不過和redis數據節點不同的是，其主要作用是監控redis數據節點。
在redis安裝目錄下有個默認的sentinel配置文件sentinel.conf，和配置主從節點類似，這裏復制三個配置文件：sentinel-26379.conf，sentinel-26380.conf和sentinel-26381.conf。分別按照如下示例編輯這三個配置文件：
port 26379 daemonize yes logfile "26379.log" dir /opt/soft/redis/data sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 sentinel myid mm55d2d712b1f3f312b637f9b546f00cdcedc787
對於端口為26380和26381的sentinel，其配置和上述類似，只需要把相應的端口號修改為對應的端口號即可。
這裏註意兩點：
①每個sentinel的myid參數也要進行修改，因為sentinel之間是通過該屬性來唯一區分其他sentinel節點的；
②參數中sentinel monitor mymaster 127.0.0.1 6379 2這裏的端口號6379是不用更改的，因為sentinel是通過檢測主節點的狀態來得知當前主節點的從節點有哪些的，因而設置為主節點的端口號即可。
配置完成後我們首先啟動三個主從節點，然後分別使用三個配置文件使用如下命令啟用sentinel：
./src/redis-sentinel sentinel-26379.conf ./src/redis-sentinel sentinel-26380.conf ./src/redis-sentinel sentinel-26381.conf
由於sentinel節點也是一個redis實例，因而我們可以通過如下命令使用redis-cli連接sentinel節點：
./src/redis-cli -p 26379
連上sentinel節點之後我們可以通過如下命令查看sentinel狀態：
127.0.0.1:26379> info sentinel
結果如下：
# Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3
可以看到，sentinel檢測到主從節點總共有三個，其中一個主節點，兩個從節點，並且sentinel節點總共也有三個。
啟動完成之後，我們可以通過主動下線主節點來模擬sentinel的故障轉移過程。首先我們連接上端口為6379的主節點，使用如下命令查看主從節點狀態：
127.0.0.1:6379> info replication
結果如下：
# Replication role:master connected_slaves:2 slave0:ip=127.0.0.1,port=6380,state=online,offset=45616,lag=1 slave1:ip=127.0.0.1,port=6381,state=online,offset=45616,lag=1 master_repl_offset:45616 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:45615
可以看到，當前主節點有兩個從節點，端口分別為6380和6381。然後我們對主節點執行如下命令：
127.0.0.1:6379> shutdown save
然後我們連接上端口號為6380的從節點，並執行如下命令：
127.0.0.1:6380> info replication
結果如下：
# Replication role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6381,state=online,offset=12344,lag=0 master_repl_offset:12477 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:12476
可以看到，當端口為6379的實例下線之後，端口為6380的實例被重新競選為新的主節點，並且端口為6381的實例被設置為6380的實例的從節點。
如果我們此時重新啟用端口為6379的節點，然後再查看主從狀態，結果如下：
# Replication role:master connected_slaves:2 slave0:ip=127.0.0.1,port=6381,state=online,offset=59918,lag=0 slave1:ip=127.0.0.1,port=6379,state=online,offset=59918,lag=1 master_repl_offset:60051 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:60050
可以看到，端口為6379的redis實例重新連接後，sentinel節點檢測到其重新連接，那麽對其發送命令，使其成為新的主節點的從節點。
Redis 集群的配置
redis集群是在redis 3.0版本推出的一個功能，其有效的解決了redis在分布式方面的需求。當遇到單機內存，並發和流量瓶頸等問題時，可采用Cluster方案達到負載均衡的目的。
並且從另一方面講，redis中sentinel有效的解決了故障轉移的問題，也解決了主節點下線客戶端無法識別新的可用節點的問題，但是如果是從節點下線了，sentinel是不會對其進行故障轉移的，並且連接從節點的客戶端也無法獲取到新的可用從節點，而這些問題在Cluster中都得到了有效的解決。
redis集群中數據是和槽（slot）掛鉤的，其總共定義了16384個槽，所有的數據根據一致哈希算法會被映射到這16384個槽中的某個槽中。
另一方面，這16384個槽是按照設置被分配到不同的redis節點上的，比如啟動了三個redis實例：cluster-A，cluster-B和cluster-C，這裏將0-5460號槽分配給cluster-A，將5461-10922號槽分配給cluster-B，將10923-16383號槽分配給cluster-C（總共有16384個槽，但是其標號類似數組下標，是從0到16383）。
也就是說數據的存儲只和槽有關，並且槽的數量是一定的，由於一致hash算法是一定的，因而將這16384個槽分配給無論多少個redis實例，對於確認的數據其都將被分配到確定的槽位上。redis集群通過這種方式來達到redis的高效和高可用性目的。
這裏需要進行說明的一點是，一致哈希算法根據數據的key值計算映射位置時和所使用的節點數量有非常大的關系。
一致哈希分區的實現思路是為系統中每個節點分配一個token，範圍一般在0~2^32，這些token構成一個哈希環，數據讀寫執行節點查找操作時，先根據key計算hash值，然後順時針找到第一個大於等於該hash值的token節點，需要操作的數據就保存在該節點上。
通過分析可以發現，一致哈希分區存在如下問題：
-
加減節點會造成哈希環中部分數據無法命中，需要手動處理或忽略這部分數據；
-
當使用少量節點時，節點變化將大範圍影響環中數據映射，因此這種方式不適合少量節點的分布式方案；
-
普通的一致性哈希分區在增減節點時需要增加一倍或減去一半節點才能保證數據和負載的平衡。
正是由於一致哈希分區的這些問題，redis使用了虛擬槽來處理分區時節點變化的問題，也即將所有的數據映射到16384個虛擬槽位上，當redis節點變化時數據映射的槽位將不會變化，並且這也是redis進行節點擴張的基礎。
對於redis集群的配置，首先將redis安裝目錄下的redis.conf文件復制六份，分別取名為：cluster-6379.conf、cluster-6380.conf、cluster-6381.conf、cluster-6382.conf、cluster-6383.conf、cluster-6384.conf。
對於一個高可用的集群方案，集群每個節點都將為其分配一個從節點，以防止數據節點因為故障下線，這裏使用六份配置文件定義六個redis實例，其中三個作為主節點，剩余三個分別作為其從節點。對於這六份配置文件，以其中一份為例，以下是其需要修改的參數：
port 6379 cluster-enabled yes cluster-node-timeout 15000 cluster-config-file "nodes-6379.conf" pidfile /var/run/redis_6379.pid logfile "cluster-6379.log" dbfilename dump-cluster-6379.rdb appendfilename "appendonly-cluster-6379.aof"
對於其余的配置文件，只需要將其中對應項的端口號和帶有端口號的文件名修改為當前要指定的端口號和端口號的文件名即可。
配置文件配置好之後使用如下命令啟動集群中的每個實例：
./src/redis-server cluster-6379.conf ./src/redis-server cluster-6380.conf ./src/redis-server cluster-6381.conf ./src/redis-server cluster-6382.conf ./src/redis-server cluster-6383.conf ./src/redis-server cluster-6384.conf
仔細閱讀上述配置文件可發現，當前配置和啟動過程中並沒有指定這六個實例的主從關系，也沒有對16384個槽位進行分配。
因而我們還需要進行進一步的配置，槽位的分配和主從關系的設定有兩種方式進行，一種是使用redis-cli連接到集群節點上後使用cluster meet命令連接其他的節點，如我們首先執行如下命令連接到6379端口的節點：
./src/redis-cli -p 6379
連接上後使用cluster meet命令分別連接其余節點：
127.0.0.1:6379>cluster meet 127.0.0.1 6380 127.0.0.1:6379>cluster meet 127.0.0.1 6381 127.0.0.1:6379>cluster meet 127.0.0.1 6382 127.0.0.1:6379>cluster meet 127.0.0.1 6383 127.0.0.1:6379>cluster meet 127.0.0.1 6384
連接好後可以使用cluster nodes命令查看當前集群狀態：
127.0.0.1:6379> cluster nodes 4fa7eac4080f0b667ffeab9b87841da49b84a6e4 127.0.0.1:6384 master - 0 1468073975551 5 connected cfb28ef1deee4e0fa78da86abe5d24566744411e 127.0.0.1:6379 myself,master - 0 0 0 connected be9485a6a729fc98c5151374bc30277e89a461d8 127.0.0.1:6383 master - 0 1468073978579 4 connected 40622f9e7adc8ebd77fca0de9edfe691cb8a74fb 127.0.0.1:6382 master - 0 1468073980598 3 connected 8e41673d59c9568aa9d29fb174ce733345b3e8f1 127.0.0.1:6380 master - 0 1468073974541 1 connected 40b8d09d44294d2e23c7c768efc8fcd153446746 127.0.0.1:6381 master - 0 1468073979589 2 connected
可以看到配置的六個節點都已經加入到了集群中，但是其現在還不能使用，因為還沒有將16384個槽分配到集群節點中。虛擬槽的分配可以使用redis-cli分別連接到6379，6380和6381端口的節點中，然後分別執行如下命令：
127.0.0.1:6379>cluster addslots {0...5461}
127.0.0.1:6380>cluster addslots {5462...10922}
127.0.0.1:6381>cluster addslots {10923...16383}
添加完槽位後可使用cluster info命令查看當前集群狀態：
127.0.0.1:6379> cluster info cluster_state:ok cluster_slots_assigned:16384 cluster_slots_ok:16384 cluster_slots_pfail:0 cluster_slots_fail:0 cluster_known_nodes:6 cluster_size:3 cluster_current_epoch:5 cluster_my_epoch:0 cluster_stats_messages_sent:4874 cluster_stats_messages_received:4726
這裏我們將16384個虛擬槽位分配給了三個節點，而剩余的三個節點我們通過如下命令將其配置為這三個節點的從節點，從而達到高可用的目的：
127.0.0.1:6382>cluster replicate cfb28ef1deee4e0fa78da86abe5d24566744411e OK 127.0.0.1:6383>cluster replicate 8e41673d59c9568aa9d29fb174ce733345b3e8f1 OK 127.0.0.1:6384>cluster replicate 40b8d09d44294d2e23c7c768efc8fcd153446746 OK
如此，所有的集群節點都配置完畢，並且處於可用狀態。這裏可以使用cluster nodes命令查看當前節點的狀態：
127.0.0.1:6379> cluster nodes 4fa7eac4080f0b667ffeab9b87841da49b84a6e4 127.0.0.1:6384 slave 40b8d09d44294d2e23c7c768efc8fcd153446746 0 1468076865939 5 connected cfb28ef1deee4e0fa78da86abe5d24566744411e 127.0.0.1:6379 myself,master - 0 0 0 connected 0-5461 be9485a6a729fc98c5151374bc30277e89a461d8 127.0.0.1:6383 slave 8e41673d59c9568aa9d29fb174ce733345b3e8f1 0 1468076868966 4 connected 40622f9e7adc8ebd77fca0de9edfe691cb8a74fb 127.0.0.1:6382 slave cfb28ef1deee4e0fa78da86abe5d24566744411e 0 1468076869976 3 connected 8e41673d59c9568aa9d29fb174ce733345b3e8f1 127.0.0.1:6380 master - 0 1468076870987 1 connected 5462-10922 40b8d09d44294d2e23c7c768efc8fcd153446746 127.0.0.1:6381 master - 0 1468076867957 2 connected 10923-16383
我們使用redis-cli使用如下命令連接集群：
./src/redis-cli -c -p 6380
註意連接集群模式的redis實例時需要加上參數-c，表示連接的是集群模式的實例。連接上後執行get命令：
127.0.0.1:6380> get hello-> Redirected to slot [866] located at 127.0.0.1:6379(nil)
可以看到，在6380端口的實例上執行get命令時，其首先會為當前的鍵通過一致哈希算法計算其所在的槽位，並且判斷該槽位不在當前redis實例中，因而重定向到目標實例上執行該命令，最後發現沒有該鍵對應的值，因而返回了一個（nil）。
轉自： https://my.oschina.net/zhangxufeng/blog/905611
Redis 單例、主從模式、sentinel 以及集群的配置方式及優缺點對比（轉）