Redis簡介、高可用及集群相關配置
1 Redis持久化的兩種方式：
1 RDB：可以再指定的時間間隔內生成數據集的時間點快照（每隔一定的時間做一個快照，進行將其刷新到磁盤上，斷電）
2 AOF：把服務器執行的所有寫操作命令記錄下來，然後在服務器啟動時，通過重新執行這些命令來還原數據集，AOF文件的操作相當於自增操作，
Redis可以同時使用RDB和AOF這兩種方式。
當Redis重啟時，會優先使用AOF文件來還原數據集。
你也可以關閉持久化功能
RDB：可以做備份，RDB可以最大化Redis性能，父進程在保存RDB文件時唯一要做的就是fork出一個子進程，然後這個子進程會處理接下來的所有保存工作，父進程無需進行任何磁盤的I/O操作。
RDB缺點：時間間隔不能太頻繁，fork可能會非常耗時，導致服務器在某一時間段內停止處理客戶端，
save 900 1 在900s內，如果有一個key被改變，那麽就進行快照
save 300 10 如果在300s內，如果有10個key被改變，那麽久進行快照
save 60 10000 同上
快照的存儲位置：
The filename where to dump the DB
dbfilename dump.rdb
[root@controller01 ~]# cd /var/lib/redis/
[root@controller01 redis]# ls
dump.rdb
[root@controller01 redis]# file dump.rdb
快照的流程
1 fork子進程
2 父進程繼續幹活
3 子進程開始將內存中的數據開始寫入磁盤中的臨時文件
4 當子進程寫完數據後，用臨時文件替換RDB文件，此RDB文件是經過壓縮的，因此其占用空間小
5 服務啟動時，直接將此文件載入到內存中即可
AOF優點
每一秒執行寫操作，down機只會丟失1秒的數據
AOF 文件是一個只進行追加操作的日誌文件，即使日誌因為某些原因而包含了威脅如完整的命令，Redis-check-aof工具也可以修復
Redis可以在AOF文件體積變大時，自動地在後臺對AOF進行重寫，
AOF 很容易被讀懂
AOF缺點：
1 體積大於RDB
2 速度慢於RDB
Redis 復制（replication）
2 Redis復制
1 使用異步復制，從Redis2.8開始，從服務器會以每一秒的頻率向主服務器報告復制流的處理進度
2 一個主服務器可以有多個從服務器
3 不僅主服務器可以有從服務器，從服務器也可以有自己的從服務器
4 復制功能不會阻塞主服務器： 即使有一個或多個從服務器正在進行初次同步， 主服務器也可以繼續處理命令請求。
5 復制功能也不會阻塞從服務器： 只要在?redis.conf?文件中進行了相應的設置， 即使從服務器正在進行初次同步， 服務器也可以使用舊版本的數據集來處理命令查詢。
6 不過， 在從服務器刪除舊版本數據集並載入新版本數據集的那段時間內， 連接請求會被阻塞。
7 你還可以配置從服務器， 讓它在與主服務器之間的連接斷開時， 向客戶端發送一個錯誤。
8 復制功能可以單純地用於數據冗余（data redundancy）， 也可以通過讓多個從服務器處理只讀命令請求來提升擴展性（scalability）： 比如說， 繁重的?SORT?命令可以交給附屬節點去運行。
9 可以通過復制功能來讓主服務器免於執行持久化操作： 只要關閉主服務器的持久化功能， 然後由從服務器去執行持久化操作即可。
二 環境準備
1 安裝gcc
2 安裝軟件
server1 
復制到其他主機
server2 
server3 
三 配置主從架構：
1 server1 為主服務器：
配置其監聽端口為所有端口
2 server 2從服務器端配置：
配置監聽段口為所有
2 配置主服務器的IP和端口為6379和server1 IP 
3 server3從服務器端配置：
服務器端及客戶端重啟服務加載配置，並在服務端插入數據：
服務端查看綁定端口情況
客戶端查看綁定端口情況
4 客戶端查看服務端插入數據是否同步成功：
四 Redis 高可用配置：
1 環境：
| 主機名 | IP地址 | 描述 |
|---|---|---|
| server 1 | 192.168.3.10 | master |
| server2 | 192.168.3.20 | slave |
| server3 | 192.168.3.30 | slave |
2 Redis sentinel介紹
sentinel 的三個任務：
1 監控(monitoring)：不斷檢測主服務器和從服務器是否運行正常
2 提醒(notification)： 當被監控的某個redis服務器出現問題時，sentinel 可以通過API向管理員或其他應用程序發送通知：
3 自動故障遷移：當一個主服務器不能正常工作時， Sentinel 會開始一次自動故障遷移操作， 它會將失效主服務器的其中一個從服務器升級為新的主服務器， 並讓失效主服務器的其他從服務器改為復制新的主服務器； 當客戶端試圖連接失效的主服務器時， 集群也會向客戶端返回新主服務器的地址， 使得集群可以使用新主服務器代替失效服務器。
啟動redis-sentinel程序：
對於 redis-sentinel 程序， 你可以用以下命令來啟動 Sentinel 系統：
對於 redis-server 程序， 你可以用以下命令來啟動一個運行在 Sentinel 模式下的 Redis 服務器：
redis-server /path/to/sentinel.conf --sentinel
兩種方法都可以啟動一個 Sentinel 實例。
啟動 Sentinel 實例必須指定相應的配置文件， 系統會使用配置文件來保存 Sentinel 的當前狀態， 並在 Sentinel 重啟時通過載入配置文件來進行狀態還原。
如果啟動 Sentinel 時沒有指定相應的配置文件， 或者指定的配置文件不可寫（not writable）， 那麽 Sentinel 會拒絕啟動。
sentinel API
默認情況下，sentinel 使用TCP的26379端口
sentinel 接受redis協議格式的命令請求，所以你可以使用 redis-cli 或者任何其他 Redis 客戶端來與 Sentinel 進行通訊。
有兩種方式可以和 Sentinel 進行通訊：
第一種方法是通過直接發送命令來查詢被監視 Redis 服務器的當前狀態， 以及 Sentinel 所知道的關於其他 Sentinel 的信息， 諸如此類。
另一種方法是使用發布與訂閱功能， 通過接收 Sentinel 發送的通知： 當執行故障轉移操作， 或者某個被監視的服務器被判斷為主觀下線或者客觀下線時， Sentinel 就會發送相應的信息。
2 復制配置文件：
2 修改配置：
參數詳解：
1 sentinel monitor mymaster 192.168.3.10 6379 2
設置master 並寫入如果有兩個節點認為主服務器down機，則主服務器down機
主觀下線和客觀下線
指單個實例sentinel實例對服務器作出的下線判斷操作
如果服務器在給定的毫秒數之內， 沒有返回 Sentinel 發送的 PING 命令的回復， 或者返回一個錯誤， 那麽 Sentinel 將這個服務器標記為主觀下線（subjectively down，簡稱 SDOWN ）。
客觀下線：多個slave對同一個服務器作出sdown判斷
1 sentinel down-after-milliseconds mymaster 5000
設置認為服務器斷線的確認時間，即5s後確認其斷線
2 sentinel config-epoch mymaster 1
設置當主服務器down機後負責與新的master同步的slave 的數量，一旦slave參與與master之間的消息同步，則其不能對外客戶端進行響應
4 復制配置文件至其他節點：
5 啟動服務：
6 進行測試：
此時的master 為server2,如果將server2 down機後，由server1接管 
五 Redis 集群：
1 添加相關文件：
2 創建配置文件
3 拷貝配置文件到其他節點：
4 修改配置文件端口號
5 安裝redis用以啟動此服務
1 安裝gcc
2 安裝redis
啟動服務：其他的一次類推
查看啟動情況
6 集群搭建：
1 安裝相關軟件用於搭建集群：
2 集群啟動
3 集群查看
4 基本操作：
1 添加節點：
啟動服務：
查看服務：
1 隨機添加節點：
2 添加master節點：
3 為指定的master添加節點：
2 節點的移動，將某一個slave 節點移動到對應的master 上
Redis簡介、高可用及集群相關配置