最近项目接触到了redis cluster，现在趁着使用做一下总结，记录一下遇到过的问题，简单的概述一下常用到的命令和功能。
本篇文章主要是以运维的角度去讲述如何去更好的规划redis cluster和跳坑。
redis cluster 官方文档： https://redis.io/topics/cluster-tutorial
一、redis cluster 是什么
redis cluster是官方redis 3.0版本之后推出的集群方案，之前类似的方案还有豌豆荚的codis集群方案、twemproxy方案，
不过twemproxy有个非常大的弊端就是不能在线扩容节点，这就比较尴尬了。redis cluster发布之后，截至目前为止，redis
cluster已经达到了成熟的程度，很多企业已经在生产系统使用，替换原有的twemproxy的分片方法。
二、redis cluster 的优点
- 支持数据分片功能，可以将数据分配到不同的实例上。
- 服务的高可用性、故障自动转移，最大程度避免单点故障
- 在线水平扩展能力，可以在线添加节点，转移数据等
- 无中心架构，各个节点度等。
- 降低原有的数据分片方案的复杂度，节省硬件资源
- 系统瓶颈更少，客户端直连方式。
以上这些优点足以是我们选用redis cluster了。
三、redis cluster 应用最佳实践（跳坑）
- 关于redis cluster实例的规划
为什么要用redis cluster呢，对于运维来讲就是实现服务的高可用，避免单点故障。笔者遇到的最坑的就是前人创建的集群的时候没有添加副本数，
是9台服务器上每台启动24个实例，然后用这216个实例创建的一个cluster。直到上次其中的一台服务器内存故障，导致服务器down机，接着集群的部分
数据不可用，客户服务受到了严重的影响。 创建集群的时候建议必须增加一个副本数，不然集群只是分片的作用，达不到高可用的要求。
redis是使用内存的数据库，规划的时候可按照服务器的内存大小来规划，我们研发说单个实例建议最大设置为20G，是官方文档中看到的，但是我还没找到。 集群的最多节点建议是1000个。
笔者目前维护的最大的集群为： 30台512G内存服务器，每台服务器上启动24个实例，共720个实例创建的一个cluster集群，副本数为1，相当于是360个
主和360个从节点。下图为30台机器的内存已使用的监控和整体的汇总展示。
- 服务器数据的选择
在服务器数据的选择上，建议采用偶数数据的机器，原因如下：
假如选用redis cluster官方教程里面的方法，拿三台主机A、B、C，每台机器上启动两个实例，那么他们的主从关系则为：
A <----B1
A1 ---->B
C <----C1
没错，你会发现，C服务器自己是自己的从，那么问题来了，加入C服务器故障，那么你的数据还是丢失的，所以说你的架构上是存在问题，不是高可用，依然存在单点，此时假如你再增加一台服务器D，那么C和D则会交叉的进行主从关系。
当然，上面这个主从关系是使用redis创建集群工具时候默认的bug，如果你一定要三台，每台上启动两个这样呢，你也可以这样做：
先使用A\B\C创建集群，全部是主节点，然后手动添加从节点，这样交叉添加也可以做到高可用。但是当你实例很多的时候你就力不从心了，所以建议采用偶数数目的服务器。
- 监听地址需要注意的地方
在配置文件中bind地址的时候千万不要用127.0.0.1,因为是要和其他服务器进行通信的，要采用真是的内网ip进行监听，不然你的集群是创建不成功的。
- 不在支持多数据库
根据官方文档的描述，redis cluster 是不支持select db的，redis单实例的时候是支持多数据库的。
- 参数优化
建议把cluster-require-full-coverage参数设置为no，即使单个slot异常，也不会出现大量的请求异常。
把cluster-node-timeout参数设置一个较小的值，比如6000（6秒）。这个参数建议不要设置太小或者太大，30s-60s即可。
以上便是在维护redis cluster的遇到的一些坑，分享给大家，希望大家提前避免。
