Redis Sentinel的基本搭建
Redis Sentinel的概念
我們知道Redis主從模式下,一旦主節點由於故障不能提供服務,需要人工將從節點晉升為主節點,同時還要通知應用方更新主節點的地址。然後在很多應用場景下這種故障處理的方式是無法接受的,應用程序需要實時感知當前的可用節點。為瞭解決這個問題,Redis Sentinel應運而生,也稱之為”哨兵”。
介紹sentinel之前,先來瞭解幾個redis的概念,
主節點master:Redis進程,主服務
從節點slave:redis進程,從服務
Redis數據節點:主節點和從節點
Sentinel節點:監控Redis數據節點,獨立的sentinel進程
Sentinel節點集合:若幹Sentinel節點的抽象組合,若幹sentinel節點進程
Redis Sentinel:Redis高可用實現方案,sentinel節點集合和redis數據節點進程
01 主從復制問題
前面的文章中我們講述瞭主從復制,可以將從節點作為主節點的災備節點,今天我們來看主從復制帶來的問題:
1、一旦主節點發生故障,從節點晉升為主節點的過程和應用調整新主節點的過程,都需要人為幹預
2、主節點的寫能力容易受到單機的限制
3、主節點的存儲能力容易受到單機的限制
一種常見的方法是使用腳本來觸發主從節點的角色切換,例如在一個一主兩從的結構中,假設主節點master,從節點slave1,slave2,我們來看故障發生時架構的狀態:
1、主節點master故障,客戶端連接失敗,兩個從節點復制失敗
2、選擇一個主節點slave1,對其執行slave of no one命令使其成為主節點master2
3、更新應用程序連接的節點為slave1的IP地址
4、slave2以slave1為新的主節點,復制slave1上的命令
5、待原來的master恢復之後,讓它成為slave1的從節點。
上述過程可以做成自動化的過程,但是需要考慮三點:a、要確保判斷節點不可達的機制健全,否則容易出現誤判斷情況
b、如果有多個從節點,如果保證隻有一個從節點被晉升為主節點是個關鍵的問題
c、通知客戶端新的主節點的機制是否足夠健壯
02 Redis Sentinel的高可用機制
Sentinel能夠自動完成故障發現和故障轉移,並及時通知應用方。這是它的核心價值所在。
Redis Sentinel是一個分佈式架構,其中包含若幹個Sentinel和若幹個Redis數據節點,每個Sentinel節點會對數據節點和其餘Sentinel節點進行監控,當它發現節點不可達時,會對節點做下線表示。如果被標識的是主節點,它還會和其他的sentinel進行協商,當大多數sentinel節點都認為主節點不可達時,他們會選舉出來一個sentinel節點來實現故障自動轉移,同時會將這個變化通知給Redis應用方,整個過程是自動的,不需要人工介入。
Redis Sentinel與Redis主從復制模式隻是多瞭若幹個sentinel節點,並沒有對redis節點做特殊處理,這是很多redis開發和運維人員容易混淆的地方。
二者架構圖如下:
在整個主服務故障到重新選擇主服務的過程中,sentinel主要幹如下幾件事情:
1、監控,sentinel節點會定期檢測redis數據節點,其餘sentinel節點是否可達
2、通知,sentinel節點會將故障轉移的結果通知給應用方。
3、主節點故障轉移:實現從節點晉升為主節點並維護後續正確的主從關系
4、配置提供者:在redis sentinel結構中,客戶端在初始化的時候連接的是sentinel節點集合,從中獲取主節點信息
上面的架構圖中不難發現sentinel也是多個的,這樣的好處有兩個:
1、可以保證sentinel的健壯性,一個sentinel掛瞭,不影響整個集群的功能。
2、對於節點的故障判斷是多個sentinel同時判斷出來的,有效的防止瞭誤判
sentinel節點本身其實就是獨立的redis節點,隻不過它們不存處數據,隻支持部分命令。
接下來,我們來看sentinel的部署和配置文件內容。
03 sentinel部署
sentinel部署之前,需要先有master和兩個slave的一主兩從架構:
127.0.0.1:6379> info replication # Replication role:master connected_slaves:2 slave0:ip=127.0.0.1,port=6380,state=online,offset=169,lag=1 slave1:ip=127.0.0.1,port=6381,state=online,offset=169,lag=1 master_repl_offset:183 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:182
sentinel的部署配置文件:
[root@VM_48_10_centos redis]# cat redis-sentinel-26379.conf port 26379 daemonize yes logfile "26379.log" dir "/usr/local/redis-3.0.7" sentinel monitor mymaster 127.0.0.1 6379 2
其中,sentinel monitor mymaster代表sentinel要監控主節點6379,2代表判斷主節點失敗至少需要2個sentinel節點同意。
其餘兩個sentinel的配置文件和這個大同小異,隻需要修改對應端口和日志文件即可。sentinel啟動命令如下:
[root@VM_48_10_centos redis]# redis-sentinel redis-sentinel-26379.conf & [1] 7311 [root@VM_48_10_centos redis]# redis-sentinel redis-sentinel-26380.conf & [1] 7366 [root@VM_48_10_centos redis]# redis-sentinel redis-sentinel-26381.conf & [2] 7380 [root@VM_48_10_centos redis]# [root@VM_48_10_centos redis]# ps -ef|grep sentinel root 7312 1 0 22:51 ? 00:00:00 redis-sentinel *:26379 [sentinel] root 7367 1 0 22:52 ? 00:00:00 redis-sentinel *:26380 [sentinel] root 7381 1 0 22:52 ? 00:00:00 redis-sentinel *:26381 [sentinel] root 7405 5850 0 22:52 pts/7 00:00:00 grep --color=auto sentinel
此時,重新查看26379這個sentinel的配置文件,會發現裡面多瞭一些內容:
[root@VM_48_10_centos redis]# cat redis-sentinel-26379.conf port 26379 daemonize yes logfile "26379.log" dir "/usr/local/redis-3.0.7" sentinel monitor mymaster 127.0.0.1 6379 2 sentinel config-epoch mymaster 0 sentinel leader-epoch mymaster 0 sentinel known-slave mymaster 127.0.0.1 6380 # Generated by CONFIG REWRITE sentinel known-slave mymaster 127.0.0.1 6381 sentinel known-sentinel mymaster 127.0.0.1 26381 0a2c77616ef88282fa12ef7c8aca142a2473cd5a sentinel known-sentinel mymaster 127.0.0.1 26380 3ad6460bf5f4b01f277fdce3aa423d596993eec5 sentinel current-epoch 0
可以發現,sentinel之間已經進行瞭交互,並寫入瞭配置文件中一些已經獲取到的內容。
使用命令info sentinel查看當前sentinel集群的信息:
[root@VM_48_10_centos redis]# redis-cli -h 127.0.0.1 -p 26379 info sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3
以上就是Redis Sentinel的使用的詳細內容,更多關於Redis Sentinel的資料請關註WalkonNet其它相關文章!
推薦閱讀:
- None Found