今天本想跟着教程開始自己集成Redis，後來發現application.peroperties中含有哨兵等配置，不太懂，轉而又去補了redis集羣部分。明天開始集成redis。下面是今日瞭解的內容。
具體操作沒有實時截圖，根據教程去實踐好了。在附件的“第八章” Redis入門指南（第2版）.pdf
一、Redis主從實例
1.啓動redis
redis-server。
2.配置從數據庫
redis-server --port 從數據庫端口號 --slaveof -- 主數據庫IP地址 主數據庫端口號。
此時，主數據庫的任何變化都會同步到從數據庫中。
3. 使用 redis-cli -p 主/從端口號 命令，進入到command下，輸入info replication查看當前數據庫信息。
4. 從數據庫只讀，一般不做寫。因爲對主數據庫的修改會同步到從數據庫中，有可能會把從數據庫中的某一鍵值修改，造成數據不一致。
5. 從數據庫可以使用 slave no one 停止與其他數據庫進行同步，從而成爲主數據庫。
二、主從同步原理
從數據庫會使用SYNC命令向主數據庫發起同步，主數據庫收到命令後，會在後臺開始保存快照，並把保存期間的收到的命令緩存起來。在Redis2.6以前，主數據庫會將所有數據保存到快照中，不能實現增量複製。在其後的版本，從數據庫使用PSYNC向主數據庫發起同步。同步原理：通過主數據庫的ID和偏移量，完成更新操作。當主數據庫實例重啓時，還是要遵循2.6以前版本的全複製。
三、哨兵（Sentinel）
1. 用途：監控數據庫是否正常運行。在主數據故障時，將從數據庫升級爲主數據庫。
2. 配置： 新建一個哨兵的配置文件：sentinel.conf 文件中輸入如下命令（當然這裏命令不只是這一種）
sentinel monitor 自定義的主數據庫名 主數據庫IP地址 主數據庫端口號 故障恢復操作前，同意恢復故障的哨兵數目
例如:
sentinel monitor mymaster 127.0.0.1 6379 1
3. 一個哨兵可以監控多個主從系統，一個主從系統可以被多個哨兵監控。
4. 原理：哨兵啓動後，和主數據庫建立兩條連接。分別是：
（1）一條用來監控主數據庫的_sentinel_:hello頻道來獲取主數據庫的信息和其他同樣在監控此主數據庫的哨兵信息。
（2）我們知道，處於訂閱狀態時，不能夠執行除了訂閱和發佈相關的其他命令。此第二條連接就是用來進行執行其他命令使用的。
和主數據庫建立連接後，哨兵會定時進行如下操作：
（1）每隔10秒，哨兵會向主、從數據庫發送INFO命令。
（2）每隔2秒，哨兵會向主、從數據庫的_sentinel_:hello發送自己的信息。
（3）每隔1秒，哨兵會向主、從數據庫和其他哨兵發送PING命令。
在配置（sentinel.conf ）中，配置： sentinel down_after_milliseconds 主數據庫名 時間 ，指定哨兵ping主數據庫無反應後的等待時間。超過此時間，主（或從）數據庫仍沒有迴應，則哨兵認爲此數據庫下線，我們成爲：“主觀下線”。
當此數據庫是主數據時，此哨兵會進一步判斷是否要進行故障恢復，會詢問其他監控此主數據庫的哨兵節點的意見。如果達到指定數量時，改哨兵會認爲此主數據庫“客觀下線”。此時，該哨兵會發起對主從系統的故障恢復並向其他節點發起選舉。以判斷是否要進行恢復（判斷標準就是此前提到了的“ 故障恢復操作前，同意恢復故障的哨兵數目”）和是否選舉自己是否成爲哨兵中的領頭羊（領頭羊進行故障恢復）。
哨兵之間進行選舉的算法，Rafe算法。（具體可以參考https://raft.github.io/）
哨兵開始恢復時，在所有從數據庫中選舉出一個主數據庫。選舉算法如下：
（1）在所有的在線從數據庫中，選擇優先級最高的從數據庫，即slave_priority
（2）如果有多個高優先級的從數據庫，則複製的命令偏移量越大（複製越完整）越優先。
（3）如果以上條件都一樣，則選擇運行ID（每個redis實例都有唯一的run id，通過SHA1-sized random number生成）最小的從數據庫。
