Redis高級特性

Redis高可用

主要是通過主從複製和哨兵機制以及keepalived自動重啓來實現高可用。

主從複製機制

redis的複製功能是支持多個數據庫之間的數據同步。一類是主數據庫（master）一類是從數據庫（slave），主數據庫可以進行讀寫操作，當發生寫操作的時候自動將數據同步到從數據庫，而從數據庫一般是隻讀的，並接收主數據庫同步過來的數據，一個主數據庫可以有多個從數據庫，而一個從數據庫只能有一個主數據庫。
通過主從複製機制可以很好的實現讀寫分離，主服務器讀，從服務器寫。

過程：
1：當一個從數據庫啓動時，會向主數據庫發送sync命令，
2：主數據庫接收到sync命令後會開始在後臺保存快照（執行rdb操作），並將保存期間接收到的命令緩存起來
3：當快照完成後，redis會將快照文件和所有緩存的命令發送給從數據庫。
4：從數據庫收到後，會載入快照文件並執行收到的緩存的命令。
實現方式是通過修改配置文件redis.conf

slaveof 192.168.33.130 6379  --設置主服務器
masterauth 123456--- 主redis服務器配置了密碼,則需要配置

哨兵機制

Redis的哨兵(sentinel) 系統用於管理多個 Redis 服務器,該系統執行以下三個任務:

• 監控(Monitoring): 哨兵(sentinel) 會不斷地檢查你的Master和Slave是否運作正常。
• 提醒(Notification):當被監控的某個 Redis出現問題時, 哨兵(sentinel) 可以通過 API 向管理員或者其他應用程序發送通知。
• 自動故障遷移(Automatic failover): 當一個Master不能正常工作時，哨兵(sentinel) 會開始一次自動故障遷移操作,它會將失效Master的其中一個Slave升級爲新的Master, 並讓失效Master的其他Slave改爲複製新的Master; （通過發佈訂閱模式通知其他的從服務器，修改配置文件，讓它們切換主機。）當客戶端試圖連接失效的Master時,集羣也會向客戶端返回新Master的地址,使得集羣可以使用Master代替失效Master。
  哨兵(sentinel) 是一個單獨的進程,你可以在一個架構中運行多個哨兵(sentinel) 進程,這些進程使用流言協議(gossipprotocols)來接收關於Master是否下線的信息,並使用投票協議(agreement protocols)來決定是否執行自動故障遷移,以及選擇哪個Slave作爲新的Master.
  每個哨兵(sentinel) 會向其它哨兵(sentinel)、master、slave定時發送消息,以確認對方是否”活”着,如果發現對方在指定時間(可配置)內未迴應,則暫時認爲對方已掛(所謂的”主觀認爲宕機” Subjective Down,簡稱sdown).
  若“哨兵羣”中的多數sentinel,都報告某一master沒響應,系統才認爲該master"徹底死亡"(即:客觀上的真正down機,Objective Down,簡稱odown),通過一定的vote算法,從剩下的slave節點中,選一臺提升爲master,然後自動修改相關配置.
  雖然哨兵(sentinel) 釋出爲一個單獨的可執行文件 redis-sentinel ,但實際上它只是一個運行在特殊模式下的 Redis 服務器，你可以在啓動一個普通 Redis 服務器時通過給定 --sentinel 選項來啓動哨兵(sentinel).
  如何修改配置實現哨兵模式

  1.拷貝到etc目錄
  cp sentinel.conf  /usr/local/redis/etc
  2.修改sentinel.conf配置文件
  sentinel monitor mymast  192.168.110.133 6379 1  #主節點 名稱 IP 端口號 選舉次數
  3. 修改心跳檢測 5000毫秒
  sentinel down-after-milliseconds mymaster 5000
  4.sentinel parallel-syncs mymaster 2 --- 做多多少合格節點
  4. 啓動哨兵模式
  ./redis-server /usr/local/redis/etc/sentinel.conf --sentinel &
  5. 停止哨兵模式
  kill -9 pid
  

Redis持久化機制

Redis持久化,就是將內存數據保存到硬盤。Redis 持久化存儲 有AOF 與 RDB 兩種模式。

RDB(默認)

二進制文件方式，RDB 是在某個時間 點將數據寫入一個臨時文件，
優點：使用單獨子進程來進行持久化，主進程不會進行任何 IO 操作，保證了 redis 的高性能。
缺點：RDB 是間隔一段時間進行持久化，如果持久化之間 redis 發生故障，會發生數據丟失。所以這種方式更適合數據要求不嚴謹的時候。、
當redis當機的時候，如果不是突然被殺進程或者斷電等類似引起的當機會在當機的時候進行一次持久化。
持久化的時間點是可以自己自定義的，修改redis.conf，具體配置參數如下

