1.1 主從同步
1、CPA原理
1. CPA原理是分布式存儲理論的基石： C(一致性)； A(可用性)； P(分區容忍性);
2. 當主從網絡無法連通時，修改操作無法同步到節點，所以“一致性”無法滿足
3. 除非我們犧牲“可用性”，也就是暫停分布式節點服務，不再提供修改數據功能，知道網絡恢復
一句話概括CAP: 當網絡分區發生時，一致性 和 可用性 兩難全
2、redis主從同步介紹
1. 和MySQL主從復制的原因一樣，Redis雖然讀取寫入的速度都特別快，但是也會產生讀壓力特別大的情況。
2. 為了分擔讀壓力，Redis支持主從復制，Redis的主從結構可以采用一主多從或者級聯結構。
3. Redis主從復制可以根據是否是全量分為全量同步和增量同步。
注：redis主節點Master掛掉時，運維讓從節點Slave接管（redis主從默認無法自動切換，需要運維手動切換）
3、全量同步（快照同步）
注：Redis全量復制一般發生在Slave初始化階段，這時Slave需要將Master上的所有數據都復制一份。具體步驟如下：
1）從服務器連接主服務器，發送SYNC命令；
2）主服務器接收到SYNC命名后，開始執行BGSAVE命令生成RDB文件並使用緩沖區記錄此后執行的所有寫命令；
3）主服務器BGSAVE執行完后，向所有從服務器發送快照文件，並在發送期間繼續記錄被執行的寫命令；
4）從服務器收到快照文件后丟棄所有舊數據，載入收到的快照；
5）主服務器快照發送完畢后開始向從服務器發送緩沖區中的寫命令；
6）從服務器完成對快照的載入，開始接收命令請求，並執行來自主服務器緩沖區的寫命令；
7）完成上面幾個步驟后就完成了從服務器數據初始化的所有操作，從服務器此時可以接收來自用戶的讀請求。
4、增量同步
1. 主節點會將那些對自己狀態產生修改性影響的指令記錄在本地內存buffer中，然后異步將buffer中指令同步到從節點
2. 從節點一邊執行同步指令達到主節點狀態，一邊向主節點反饋自己同步到哪里（偏移量）
3. 當網絡狀態不好時，從節點無法和主節點進行同步，當網絡恢復時需要進行快照同步
5、Redis主從同步策略
1. 主從剛剛連接的時候，進行全量同步；全同步結束后，進行增量同步。
2. 當然，如果有需要，slave 在任何時候都可以發起全量同步。
3. redis 策略是，無論如何，首先會嘗試進行增量同步，如不成功，要求從機進行全量同步。
6、注意點
1. 如果多個Slave斷線了，需要重啟的時候，因為只要Slave啟動，就會發送sync請求和主機全量同步，當多個同時出現的時候，可能會導致Master IO劇增宕機。
1.2 哨兵模式----sentinel
參考博客：https://www.cnblogs.com/zhoujinyi/p/5569462.html
參考博客2：https://segmentfault.com/a/1190000002680804
1、sentinel作用
1. 當用Redis做主從方案時，假如master宕機，Redis本身無法自動進行主備切換
2. 而Redis-sentinel本身也是一個獨立運行的進程，它能監控多個master-slave集群，發現master宕機后能進行自動切換。
2、sentinel原理
1. sentinel負責持續監控主節點的健康，當主節掛掉時，自動選擇一個最優的從節點切換成主節點
2. 從節點來連接集群時會首先連接sentinel，通過sentinel來查詢主節點的地址
3. 當主節點發生故障時，sentinel會將最新的主節點地址告訴客戶端，可以實現無需重啟自動切換redis
3、Sentinel支持集群
1. 只使用單個sentinel進程來監控redis集群是不可靠的，當sentinel進程宕掉后sentinel本身也有單點問題
2. 如果有多個sentinel，redis的客戶端可以隨意地連接任意一個sentinel來獲得關於redis集群中的信息。
4、Sentinel版本
1. Sentinel當前穩定版本稱為Sentinel 2，Redis2.8和Redis3.0附帶穩定的哨兵版本
2. 安裝完redis-3.2.8后，redis-3.2.8/src/redis-sentinel啟動程序 redis-3.2.8/sentinel.conf是配置文件。
5、運行sentinel兩種方式（效果相同）
法1：redis-sentinel /path/to/sentinel.conf
法2：redis-server /path/to/sentinel.conf --sentinel
1. 以上兩種方式，都必須指定一個sentinel的配置文件sentinel.conf，如果不指定，將無法啟動sentinel。
2. sentinel默認監聽26379端口，所以運行前必須確定該端口沒有被別的進程占用。
6、sentinel.conf配置文件說明
1. 配置文件只需要配置master的信息就好啦，不用配置slave的信息，因為slave能夠被自動檢測到
2. 需要注意的是，配置文件在sentinel運行期間是會被動態修改的，例如當發生主備切換時候，配置文件中的master會被修改為另外一個slave。
3. 這樣，之后sentinel如果重啟時，就可以根據這個配置來恢復其之前所監控的redis集群的狀態。
# sentinel.conf 配置說明
sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 60000 sentinel failover-timeout mymaster 180000 sentinel parallel-syncs mymaster 1
'''1、sentinel monitor mymaster 127.0.0.1 6379 2''' #1）sentinel監控的master的名字叫做mymaster,地址為127.0.0.1:6379 #2）當集群中有2個sentinel認為master死了時，才能真正認為該master已經不可用了 '''2、sentinel down-after-milliseconds mymaster 60000''' #1）sentinel會向master發送心跳PING來確認master是否存活，如果master在60000毫秒內不回應PONG #2）那么這個sentinel會單方面地認為這個master已經不可用了 '''3、sentinel failover-timeout mymaster 180000''' #1）如果sentinel A推薦sentinel B去執行failover，B會等待一段時間后，自行再次去對同一個master執行failover， #2）這個等待的時間是通過failover-timeout配置項去配置的。 #3）從這個規則可以看出，sentinel集群中的sentinel不會再同一時刻並發去failover同一個master， #4）第一個進行failover的sentinel如果失敗了，另外一個將會在一定時間內進行重新進行failover，以此類推。 '''4、sentinel parallel-syncs mymaster 1''' #1）在發生failover主備切換時，這個選項指定了最多可以有多少個slave同時對新的master進行同步 #2）如果這個數字越大，就意味着越多的slave因為replication而不可用，這個數字越小，完成failover所需的時間就越長。 #3）可以通過將這個值設為 1 來保證每次只有一個slave處於不能處理命令請求的狀態。
7、配置傳播
1. 一旦一個sentinel成功地對一個master進行了failover，它將會把關於master的最新配置通過廣播形式通知其它sentinel，其它的sentinel則更新對應master的配置。
2. 一個faiover要想被成功實行，sentinel必須能夠向選為master的slave發送SLAVE OF NO ONE命令，然后能夠通過INFO命令看到新master的配置信息。
3. 當將一個slave選舉為master並發送SLAVE OF NO ONE`后，即使其它的slave還沒針對新master重新配置自己，failover也被認為是成功了的。
因為每一個配置都有一個版本號，所以以版本號最大的那個為標准：
1）假設有一個名為mymaster的地址為192.168.1.50:6379。
2）一開始，集群中所有的sentinel都知道這個地址，於是為mymaster的配置打上版本號1。
3）一段時候后mymaster死了，有一個sentinel被授權用版本號2對其進行failover。
4）如果failover成功了，假設地址改為了192.168.1.50:9000，此時配置的版本號為2
5）進行failover的sentinel會將新配置廣播給其他的sentinel，發現新配置的版本號為2時，版本號變大了，
說明配置更新了，於是就會采用最新的版本號為2的配置。
1.3 codis
1、為什么會出現codis
1. 在大數據高並發場景下，單個redis實例往往會無法應對
2. 首先redis內存不易過大，內存太大會導致rdb文件過大，導致主從同步時間過長
3. 其次在CPU利用率中上，單個redis實例只能利用單核，數據量太大，壓力就會特別大
2、什么是codis
1. codis是redis集群解決方案之一，codis是GO語言開發的代理中間件
2. 當客戶端向codis發送指令時，codis負責將指令轉發給后面的redis實例來執行，並將返回結果轉發給客戶端
3、codis部署方案
1. 單個codis代理支撐的QPS比較有限，通過啟動多個codis代理可以顯著增加整體QPS
2. 多codis還能起到容災功能，掛掉一個codis代理還有很多codis代理可以繼續服務
4、codis分片的原理
1. codis負責將特定key轉發到特定redis實例，codis默認將所有key划分為1024個槽位
2. 首先會對客戶端傳來的key進行crc32計算hash值，然后將hash后的整數值對1024進行取模，這個余數就是對應的key槽位
3. 每個槽位都會唯一映射到后面的多個redis實例之一，codis會在內存中維護槽位和redis實例的映射關系
4. 這樣有了上面key對應的槽位，那么它應該轉發到那個redis實例就很明確了
5. 槽位數量默認是1024，如果集群中節點較多，建議將這個數值大一些，比如2048,4096
5、不同codis槽位如何同步
1. 如果codis槽位值存在內存中，那么不同的codis實例間的槽位關系得不到同步
2. 所以codis還需要一個分布式配置存儲的數據庫專門來持久化槽位關系
3. codis將槽位關系存儲在zookeeper中，並且提供一個dashboard可以來觀察和修改槽位關系
111111111111111111111111111111