Redis高可用架構的應用及改進經驗談
前言
隨著很多公司使用Redis作為緩存和高性能存儲方案，Redis的可用性也變得越來越重要。目前 比較主流的HA方案是Sentinel+Redis主從復制。Sentinel是Redis官方自帶的高可用中間件，運維簡單、穩定，建議使用Redis 3.0及以上穩定版本。
本文重點介紹如何使用該架構，以及需要注意的問題和解決方案。
HA架構圖
首先部署Redis主從復制集群，比如1主3從；然后部署3個Sentinel節點。
為了安全起見，Sentinel節點分別部署在不同的服務器上，Redis主從節點分別部署在不同服務器上。 具體部署步驟，這里不再贅述。
最佳實踐
針對這個HA架構，應用程序該如何使用呢？這里介紹一個比較簡單可靠的使用方法。
在應用程序（APP）配置里設置如下信息：
-
3個Sentinel的連接方式（不是Redis主庫連接方式）
-
Redis密碼
-
masterName
說明： 如果Sentinel上層使用了LVS，那么配置里改為VIP。
應用程序通過和Sentinel交互，獲取到Redis主庫信息，然后再處理讀寫請求。 其中，由于Sentinel帶來的性能開銷很小，可以忽略。
需要注意的地方：
-
多個Sentinel連接方式，驅動如何選擇
推薦的處理方式：采用輪訓或者隨機選擇，支持負載均衡。
-
如果某個Sentinel宕機，驅動如何處理
推薦的處理方式：采用重試和黑名單機制，及時上線和下線故障節點，支持高可用。
-
驅動是否具有連接池功能
一般情況下，主流的語言，比如Java，PHP等等，驅動具有連接管理器的，支持連接復用。
可以從Redis的info信息里查看，如下：
10.11.11.13:6379> info clients
# Clients
connected_clients:150
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
如果連接無法復用，connected_clients會飆升到上千，甚至導致Redis服務異常，停止處理請求。 如果驅動不支持連接池，需要選擇新驅動，或者二次開發驅動。
問題分析
使用以上HA架構，細心的朋友會發現這樣一個問題。 如果Redis主庫宕機，Redis配置會發生改變，如下：
某些參數的值會自動被加上""，比如密碼參數。 一般禁止使用類似""作為密碼的一部分。Redis密碼 參數一旦被加上""，在運維和使用過程中，就會存在比較大的風險和麻煩。
分析Redis源碼，以下情況會觸發配置修改：
1）Master故障切換
2）新加入Sentinel
3）執行 config rewrite
4）執行 sentinel flushconfig
5）執行 sentinel remove
6）Sentinel新加入Redis master節點
解決方案
針對該問題，常用解決方法：
1 人工處理
為Redis密碼加上監控，一旦變更，報警后人工處理。 這是最簡單也是不可靠的方法。
2 腳本控制
開發一個腳本，周期性監控Redis密碼，一旦發現變更后，自動改回。 這種方法，增加了運維成本和風險，也無法100%保證解決問題。
3 修改源碼邏輯
修改源碼，從根本上解決這個問題，方法如下：
src/config.c
修改函數int rewriteConfig(char *path)
注釋如下兩行：
rewriteConfigStringOption(state,"masterauth",server.masterauth,NULL);
rewriteConfigStringOption(state,"requirepass",server.requirepass,NULL);
修改后重新編譯Redis源碼。 可以通過執行config rewrite命令驗證，Redis密碼參數不會備自動修改了。
由于代碼改動很小，沒有風險點，筆者在線上已經使用一年多時間，Redis服務很穩定，沒有問題。
來自：http://dbaplus.cn/news-21-1178-1.html