Redis集羣架構

Replication+Sentinel

 

這裏Sentinel的做用有三個:

• 監控:Sentinel 會不斷的檢查主服務器和從服務器是否正常運行。
• 通知:當被監控的某個Redis服務器出現問題，Sentinel經過API腳本向管理員或者其餘的應用程序發送通知。
• 自動故障轉移:當主節點不能正常工做時，Sentinel會開始一次自動的故障轉移操做，它會將與失效主節點是主從關係的其中一個從節點升級爲新的主節點，而且將其餘的從節點指向新的主節點。

工做原理就是，當Master宕機的時候，Sentinel會選舉出新的Master，並根據Sentinel中client-reconfig-script腳本配置的內容，去動態修改VIP(虛擬IP)，將VIP(虛擬IP)指向新的Master。咱們的客戶端就連向指定的VIP便可！

 

缺陷:
(1)主從切換的過程當中會丟數據
(2)Redis只能單點寫，不能水平擴容

Proxy+Replication+Sentinel

這裏的Proxy目前有兩種選擇:Codis和Twemproxy.

 

工做原理以下

• 前端使用Twemproxy+KeepAlived作代理，將其後端的多臺Redis實例分片進行統一管理與分配
• 每個分片節點的Slave都是Master的副本且只讀
• Sentinel持續不斷的監控每一個分片節點的Master，當Master出現故障且不可用狀態時，Sentinel會通知/啓動自動故障轉移等動做
• Sentinel 能夠在發生故障轉移動做後觸發相應腳本（經過 client-reconfig-script 參數配置 ），腳本獲取到最新的Master來修改Twemproxy配置

缺陷:
(1)部署結構超級複雜
(2)可擴展性差，進行擴縮容須要手動干預
(3)運維不方便

 

Redis Cluster

 

工做原理以下

• 客戶端與Redis節點直連,不須要中間Proxy層，直接鏈接任意一個Master節點
• 根據公式HASH_SLOT=CRC16(key) mod 16384，計算出映射到哪一個分片上，而後Redis會去相應的節點進行操做

具備以下優勢:
(1)無需Sentinel哨兵監控，若是Master掛了，Redis Cluster內部自動將Slave切換Master
(2)能夠進行水平擴容
(3)支持自動化遷移，當出現某個Slave宕機了，那麼就只有Master了，這時候的高可用性就沒法很好的保證了，萬一Master也宕機了，咋辦呢？ 針對這種狀況，若是說其餘Master有多餘的Slave ，集羣自動把多餘的Slave遷移到沒有Slave的Master 中。

缺點:
(1)批量操做是個坑
(2)資源隔離性較差，容易出現相互影響的狀況。

 

問題1:懂Redis事務麼？
正常版：Redis事務是一些列redis命令的集合,blabla…
高調版: 咱們在生產上採用的是Redis Cluster集羣架構，不一樣的key是有可能分配在不一樣的Redis節點上的，在這種狀況下Redis的事務機制是不生效的。其次，Redis事務不支持回滾操做，簡直是雞肋！因此基本不用！

問題2:Redis的多數據庫機制，瞭解多少？
正常版：Redis支持多個數據庫，而且每一個數據庫的數據是隔離的不能共享，單機下的redis能夠支持16個數據庫（db0 ~ db15）
高調版: 在Redis Cluster集羣架構下只有一個數據庫空間，即db0。所以，咱們沒有使用Redis的多數據庫功能！

問題3:Redis集羣機制中，你以爲有什麼不足的地方嗎？
正常版: 不知道
高調版: 假設我有一個key，對應的value是Hash類型的。若是Hash對象很是大，是不支持映射到不一樣節點的！只能映射到集羣中的一個節點上！還有就是作批量操做比較麻煩！

問題4:懂Redis的批量操做麼？
正常版: 懂一點。好比mset、mget操做等，blabla
高調版: 咱們在生產上採用的是Redis Cluster集羣架構，不一樣的key會劃分到不一樣的slot中，所以直接使用mset或者mget等操做是行不通的。

問題5:那在Redis集羣模式下，如何進行批量操做？
正常版:不知道
高調版:這個問題其實能夠寫一篇文章了，改天寫。這裏說一種有一個很簡單的答法，足夠面試用。即:
若是執行的key數量比較少，就不用mget了，就用串行get操做。若是真的須要執行的key不少，就使用Hashtag保證這些key映射到同一臺Redis節點上。簡單來講語法以下

對於key爲{foo}.student一、{foo}.student2，{foo}student3，這類key必定是在同一個redis節點上。由於key中「{}」之間的字符串就是當前key的hash tags， 只有key中{ }中的部分才被用來作hash，所以計算出來的redis節點必定是同一個!

ps:若是你用的是Proxy分片集羣架構，例如Codis這種，會將mget/mset的多個key拆分紅多個命令發往不一樣得Redis實例，這裏很少說。我推薦答的仍是Redis Cluster。

問題6:大家有對Redis作讀寫分離麼？
正常版:沒有作，至於緣由額。。。額。。。額。。沒辦法了，硬着頭皮扯~
高調版:不作讀寫分離。咱們用的是Redis Cluster的架構，是屬於分片集羣的架構。而Redis自己在內存上操做，不會涉及IO吞吐，即便讀寫分離也不會提高太多性能，Redis在生產上的主要問題是考慮容量，單機最多10-20G，key太多下降Redis性能.所以採用分片集羣結構，已經能保證了咱們的性能。其次，用上了讀寫分離後，還要考慮主從一致性，主從延遲等問題，徒增業務複雜度。