redis的主從復制模式下,一旦主節點出現了故障無法提供服務了,需要人工進行主從切換,同時大量的客戶端需要被通知切換到新的主節點上,對于有了一定規模的應用來說,這種方案的延遲是無法接受的,于是redis2.8提供了Redis-Sentinel(哨兵)來解決這個問題.
目錄
1.啥是哨兵節點:
2.redis數據節點:
3.哨兵節點集合:
4.人工干預處理流程:
5.哨兵節點監控處理及流程:
1.啥是哨兵節點:
哨兵節點是一個獨立的redis-sentinel進程,是負責監控redis數據節點的節點.
2.redis數據節點:
主節點和從節點共同成為數據節點.
3.哨兵節點集合:
若干個哨兵節點(redis-sentinel)共同構成的集合.
哨兵節點個數設置:
哨兵節點在使用的時候,可以有一個,也可以使用多個,但一般不會只使用一個,而是若干個哨兵節點構成的集合.共同監控一組數據節點:
1. 是為了防止一個哨兵節點因誤判或偶然性的網絡問題等做出錯誤的相應,當多個哨兵節點共同監控,當出現問題時,多個哨兵節點都反饋,提高正確性.
2. 哨兵節點本身也可能出現問題.若哨兵節點只有一個,當這個哨兵節點掛了,后續redis主節點掛了,就無法進行自動恢復過程了.
4.人工干預處理流程:
當主節點出現問題不能提供服務時,
1>.程序員通過監控系統,發現redis主節點故障宕機了.先嘗試重啟主節點,看能否解決問題,
2>.若主節點問題暫時找不到,就選擇一個從節點作為新的主節點(slaveof no one命令),然后修改剩余從節點,連接到新的主節點上(slaveof ip port命令).
3>.告知客戶端(修改客戶端配置),讓客戶端能夠連接新的主節點,掛到這組機器上.
后續若主節點能正常啟動了,就讓其作為新的從節點,連接到主節點上.
這一系列操作,對機器來說,延時性是非常高的,手動完成這一系列操作后,至少要半個小時以上,這個過程中,一直無法進行寫操作,是無法接受的;
還有,萬一在人工操作的過程中,出現了錯誤操作,可能帶來更嚴重的問題,這都是不可預防的.
于是就更需要引入哨兵機制,通過自動化的方式,讓程序對主節點掛了做出處理.
若是從節點掛了,影響不是很大,讀寫操作都還能正常進行;若是主節點掛了,redis哨兵節點就需要進行處理了.
5.哨兵節點監控處理及流程:
使用多個哨兵節點(計數個),通過建立tcp長連接(定期發送心跳包),一起監控redis數據節點(主,從節點).
1>.監控: 哨兵節點通過監控發現主節點出現問題時,不會立即做出處理,而是向其他哨兵節點確認,多數節點都發現該節點出現故障,就進行處理操作.
這步主要是防?該情況：出故障的不是主節點，?是發現故障的哨兵節點，該情況經常發?于哨兵節點的?絡被孤?的場景下.
2>.監控到主節點出現故障后,從哨兵節點集群中選出一個leader來處理故障轉移.
3>.故障轉移: leader哨兵節點從 從節點中選出一個作為主節點,讓其他從節點同步新主節點；
4>.通知: 哨兵節點通知應?層客戶端程序,讓其轉移到新主節點。后續客戶端進行讀寫操作就會針對新的主節點操作了.
redis哨兵的核心功能:
1.監控;
2.自動故障轉移
3.通知
哨兵節點的個數:
最好設置成計數個(3個剛好), 這和leader的選舉有關和一些別的原因,后續會再細說.
