redis 集群详解及搭建过程
1. 引言
從?3.0?版本開始,redis?具備了集群功能,實現了分布式、容錯、去中心化等特性,在生產環境中對于保證數據一致性和安全性、提高系統響應能力都有著很必要的意義。
本文我們就來介紹?redis?集群的三種搭建模式和搭建方法。
1.1. redis?集群的特性
redis?集群的目標是線性可擴展性和保證最終一致性,因此,redis?集群不存在中心節點或代理節點。
同時,一致性的保證是建立在一部分容錯性犧牲的基礎上的,系統通過主從節點的模式在保證對節點失效具有有限抵抗力的前提下,盡可能保證數據的一致性。
redis?集群實現了節點的自動發現、master?的自動選舉、熱分片、ASK?轉向和?MOVED?轉向等機制。
可以參考官方文檔:
https://redis.io/topics/cluster-tutorial。
1.2. 集群端口
無論是哪種模式的?redis?集群,都需要指定服務端口(默認為?6379),但?redis?實際上是通過服務端口?+?10000?的端口來進行數據同步的。
因此,如果集群無法建立或同步無法進行,除了需要考慮服務端口是否連通以外,還需要檢測同步端口的可用性。
2. 主從模式集群
redis?支持簡單的主從單向同步的集群結構,主節點負責寫入數據,同步到從節點,從節點進行只讀操作。
主從單向同步的集群結構可以有效提升系統的吞吐量,同時保證數據的安全性。
2.1. 搭建方法
主從模式的集群搭建方法非常簡單,只需要在從節點的配置文件中寫入:
slaveof 112.126.74.142 6379這樣,啟動該節點后,他就成為了?112.126.74.142:6379?節點的從節點。
2.2. 從節點的寫入操作
需要注意的是,從節點默認也可以進行讀寫操作,但從節點的寫入將會導致這部分數據不會被同步,從而造成數據不一致的問題。
可以通過指定配置來強制從節點不可寫入:
此時對從節點進行寫入操作會報錯:
(error) READONLY You can't write against a read only replica.2.3. 從節點的同步機制
在?redis-cli?中,通過執行?info?replication?可以看到集群信息。
# Replication role:slave master_host:127.0.0.1 master_port:6379 master_link_status:up master_last_io_seconds_ago:6 master_sync_in_progress:0 slave_repl_offset:462 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:201640b5a63c036087b7a459245a6f6a699b8a36 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:462 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:462其中有兩個標識:
如果?A?是集群主節點,B?是?A?的從節點,C?是?B?的從節點,那么?C?的?master_replid?則存儲的是?A?的節點標識,這意味著,如果?B?節點非只讀,B?節點內寫入的數據并不會同步到?C?節點。
數據的同步就是基于?master_replid?與?master_repl_offset?兩個字段進行的,每個從節點都保存了當前已同步數據的偏移,從而實現部分同步。
主節點一旦重啟,master_replid?就會發生變動,從而造成所有從節點重新同步全量數據,由于?master_replid?是自動生成的,我們并不能干涉這一過程。
3. 高可用集群?–?HA
上面所描述的主從集群存在一個問題,那就是當主節點宕機時,將導致整個集群無法提供服務。
為了保證集群的容錯性,redis?提供了官方的?HA?方案,他是通過建立哨兵節點或哨兵集群來實現對?master?的監控和對?slaver?的提權。
哨兵節點通過監控?redis?集群中?master?的狀態實現當?master?狀態異常時,在?master?的多個?slaver?中選舉一個并通過發送?SLAVEOF?NO?ONE?命令提升其為?master?節點,同時自動發送?SLAVE?OF?命令給其他?slaver?節點,從而讓集群重新工作起來,這個過程稱為?failover?過程。
多個哨兵節點可以組成集群,從而避免某個哨兵節點宕機的情況發生。
3.1. 集群搭建
首先,我們需要創建哨兵節點配置文件:
port 20086 #默認端口26379 dir "/tmp" logfile "/var/log/redis/sentinel_20086.log" daemonize yes# 配置監視的進群的主節點 ip 和端口 1 表示至少需要幾個哨兵統一認定才可以做出判斷 sentinel monitor mymaster 127.0.0.1 6380 1# 表示如果 5s 內 mymaster 沒響應,就認為 SDOWN sentinel down-after-milliseconds mymaster 5000 # 表示如果15秒后,mysater 仍沒活過來,則啟動 failover,從剩下從節點序曲新的主節點 sentinel failover-timeout mymaster 15000 # 在發生failover主備切換時,這個選項指定了最多可以有多少個slave同時對新的master進行同步,這個數字越小,完成failover所需的時間就越長,但是如果這個數字越大,就意味著越多的slave因為replication而不可用。可以通過將這個值設為 1 來保證每次只有一個slave處于不能處理命令請求的狀態 sentinel parallel-syncs T1 1# sentinel 連接設置了密碼和主從 # sentinel auth-pass <master_name> xxxxx# 發生切換之后執行的一個自定義腳本 # sentinel client-reconfig-script <master-name> <script-path>通過?redis-sentinel?命令指定配置文件啟動即可。
4. redis-cluster
盡管可以使用哨兵主從集群實現可用性保證,但是這種實現方式每個節點的數據都是全量復制,數據存放量存在著局限性,受限于內存最小的節點。
為了增大存儲性能,實現真正的分布式存儲系統,sharding?的方案是非常有必要的。
所謂的?sharding?方案指的是將全量數據分成?16384?個散列槽,我們只需采用密鑰模數?16384?的?CRC16?就可以計算?key?所在的散列槽位置,這樣,每個節點容納全部?16384?個散列槽中的一部分,所有?master?節點共同組成完整的數據。
4.1. 配置集群
如果需要?sharding?模式與主從模式結合使用,那么需要在建立集群時通過命令指定,而不能在配置文件中添加?slaveof?配置項。
首先修改?redis?配置打開?cluster?配置:
cluster-config-file?配置的文件?redis?集群啟動后會自動寫入集群信息,如果要刪除集群重建,最暴力的方法就是刪除集群中每臺機器上的?cluster-config-file?配置文件。
其他配置項還有:
- cluster-slave-validity-factor?–?slave節點與master斷線的時間是否過長,如果?(node-timeout?*?slave-validity-factor)?+?repl-ping-slave-period?大于了該值,則?slave?不會被提升為?master,默認值為?10
- cluster-migration-barrier?–?master?的最小?slaver?數,避免組建集群時?slaver?不能平均分配的情況發生,默認為?0
- cluster-require-full-coverage?–?是否?sharding?所有?slot?才能夠提供服務,默認為?yes,如果設置為?no,可以在?slot?沒有全部分配的時候提供服務,不建議,這樣會造成分區的時候,小分區的master一直在接受寫請求,而造成很長時間數據不一致
4.2. 啟動集群
首先,更新完配置后,需要啟動所有節點的?redis-server。
redis5.0?版本以后集群操作從?redis-trib.rb?命令遷移到?redis-cli,通過?redis-cli?--cluster?命令就可以組建集群了。
–cluster-replicas?指定了集群中每個?master?節點的?slaver?數量。
- 需要注意的是,至少三臺?master?主機才能組成一個?redis-cluster,并且集群中的所有節點初始時必須不能有數據
4.3. 報錯處理?–?Not?all?16384?slots?are?covered?by?nodes
可以通過?redis-cli?--cluster?fix?命令修復,讓集群中槽位重新分布。
通過執行?redis-cli?--cluster?check?host:port?可以檢測集群中的槽位分布情況。
官方文檔中還介紹了集群的其他操作,例如節點的添加和刪除,可以進一步閱讀。
4.4. MOVED?xxx?xxx.xxx.xxx.xxx:xxxx
使用?redis-cli?連接集群進行操作,會出現?MOVED?錯誤。
這是因為出現了?MOVED?轉向,提示客戶端轉向分片所在節點進行操作,關于?MOVED?轉向和?ASK?轉向我們下一篇文章中再來介紹。
redis?要求客戶端自己處理?MOVED?轉向和?ASK?轉向,所以?redis-cli?中已經擁有了處理邏輯,只需在登錄時增加?-c?參數即可自動進行轉向,也就不會再報出相應的錯誤了。
5. 參考資料
https://redis.io/topics/cluster-tutorial。
https://blog.csdn.net/qq_20597727/article/details/83385737。
https://www.cnblogs.com/vansky/p/9130647.html。
https://www.cnblogs.com/zhoujinyi/p/5570024.html。
https://blog.csdn.net/vtopqx/article/details/50235737。
https://blog.csdn.net/huwei2003/article/details/50973893。
總結
以上是生活随笔為你收集整理的redis 集群详解及搭建过程的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: [机器学习与scikit-learn-2
- 下一篇: 【EXLIBRIS】#小词旮旯# 000