前言
一、主從復制
概念
和mysql的主從復制一樣 都是將服務器的數據復制到另一個數據庫中 發送的稱為master 接受的叫slave 數據為單向傳輸 只可以主到從
每臺Redis服務器都是主節點；且一個主節點可以有多個從節點(或沒有從節點)，但一個從節點只能有一個主節點。
作用
數據冗余 實現了數據的熱備份，是持久化之外的一種數據冗余方式
故障切換 當主節點宕機或者出現錯誤時 由從服務器來提供服務 實現故障切換
負載均衡：在主從復制的基礎上，配合讀寫分離，可以由主節點提供寫服務，由從節點提供讀服務（即寫Redis數據時應用連接主節點，讀Redis數據時應用連接從節點），分擔服務器負載；尤其是在寫少讀多的場景下，通過多個從節點分擔讀負載，可以大大提高Redis服務器的并發量。
基礎 給集群和哨兵提供環境
主從復制過程
1 若啟動一個Slave機器進程，則它會向Master機器發送一個“sync command”命令，請求同步連接。
2 無論是第一次連接還是重新連接，Master機器都會啟動一個后臺進程，將數據快照保存到數據文件中（執行rdb操作），同時Master還會記錄修改數據的所有命令并緩存在數據文件中。
3 后臺進程完成緩存操作之后，Maste機器就會向Slave機器發送數據文件，Slave端機器將數據文件保存到硬盤上，然后將其加載到內存中，接著Master機器就會將修改數據的所有操作一并發送給Slave端機器。若Slave出現故障導致宕機，則恢復正常后會自動重新連接。
4 Master機器收到Slave端機器的連接后，將其完整的數據文件發送給Slave端機器，如果Mater同時收到多個Slave發來的同步請求，則Master會在后臺啟動一個進程以保存數據文件，然后將其發送給所有的Slave端機器，確保所有的Slave端機器都正常。
部署
三臺服務器 一主倆從
先部署redis 每臺配置一致
systemctl stop firewalld
setenforce 0
yum install -y gcc gcc-c++ make
tar zxvf redis-5.0.7.tar.gz -C /opt/
cd /opt/redis-5.0.7/
make
make PREFIX=/usr/local/redis install
cd /opt/redis-5.0.7/utils
./install_server.sh
回車四次，之后輸入可執行文件路徑
Please select the redis executable path [] /usr/local/redis/bin/redis-server
ln -s /usr/local/redis/bin/* /usr/local/bin/
主節點配置
vim /etc/redis/6379.conf
bind 0.0.0.0 70行，修改bind 項，0.0.0.0監聽所有網段
daemonize yes 137行，開啟守護進程
logfile /var/log/redis_6379.log 172行，指定日志文件目錄
dir /var/lib/redis/6379 264行，指定工作目錄
appendonly yes 700行，開啟AOF持久化功能
/etc/init.d/redis_6379 restart
netstat -natp | grep 6379 檢查端口是否開啟
從節點配置
vim /etc/redis/6379.conf
bind 0.0.0.0 70行，修改bind 項，0.0.0.0監聽所有網卡
daemonize yes 137行，開啟守護進程
logfile /var/log/redis_6379.log 172行，指定日志文件目錄
dir /var/lib/redis/6379 264行，指定工作目錄
replicaof 192.168.25.4 6379 288行，指定要同步的Master節點IP和端口
appendonly yes 700行，開啟AOF持久化功能
/etc/init.d/redis_6379 restart
查看結果
在主節點查看日志
tail -f /var/log/redis_6379.log
驗證
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.25.6,port=6379,state=online,offset=504,lag=1
slave1:ip=192.168.25.5,port=6379,state=online,offset=504,lag=0
二、哨兵模式
1 概念
是一個分布式系統，用于對主從結構中的每臺服務器進行監控，當出現故障時通過投票機制選擇新的 Master 并將所有 Slave 連接到新的 Master。所以整個運行哨兵的集群的數量不得少于3個節點。
2.作用
- 監控：哨兵會不斷地檢查主節點和從節點是否運作正常。
- 自動故障轉移：當主節點不能正常工作時，哨兵會開始自動故障轉移操作，它會將失效主節點的其中一個從節點升級為新的主節點，并讓其他從節點改為復制新的主節點。
- 通知（提醒）：哨兵可以將故障轉移的結果發送給客戶端。
3 組成
- 哨兵節點：哨兵系統由一個或多個哨兵節點組成，哨兵節點是特殊的redis節點，不存儲數據。
- 數據節點：主節點和從節點都是數據節點。
哨兵的啟動依賴于主從模式，所以須把主從模式安裝好的情況下再去做哨兵模式，所有節點上都需要部署哨兵模式，哨兵模式會監控所有的 Redis 工作節點是否正常，當 Master 出現問題的時候，因為其他節點與主節點失去聯系，因此會投票，投票過半就認為這個 Master 的確出現問題，然后會通知哨兵間，然后從 Slaves 中選取一個作為新的 Master。
主觀下線和客觀下線
主觀下線是指哨兵節點會每秒一次的頻率向建立了命令節點的實例發送ping命令，如果在 down-after-milliseconds 毫秒內沒有做出有效響應包括（pong/loading/masterdown）以外的響應，哨兵就會將該實例在本結構體中的狀態標記為 sri_s_down 主觀下線
客觀下線是指當一個哨兵節點發現主節點處于主觀下線狀態時，就會向其他的哨兵節點發出詢問，該節點是否已經主觀下線。如果超過配置參數 quorum 個節點認為是主觀下線時，該哨兵節點就會將自己維護的結構體中該主節點標記為 sri_o_down 客觀下線
部署
所有的節點都要部署哨兵
vim /opt/redis-5.0.7/sentinel.conf
protected-mode no #17行，關閉保護模式
port 26379 #21行，Redis哨兵默認的監聽端口
daemonize yes #26行，指定sentinel為后臺啟動
logfile "/var/log/sentinel.log" #36行，指定日志存放路徑
dir "/var/lib/redis/6379" #65行，指定數據庫存放路徑
sentinel monitor mymaster 192.168.184.10 6379 2 #84行，修改 指定該哨兵節點監控192.168.184.10:6379這個主節點，該主節點的名稱是mymaster，最后的2的含義與主節點的故障判定有關：至少需要2個哨兵節點同意，才能判定主節點故障并進行故障轉移
sentinel down-after-milliseconds mymaster 30000 #113行，判定服務器down掉的時間周期，默認30000毫秒（30秒）
sentinel failover-timeout mymaster 180000 #146行，故障節點的最大超時時間為180000（180秒）
開啟哨兵
先開master 后開slave
模擬故障
查詢主節點redis服務節點號
殺掉主節點進程 并查看日志
kill -9 62009
tail -f /var/log/sentinel.log
查看現在的主節點 現在主節點切換到slave1
三 集群
1 概念
集群，即Redis Cluster，是Redis 3.0開始引入的分布式存儲方案。
集群由多個節點(Node)組成，Redis的數據分布在這些節點中。集群中的節點分為主節點和從節點：只有主節點負責讀寫請求和集群信息的維護；從節點只進行主節點數據和狀態信息的復制。
2 作用
1 數據分區：數據分區(或稱數據分片)是集群最核心的功能。
集群將數據分散到多個節點，一方面突破了Redis單機內存大小的限制，存儲容量大大增加；另一方面每個主節點都可以對外提供讀服務和寫服務，大大提高了集群的響應能力。
Redis單機內存大小受限問題，在介紹持久化和主從復制時都有提及；例如，如果單機內存太大，bgsave和bgrewriteaof的fork操作可能導致主進程阻塞，主從環境下主機切換時可能導致從節點長時間無法提供服務，全量復制階段主節點的復制緩沖區可能溢出。
2 高可用：集群支持主從復制和主節點的自動故障轉移（與哨兵類似）；當任一節點發生故障時，集群仍然可以對外提供服務。
3、Redis集群的數據分片
Redis集群引入了哈希槽的概念
Redis集群有16384個哈希槽（編號0-16383）
集群的每個節點負責一部分哈希槽
每個Key通過CRC16校驗后對16384取余來決定放置哪個哈希槽，通過這個值，去找到對應的插槽所對應的節點，然后直接自動跳轉到這個對應的節點上進行存取操作
#以3個節點組成的集群為例：
節點A包含0到5460號哈希槽
節點B包含5461到10922號哈希槽
節點C包含10923到16383號哈希槽
Redis集群的主從復制模型
集群中具有A、B、C三個節點，如果節點B失敗了，整個集群就會因缺少5461-10922這個范圍的槽而不可以用。
為每個節點添加一個從節點A1、B1、C1整個集群便有三個Master節點和三個slave節點組成，在節點B失敗后，集群選舉B1位為的主節點繼續服務。當B和B1都失敗后，集群將不可用
部署
注意6個端口和IP都要不一樣。
vim /etc/redis/6379.conf
bind 192.168.25.4 70行，修改bind項，監聽自己的IP
protected-mode no 89行，修改，關閉保護模式
port 7001 93行，修改，redis監聽端口，
daemonize yes 137行，以獨立進程啟動
cluster-enabled yes 833行，取消注釋，開啟群集功能
cluster-config-file nodes-6379.conf 841行，取消注釋，群集名稱文件設置，無需修改
cluster-node-timeout 15000 847行，取消注釋群集超時時間設置
appendonly yes 700行，修改，開啟AOF持久化
#重啟服務
/etc/init.d/redis_6379 restart
#加入集群
redis-cli --cluster create 192.168.25.4:7001 192.168.25.5:7003 192.168.25.6:7005 192.168.25.7:7006 192.168.25.8:7007 192.168.25.9:7008 --cluster-replicas 1
redis-cli -h 192.168.25.4 -p 7001 -c #加-c參數，節點之間就可以互相跳轉
cluster slots #查看節點的哈希槽編號范圍
set sky x1
cluster keyslot x1 #查看name鍵的槽編號
到此這篇關于redis三種高可用方式部署的實現的文章就介紹到這了,更多相關redis 高可用方式部署內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家！
您可能感興趣的文章:- 淺談Redis在微服務架構中的幾種應用場景
- Redis5之后版本的高可用集群搭建的實現
- 詳解三分鐘快速搭建分布式高可用的Redis集群
- Redis為什么快如何實現高可用及持久化
- Redis服務之高可用組件sentinel詳解
- Redis Sentinel實現高可用配置的詳細步驟
- 解析高可用Redis服務架構分析與搭建方案
