redis cluster 实践总结

最近项目接触到了redis cluster，现在趁着使用做一下总结，记录一下遇到过的问题，简单的概述一下常用到的命令和功能。

本篇文章主要是以运维的角度去讲述如何去更好的规划redis cluster和跳坑。

一、redis cluster 是什么

redis cluster是官方redis 3.0版本之后推出的集群方案，之前类似的方案还有豌豆荚的codis集群方案、twemproxy方案，

不过twemproxy有个非常大的弊端就是不能在线扩容节点，这就比较尴尬了。redis cluster发布之后，截至目前为止，redis

cluster已经达到了成熟的程度，很多企业已经在生产系统使用，替换原有的twemproxy的分片方法。

二、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的遇到的一些坑，分享给大家，希望大家提前避免。

巴特西