介紹
上個禮拜，我搭建了一個mongo分片集羣，發現分佈式系統保證高可用和高性能的套路都差很少。高性能就是作分片（能夠類比爲分庫分表，將數據分到不一樣服務器上），在Kafka中叫分區，在mongodb中叫shard，在HDFS上叫DataNode。而保證高可用的方式就是作交叉備份。而後我很好奇Redis是怎麼部署的。node
上測試環境查看集羣的狀態web
info replication
輸出以下，好吧，沒有作高可用，一個master節點開跑。面試
# Replication
role:master
connected_slaves:0
一個Redis實例其實有不少問題，最起碼Redis崩了就無法提供服務了，並且單機可以承載的QPS在上萬到幾萬不等redis
replication（複製）
若是業務要承載的QPS在幾十萬，單機是不可能作到的，此時就能夠用到複製。作一個主從架構，一主多從，master節點負責寫，slave節點負責讀，假如說一個節點能夠承載的5w讀QPS，那麼兩個節點就能夠承載10w的讀QPS，水平擴容很是方便。mongodb
master節點掛太多slave節點會有性能問題，此時就能夠在slave節點上掛slave節點
redis replication的核心機制有以下幾點
1.redis採用異步方式複製數據到slave node，不會block master node的正常工做
2.一個master node能夠配置多個slave node，slave node也能夠鏈接其餘的slave node
3.slave node主要用來進行橫向擴容，作讀寫分離，擴容的slave node能夠提升讀的吞吐量shell
主從複製的實現原理服務器
1.slave鏈接master，發送SYNC命令；
2.master接收到SYNC命名後，開始執行BGSAVE命令生成RDB文件並使用緩衝區記錄此後執行的全部寫命令；
3.master BGSAVE執行完後，向slave發送快照文件，並在發送期間繼續記錄被執行的寫命令；
4.slave收到快照文件後丟棄全部舊數據，載入收到的快照；
5.master快照發送完畢後開始向salve發送緩衝區中的寫命令；
6.slave完成對快照的載入，開始接收命令請求，並執行來自主服務器緩衝區的寫命令；微信
sentinel（哨兵）
主從架構有一個缺點就是若是master節點掛了，那麼寫服務是不可用的，由於slave節點默認是隻讀的，這時就重啓master節點或者從新配置主從，有沒有更好的方案呢？相似zookeeper的組件，能自動完成主從切換。在Redis中還真有，就是sentinel節點，當master節點發生故障能自動完成主從切換。
架構
當master節點掛掉時，sentinel將一個slave節點變成maste節點，當原先的master節點可用時，以slave的角色加入集羣。
一個高可用的系統是很忌諱有單點問題的。看到沒，sentinel就是一個單點，若是sentinel掛了，主從切換也就沒人作了。因此應該將sentinel也作成一個集羣
哨兵的做用有以下幾點
1.集羣監控，負責監控redis master和slave進程是否正常工做
2.消息通知，若是某個redis實例有故障，那麼哨兵負責發送消息做爲報警通知給管理員
3.故障轉移，若是master node掛掉了，會自動轉移到slave node上
4.配置中心，客戶端初始化時，經過哨兵得到master地址，若是故障轉移發生了，通知客戶端新的master地址app
redis cluster（集羣）
主從+哨兵，只能保證Redis的高可用，並不能保證Redis的高性能，由於一個master節點並不能放海量數據，並且單個Redis的實例過大時，會致使rdb文件過大，當執行主從同步時時間過長。
若是想作到高性能該怎麼辦？分片啊，我一開始就提到了，都是一個套路。redis搞幾個節點，每一個節點存儲一部分數據。可想而之，此時查詢和插入都得按照必定的分片策略，總不能查詢一個數據把全部的redis節點遍歷一遍吧。而這種操做不該該放在客戶端，中間件興起了，常見的有codis，twemproxy
圖片來自《Redis 深度歷險：核心原理與應用實踐》
客戶端不鏈接具體的Redis，而是鏈接Codis，2個Codis節點保證高可用，和Mycat一個套路。
固然Redis做者也意識到這個問題了，redis cluster應用而生。
沒時間寫了，下一篇再補充sentinel 和 redis cluster的其餘知識吧
參考博客
老錢《Redis 深度歷險：核心原理與應用實踐》
中華石杉《Java工程師面試突擊》
推薦閱讀
本文分享自微信公衆號 - Java識堂（erlieStar）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。