1.參考文檔與參考資料問題
安裝codis集群之前，我先在網上找資料，然后又到github的項目官方地址找，不得不說，相關的資料不好找，而且找到之后有些東西說的也不是很清楚。由於codis版本迭代的問題，基本上codis2和codis3的安裝配置還是有一些區別的，所以造成了安裝配置相關的資料更是讓人不知所雲。由於之前沒有接觸過zookeeper，官方github地址上的安裝配置資料只有一頁（只有一頁！！！崩潰），所以前兩天安裝配置一直在踩坑，后來看到這一篇文檔：
http://blog.csdn.net/zengxuewen2045/article/details/51559880才算是基本通過。安裝配置的問題解決了，下面的使用配置又開始大坑小坑不斷了。。。哎！還是相關的資料太少了，成熟的方案也比較少（或者是沒有公開）。
2.zookeeper在集群中的作用？
由於本人是運維，沒有搞過開發，也沒有搞過zookeeper，只知道zookeeper是一個集群管理工具，但是具體怎么使用，如何生效和調用確實一無所知，所以這個問題從我安裝開始到安裝完一直存在。現在也是大概清楚，可以看一下下面的截圖：
首先我們使用zkCli.sh登錄zookeeper查看受管理集群情況：
#使用如下命令登錄cd /usr/local/zookeeper/bin./zkCli.sh -server 127.0.0.1:2181
進入之后：
[zk: 127.0.0.1:2181(CONNECTED) 0] ls /[jodis, codis3, zookeeper][zk: 127.0.0.1:2181(CONNECTED) 1] ls /jodis [codis-test][zk: 127.0.0.1:2181(CONNECTED) 2] ls /codis3[codis-test][zk: 127.0.0.1:2181(CONNECTED) 3] ls /zookeeper[quota][zk: 127.0.0.1:2181(CONNECTED) 4] ls /jodis/codis-test[proxy-8ffc27d44a1deeaea72074a02c5a6de8, proxy-bb04876c8293332d5d08fa4a88400c22][zk: 127.0.0.1:2181(CONNECTED) 5] ls /codis3/codis-test[proxy, sentinel, slots, topom, group][zk: 127.0.0.1:2181(CONNECTED) 6] ls /codis3/codis-test/proxy[proxy-8ffc27d44a1deeaea72074a02c5a6de8, proxy-bb04876c8293332d5d08fa4a88400c22][zk: 127.0.0.1:2181(CONNECTED) 7] ls /codis3/codis-test/group[group-0002, group-0003, group-0001][zk: 127.0.0.1:2181(CONNECTED) 8] ls /zookeeper/quota []
我在codis-test下面配置了兩個proxy，所以通過zookeeper可以查看到這些狀態信息。我們就可以通過jodis或者codis3訪問proxy了。
當然，我的解釋可能是錯的，但是大致意思就是這樣了。
3.codis3.2使用主從以及高可用
codis3.2官方文檔中介紹是基於 redis-sentinel 實現主備自動切換
，而且codis-fe界面也可以配置sentinel，但是實際使用中真的是問題多多。尤其是主從切換和數據一致性問題。
3.1 使用sentinel做主備切換
在之前的配置文檔里面，3台主機上的分別配置了3個sentinel，共計9個，每台主機上的sentinel分別監控各自主機的codsi-server（當然，在實際環境中配置sentinel，肯定要配置在不同的主機上，以實現高可用災備）。當我把sentinel在fe界面配置到codis集群之后，問題就出現了。
首先介紹一下codis集群對於sentinel的使用。codis集群使用sentinel，是把每個主機組當做一個監控的組，你原來配置的組基本上是不起作用的，而且如果你原來配置了組，還有可能會造成混亂。
說明一下情況，在fe界面配置sentinel之前，我在3個主機上分別配置了1主1從，兩個codis-server組成一個主機組，使用3個sentinel監控。而配置完成之后在每個sentinel上原有sentinel監控的組還存在，codis集群又加了3個監控組，如下：
sentinel known-sentinel codis-test-3 192.168.0.178 46380 0d4c91b43b21e7c8c4422fee51bba5b7056c4532sentinel known-sentinel codis-test-3 192.168.0.102 36380 9d04f72b7ad031c46fb5a4168d0963c3db439ceasentinel known-sentinel codis-test-2 192.168.0.102 46380 4bee7292b2ea6192145713542cb56f1e72fbb459sentinel known-sentinel codis-test-2 192.168.0.146 36380 be3d3d816dc0da4a331367fc3b5bbe6e7cb97f3csentinel known-sentinel codis-test-1 192.168.0.146 46380 8ddb852b6abc8741ae0d1002a0554d9fb189302asentinel known-sentinel codis-test-1 192.168.0.178 46380 0d4c91b43b21e7c8c4422fee51bba5b7056c4532sentinel known-sentinel codis002 192.168.0.178 36380 9ffb90c46b3d04bb366293a387772724022be2f5sentinel known-sentinel codis002 192.168.0.178 46380 0d4c91b43b21e7c8c4422fee51bba5b7056c4532sentinel known-slave codis002 192.168.0.102 6380sentinel monitor codis-test-1 192.168.0.146 6379 2
也即是說，當你把sentinel加到codis集群中，這個sentinel就會監控所有主機了，而不是監控它所在主機的一主一從。所以建議要使用sentinel的時候，就不要預先配置監控組了。當你加到codis集群之后，codis會自動添加的。
但是又有一個問題，還是數據一致性這種大問題，當我配置好主機組和sentinel之后，將各個sentinel進行“sync”操作，突然發現
因為在數據分片的時候，不同的主機組有不同的分片，同一主機組的內容肯定是要同步的，但是看一下截圖，里面的從主機竟然不跟當前組的主進行同步，而是跟其他組的主機進行同步，這個時候就會產生同一組內主從codis-server數據不一致的問題。看日志：
里面的主從切換主要還是sentinel在起作用，每次的主從切換主要是sentinel的投票選擇的結果。雖然最后恢復了，但是這種隱患在生產環境中出現就是事故了。（實際上，在測試中，曾有過，3個主機組其中5的codis-server向剩下的一個同步的情況，這就造成了，雖然是不同的片區，但是數據都是一樣的，而且這個時候使用redis-cli進行set操作的時候經常報錯，很少有操作成功的）。
那么如果不把sentinel加到codis集群中，只用sentinel監控自己的集群，結果怎么樣？
這個也測試了，如果主節點6380掛掉，fe界面會顯示節點狀態
此時原來的從節點6379會不斷請求數據同步，這個時候sentinel會進行投票，然后把6379提升為主節點可讀可寫，但是在fe界面並不會發生改變，也就是雖然實際上節點狀態變化了，但是並不會在codis集群中體現出來，還需要我們在和界面先“PROMOTE”，然后點擊
才可以，如下：
才可以，如下：
所以，還是脫離不了手動操作的情況。
3.2 使用codis-ha的情況
在集群組的主從狀態正常的情況下，我們把所有的sentinel停掉，然后把fe界面上配置的sentinel也全部remove掉，然后把codis-ha啟動起來（3個主機上都啟動）。
nohup /home/codis/bin/codis-ha --log=/home/codis/logs/codis/ha.log --log-level=WARN --dashboard=192.168.0.146:18080 &
注意：此時我們已經預先配置了codis-server的主從狀態在redis.conf配置文件中。
看一下現在的狀態：
現在我們停掉192.168.0.146:6379的codis-server
看一下此時ha的日志：
現在我們遠程訪問一下：
此時的146的6380端口，set/get都沒有問題，可讀可寫。
然后再次啟動6379，看一下日志：
然后看了一下6380和ha的日志，很尷尬，一直沒有變化，fe界面也沒有變化，這是要讓手動加啊。。。
看一下，現在連接6379也是可讀可寫的，已經有數據不一致了。
這個時候我想把6379再次加到組中，突然報錯了，
開始加進去就是這種狀態，但是突然就沒有了。
看一下ha日志：
是原來的6379從組1刪除之后，就不能再次添加了嗎？
3.3 不使用codis-ha也不用sentinel的情況
把原來的6379停掉之后，由於之前配置了主從，現在沒有sentinel，所以6380一直在請求6379，狀態一直沒變，codis也沒有改變。
當我手動“PROMOTE”之后，查看6380日志：
遠程連接6380：
可讀可寫了。
啟動6379：
狀態一直沒有改變，但是當我點擊“sync”之后，日志就變化了，如下：
可以看到，6379成了6380的從，並且開始進行數據同步了。這種情況感覺和不把sentinel加入集群中差不多。
3.4 都有問題，我該怎么搞？
可以看出，上面的幾個方案都有一些問題，codis的異常恢復方案做的還是不太完善，這種情況下在線上使用的話肯定是問題多多的。那么該怎么搞呢？可能各個公司都有自己的方案。這里說一下我個人的思考：
1.使用sentinel
使用sentinel的話，建議可以不配置到codis集群中，然后可以在sentinel.conf中設置notify.sh腳本中監測codis-server的狀態，如果掛了就重啟，這樣速度更快。
2.使用ha
不建議，因為會把原有的刪除，刪除之后再加上好像還有問題。
3.都不使用
那就要手動了，當然可以用腳本輔助。
咱們看一下官方文檔：
codis官方也沒有提供可用的高可用方案。這樣的話只能根據使用場景使用腳本或者監控工具輔助了。
4.dashboard掛掉之后，原有的proxy組是否受影響？
如果dashboard掛掉之后，不會影響proxy的訪問，而且我們可以設置多個proxy，然后通過zookeeper來管理，這些proxy由於后端的主機集群是一樣的，所以讀寫操作的結果也是相同的，這樣就做到呢高可用。
5.使用反代之后的性能損失
使用反代之后肯定是有性能損失的，但是現在有了zookeeper，我們可以不用
haproxy，lvs，nginx這些反代工具了。