codis3.2安装配置中的一些问题

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:

进入之后：

[zk: 127.0.0.1:(CONNECTED) ] ls /
[jodis, codis3, zookeeper]
[zk: 127.0.0.1:(CONNECTED) ] ls /jodis 
[codis-test]
[zk: 127.0.0.1:(CONNECTED) ] ls /codis3
[codis-test]
[zk: 127.0.0.1:(CONNECTED) ] ls /zookeeper
[quota]
[zk: 127.0.0.1:(CONNECTED) ] ls /jodis/codis-test
[proxy-8ffc27d44a1deeaea72074a02c5a6de8, proxy-bb04876c8293332d5d08fa4a88400c22]
[zk: 127.0.0.1:(CONNECTED) ] ls /codis3/codis-test
[proxy, sentinel, slots, topom, group]
[zk: 127.0.0.1:(CONNECTED) ] ls /codis3/codis-test/proxy
[proxy-8ffc27d44a1deeaea72074a02c5a6de8, proxy-bb04876c8293332d5d08fa4a88400c22]
[zk: 127.0.0.1:(CONNECTED) ] ls /codis3/codis-test/group
[group-, group-, group-]
[zk: 127.0.0.1:(CONNECTED) ] 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- 192.168.0.178  0d4c91b43b21e7c8c4422fee51bba5b7056c4532
sentinel known-sentinel codis-test- 192.168.0.102  9d04f72b7ad031c46fb5a4168d0963c3db439cea
sentinel known-sentinel codis-test- 192.168.0.102  4bee7292b2ea6192145713542cb56f1e72fbb459
sentinel known-sentinel codis-test- 192.168.0.146  be3d3d816dc0da4a331367fc3b5bbe6e7cb97f3c
sentinel known-sentinel codis-test- 192.168.0.146  8ddb852b6abc8741ae0d1002a0554d9fb189302a
sentinel known-sentinel codis-test- 192.168.0.178  0d4c91b43b21e7c8c4422fee51bba5b7056c4532
sentinel known-sentinel codis002 192.168.0.178  9ffb90c46b3d04bb366293a387772724022be2f5
sentinel known-sentinel codis002 192.168.0.178  0d4c91b43b21e7c8c4422fee51bba5b7056c4532
sentinel known-slave codis002 192.168.0.102 
sentinel monitor codis-test- 192.168.0.146  

也即是说，当你把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这些反代工具了。