1. 背景
zhe800公司內(nèi)大量使用redis，且用途多樣：緩存、隊(duì)列碴萧、數(shù)據(jù)庫肝箱，都有功能。同時(shí)公司內(nèi)對(duì)redis的使用比較隨意扳剿，每個(gè)應(yīng)用按自己的需求要求運(yùn)維部署redis-server，導(dǎo)致對(duì)redis的使用很混亂，運(yùn)維部門都無法精確得知redis-server的部署情況踱蠢。經(jīng)過長(zhǎng)時(shí)間的調(diào)查、搜集資料才整理出公司內(nèi)redis的使用情況棋电，目前部署數(shù)百多個(gè)redis-server實(shí)例茎截、版本分為：2.8.9、2.8.11赶盔、2.8.17企锌、2.8.19、2.8.23 多種于未。
2. 需求的演變
鑒于公司redis使用撕攒、管理混亂的情況陡鹃，公司要求改善對(duì)redis的使用和管理，由成都“基礎(chǔ)架構(gòu)部”負(fù)責(zé)此項(xiàng)改進(jìn)抖坪。此時(shí)產(chǎn)生了第一階段需求：
1萍鲸、通過一個(gè)統(tǒng)一管理系統(tǒng)管理公司內(nèi)所有的redis進(jìn)程
2、可以通過這個(gè)管理系統(tǒng)監(jiān)控redis的運(yùn)行狀態(tài)
3擦俐、redis資源通過管理系統(tǒng)來分配
針對(duì)第一階段的需求脊阴，我們基礎(chǔ)架構(gòu)部和用戶、運(yùn)維部蚯瞧、技術(shù)委員會(huì)進(jìn)行了多次討論嘿期，認(rèn)為目前redis使用的問題：
沒有實(shí)現(xiàn)跨機(jī)房高可用，這點(diǎn)很重要状知，公司內(nèi)所有應(yīng)用要求必須跨機(jī)房高可用秽五。
沒有考慮橫向擴(kuò)展問題。
一部分隊(duì)列饥悴、持久化等功能不適合使用redis坦喘，應(yīng)該使用更“專業(yè)”的隊(duì)列系統(tǒng)和數(shù)據(jù)庫解決。
此時(shí)對(duì)第一階段需求進(jìn)行了修改西设，產(chǎn)生了第二階段需求：
1瓣铣、redis僅作為緩存使用。
2贷揽、實(shí)現(xiàn)橫向擴(kuò)展棠笑。
3、實(shí)現(xiàn)跨機(jī)房高可用禽绪，雙機(jī)房至少要實(shí)現(xiàn)“溫備”蓖救。
4、由一個(gè)后臺(tái)系統(tǒng)管理印屁、分配循捺、監(jiān)控redis資源。
其中第3個(gè)需求：實(shí)現(xiàn)跨機(jī)房高可用最為困難雄人，因?yàn)榫彺娴牡湫蛨?chǎng)景：緩沖數(shù)據(jù)庫查詢从橘，如果主機(jī)房失效后，切換到備機(jī)房的緩存服務(wù)础钠，此時(shí)備機(jī)房緩存沒有數(shù)據(jù)（是”冷“的）恰力，會(huì)導(dǎo)致對(duì)數(shù)據(jù)庫（MySQL）的查詢量爆增；因此要求備機(jī)房的緩存必須至少有主機(jī)房的部分?jǐn)?shù)據(jù)旗吁，在主機(jī)房失效的情況下才能防止數(shù)據(jù)庫查詢量爆增踩萎，而且在緩存的持續(xù)使用下，備機(jī)房緩存會(huì)很快達(dá)到主機(jī)房的狀態(tài)很钓。
因此跨機(jī)房數(shù)據(jù)同步是必須的香府。
3. 選型
在最終需求的指導(dǎo)下翻具，已經(jīng)明確我們基礎(chǔ)架構(gòu)部需要打造一套緩存服務(wù)系統(tǒng)，包含redis-server和管理回还、監(jiān)控系統(tǒng)。
此時(shí)我們有兩種方案可選擇：
1. 基于代理的橫向擴(kuò)展方案
以codis為代表的基于代理的集群方案叹洲，通過在redis-client和redis-server之間增加一個(gè)代理層柠硕，通過代理層sharding鏈接到正確的redis-server進(jìn)行操作。
2. 基于redis官方集群的方案
redis從3.0版開始提供了很受期待的集群功能运提，按照CAP理論蝗柔，redis cluster屬于保證AP，放棄C民泵，僅能提供最終一致性癣丧。按照redis cluster的協(xié)議，client需要在本地sharding栈妆，選擇正確的redis結(jié)點(diǎn)胁编，然后進(jìn)行操作，否則會(huì)返回MOVE錯(cuò)誤鳞尔。
調(diào)研結(jié)論是：采用redis官方集群方案
有以下原因促使我們選擇redis cluster方案：
1嬉橙、基于代理的方案會(huì)導(dǎo)致性能下降，對(duì)于一個(gè)緩存服務(wù)來說性能很重要寥假。
2市框、redis cluster方案較簡(jiǎn)單，不需要部署額外的進(jìn)程糕韧，其本身就能實(shí)現(xiàn)高可用了枫振，如果是基于代理的方案，代理本身也需要高可用萤彩，這增加了復(fù)雜度粪滤。
3、redis cluster是官方支持的自帶功能乒疏，比起第三方開發(fā)的代理進(jìn)程额衙，可能更穩(wěn)定可靠。
4怕吴、redis cluster能實(shí)現(xiàn)讀擴(kuò)展窍侧、讀寫分離功能；如果使用代理转绷，那么讀寫擴(kuò)展時(shí)必須同時(shí)考慮redis-server和代理程序伟件。
redis cluster仍然不能實(shí)現(xiàn)跨機(jī)房容災(zāi)，跨機(jī)房高可用的功能最后決定由基礎(chǔ)架構(gòu)部自行實(shí)現(xiàn)
4. redis cluster簡(jiǎn)介
其基本思想是將數(shù)據(jù)放置于槽（slots）中议经，slot有0x3fff（16384）個(gè)斧账。為了實(shí)現(xiàn)數(shù)據(jù)分片谴返，這些槽分布在多個(gè)redis master結(jié)點(diǎn)中，為了實(shí)現(xiàn)高可用咧织，每個(gè)master結(jié)點(diǎn)擁有零到多個(gè)slave結(jié)點(diǎn)嗓袱，這些slave同步保存master的數(shù)據(jù)，一旦master crash以后习绢，會(huì)選舉他的slave結(jié)點(diǎn)成為新的master渠抹。
僅master結(jié)點(diǎn)可寫入，然后數(shù)據(jù)會(huì)異步同步到slave闪萄，slave可讀不可寫梧却。
因此理想情況下：結(jié)點(diǎn)永不crash、只讀寫master結(jié)點(diǎn)败去，redis cluster可保證強(qiáng)一致放航。 但因?yàn)楝F(xiàn)實(shí)使用中，結(jié)點(diǎn)可能crash圆裕，且可讀slave結(jié)點(diǎn)广鳍，因此redis cluster僅能保證最終一致性。
redis cluster通過謠言傳播同步結(jié)點(diǎn)的狀態(tài)葫辐，每一個(gè)結(jié)點(diǎn)都保存了所有結(jié)點(diǎn)的狀態(tài)信息搜锰，其中最重要的是：結(jié)點(diǎn)的ip+端口、每個(gè)節(jié)點(diǎn)包含的slots耿战。
client 集群模式流程：
1蛋叼、從任意一個(gè)集群的結(jié)點(diǎn)獲取所有結(jié)點(diǎn)的狀態(tài)（使用CLUSTER NODES命令)，同時(shí)獲知了每一個(gè)slot所在的結(jié)點(diǎn)剂陡。結(jié)點(diǎn)有兩個(gè)角色：master/slave狈涮。
2、在get/set/hget/hset等命令時(shí)鸭栖，對(duì)key進(jìn)行計(jì)算：crc16(key) & 0x3fff歌馍，所得的結(jié)果就是slot編號(hào)。
3晕鹊、通過slot編號(hào)獲取結(jié)點(diǎn)的ip+port松却，然后發(fā)送此結(jié)點(diǎn)。
4溅话、此時(shí)如果返回-ASK ip:port錯(cuò)誤晓锻，表明slot臨時(shí)發(fā)生了變化，此時(shí)應(yīng)往ASK指定的結(jié)點(diǎn)先發(fā)送ASKING命令飞几，再發(fā)送實(shí)際的命令砚哆。
5、此時(shí)如果返回-MOVED slot-number ip:port錯(cuò)誤屑墨，表明集群發(fā)生了變化（擴(kuò)容躁锁、縮減纷铣、槽遷移過），則先將命令發(fā)送到MOVED錯(cuò)誤指明的結(jié)點(diǎn)后战转，重新獲取集群結(jié)點(diǎn)狀態(tài)搜立，以同步最新的結(jié)點(diǎn)狀態(tài)。
5. 管理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)
zhe800基于redis cluster的緩存服務(wù)被命令為z(he800-r)edis槐秧，包含一個(gè)管理系統(tǒng)對(duì)所有緩存集群進(jìn)行管理儒拂，以及雙機(jī)房數(shù)據(jù)同步機(jī)制，保證主備兩個(gè)機(jī)房之間部分?jǐn)?shù)據(jù)同步色鸳，實(shí)現(xiàn)雙機(jī)房容災(zāi)。
對(duì)于zedis见转，我們有幾個(gè)指導(dǎo)原則：
1命雀、簡(jiǎn)單：復(fù)雜的方案容易出錯(cuò)，且成本高斩箫，因此在簡(jiǎn)單和復(fù)雜之中選擇簡(jiǎn)單的方案吏砂。
2、用戶透明：不要要求用戶了解大量的細(xì)節(jié)才能使用乘客。
3狐血、可用：可正常使用，可從錯(cuò)誤中恢復(fù)易核。
5.1 管理系統(tǒng)的功能設(shè)計(jì)
緩存集群的操作：
容量擴(kuò)容/讀寫擴(kuò)容：增加1個(gè)到多個(gè)分片匈织，同時(shí)擴(kuò)展了讀寫能力。
高可用/讀擴(kuò)容：僅增加slave結(jié)點(diǎn)數(shù)牡直，增強(qiáng)高可用性缀匕，同時(shí)擴(kuò)展了讀能力。
1碰逸、分配：按應(yīng)用的需求分配一個(gè)全新的redis cluster乡小，如果配置了跨機(jī)房容災(zāi)選項(xiàng)，還會(huì)按需求在備機(jī)房啟動(dòng)一個(gè)災(zāi)備集群饵史。
2满钟、下線：將一個(gè)運(yùn)行中的redis cluster刪除，并進(jìn)行清理胳喷。
3湃番、擴(kuò)容：
4、縮減：擴(kuò)容的逆操作厌蔽，支持讀寫縮減和讀縮減牵辣。
監(jiān)控：
1、物理機(jī)資源監(jiān)控：監(jiān)控物理機(jī)當(dāng)前的資源奴饮，為緩存集群的操作提供依據(jù)纬向。
2择浊、集群監(jiān)控：對(duì)每個(gè)節(jié)點(diǎn)到集群本身進(jìn)行監(jiān)控，提供給運(yùn)維查看逾条。
3琢岩、報(bào)警：對(duì)接公司報(bào)警系統(tǒng)，遇到結(jié)點(diǎn)crash师脂、集群不可用等情況及時(shí)發(fā)出報(bào)警
緩存集群的操作需要以物理機(jī)資源數(shù)據(jù)為依據(jù)担孔，這部分?jǐn)?shù)據(jù)通過zabbix獲取。同時(shí)集群的每個(gè)節(jié)點(diǎn)需要使用cgroup進(jìn)行資源隔離吃警，這些操作都由管理后臺(tái)自動(dòng)進(jìn)行糕篇。
對(duì)物理機(jī)的操作：?jiǎn)?dòng)redis-server進(jìn)程、創(chuàng)建執(zhí)行文件夾酌心、生成redis.conf文件等操作通過salt進(jìn)行拌消，因?yàn)楣緝?nèi)每臺(tái)服務(wù)器都安裝了salt-minion，因此可直接利用安券。
5.2 事務(wù)支持
對(duì)redis cluster的各種操作都是通過redis client向redis-server發(fā)送命令實(shí)現(xiàn)墩崩，但是這些操作必須是原子操作，長(zhǎng)時(shí)間的操作必須可中途放棄并會(huì)滾到初始狀態(tài)侯勉，否則對(duì)redis cluster的操作風(fēng)險(xiǎn)會(huì)比較高鹦筹，運(yùn)維人員可能不敢使用管理系統(tǒng)。
事務(wù)系統(tǒng)采取模仿數(shù)據(jù)庫的一種實(shí)現(xiàn)方式：記錄日志址貌。數(shù)據(jù)庫日志分為：undo铐拐、redo、undo/redo三種形式练对。
我們采取undo日志的形式余舶，對(duì)于管理系統(tǒng)四大操作：
分配
下線
擴(kuò)容
縮減
都通過事務(wù)系統(tǒng)執(zhí)行。
模仿數(shù)據(jù)庫锹淌，事務(wù)管理器提供三個(gè)原語：
1匿值、begin: 開始一個(gè)事務(wù)，并返回一個(gè)事務(wù)id（tid）
2赂摆、abort-rollback: 中途放棄挟憔，會(huì)滾到begin時(shí)候的狀態(tài)
3、commit: 提交事務(wù)烟号，標(biāo)記事務(wù)已經(jīng)完成绊谭。
四大操作每一個(gè)步驟都會(huì)在操作成功后，記錄undo日志到文件系統(tǒng)中汪拥，因此還需要確保每個(gè)“步驟”是原子操作达传，如果遇到abort或者錯(cuò)誤時(shí)，逆向執(zhí)行undo日志中命令就能恢復(fù)到初始狀態(tài)了。如果rollback仍然失敗宪赶，則說明遇到了管理系統(tǒng)無法處理的故障（如機(jī)器斷電宗弯、網(wǎng)絡(luò)中斷等）此時(shí)需要暫停會(huì)滾，通知運(yùn)維人員恢復(fù)故障搂妻，再進(jìn)行回滾蒙保。
6. 高可用的實(shí)現(xiàn)
6.1 redis cluster的高可用
redis很早就可以通過master-slave機(jī)制實(shí)現(xiàn)雙機(jī)熱備，到了cluster時(shí)代欲主，仍然保留了master-slave機(jī)制邓厕。
在cluster模式中，每個(gè)master結(jié)點(diǎn)保存了一部分slots扁瓢，同時(shí)每個(gè)master結(jié)點(diǎn)可設(shè)置0～多個(gè)slave結(jié)點(diǎn)详恼，master的數(shù)據(jù)會(huì)異步同步到slave結(jié)點(diǎn)（redis的特點(diǎn)：所有IO操作皆異步），這樣一個(gè)master-slave的組合可稱之為一個(gè)partition引几；一個(gè)partition是高可用的：
slave結(jié)點(diǎn)crash单雾，對(duì)集群本身無影響，對(duì)partition無影響;slave結(jié)點(diǎn)重新連接上master后會(huì)檢查自己與master的數(shù)據(jù)差別她紫，如果差距太大，會(huì)先進(jìn)行一次全量同步屿储，然后開始增量同步贿讹。
master結(jié)點(diǎn)crash，對(duì)集群本身無影響够掠，對(duì)partition有影響民褂；集群會(huì)選舉一個(gè)slave作為新的master，因?yàn)閟lave結(jié)點(diǎn)幾乎有master結(jié)點(diǎn)的所有數(shù)據(jù)疯潭，因此數(shù)據(jù)僅有小概率丟失赊堪。
partition整體crash，集群會(huì)整體不可用竖哩，因?yàn)榧赫J(rèn)為slots不連續(xù)了哭廉，保存在這個(gè)partition中的slots無法訪問。如果沒開啟持久化相叁，會(huì)導(dǎo)致這部分?jǐn)?shù)據(jù)永久丟失遵绰。
可見，redis cluster做到了一定的高可用增淹，我們使用jedis測(cè)試結(jié)果來看椿访，在一個(gè)1主1備的redis cluster中，隨機(jī)kill一個(gè)結(jié)點(diǎn)不會(huì)導(dǎo)致任何錯(cuò)誤虑润，但kill一個(gè)master結(jié)點(diǎn)和它所有的slave結(jié)點(diǎn)就會(huì)導(dǎo)致集群不可用的錯(cuò)誤成玫，此時(shí)無法get/set數(shù)據(jù)。
6.2 對(duì)于高可用的思考
對(duì)于redis cluster高可用的研究和實(shí)驗(yàn)發(fā)現(xiàn)，其應(yīng)對(duì)單機(jī)房高可用是可以勝任的哭当，已有的客戶端：jedis新版本也能很好的處理高可用問題猪腕。
但對(duì)于跨機(jī)房高可用/容災(zāi)，仍然沒有發(fā)現(xiàn)現(xiàn)成的方案可供使用荣病，對(duì)此有以下方案被提出：
1码撰、客戶端雙寫：客戶端需要連接到主、備兩個(gè)集群个盆，同步寫主脖岛、異步寫備；平時(shí)讀主集群的數(shù)據(jù)颊亮，主集群不可用后馬上切換為同步寫備柴梆、讀備。
2终惑、集群間數(shù)據(jù)同步：開啟持久化绍在，然后同步redis的數(shù)據(jù)庫文件。
3雹有、服務(wù)端雙寫：redis-server將set/hset等寫命令再寫一份到備集群偿渡。
最終我們選擇了第三個(gè)方案：服務(wù)端雙寫。原因?yàn)椋?/p>
按照用戶透明原則霸奕，如果要求客戶端雙寫溜宽，客戶端需要做的事太多，而服務(wù)端雙寫方案客戶端僅需處理主備集群切換就可以了质帅。
集群間數(shù)據(jù)同步方案适揉，要求數(shù)據(jù)先寫到文件中，在同步到災(zāi)備集群煤惩，這其實(shí)是不必要的嫉嘀，因?yàn)槿绻龅诫p機(jī)房容災(zāi)，持久化都是可以關(guān)閉的魄揉，因?yàn)閜artition整體crash的集群大幅度下降了(按平方下降剪侮，如果單個(gè)partition crash的幾率為p，主備parttion同時(shí)crash的幾率僅有p^2洛退，且p隨著slave結(jié)點(diǎn)的數(shù)量指數(shù)級(jí)的變衅北搿），退一步說:因?yàn)楸旧頌榫彺娣?wù)不狮，可接受少量數(shù)據(jù)丟失降铸。
服務(wù)端雙寫足夠簡(jiǎn)單，僅需要將客戶單對(duì)redis-server的寫入命令復(fù)制一份發(fā)送到災(zāi)備集群即可摇零。
服務(wù)端雙寫并不需要完全雙寫推掸，僅保證災(zāi)備集群擁有主集群的部分?jǐn)?shù)據(jù)即可，因?yàn)閷?duì)于緩存服務(wù)來說，只要發(fā)生災(zāi)備時(shí)谅畅，災(zāi)備集群不“冷”就可以接受了登渣；同時(shí)這也節(jié)省了機(jī)房間光纖帶寬。
6.3 跨機(jī)房高可用
跨機(jī)房高可用的基本思想為：在主備兩個(gè)兩個(gè)機(jī)房各啟動(dòng)一個(gè)redis cluster毡泻，主機(jī)房集群在寫入數(shù)據(jù)的時(shí)候胜茧，同時(shí)寫入一分到備機(jī)房。
要達(dá)到以上設(shè)計(jì)目的仇味，必須對(duì)官方redis進(jìn)行修改呻顽，我們選擇了版本3.2.0為基礎(chǔ)進(jìn)行修改。 redis的一個(gè)重要設(shè)計(jì)思想是所有IO操作皆異步非阻塞進(jìn)行丹墨，為此redis封裝了ae一個(gè)事件處理庫封裝了各個(gè)操作系統(tǒng)提供的事件處理模型：
OS X/Darwin/BSD:kqueue
Linux:epoll
Sun OS:evport
Others:select
在3大操作系統(tǒng)中并不支持Windows的IO Complete Port廊遍，原因是IOCP是真異步模型，在收到事件通知時(shí)贩挣，數(shù)據(jù)已經(jīng)接收到/發(fā)送完畢喉前，而不像epoll,kqueue等模型，在收到事件通知時(shí)王财，還需要再調(diào)用read/write卵迂，通知僅僅是告訴用戶態(tài)可讀/可寫了，而遠(yuǎn)不同于IOCP绒净，通知是通知用戶態(tài)讀/寫已經(jīng)完成了见咒。由此可見IOCP現(xiàn)在比較難融入redis現(xiàn)有的IO層中。
我們先開始研究redis的代碼疯溺，可得知它的IO層設(shè)計(jì)：
redis執(zhí)行一個(gè)命令的時(shí)序:
最終我們決定在processInputBuffer中，解析redis協(xié)議時(shí)哎垦，將寫操作按配置的百分比過濾后囱嫩，復(fù)制一份發(fā)送到備機(jī)房；此時(shí)有新的考慮：
備機(jī)房的接收者也是集群漏设，如果需要發(fā)送給集群墨闲，那么勢(shì)必會(huì)增加對(duì)redis-server代碼的修改程度，因?yàn)檫€必須處理目標(biāo)集群的高可用郑口、sharding問題鸳碧，風(fēng)險(xiǎn)增加。我們希望對(duì)redis-server的修改盡可能的小犬性。
如果機(jī)房間光纖中斷瞻离，會(huì)丟失一部分?jǐn)?shù)據(jù)；雖然作為緩存集群乒裆，數(shù)據(jù)可以丟失一小部分套利，但能保證數(shù)據(jù)不丟失盡量不丟。
只能寫入另一個(gè)redis cluster中，不靈活肉迫。
因此我們?cè)黾恿艘粋€(gè)名為zedis-gateway的代理程序验辞，redis-server中復(fù)制出來的寫操作先發(fā)送到zedis-gateway，zedis-gateway負(fù)責(zé)對(duì)這些寫操作進(jìn)行處理喊衫，發(fā)送到備份集群跌造。增加zedis-gateway的好處：
zedis-gateway可靈活處理接收到的寫操作，比如：寫入備份集群族购、寫入MySQL數(shù)據(jù)庫中壳贪、等等。
zedis-gateway負(fù)責(zé)處理較復(fù)雜的联四，寫入備份集群的failover撑碴、sharding問題，簡(jiǎn)化了對(duì)redis-server的修改朝墩。
如果機(jī)房間光纖中斷醉拓，zedis-gateway可將寫操作暫時(shí)寫入文件；等待通信恢復(fù)后在從文件中發(fā)送暫時(shí)保存的寫操作收苏；數(shù)據(jù)可以不丟失亿卤。
首先，我們?yōu)閞edis增加了兩個(gè)配置項(xiàng)：
同時(shí)zedis-gateway也需要高可用鹿霸，我們簡(jiǎn)單實(shí)現(xiàn)：
每個(gè)redis-server可配置多個(gè)zedis-gateway地址排吴，從中隨機(jī)選擇一個(gè)連接發(fā)送寫命令。
如果某個(gè)zedis-gateway地址連接不上懦鼠，或連接錯(cuò)誤钻哩，則再隨機(jī)選一個(gè)，直到能連上一個(gè)正確的或者一個(gè)也不能連上肛冶。
如果沒有一個(gè)zedis-gateway地址連接成功街氢，則寫入錯(cuò)誤日志；但不影響其他操作睦袖。
最后將官方版redis-server修改為：
雙機(jī)房容災(zāi)zedis集群結(jié)構(gòu)為：
實(shí)現(xiàn)結(jié)果：
我們實(shí)現(xiàn)了主備機(jī)房間集群數(shù)據(jù)0～100%同步珊肃，但為了節(jié)省機(jī)房間光纖帶寬，一般不允許開啟100％同步馅笙。
性能損失：在100%雙寫的配置下伦乔，性能損失<10%。
動(dòng)態(tài)調(diào)整：所有關(guān)于雙寫的配置都可以在運(yùn)行中隨時(shí)調(diào)整董习。
可維護(hù)：zedis-gateway可以隨時(shí)更新版本烈和，而不會(huì)影響雙寫。
7. 問題與展望
目前的zedis還存在一些問題皿淋，需要我們持續(xù)已經(jīng)斥杜，以達(dá)到完善虱颗。
1、redis client中蔗喂，只有jedis對(duì)集群支持最好忘渔，其他語言版本，如ruby缰儿、node.js畦粮、golang版本的客戶端還需要進(jìn)行一定改造才能支持redis cluster。
2乖阵、zedis-gateway目前還是單進(jìn)程宣赔、單線程模型，如果未來它成為瓶頸瞪浸，我們還需要增加進(jìn)程數(shù)儒将；后續(xù)根據(jù)需求也許需要將它改造為類似nginx的多進(jìn)程模型。
3对蒲、修改版的redis還需要優(yōu)化钩蚊。
4、目前只能從主到備雙寫數(shù)據(jù)蹈矮，如果從主切換到備砰逻，再從備切換到主，會(huì)丟失一部分?jǐn)?shù)據(jù)泛鸟；因?yàn)槟壳岸ㄎ粸榫彺婕候鹋兀虼丝山邮苓@個(gè)損失，如果今后需要升級(jí)作為內(nèi)存數(shù)據(jù)庫使用北滥，我們就還需要處理這個(gè)問題刚操。
5、只有部分命令支持雙寫再芋，剩余的還在添加中菊霜。
