※網頁設計最專業,超強功能平台可客製化
窩窩以「數位行銷」「品牌經營」「網站與應用程式」「印刷品設計」等四大主軸，為每一位客戶客製建立行銷脈絡及洞燭市場先機。
主從複製
Master-Slave主從概念
同時運行多個redis服務端,其中一個作為主(master),其他的一個或多個作為從(slave),主從之間通過網絡進行通訊,slave通過複製master的數據來保持與master的數據同步,實現數據冗餘;
在Redis中,配置主從複製非常簡單,Redis允許slave實例對master進行完整拷貝,在連接斷開時,slave會自動重新連接至主實例,並盡可能與master保持同步;
三個主要機制:
- 當連接可用時,master將發送命令流到slave來使salve保持更新,以下操作將引發該操作,對msater數據的寫入操作(包括刪除更新),key過期;
- master和slave節點都會進行超時檢測,當連接不穩定時,slave將儘快重新連接並進行部分重新同步,即不需要完全重新同步;
- 若無法進行部分重新同步,則slave將發起完全重新同步,master會將最新的數據快照發送給slave,後續的操作仍然是發送命令流;
其他特性:
主從之間,採用異步複製,複製過程中依然可以正常響應客戶端操作,支持一主多從,且從節點還可以類似的級聯其他從節點,如圖所示:
主從複製的作用:
- 使用主從複製,能夠避免Redis的單點故障,實現數據防災備份;
- 可配置主節點執行寫入,多個從節點分擔查詢,實現讀寫分離獲得更好的性能
注意:使用主從來做讀寫分離時,意味主節點自身沒有任何持久化數據;如果配置了哨兵,一旦節點重啟,則將使用空數據進行同步,導致從節點覆蓋所有持久化數據,這是非常危險的,牆裂建議在主節點和從節點上開啟持久化,如果一定要關閉,則必須配置主節點禁止哨兵自動重啟故障節點;具體故障模式:連接
配置:
#配置文件中按以下方式添加主節點的ip 和端口即可
replicaof 192.168.1.1 6379
#若主節點配置了授權密碼則需要指定密碼
masterauth 密碼
#主節點通過以下方式設置授權密碼
requirepass 密碼
#客戶端連接后需要先驗證密碼
auth 密碼
#可通過以下指令查看當前連接的服務的主從信息
info replication
副本只讀:
默認情況下副本是只讀的,若需要可以通過配置replica-read-only為no來使副本變為可寫的,但是要強調的是副本寫入的數據,僅寫入到當前副本本地,不會同步至任何節點,包括當前副本的副本;當副本重啟后這寫數據將消失,即臨時數據;
哨兵
哨兵(Sentinel) 是為redis提供了高可用性(high available/HA),使用Sentinel部署Redis時,可實現在無需人工干預的情況下,自動完成固定類型的故障修復;是Redis盡可能處於正常工作狀態;
哨兵的主要功能:
- 集群監控:監控redis各個節點是否正常工作;
- 消息通知:當某個節點出現故障時,可通過API\通知系統管理員或是其他程序;
- 故障轉移(failover):當master無法無法正常工作時,哨兵可以啟動故障轉移過程,該過程會將某一個slave節點提升為master節點,並主動通知使用redis服務器的應用程序要使用新的地址;
- 配置中心:當客戶端連接至哨兵時,可通過哨兵獲取可用的Redis服務信息;
哨兵的分佈式性質:
Sentinel本身是一個分佈式系統,即會有多個Sentinel進程通過網絡協同合作,具有以下優點:
-
當多個哨兵就某一master不可用這一事實達成共識,才會進行故障轉移,降低了因網絡波動造成誤報的可能性;
-
即使一些哨兵進程無法工作時,其他可用的哨兵仍然能夠正常工作,提供了整個系統應對故障的能力;
反過來,如果只有單獨的一個哨兵進程實際上是沒有辦法提供高可用的;
啟動哨兵
哨兵的執行文件本質就是redis的服務端,只不過運行的模式不同了,另外運行哨兵必須提供配置文件,否則將拒絕啟動;
首先需要準備配置文件,在下載的源碼中找到sentinel.conf 為了後續方便修改可以將其複製到bin目錄下
指定master的地址和端口
sentinel monitor mymaster 127.0.0.1 6379 2
啟動哨兵的命令有兩種寫法:
#方式1
redis-sentinel sentinel.conf
#方式1
redis-server sentinel.conf --sentinel
若啟動哨兵成功可以在控制台中看到其輸出的master節點信息;
默認情況下哨兵監聽在26379端口上,若開啟了防火牆則需要開放該端口,否則哨兵無法正常工作;
完成故障切換的過程
故障切換的定義:
當master不可用時將一個可用的slave提升稱為master,使結點保持正常訪問;
基於網絡存在不穩定性這個特性,一些時候某個哨兵進程可能無法與master正常通訊,但是這並不意味這master真的不可用了,哨兵無法就此認定master不可用這一事實,哨兵需要能夠檢測master是否客觀的不可用了,並在master不可用成為客觀事實后開始執行故障切換;
- 每個Sentinel(哨兵)進程以每秒鐘一次的頻率向整個集群中的Master主服務器，Slave從服務器 以及其他Sentinel(哨兵)進程發送一個 PING 命令
- 如果一個實例(instance)距離最後一次有效回復 PING 命令的時間超過 down-after- milliseconds 選項所指定的值，則這個實例會被 Sentinel(哨兵)進程標記為主觀下線(sdown)
- 如果一個Master主服務器被標記為主觀下線(SDOWN)，則正在監視這個Master主服務器的所有Sentinel(哨兵)進程要以每秒一次的頻率確認Master主服務器的確進入了主觀下線狀態。
- 當有足夠數量的 Sentinel(哨兵)進程(大於等於配置文件指定的值)在指定的時間範圍內確認Master主服務器進入了主觀下線狀態(SDOWN)， 則Master主服務器會被標記為客觀下線(ODOWN)。
- 在一般情況下， 每個Sentinel(哨兵)進程會以每 10 秒一次的頻率向集群中的所有Master主服務器、Slave從服務器發送 INFO 命令。
- 當Master主服務器被 Sentinel(哨兵)進程標記為客觀下線(ODOWN)時，Sentinel(哨兵)進程向下線的 Master主服務器的所有 Slave從服務器發送 INFO 命令的頻率會從 10 秒一次改為每秒一次。
- 若沒有足夠數量的 Sentinel(哨兵)進程同意 Master主服務器下線， Master主服務器的客觀下線狀態就會被移除。若 Master主服務器重新向 Sentinel(哨兵)進程發送 PING 命令返回有效回 復，Master主服務器的主觀下線狀態就會被移除。
故障切換涉及到的事件和參數:
-
sdown:主觀下線,當某個哨兵與master之間在指定時間內無法正常通訊后該哨兵將產生sdown事件
-
quorum(仲裁數):是一個整數,表示master從主觀下線變為客觀下線所需要的哨兵數量(但有quorum個哨兵與master通訊失敗則master進入主觀下線)
-
odown:當sdown的事件的數量達到指定值(quorum)時,將產odown事件,表示master客觀下線了;
-
majority(大多數):是一個整數,該值通過計算自動得出,計算公式為floor(哨兵總數量/2)+1 floor為下取整
當odown產生時,會選出一個哨兵準備進行故障切換,在切換前該哨兵還需要獲得大多數(majority)哨兵的授權,授權成功則開始進行故障切換;
故障切換完成后,若先前宕機的節點(原來的master)恢復正常,則該節點會降為slave;
部署Sentinel的基本知識
-
哨兵應與分佈式的形式存在,若哨兵僅部署一個則實際上沒有辦法提高可用性,當僅有的哨兵進程遇到問題退出后,則無法完成故障恢復;
-
一個健壯的部署至少需要三個Sentinel實例
-
三個哨兵應該部署在相互的獨立的計算機或虛擬機中;
-
Sentinel無法保證在執行故障轉移期間的寫入的數據是否能夠保留下來;
部署案例:
下例圖中名稱的釋義:
S:sentinel
M:master
R:replace(slave)
1.不要採用下例部署
上述部署中若M1(包括S1,因為在同一個機器上)宕機,剩下的S2雖然可以認定M1主觀下線,但是卻無法得到大多數哨兵的授權並開始故障切換,因為此時majority為2;
2.簡單且實用的部署
上述部署由三個節點組成,每個節點都運行着Redis進程和Sentinel進程,結構簡單,安全性也有了提高;
當M1發生故障時,S2和S3可以就該故障達成一致,並且能夠授權進行故障切換,從而使得客戶端可以正常使用;但也存在丟失已寫入數據的情況,因為redis內部使用異步複製,Master和Slave之間的數據在某個時間點可能不一致;
注意:
由於網絡存在分區性質,若客戶端C1和M1處於同一分區,但是該分區與S1,S2所在的分區無法通訊時,C1可以繼續向M1寫入數據,這寫數據將丟失,因為當網絡恢復時,M1可會被降為slave,而丟棄自己原本的數據;
使用下例配置可緩解該問題:
min-replicas-to-write 1
min-replicas-max-lag 5
上述配置表示,只要master無法寫入數據到任何一個slave超過5秒,則master停止接受寫入;
3.在客戶端部署哨兵
若某些原因導致沒有足夠的服務器節點用於部署哨兵,則可以將哨兵部署至客戶端,如下所示
※推薦評價好的iphone維修中心
擁有專業的維修技術團隊，同時聘請資深iphone手機維修專家，現場說明手機問題，快速修理，沒修好不收錢
若M1出現故障,則S1,S2,S3可順利的進行故障切換;但要注意該部署可能出現案例2中的問題
當然你也可以在客戶端和服務端同時部署哨兵;
配置示例:
#指出master地址和端口 以及仲裁數
sentinel monitor mymaster 127.0.0.1 6379 2
# 與master通訊超時時間,達到超時時間則sdown+1
sentinel down-after-milliseconds mymaster 60000
# 同一個master,開始新的故障轉移的時間(將是上一次的兩倍)
# 若slave連接到錯誤的master超過這個時間后slave將被重新連接到正確的master
# 取消正在進行中的故障轉移等待時間
# 按照parallel-syncs指定的配置進行複製的時間,超時候將不再受parallel-syncs的限制
sentinel failover-timeout mymaster 180000
# 發生故障轉移后,同時進行同步的副本數量
sentinel parallel-syncs mymaster 1
集群
Redis 集群是一個提供在多個Redis間節點間共享數據的程序集。
Redis集群並不支持處理多個keys的命令(如mset),因為這需要在不同的節點間移動數據,從而達不到像Redis那樣的性能,在高負載的情況下可能會導致不可預料的錯誤.
Redis 集群通過分區來提供一定程度的可用性,在實際環境中當某個節點宕機或者不可達的情況下繼續處理命令. Redis 集群的優勢:
- 自動分割數據到不同的節點上。
- 整個集群的部分節點失敗或者不可達的情況下能夠繼續處理命令。
示意圖:
集群的數據分片
Redis 集群沒有使用一致性hash, 而是引入了 哈希槽的概念.
Redis 集群有16384個哈希槽,每個key通過CRC16算法校驗后對16384取模來決定放置哪個槽.集群的每個節點負責一部分hash槽,舉個例子,比如當前集群有3個節點,那麼:
- 節點 A 包含 0 到 5500號哈希槽.
- 節點 B 包含5501 到 11000 號哈希槽.
- 節點 C 包含11001 到 16384號哈希槽.
這種結構很容易添加或者刪除節點. 比如如果我想新添加個節點D, 我需要從節點 A, B, C中得部分槽到D上. 如果我想移除節點A,需要將A中的槽移到B和C節點上,然後將沒有任何槽的A節點從集群中移除即可. 由於從一個節點將哈希槽移動到另一個節點並不會停止服務,所以無論添加刪除或者改變某個節點的哈希槽的數量都不會造成集群不可用的狀態.
客戶端可以訪問任意節點進行讀寫操作,若哈希槽不在當前訪問的節點redis會自動的將指令移動到相關節點上;
主從複製模型
為了使在部分節點失敗或者大部分節點無法通信的情況下集群仍然可用，集群使用了主從複製模型,每個節點都會有至少一個slave;
集群在沒有slave的情況下,如果某個節點故障了，那麼整個集群就會以為缺少一部分槽而不可用.
然而如果在創建集群時為每個節點都添加了從節點,在某個節點故障后,其從節點將被選舉為新的主節點,整個集群就不會因找不到槽而不可用,當然若某個節點與其所有子節點都故障了那麼整個節點將不可用;
一致性保證
Redis 並不能保證數據的強一致性. 這意味這在實際中集群在特定的條件下可能會丟失寫操作,主要有兩方面原因:
- 主節點到從節點之間的指令複製是異步完成的,主從之間在某個時間點可能不一致
- 出現網絡分區,導致主節點可正常寫入,但是從節點已經被其他分區節點選舉為新的master,寫入的數據將丟失
容錯性
當某master節點故障時,其他master節點將發起投票,若一半以上的master認為其不可用,則從該節點的從節點中(若存在)選舉新的master;
若該master沒有從節點,則集群將不可用
另外當集群一半以上的節點都不可用時則無論這些節點是否有從節點,集群立即不可用;
創建集群:
Redis在5.0版本時放棄了Ruby集群的方式,改為C語言編寫的 redis-cli方式,使得集群的構建方式複雜度大大降低。
集群至少需要三個節點,每個節點一個從節點總共為6個
-
配置:
若要以集群方式運行,則需要按以下方式修改配置文件,以啟用集群:
cluster-enabled yes
在實際開發中仍然建議使用單獨的虛擬機來部署所有的redis節點,下例為了簡化操作,在同一台虛擬機上搭建集群來進行測試:
-
添加上述配置后將bin目錄複製6分名稱為7001-7006,端口從7001-7006
-
分別啟動6個redis示例
-
使用redis-cli創建集群
redis-cli --cluster create 10.211.55.9:7001 10.211.55.9:7002 10.211.55.9:7003 10.211.55.9:7004 10.211.55.9:7005 10.211.55.9:7006 --cluster-replicas 1
過程中集群將重寫配置文件,需輸入yes確認
創建完成后提示如下信息:
可以看到,集群自動為每個master平均分配了哈希槽,並且設置了一個slave
-
連接集群
./redis-cli -h 10.211.55.9 -p 7001 -c
# 參數 -c 即表示連接到集群
-
查看集群狀態
cluster info
-
查看節點信息,包括ip,port,id,槽,主/從;
cluster nodes
添加節點
Redis集群支持動態擴展,期間redis可正常響應客戶端訪問
-
首先製作新的redis實例端口為7007並啟動
-
添加到集群中
./redis-cli --cluster add-node 10.211.55.9:7007 10.211.55.9:7001
添加成功:
-
新的節點默認作為master,但是該master沒有分配槽位,使用前必須分配哈希槽
下例表示從id為cc2e48268ccdd52d1c7840c8f9d2d7f15cc74c1b的節點移動1000個槽到cda3828e42e23dcbdb141db2fed221bc07c59f65節點
./redis-cli --cluster reshard 10.211.55.9:7001 --cluster-from cc2e48268ccdd52d1c7840c8f9d2d7f15cc74c1b --cluster-to cda3828e42e23dcbdb141db2fed221bc07c59f65 --cluster-slots 1000
#--cluster-from 來源節點 多個之前用逗號隔開, all 表示從所有節點中平均分配
#--cluster-to 目標節點
#--cluster-slots 1000 移動哈希槽數量
-
為新的master添加從節點
刪除節點
-
刪除從節點7008
./redis-cli --cluster del-node 10.211.55.9:7008 887d2f115f6a94bda86863576d73a131f12229d5
#指定集群host:port 和要刪除的節點id
-
將主節點的哈希槽分配給其他的主節點
/redis-cli --cluster reshard 10.211.55.9:7001 --cluster-from cda3828e42e23dcbdb141db2fed221bc07c59f65 --cluster-to cc2e48268ccdd52d1c7840c8f9d2d7f15cc74c1b
-
刪除主節點
./redis-cli --cluster del-node 10.211.55.9:7007 887d2f115f6a94bda86863576d73a131f12229d5
#指定集群host:port 和要刪除的節點id
-
哈希槽均衡,該操作檢查各節點的槽均衡情況,若差異較大則自動重新分配
./redis-cli --cluster rebalance 10.211.55.9:7001
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
※台北網頁設計公司這麼多該如何選擇?
網動是一群專業、熱情、向前行的工作團隊,我們擁有靈活的組織與溝通的能力,能傾聽客戶聲音,激發創意的火花,呈現完美的作品
