超多图文，对新手友好度极好。敲命令的过程中，难免会敲错，但为了截好一张合适的图，一旦出现一点问题，为了好的演示效果，就要从头开始敲。且看且珍惜。
再认识redis集群前，若想先知道redis单机版的可查看，springboot整合redis。好了，下面开始了。
每个redis实例可称为一个节点，安装redis并以默认端口启动是节点，不关闭，以另一个端口启动，是一个新节点。在另一台机器安装redis并启动，也是一个新节点。
节点分为主节点(master)，从节点(slave)，数据从主节点向多个从节点上同步。
redis3.0开始支持集群，redis集群是没有统一的入口的，客户端（client）连接集群的时候连接集群中的任意节点（node）即可，集群内部的节点是相互通信的（PING-PONG机制）。
一，集群方式
1，主从模式
一个master可以拥有多个slave，但是一个slave只能对应一个master。这样，当某个slave挂了不影响其他slave的读和master的读和写，重新启动后会，数据会从master上同步过来。
在主从模式下，因为只有一个主节点可以写，而主，从节点都可以读，所以通常主节点负责写，从节点负责读。
但是，当唯一的master挂了以后，虽然这样并不影响slave的读，但redis也不再提供写服务，需要将master重启后，redis才重新对外提供写服务。
2，Sentinel模式
sentinel模式是建立在主从模式的基础上，避免单个master挂了以后，redis不能提供写服务。因为从节点上备份了主节点的所有数据，那么当master挂了以后，sentinel会在slave中选择一个作为master，并修改它们的配置文件，其他slave的配置文件也会被修改，比如slaveof属性会指向新的master，比如之前配置的密码。此时，客户端就不是直接连接Redis，而是连接sentinel的ip和port，由sentinel来提供具体Redis服务。
把之前挂了的master重新启动后，它将不再是master而是作为slave接收新的master的同步数据。
3，Cluster模式
Cluster模式是建立在Sentinel模式的基础上的，当数据多到需要动态扩容的时候，前面两种就不行了，需要对数据进行分片，根据一定的规则把redis数据分配到多台机器。
该模式就支持动态扩容，可以在线增加或删除节点，而且客户端可以连接任何一个主节点进行读写，不过此时的从节点仅仅只是备份的作用。至于为何能做到动态扩容，主要是因为Redis集群没有使用一致性hash,而是使用的哈希槽。Redis集群会有个哈希槽，每个key通过CRC16校验后对取模来决定放置哪个槽，而集群的每个节点负责一部分hash槽。
那么这样就很容易添加或者删除节点，比如如果我想新添加个新节点，我只需要从已有的节点中的部分槽到过来；如果我想移除某个节点，就只需要将该节点的槽移到其它节点上，然后将没有任何槽的A节点从集群中移除即可。由于从一个节点将哈希槽移动到另一个节点并不会停止服务，所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态。
需要注意的是，该模式下不支持同时处理多个key（如MSET/MGET），因为redis需要把key均匀分布在各个节点上，并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为。
二，搭建集群
这里就直接搭建较为复杂的Cluster模式集群，也是企业级开发过程中使用最多的。
1，准备工作
Linux可以连接外网，有wget（用于在线下载redis），系统安装好gcc环境，（不然编译redis会报错）。
2，下载、解压、移到指定目录，编译Redis
安装完成，在/usr/local/bin/目录下就会看见
3，建redis各节点目录
最终目录结构如下
4，redis集群的运行脚本
把之前安装好的redis的src目录下运行脚本拷贝过来，每个redis版本的运行脚本有细微差异，请以你自己的版本为准，就是下图绿色部分。
最终效果如下图所示
5，批量复制redis实例
最终效果图如下所示
6，逐个修改redis配置
以的为例子，其余五个类似。
cd/usr/local/redis-cluster/viredis.conf
打开配置文件，按i进入编辑模式，按照出现的顺序，主要需要修改的地方是
bind...（绑定当前电脑的IP，这是我虚拟机的，你绑定成你虚拟机的ip）port（因为我这是一台机器运行6个redis实例，所以要启动6个实例，得为它配置6个不同的端口，若你是6台机器，默认的端口就行，无需更改）daemonizeyes（这是设置是否后台启动Redis，默认no，但是生产环境肯定要默认就开启Redis，所以这里设置为yes。）pidfile/var/run/redis_.pid（_这个一定要和第一个配置的端口一样）dir/usr/local/redis-cluster//data/（数据文件存放位置，我换成指定目录下存放）appendonlyyescluster-enabledyes（启动集群模式）cluster-config-filenodes.conf（这个也要和之前的端口对应）cluster-node-timeout（超时时间）
完成以上修改，Esc退出编辑模式，输入:wq保存并退出。类似同样的操作操作再来五次。若是对redis的配置文件有兴趣，我在学习的过程中找到个详细的翻译版，可点击链接进去学习。
7，逐个启动redis节点
cd/usr/local/redis-cluster/usr/local/bin/redis-server/usr/local/redis-cluster//redis.conf/usr/local/bin/redis-server/usr/local/redis-cluster//redis.conf/usr/local/bin/redis-server/usr/local/redis-cluster//redis.conf/usr/local/bin/redis-server/usr/local/redis-cluster//redis.conf/usr/local/bin/redis-server/usr/local/redis-cluster//redis.conf/usr/local/bin/redis-server/usr/local/redis-cluster//redis.conf
运行效果如图所示
现在检查一下是否成功开启，如下图所示，都开启成功。
ps-el
grepredis
8，搭建集群
此时的节点虽然都启动成功了，但他们还不在一个集群里面，不能互相发现，测试会报错：(error)CLUSTERDOWNHashslotnotserved。
/usr/local/redis-cluster/bin/redis-cli-h...-pkeys*setnamemafly
如下图所示
解决报错，如果你是redis5.0以前的，你需要安装集群所需的ruby相关依赖
这步若安装报错，请查看Couldnotfindavalidgemredis。
如果你是redis5.0及之后的，无需安装ruby依赖，redis安装目录里内置了集群命令行工具redis-trib，它是一个Ruby程序，这个程序通过向实例发送特殊命令来完成创建新集群，检查集群，或者对集群进行重新分片工作。
redis-cli--clustercreate...:...:...:...:...:...:--cluster-replicas1
--cluster-replicas1这个指的是从机的数量，表示我们希望为集群中的每个主节点创建一个从节点。
红色选框是给三个主节点分配的共个槽点。
*色选框是主从节点的分配情况。
蓝色选框是各个节点的详情。
9，测试
现在通过客户端命令连接上，通过集群命令看一下状态和节点信息等
/usr/local/redis-cluster/bin/redis-cli-c-h...-pclusterinfoclusternodes
效果图如下，集群搭建成功。
现在往这个主节点写入一条信息，我们可以在这个主节点取到信息，集群间各个节点可以通信。
setnamelgxgetname
三，故障转移
1，故障转移机制详解
集群中的节点会向其它节点发送PING消息（该PING消息会带着当前集群和节点的信息），如果在规定时间内，没有收到对应的PONG消息，就把此节点标记为疑似下线。当被分配了slot槽位的主节点中有超过一半的节点都认为此节点疑似下线（就是其它节点以更高的频次，更频繁的与该节点PING-PONG），那么该节点就真的下线。其它节点收到某节点已经下线的广播后，把自己内部的集群维护信息也修改为该节点已事实下线。节点资格审查：然后对从节点进行资格审查，每个从节点检查最后与主节点的断线时间，如果该值超过配置文件的设置，那么取消该从节点的资格。准备选举时间：这里使用了延迟触发机制，主要是给那些延迟低的更高的优先级，延迟低的让它提前参与被选举，延迟高的让它靠后参与被选举。（延迟的高低是依据之前与主节点的最后断线时间确定的）选举投票：当从节点获取选举资格后，会向其他带有slot槽位的主节点发起选举请求，由它们进行投票，优先级越高的从节点就越有可能成为主节点，当从节点获取的票数到达一定数值时（如集群内有N个主节点，那么只要有一个从节点获得了N/2+1的选票即认为胜出），就会替换成为主节点。替换主节点：被选举出来的从节点会执行slaveofnoone把自己的状态从slave变成master，然后执行clusterDelSlot操作撤销故障主节点负责的槽，并执行clusterAddSlot把这些槽分配给自己，之后向集群广播自己的pong消息，通知集群内所有的节点，当前从节点已变为主节点。接管相关操作：新的主节点接管了之前故障的主节点的槽信息，接收和处理与自己槽位相关的命令请求。2，故障转移测试
这是之前集群中具体节点的情况，我简化成如下，可以向上回看图片中的集群信息。
这里关闭该端口的进程，即模拟该主节点挂掉。
登录挂掉的redis节点，会被拒绝服务，通过还在正常运行的某个主节点进入，然后再次查看集群中的信息
简而言之，就是之前的集群信息变成了如下所示
现在，我重启刚才挂掉的主节点，重新查看集群内部的节点情况，具体情况如下图所示。
简而言之，现在集群内的节点情况如下