#dbfilename：持久化數據存儲在本地的文件
dbfilename dump.rdb
#dir：持久化數據存儲在本地的路徑，如果是在/redis/redis-3.0.6/src下啓動的redis-cli，則數據會存儲在當前src目錄下
dir ./
##snapshot觸發的時機，save    
##如下爲900秒後，至少有一個變更操作，纔會snapshot  
##對於此值的設置，需要謹慎，評估系統的變更操作密集程度  
##可以通過“save “””來關閉snapshot功能  
#save時間，以下分別表示更改了1個key時間隔900s進行持久化存儲；更改了10個key300s進行存儲；更改10000個key60s進行存儲。
save 900 1
save 300 10
save 60 10000
##當snapshot時出現錯誤無法繼續時，是否阻塞客戶端“變更操作”，“錯誤”可能因爲磁盤已滿/磁盤故障/OS級別異常等  
stop-writes-on-bgsave-error yes  
##是否啓用rdb文件壓縮，默認爲“yes”，壓縮往往意味着“額外的cpu消耗”，同時也意味這較小的文件尺寸以及較短的網絡傳輸時間  
rdbcompression yes  

AOF

是日誌形式進行存儲的，文件較大。每次修改都持久化，可以理解爲實時的。
優點：可以保持更高的數據完整性，如果設置追加 file 的時間是 1s，如果 redis 發生故障，最多會丟失 1s 的數據；且如果日誌寫入不完整支持 redis-check-aof 來進行日誌修復；AOF 文件沒被 rewrite 之前（文件過大時會對命令進行合併重寫），可以刪除其中的某些命令（比如誤操作的 flushall）。
缺點：AOF 文件比 RDB 文件大，且恢復速度慢。
通過配置文件配置可手動開啓

##此選項爲aof功能的開關，默認爲“no”，可以通過“yes”來開啓aof功能  
##只有在“yes”下，aof重寫/文件同步等特性纔會生效  
appendonly yes  

##指定aof文件名稱  
appendfilename appendonly.aof  

##指定aof操作中文件同步策略，有三個合法值：always everysec no,默認爲everysec  
appendfsync everysec  
##在aof-rewrite期間，appendfsync是否暫緩文件同步，"no"表示“不暫緩”，“yes”表示“暫緩”，默認爲“no”  
no-appendfsync-on-rewrite no  

##aof文件rewrite觸發的最小文件尺寸(mb,gb),只有大於此aof文件大於此尺寸是纔會觸發rewrite，默認“64mb”，建議“512mb”  
auto-aof-rewrite-min-size 64mb  

##相對於“上一次”rewrite，本次rewrite觸發時aof文件應該增長的百分比。  
##每一次rewrite之後，redis都會記錄下此時“新aof”文件的大小(例如A)，那麼當aof文件增長到A*(1 + p)之後  
##觸發下一次rewrite，每一次aof記錄的添加，都會檢測當前aof文件的尺寸。  
auto-aof-rewrite-percentage 100  

AOF和RDB是可以混合使用的。

Redis內存淘汰策略

Redis中的事務

傳統關係型數據庫中數據庫中通過ACID來確保事務的可靠和安全。在redis中事務總是具有原子性，隔離性和一致性。當redis運行在莫一種持久化模式下，也會具有持久性。
redis通過MULTI EXEC WATCH等命令實現事務的功能，提供了一種將多個命令打包然後一次性按照順序執行的機制。在事務執行期間，服務器不會中斷事務而去執行其他客戶端的命令請求。其他命令會在事務執行完畢之後執行。

Redis裏面的發佈訂閱

Redis 發佈訂閱(pub/sub)是一種消息通信模式：發送者(pub)發送消息，訂閱者(sub)接收消息。
Redis 客戶端可以訂閱任意數量的頻道。
下圖展示了頻道 channel1 ， 以及訂閱這個頻道的三個客戶端 —— client2 、 client5 和 client1 之間的關係：

當有新消息通過 PUBLISH 命令發送給頻道 channel1 時， 這個消息就會被髮送給訂閱它的三個客戶端：

以下實例演示了發佈訂閱是如何工作的。在我們實例中我們創建了訂閱頻道名爲 redisChat:

redis 127.0.0.1:6379> SUBSCRIBE redisChat

Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "redisChat"
3) (integer) 1

現在，我們先重新開啓個 redis 客戶端，然後在同一個頻道 redisChat 發佈兩次消息，訂閱者就能接收到消息。

redis 127.0.0.1:6379> PUBLISH redisChat "Redis is a great caching technique"

(integer) 1

redis 127.0.0.1:6379> PUBLISH redisChat "Learn redis by runoob.com"

(integer) 1

# 訂閱者的客戶端會顯示如下消息
1) "message"
2) "redisChat"
3) "Redis is a great caching technique"
1) "message"
2) "redisChat"
3) "Learn redis by runoob.com"