docker容器中部署redis cluster集群的详细操作步骤（3主3从）

要部署redis-cluster集群模式，先来了解redis-cluster集群模式的两种实现原理，一种是使用槽的方式进行处理，需要计算16384个槽的位置，一种是使用一致性hash来计算hash环。两种方式大同小异，都是需要计算。下面详细的来说明一下：

redis集群功能的限制：redis集群相对单机来说，在功能上存在一些限制。
redis集群时使用 JAVA CRC16校验算法来计算槽位

1.使用槽来实现

key批量操作支持有限
类似mset、mget操作，目前只支持对具有相同slot值的key进行批量操作。对于映射为不同slot值的key由于执行mset、mget等操作可能存在多个节点上，因此不被支持。

key事务操作支持有限
只支持多key在同一节点上的事务操作，当多个key分布在不同的节点上时无法使用事务功能。

key作为数据分区的最小粒度

不能将一个大的键值对象如hash、list等映射到不同的节点
不支持多数据库空间
单机下的redis可以支持16个数据库（0-15），集群模式下只能使用一个数据库空间，即db0。

复制结构只支持一层
从节点只能复制主节点，不支持嵌套树状复制结构。

命令太多会重定向，耗时多

2.使用一致性hash
一致性hash可以很好的解决稳定性问题，可以将所有的存储节点排列在首尾相接的hash环上，每个key在计算hash后会顺时针找到临接的存储节点存放。而当有节点加入或退出时，仅影响该节点在hash环上顺时针相邻的后续节点。

hash倾斜
如果节点很少，容易出现倾斜，负载不均衡问题。一致性hash算法，引入了虚拟节点，在整个环上，均衡增加若干个节点。比如a1，a2,b1,b2,c1,c2等，a1和a2都属于A节点的。解决hash倾斜问题

部署集群：

1、创建6个redis节点

3主3从方式，从为了同步备份，主进行slot数据分片。
下面写了一个shell脚本来创建6个节点信息：

for port in $(seq 7001 7006);\
do \
mkdir -p /mydata/redis/node-${port}/conf
touch /mydata/redis/node-${port}/conf/redis.conf
cat <<EOF> /mydata/redis/node-${port}/conf/redis.conf
port ${port}
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
cluster-announce-ip 192.168.0.106
cluster-announce-port ${port}
cluster-announce-bus-port 1${port}
appendonly yes
EOF
docker run -p ${port}:${port} -p 1${port}:1${port} --name redis-${port} --privileged=true \
  -v /mydata/redis/node-${port}/data:/data \
  -v /mydata/redis/node-${port}/conf/redis.conf:/etc/redis/redis.conf \
  -d redis:5.0.7 redis-server /etc/redis/redis.conf; \
done

执行这个脚本一定要按照自己虚拟机的ip地址进行操作，还有就是启动docker的守护进程

创建成功与否可以通过docker ps来检查容器是否运行，具体截图如下所示：

2、配置redis集群

进入某个容器的控制台：
docker exec -it redis-7001 /bin/bash
进入容器之后，执行如下命令：

redis-cli --cluster create 192.168.0.106:7001 192.168.0.106:7002 192.168.0.106:7003 192.168.0.106:7004 192.168.0.106:7005 192.168.0.106:7006 --cluster-replicas 1

记录控制台打印信息：

可以看到，7001，7003，7002为master节点，7004、7006、7005为slave节点，
通过截图可以看出，7004为7003的从节点，7006为7002的从节点，7005为7001的从节点

当我们把7003（docker stop redis-7003
）停止以后，再使用cluster nodes可以看到，集群节点信息发生变化，截图如下：

重新启动redis-7003（docker restart redis-7003），再次查看集群状态，发现如下所示：

说明：当redis-cluster集群主节点发生故障的时候，从节点会马上升级为主节点，当主从节点自动恢复的时候，又重新加入了集群，这个时候的从节点就只能成为主节点了。

总结：目前几乎所有的集群架构模式都是主节点宕机之后，从节点自动升级为主节点，当主节点恢复之后，只能变为从节点，而无法变成之前那样的主从节点的关系。因为在主节点的宕机的间隔内，主节点无法接受外部数据的插入，只有从节点来替代这段时间的空白。当主节点恢复之后，又要同步之前从节点接受的数据，所以无法恢复为之前的主节点，只能以从节点的身份加入集群。