redis集群（主从配置）
市面上太多kv的緩存，最常用的就屬memcache了，但是memcache存在單點問題，不過小日本有復制版本，但是使用的人比較少，redis的出現讓kv內存存儲的想法成為現實。今天主要內容便是redis主從實現簡單的集群，實際上redis的安裝配置砸門ttlsa之前就有個文章，廢話少說，進入正題吧
Redis簡介
redis是一個key-value存儲系統。和Memcached類似，它支持存儲的value類型相對更多，包括string(字符串)、 list(鏈表)、set(集合)和zset(有序集合)。這些數據類型都支持push/pop、add/remove及取交集并集和差集及更豐富的操 作，而且這些操作都是原子性的。在此基礎上，redis支持各種不同方式的排序。與memcached一樣，為了保證效率，數據都是緩存在內存中。區別的 是redis會周期性的把更新的數據寫入磁盤或者把修改操作寫入追加的記錄文件，并且在此基礎上實現了master-slave(主從)同步。
Redis 是一個高性能的key-value數據庫。 redis的出現，很大程度補償了memcached這類key/value存儲的不足，在部 分場合可以對關系數據庫起到很好的補充作用。它提供了Python，Ruby，Erlang，PHP客戶端，使用很方便。
?
1. 下載軟件包
# cd /usr/local/src/
# wget http://redis.googlecode.com/files/redis-2.6.11.tar.gz
2. Redis安裝
主從都需要安裝
# tar -xzvf redis-2.6.11.tar.gz
# mv redis-2.6.11 /usr/local/
# cd /usr/local/redis-2.6.11/
# make
備注：這邊就不make install 了，直接使用make好的文件
3. redis配置
找到配置文件/usr/local/redis-2.6.11/redis.conf
修改如下內容：
daemonize no 改為 yes # 是否后臺運行
port 6379 改為 12002 ?# 端口
dir ./ 改為 /data/redis_12002/ 或者/www/redis_12002/ ?# 數據目錄
其他配置請查看相應文檔，文章結尾將會附上所有配置參數
4. redis啟動與關閉
啟動
/usr/local/redis-2.6.11/src/redis-server /usr/local/redis-2.6.11/redis.conf
停止
/usr/local/redis-2.6.11/src/redis-cli -n 12002 shutdown
?
5. redis命令測試
先登錄shell客戶端
/usr/local/redis-2.6.11/src/redis-cli -p 12002
?
set 測試
redis 127.0.0.1:12002> set name abc
OK <---成功
?
get 測試
redis 127.0.0.1:12002> get name
"abc"
關于list，hash等等就不在演示了，具體查看相關文檔
6. Redis主從配置
6.1 只需要修改slave的配置
找到配置文件/usr/local/redis-2.6.11/redis.conf
修改如下內容：
slaveof 192.168.77.211 12002 # slaveof master的ip master的端口
6.2 主從測試
在master set
redis 192.168.77.211:12002> set testms gogogo
OK
?
在slave get
redis 192.168.77.197:12002> get testms
"gogogo" <---- 獲取到的value
7. 附加：redis配置文件
daemonize yes
pidfile /var/run/redis.pid
port 12002
timeout 0
tcp-keepalive 0
loglevel notice
logfile stdout
databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir /www/redis_12002/
slave-serve-stale-data yes
slave-read-only yes
repl-disable-tcp-nodelay no
slave-priority 100
appendonly no
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
如上為單機版本redis的配置文件，如果需要改為主從，只需要增加
slaveof 192.168.77.211(redis master IP) 12002（redis master 端口）
7. 結束語
當然，這還只是集群的第一步，大家可以使用keepalive來實現主的故障轉移功能。工作中我們最常用的要數redis主從，所以keepalive + redis實現高可用性集群這邊不在講述。
根據一些測試整理出來的一份方案：
1. Redis 性能
對于redis 的一些簡單測試，僅供參考：
測試環境：Redhat6.2 , Xeon E5520(4核)*2/8G，1000M網卡
Redis 版本：2.6.9
?
客戶端機器使用redis-benchmark 簡單GET、SET操作：
1. 1單實例測試
1. Value大小：10Byte~1390Byte
處理速度： 7.5 w/s，速度受單線程處理能力限制
2. Value 大小：1400 左右
處理速度突降到5w/s 樣子，網卡未能跑滿；由于請求包大于MTU造成TCP分包，服務端中斷處理請求加倍，造成業務急劇下降。
3. Value大小：>1.5 k
1000M網卡跑滿，速度受網卡速度限制
處理速度與包大小大概關系如下：
1.2 多實例測試
前提是系統網卡軟中斷均衡到多CPU核心處理，測試機器網卡開啟RSS，有16個隊列：
操作：10字節Value SET，服務端開啟8個實例，四臺客戶端服務器每臺開啟兩個redis-benchmark，每個client 速度近4W/s，服務端總處理30w/s左右。
網卡流量：
其中8個單數核心CPU全部耗盡，像是超線程沒有利用上，測試已經達到很好效果，就沒有繼續測試下去了。從單實例跑滿一個核心7.5w/s，8個實 例跑滿8個核心，30W/s來看，CPU使用和性能提升不成正比， RSS會造成redis-server線程基本每收到一個請求都切換一次CPU核心，軟中斷CPU占用太高。這種情況RPS/RFS功能也許就很合適 了，RSS只需要映射1~2個核心，然后再講軟中斷根據redis-server端口動態轉發，保證redis進程都在一個核心上執行，減少進程不必要的 切換。
?
開多實例可以充分利用系統CPU、網卡處理小包能力。具體看業務場景，考慮包平均大小、處理CPU消耗、業務量。如果多實例是為了提高處理能力，需要注意配置網卡軟中斷均衡，否則處理能力也無法提升。
?
2. Redis 持久化
測試策略：AOF + 定時rewriteaof
1. 準備數據量：
1億，Key：12 字節 Value：15字節，存儲為string，進程占用內存12G
2. Dump
文件大小2.8G，執行時間：95s，重啟加載時間：112s
2. Bgrewriteaof
文件大小5.1G，執行時間：95s，重啟加載時間：165s
3.開啟AOF后性能影響（每秒fsync一次）：
8K/s SET 操作時：cup 從20% 增加到40%
4.修改1Kw數據：
文件大小：5.6G，重啟加載時間：194s
5.修改2K數據
文件大小：6.1G，重啟加載時間：200s
另：Redis2.4 版本以后對fsync做了不少優化， bgrewriteaof，bgsave 期間對redis對外提供服務完全無任何影響。
?
3. Redis 主從復制
因為目前版本沒有mysql 主從那樣的增量備份，對網路穩定性要求很高，如果頻繁TCP連接斷開會對服務器和網絡帶來很大負擔。
就目前生產環境主從機器部署同一個機架下，幾個月都不會又一次連接斷開重連的情況的。
?
4. keepalived 簡介
參考官方文檔：http://keepalived.org/pdf/sery-lvs-cluster.pdf
Keepalived 是一個用c寫的路由選擇軟件，配合IPVS 負載均衡實用，通過VRRP 協議提供高可用。目前最新版本1.2.7.Keepalived 機器之間實用VRRP路由協議切換VIP，切換速度秒級，且不存在腦裂問題。可以實現
可以實現一主多備，主掛后備自動選舉，漂移VIP，切換速度秒級；切換時可通過運行指定腳本更改業務服務狀態。
如兩臺主機A、B，可以實現如下切換：
1．A 、B 依次啟動，A作為主、B為從
2 .主A 掛掉，B接管業務，作為主
3.A 起來，作為從SLAVEOF B
4.B 掛掉，A 切回主
將一臺全部作為主，即可實現主從，可做讀寫分離；也可以通過多個VIP，在一臺機器上多個實例中一半主、一半從，實現互備份，兩機同時負責部分業務，一臺宕機后業務都集中在一臺上
安裝配置都比較簡單：
需要依賴包：openssl-devel（ubuntu 中為 libssl-dev),popt-devel （ubuntu中為libpopt-dev）。
配置文件默認路徑：/etc/keepalived/keepalived.conf 也可以手動指定路徑，不過要注意的是手動指定需要使用絕對路徑。主要要確保配置文件的正確性，keepalived 不會檢查配置是否符合規則。
使用keepalived -D 運行，即可啟動3個守護進程：一個父進程，一個check健康檢查，一個Vrrp，-D將日志寫入/var/log/message，可以通過日志查看切換狀況。
注意問題：
1. VRRP 協議是組播協議，需要保證主、備、VIP 都在同一個VLAN下
2. 不同的VIP 需要與不同的VRID 對應，一個VLAN 中VRID 不能和其他組沖突
3. 在keepalived 有兩個角色：Master(一個)、Backup（多個），如果設置一個為Master，但Master掛了后再起來，必然再次業務又一次切換，這對于有 狀態服務是不可接受的。解決方案就是兩臺機器都設置為Backup，而且優先級高的Backup設置為nopreemt 不搶占。
?
5. 通過keepalived實現的高可用方案
?
切換流程：
1. 當Master掛了后，VIP漂移到Slave；Slave 上keepalived 通知redis 執行：slaveof no one ,開始提供業務
2. 當Master起來后，VIP 地址不變，Master的keepalived 通知redis 執行slaveof slave IP host ，開始作為從同步數據
3. 依次類推
主從同時Down機情況：
1. 非計劃性，不做考慮，一般也不會存在這種問題
2. 、計劃性重啟，重啟之前通過運維手段SAVE DUMP 主庫數據；需要注意順序：
1. 關閉其中一臺機器上所有redis，是得master全部切到另外一臺機器（多實例部署，單機上既有主又有從的情況）；并關閉機器
2. 依次dump主上redis服務
3. 關閉主
4. 啟動主，并等待數據load完畢
5. 啟動從
刪除DUMP 文件（避免重啟加載慢）
?
6. 使用Twemproxy 實現集群方案
一個由twitter開源的c版本proxy，同時支持memcached和redis，目前最新版本為：0.2.4，持續開發中;https://github.com/twitter/twemproxy .twitter用它主要減少前端與緩存服務間網絡連接數。
特點：快、輕量級、減少后端Cache Server連接數、易配置、支持ketama、modula、random、常用hash 分片算法。
這里使用keepalived實現高可用主備方案，解決proxy單點問題；
優點：
1. 對于客戶端而言，redis集群是透明的，客戶端簡單，遍于動態擴容
2. Proxy為單點、處理一致性hash時，集群節點可用性檢測不存在腦裂問題
3. 高性能，CPU密集型，而redis節點集群多CPU資源冗余，可部署在redis節點集群上，不需要額外設備
?
7 . 一致性hash
使用zookeeper 實現一致性hash。
redis服務啟動時，將自己的路由信息通過臨時節點方式寫入zk，客戶端通過zk client讀取可用的路由信息。
?
具體實現見我另外一篇：redis 一致性hash
?
8 . 監控工具
歷史redis運行查詢：CPU、內存、命中率、請求量、主從切換等
實時監控曲線
短信報警
使用基于開源Redis Live 修改工具，便于批量實例監控，基礎功能都已實現，細節也將逐步完善。
源碼地址如下：
https://github.com/LittlePeng/redis-monitor
總結
以上是生活随笔為你收集整理的redis集群（主从配置）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 基于OpenCL的深度学习工具：AMD
- 下一篇： TS流解析之PAT表格解析