Redis集群常用操作方式

目前对集群的操作可以通过社区提供的ruby脚本（redis-trib.rb，包含在src目录下）和内置命令进行（Cluster命令组）进行，包括Jedis在内的一些客户端工具也提供了部分集群操作。下面以前者为例介绍常用的集群操作。

安装集群
截止本文发布时，Redis社区并没有提供集群版的二进制包，所以需要自己从github下载最新源码然后进行编译安装。编译方法在源码包的readme中有详细说明，需要注意的是内存分配器推荐使用jemalloc，即通过“make MALLOC=jemalloc”指令进行编译。
社区要求最小的Redis集群需要包含3个Redis主节点，如果考虑到自动故障恢复的话，则需要6个节点为佳。
每个节点单独启动Redis服务，务必设置下列配置项（前两项必须设为yes）：
Daemonize yes //redis服务为后台守护进程
cluster-enabled yes //redis服务以集群模式启动
pidfile pid文件路径
logfile log文件路径
cluster-config-file node配置文件路径 //此文件在redis服务启动时产生，一般只供程序读写
如果仅仅将Redis作为缓存，而不需要持久化的话，启动时需要设置参数save为空字符串，参数appendonly为no。
如果作为测试意图，可以在一台物理机器上启动多个实例，每个模拟不同的节点，此时不同实例需要使用不同的端口。如果用作生产集群，不建议多个节点共享一台机器。
然后使用下列命令创建集群：
./redis-trib.rb create --replicas 1 <all node's address>
该命令根据参数中指定的节点地址，生成推荐的主节点和从节点，以及数据分区和节点的对应关系。当用户确认后，便开始创建集群。如果用户不赞同推荐的配置，则集群不能创建。此次只有推荐的配置，用户不能自定义配置。当然，如果对节点角色和数据分区有异议，也可在集群创建后，通过后续的命令进行调整。

重新分区
此操作一般用于添加或者移除节点的场景，否则，请慎用此操作。重新分区命令如下：
./redis-trib.rb reshard <arbitray node's address in cluster>
参数中只要指定集群中任一节点的地址即可，该命令能自动发现集群中的所有节点。重新分区必须在集群没有写入操作的场景下进行，否则不但会导致写入失败，而且分区操作也会失败。
重新分区后应该执行下列命令进行检查：
./redis-trib.rb check <arbitray node's address in cluster>
重新分区会导致分区中的所有key在不同的节点之间移动，所以这是一个的代价高的操作。

移除节点
./redis-trib.rb del-node <arbitray node's address in cluster> <node-id>
上述为移除节点的命令，参数node-id表示需要移除的节点标示，该标识可通过cluster nodes命令获取，也可从节点的cluster-config-file中查阅。
从节点可以直接移除，但是主节点必须先置空后才能移除。置空master节点的方法是通过reshar命令移除其包含的所有数据分区。
节点被移除后，其在剩余节点的cluster-config-file中的相应记录也会被清除。
移除节点的内部命令是CLUSTER FORGET <node-id>。

Failover
自动failover
当一个主节点故障后，会触发自动failover，也就是将此主节点对应的一个从节点选举为新的主节点。自动failover过程中，会影响客户端的读写，例如：客户端写可能会抛出下列异常：
Exception in thread "main" redis.clients.jedis.exceptions.JedisClusterMaxRedirectionsException: Too many Cluster redirections?
自动failover完成后，如果重启故障的主节点成功，它将自动变为一个从节点。
手动failover
在从节点上执行“cluster failover”命令将触发手动failover，结果是原来的主节点变成了从节点，从节点变成了主节点。
较之自动failover，手动的更安全可靠，因为在主从节点没有完全同步之前，不会将客户端的操作重定向到新的主节点。在手动failover执行期间，客户端读写操作不受影响。

添加节点
./redis-trib.rb add-node  <new node's address>  <arbitray node's address in cluster>
该命令将新添加的节点作为一个“空”的主节点，即不包含任何的数据分区。
./redis-trib.rb add-node --slave <new node's address> <arbitray node's address in cluster>
该命令将新添加的节点将作为一个从节点，其对应的主节点由集群随机选取从节点数最少的主节点。
./redis-trib.rb add-node --slave --master-id <master-node-id> <new node's address> <arbitray node's address in cluster>
该命令将新添加的节点作为一个指定主节点的从节点。
不管新添加的节点作为主节点还是从节点，都不影响当前的读写操作。但是如果新节点作为主节点的话，初始时其不包含任何数据分区，也就是说其实并未真正发挥主节点的作用。为了给其分配新的数据分区需要执行重新分区（reshard）命令，此时需要在写操作暂停的场景下进行操作。
也可以将新添加的“空”主节点转变为从节点，使用如下类似命令：
redis 127.0.0.1:7006> cluster replicate  < master-node-id >
该命令执行时，必须通过redis-cli登陆到需要转换的节点上，否则命令结果可能错乱。master-node-id表示从节点对应的主节点标识。这个命令还可以切换从节点对应到不同的主节点。
如果要将之前移除的一个节点再次加入，需要删除以前的rdb和cluster-config-file文件。

副本迁移
假设集群中每个主节点各有一个从节点，万一某个主节点和对应的从节点都失败了，则集群会出现不可用的情况。虽然这种场景很少，但是不能完全避免。
可以为一个主节点添加多个从节点，这样可以避免这个问题，但是这种方法太昂贵了。一种折衷的方法是：在每个主节点各有一个从节点的前提下，再添加少数几个从节点，先将它们对应到任意的主节点上。当发现有主节点的从节点个数为0时，并且还有其它主节点拥有多个从节点时。则从后者中选取一个从节点，将其转变为前者的从节点。
这种方法虽然可以最大化的避免集群不可用的问题，但是不能完全避免。
Redis集群目前已经实现了自动的副本迁移功能，只需在配置文件中启用“cluster-migration-barrier”选项即可（默认值为1），即如果出现一个主节点的所有从节点故障，并且还有其它主节点的从节点个数大于1的场景，则从后者的从节点中选择一个转换为前者的从节点。
也可手动执行副本迁移，通过命令“CLUSTER REPLICATE <master-node-id>”来实现。

停止集群
社区并没有提及集群的停止方法，经过实验后发现可以通过先停止所有从节点，再停止所有主节点的方式完成此功能。如果先停止主节点的话，可能会触发自动failover。启动时先启动所有主节点，再启动所有从节点。启动时将从cluster-config-file中获取节点之前的角色。 

升级集群
从节点升级很简单，只需要先停止节点服务，然后启动更新后版本即可。如果此过程中有客户端正在使用此节点，当发现不可用时会重连到其它从节点或者主节点。
如果升级主节点，过程稍微麻烦一点，可以按照下列步骤：
1. 使用cluster failover命令执行手动failover，将主节点转换为从节点；
2. 对转换后的从节点进行升级；
3. 再次执行手动failover，将从节点转换为主节点。
上述步骤只能对一个主节点进行升级，其余主节点升级，按照这些步骤执行多次即可。