redis（二）redis的主從模式和集群模式
主從模式
redis的主從模式，指的是針對多台redis實例時候，只存在一台主服務器master，提供讀寫的功能，同時存在依附在這台主服務器的從服務器slaver，只提供讀服務，且數據和主服務器保持一致。主服務器只能有一台，從服務器可以有多台，而且可以存在級聯模式(從服務器下面也掛載從服務器)。主從的存在是為了分散訪問量，提高訪問可讀性，同事保證數據的冗余和備份。
從服務器需要在配置文件中指定主服務的地址 slaveof 127.0.0.1 6379(主服務器的ip)。
redis的主從數據同步：
1、全量同步：
一般出現在從節點初始化階段，全量數據需要從主節點上復制過來。
收到同步命令之后，master都會啟動一個后台進程，將數據庫快照保存到文件中，同時master主進程會開始收集新的寫命令並緩存起來。如果master同時收到多個 slave發來的同步連接命令，只會使用啟動一個進程來寫數據庫鏡像，然后發送給所有slave，但是可能出現io劇增導致主服務器宕機。
2、增量同步：出現在從服務器初始化成功之后，開始正常提供服務之后，對主服務器發起增量同步，主服務器通過之前建立好的連接，發送寫命令給從服務器。在增量同步失敗的情況下，可以發起全量同步。
哨兵作用：
哨兵模式的出現，是為了彌補主服務突然宕機的情況下，能夠及時選舉出新的主服務器，使得服務依舊可用。 通過sentinel.conf配置文件進行配置 sentinel monitor mymast 192.168.110.133 6379 1 #主節點 名稱 IP 端口號 選舉次數
哨兵模式，指的是在原有主從的基礎之上，增加sentinel系統來實時用來監聽redis的健康狀況。哨兵本質也是redis，用於監聽redis服務，哨兵模式是集群模式，每個哨兵都是實時想其他哨兵，master，slaver發送心跳，來判斷是都活着。當出現master不能訪問的時候，采集其他哨兵對master的判斷情況，當有半數以上的投票判斷master死亡之后，哨兵集群會通過一定的算法來重新選舉出一個slaver節點作為master，以保證整個reids服務的可用性。
選舉結束之后，所有的配置文件都會發生修改。
正對死亡的reids實例，哨兵也會監聽。當原來死亡的主服務器重新恢復之后，哨兵集群會把它當做從服務器加入到redis服務中。
自動切換ip漂移：
在主從模式下，客戶端訪問redis的服務器的ip地址是固定的，通過keepalived，可以使得客戶端在redis故障切換之后，不需要修改ip，只需要訪問固定的虛擬ip就可以。
集群模式
redis集群模式，指的是針對多個redis實例，去中心化，去中間件，集群中的每個節點都是平等的關系，都是對等的，每個節點都保存各自的數據和整個集群的狀態，並且每個節點都和其他所有節點連接，而且這些連接保持活躍，這樣就保證了我們只需要連接集群中的任意一個節點，就可以獲取到其他節點的數據。
redis集群沒有統一的ip入口，客戶端與redis節點直連,不需要中間proxy層，客戶端訪問任意一個節點，都可以進入集群，訪問集群的所有數據。節點內部使用PING-PONG機制來互相通信，當集群添加一個節點的時候，只需要連接集群中任意一個節點即可，不需要連接所有節點。(https://blog.csdn.net/nihao12323432/article/details/81204499)
當超過半數的master節點檢測某個master節點失效時(通行超時)，該節點才會失效，進行故障轉移。因此必須要有3個以上的master才可以創建出集群。
如果一個master進行故障轉移的時候，發現沒有slaver來使用，那么整個集群fails。當整個集群有一半的master出現故障，無論有沒有slaver，整個集群fails。
通過 redis-trib.rb create --replicas 1來創建集群。
哈希槽：
哈希槽的存在，是為了能快速找到key所在的節點。一個redis集群包含2^16=16384個哈希槽，會分配給各個節點。可以通過槽的分配來控制不同節點的數據量和請求數。哈希槽通過順時針來分片，即一個節點順時針到下一個幾點之間的槽屬於下一個節點。
每一個key，通過公式slot=CRC16（key）/16384來計算屬於哪個槽。
擴容的時候，只需要動一個節點的數據即可。eg.A->B(順時針)，中間插入C節點，那么只修要遷移B的數據，重新分配到B和C中即可。
每一個redis實例節點都會保持元數據對應的哈希槽信息，數據會不斷的同步。