溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容介紹了“redis集群特性有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
主從復制的好處有2點：
1、 避免redis單點故障
2、 構建讀寫分離架構，滿足讀多寫少的應用場景
創建6379、6380、6381目錄，分別將安裝目錄下的redis.conf拷貝到這三個目錄下。
分別進入這三個目錄，分別修改配置文件，將端口分別設置為：6379（Master）、6380（Slave）、6381（Slave）。同時要設置pidfile文件為不同的路徑。
在redis中設置主從有2種方式：
1、 在redis.conf中設置slaveof
a) slaveof
2、 使用redis-cli客戶端連接到redis服務，執行slaveof命令
a) slaveof
第二種方式在重啟后將失去主從復制關系。
查看主從信息：INFO replication
主：
role：角色
connected_slaves：從庫數量
slave0：從庫信息
從：
默認情況下redis數據庫充當slave角色時是只讀的不能進行寫操作。
可以在配置文件中開啟非只讀：slave-read-only no
1、 當從庫和主庫建立MS關系后，會向主數據庫發送SYNC命令；
2、 主庫接收到SYNC命令后會開始在后臺保存快照（RDB持久化過程），并將期間接收到的寫命令緩存起來；
3、 當快照完成后，主Redis會將快照文件和所有緩存的寫命令發送給從Redis；
4、 從Redis接收到后，會載入快照文件并且執行收到的緩存的命令；
5、 之后，主Redis每當接收到寫命令時就會將命令發送從Redis，從而保證數據的一致；
通過前面的復制過程我們了解到，主庫接收到SYNC的命令時會執行RDB過程，即使在配置文件中禁用RDB持久化也會生成，那么如果主庫所在的服務器磁盤IO性能較差，那么這個復制過程就會出現瓶頸，慶幸的是，Redis在2.8.18版本開始實現了無磁盤復制功能（不過該功能還是處于試驗階段）。
原理：
Redis在與從數據庫進行復制初始化時將不會將快照存儲到磁盤，而是直接通過網絡發送給從數據庫，避免了IO性能差問題。
開啟無磁盤復制：repl-diskless-sync yes
如果在主從復制架構中出現宕機的情況，需要分情況看：
a) 這個相對而言比較簡單，在Redis中從庫重新啟動后會自動加入到主從架構中，自動完成同步數據； b) 問題？ 如果從庫在斷開期間，主庫的變化不大，從庫再次啟動后， 主庫依然會將所有的數據做RDB操作嗎？還是增量更新？（從庫有做持久化的前提下）
不會的，因為在Redis2.8版本后就實現了，主從斷線后恢復的情況下實現增量復制。
這個相對而言就會復雜一些，需要以下2步才能完成
i. 第一步，在從數據庫中執行SLAVEOF NO ONE命令，斷開主從關系并且提升為主庫繼續服務； ii. 第二步，將主庫重新啟動后，執行SLAVEOF命令，將其設置為其他庫的從庫，這時數據就能更新回來；
這個手動完成恢復的過程其實是比較麻煩的并且容易出錯，有沒有好辦法解決呢？當前有的，Redis提高的哨兵（sentinel）的功能。
顧名思義，哨兵的作用就是對Redis的系統的運行情況的監控，它是一個獨立進程。它的功能有2個：
1、 監控主數據庫和從數據庫是否運行正常；
2、 主數據出現故障后自動將從數據庫轉化為主數據庫；
單個哨兵的架構：
多個哨兵的架構：
多個哨兵，不僅同時監控主從數據庫，而且哨兵之間互為監控。
啟動哨兵進程首先需要創建哨兵配置文件：
vim sentinel.conf
輸入內容：
sentinel monitor taotaoMaster 127.0.0.1 6379 1
說明：
taotaoMaster：監控主數據的名稱，自定義即可，可以使用大小寫字母和“.-_”符號 127.0.0.1：監控的主數據庫的IP 6379：監控的主數據庫的端口 1：最低通過票數
啟動哨兵進程：
redis-sentinel ./sentinel.conf
由上圖可以看到：
1、 哨兵已經啟動，它的id為9059917216012421e8e89a4aa02f15b75346d2b7
2、 為master數據庫添加了一個監控
3、 發現了2個slave（由此可以看出，哨兵無需配置slave，只需要指定master，哨兵會自動發現slave）
vim sentinel.conf
輸入內容：
sentinel monitor taotaoMaster 127.0.0.1 6381 2 sentinel monitor taotaoMaster2 127.0.0.1 6381 1
即使有了主從復制，每個數據庫都要保存整個集群中的所有數據，容易形成木桶效應。
使用Jedis實現了分片集群，是由客戶端控制哪些key數據保存到哪個數據庫中，如果在水平擴容時就必須手動進行數據遷移，而且需要將整個集群停止服務，這樣做非常不好的。
Redis3.0版本的一大特性就是集群（Cluster），接下來我們一起學習集群。
(1)所有的redis節點彼此互聯(PING-PONG機制),內部使用二進制協議優化傳輸速度和帶寬.
(2)節點的fail是通過集群中超過半數的節點檢測失效時才生效.
(3)客戶端與redis節點直連,不需要中間proxy層.客戶端不需要連接集群所有節點,連接集群中任何一個可用節點即可
(4)redis-cluster把所有的物理節點映射到[0-16383]slot（插槽）上,cluster 負責維護node<->slot<->value
1、 設置不同的端口，6379、6380、6381
2、 開啟集群，cluster-enabled yes
3、 指定集群的配置文件，cluster-config-file “nodes-xxxx.conf”
首先，進入redis的安裝包路徑下：
cd /usr/local/src/redis/redis-3.0.1/src/
執行命令：
./redis-trib.rb create --replicas 0 192.168.56.102:6379 192.168.56.102:6380 192.168.56.102:6381
–replicas 0：指定了從數據的數量為0
注意：這里不能使用127.0.0.1，否則在Jedis客戶端使用時無法連接到！
redis-trib用法：
什么情況？？(error) MOVED 7638 127.0.0.1:6380
因為abc的hash槽信息是在6380上，現在使用redis-cli連接的6379，無法完成set操作，需要客戶端跟蹤重定向。
redis-cli -c
通過cluster nodes命令可以查看當前集群的信息：
該信息反映出了集群中的每個節點的id、身份、連接數、插槽數等。
當我們執行set abc 123命令時，redis是如何將數據保存到集群中的呢？執行步驟：
1、 接收命令set abc 123 2、 通過key（abc）計算出插槽值，然后根據插槽值找到對應的節點。（abc的插槽值為：7638） 3、 重定向到該節點執行命令
整個Redis提供了16384個插槽，也就是說集群中的每個節點分得的插槽數總和為16384。
./redis-trib.rb 腳本實現了是將16384個插槽平均分配給了N個節點。
注意：如果插槽數有部分是沒有指定到節點的，那么這部分插槽所對應的key將不能使用。
計算key的插槽值：
key的有效部分使用CRC16算法計算出哈希值，再將哈希值對16384取余，得到插槽值。
什么是有效部分？
1、 如果key中包含了{符號，且在{符號后存在}符號，并且{和}之間至少有一個字符，則有效部分是指{和}之間的部分；
a) key={hello}_tatao的有效部分是hello
2、 如果不滿足上一條情況，整個key都是有效部分；
a) key=hello_taotao的有效部分是全部
再開啟一個實例的端口為6382
執行腳本：
./redis-trib.rb add-node 192.168.56.102:6382 192.168.56.102:6379
已經添加成功！查看集群信息：
發現沒有插槽數。
接下來需要給6382這個服務分配插槽，將6379的一部分（1000個）插槽分配給6382：
查看節點情況：
想要刪除集群節點中的某一個節點，需要嚴格執行2步：
1、 將這個節點上的所有插槽轉移到其他節點上；
a) 假設我們想要刪除6380這個節點 b) 執行腳本：./redis-trib.rb reshard 192.168.56.102:6380 c) 選擇需要轉移的插槽的數量，因為3380有5128個，所以轉移5128個 d) 輸入轉移的節點的id，我們轉移到6382節點：82ed0d63cfa6d19956dca833930977a87d6ddf7 e) 輸入插槽來源id，也就是6380的id f) 輸入done，開始轉移 g) 查看集群信息，可以看到6380節點已經沒有插槽了。
2、 使用redis-trib.rb刪除節點
a) ./redis-trib.rb del-node 192.168.56.102:6380 4a9b8886ba5261e82597f5590fcdb49ea47c4c6c b) del-node host:port node_id c) d) 查看集群信息，可以看到已經沒有6380這個節點了。
1、 集群中的每個節點都會定期的向其它節點發送PING命令，并且通過有沒有收到回復判斷目標節點是否下線； 2、 集群中每一秒就會隨機選擇5個節點，然后選擇其中最久沒有響應的節點放PING命令； 3、 如果一定時間內目標節點都沒有響應，那么該節點就認為目標節點疑似下線； 4、 當集群中的節點超過半數認為該目標節點疑似下線，那么該節點就會被標記為下線； 5、 當集群中的任何一個節點下線，就會導致插槽區有空檔，不完整，那么該集群將不可用； 6、 如何解決上述問題？ a) 在Redis集群中可以使用主從模式實現某一個節點的高可用 b) 當該節點（master）宕機后，集群會將該節點的從數據庫（slave）轉變為（master）繼續完成集群服務；
架構：
出現故障：
需要啟動6個redis實例，分別是：
6379（主） 6479（從）
6380（主） 6480（從）
6381（主） 6481（從）
啟動redis實例：
cd 6379/ && redis-server ./redis.conf && cd .. cd 6380/ && redis-server ./redis.conf && cd .. cd 6381/ && redis-server ./redis.conf && cd .. cd 6479/ && redis-server ./redis.conf && cd .. cd 6480/ && redis-server ./redis.conf && cd .. cd 6481/ && redis-server ./redis.conf && cd
創建集群，指定了從庫數量為1，創建順序為主庫（3個）、從庫（3個）：
./redis-trib.rb create --replicas 1 192.168.56.102:6379 192.168.56.102:6380 192.168.56.102:6381 192.168.56.102:6479 192.168.56.102:6480 192.168.56.102:6481
“redis集群特性有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
