前言
哨兵模式虽然让读写分离更加高可用，但单台服务器由于本身的内存和CPU瓶颈，对于高并发和大数据业务的应用场景还是远远不能满足；对于这种情况，有点经验的小伙伴会毫不犹豫的想到集群，搞他好几个节点，负载均衡再加上故障转移，岂不美哉。是的，就是这个理，接下来玩玩。
正文
集群，相信这个词小伙伴应该听的耳朵起茧子了吧；多搞几台服务器，让请求/命令平均分发到各个服务器，避免单台服务器承载过大压力；对于Redis集群来说，为了实现自动故障转移，还需要在每个主节点上增加一个或多个从节点，当主节点发生故障时，从节点自动补上，实现高可用。
总的来说，Redis集群有以下作用：
多主节点的实现可以应对高并发场景，并发量增大，节点可以随时扩展满足需求；
多主节点的实现可以存储更多的数据，因为数据均匀分布到各个节点；
多主节点搭配多从节点的实现让高可用更加稳定，即当有主节点发生故障时，对应下面的从节点会升级为主节点，正常提供功能；
老规矩不变，一边实操一边总结，接下来搭建一个3主3从的集群，这是最简单的。Redis集群中最少需要3个主节点，再加上为了实现高可用，每个主节点至少得跟一个从节点，不然一个主节点挂了，找不到完整的数据，整个集群就不能用了；至于为什么会找不到完整的数据，下面会聊到。
接下来要搭建的集群环境如下：
简要说明：
6370为主节点，6381为6370的从节点；
6380为主节点，6391为6380的从节点；
6390为主节点，6371为6390的从节点；
在集群环境中主节点之间是相互通讯的(这里没有哨兵)，每一个节点都是数据节点；
这里集群方案使用redis-cli自动指定主从关系(小伙伴的主从关系可能会和我这不一样哦)，也可以手动指定；反正思路都一样；
以下演示在同一台机器上，通过端口区分各个节点；在实际开发中，一般都是用不同的服务器。
案例演示
准备六个节点的配置文件，开启集群相关配置；
拷贝最初默认的配置文件，然后进行更改，主要更改以下项：
port 6370 # 指定Redis节点端口
pidfile /var/run/redis_6370.pid # 指定对应进程文件
dbfilename dump6370.rdb # 每个节点的rdb持久化文件
cluster-enabled yes # 开启集群，这个比较重要
cluster-config-file nodes-6370.conf #指定每个节点的集群配置文件，这个比较重要以上配置文件内容在其他节点(6370,6371,6380,6381,6390,6391)都需要进行修改，只是将其中6370改为对应节点的端口即可，目的就是为了不同节点使用不同端口并区分用到的不同文件即可；比如需要修改6371节点的配置文件如下：
port 6371 # 指定Redis节点端口
pidfile /var/run/redis_6371.pid # 指定对应进程文件
dbfilename dump6371.rdb # 每个节点的rdb持久化文件
cluster-enabled yes # 开启集群，这个比较重要
cluster-config-file nodes-6371.conf #指定每个节点的集群配置文件，这个比较重要其中cluster-enabled和cluster-config-file是集群配置的重点。
启动六个节点，刚开始各个节点是相互独立的；
准备好配置文件之后，就可以使用redis-server指定配置文件启动节点啦，如果节点多，小伙伴可以编写脚本哦；
./redis-server ZoeCluster/redis6370.conf # 启动6370节点
./redis-server ZoeCluster/redis6371.conf # 启动6371节点
./redis-server ZoeCluster/redis6380.conf # 启动6380节点
./redis-server ZoeCluster/redis6381.conf # 启动6381节点
./redis-server ZoeCluster/redis6390.conf # 启动6390节点
./redis-server ZoeCluster/redis6391.conf # 启动6391节点启动效果如下：
这样只是将各个节点启动起来，集群关系还没创建呢，如果不信，可以使用redis-cli连接任意一个节点查看集群信息，如下：如上图，cluster-size为0，集群的关键，槽也还没有分配；那接下来肯定是要将各节点的集群关系搞起来；
建立节点集群关系
由于我使用的Redis版本是5.0，直接可以使用redis-cli就可以进行集群搭建，在此版本之前都推荐使用redis-trib.rb进行相关操作，这个是一个Ruby脚本，需要安装相关环境，小伙伴可以下来尝试；
使用命令如下：
./redis-cli --cluster create --cluster-replicas 1 127.0.0.1:6370 127.0.0.1:6380 127.0.0.1:6390 127.0.0.1:6371 127.0.0.1:6381 127.0.0.1:6391参数简介：
-- cluster : 指定是用于创建集群环境；
-a：密码，即如果有密码，可以通过-a传参，这里没有设置密码；
--cluster-replicas：这里设置为1, 用于配置主节点上的从节点数，1就代表一主一从，2就代表一主二从，依次类推；
后面的是节点IP:节点端口，一般前面的是主节点，后面的是从节点；如果同意集群方案，然后就开始进行相关操作，如下：同样，可以连接到任意一个节点，查看集群情况，如下：注：关于主从节点之间的主从复制过程就不在这说了，和之前说过的主从复制一样；
演示访问操作；
使用redis-cli连接任意节点写入数据，如果不指定集群连接的话，会写入数据失败，如下：
由于集群环境下，数据的存储位置是根据Key来计算而来的(这里牵涉到一致性哈希算法)，使得数据可以均匀分配到各节点上，所以在redis-cli连接的时候需要指定集群模式，如下：
如上图所示，指定集群模式之后就可以正常存取了；
故障演示
既然集群环境，肯定少不了要好好测测；
模拟从节点挂掉
找个从节点停掉试试，这里停掉6371节点，根据创建集群信息知道，它的主节点是6390；
主节点显示从节点断开连接，看看它的主节点反应：
其他集群节点只是将从节点标记为failing状态，即下线状态，如下：
对于存取数据也不受影响，这里就不截图了，小伙伴自行尝试吧；
当故障的从节点6371重新连上时，主节点恢复主从关系，并进行主从复制操作；其他集群节点会清除原来标记的下线状态，将其改为上线；
模拟主节点挂掉
这里就手动将6390这个节点停掉，会有怎样的反应呢？
自身从节点会每隔一秒检测连接，如果超时(默认是15秒)，会选举从节点做为集群的主节点来提供服务，如下图：
数据存取最终还是不受影响；
对于其他集群节点，将故障节点标记为failing，让新上任的主节点提供服务，如下图：存取数据也是不受影响的；
挂掉的主节点6390如果恢复，那它只能变为6371的从节点啦，并进行相关主从复制操作；而集群的其他节点只是将其原有的Fail状态清除，表示可以正常连接；
Redis集群就是这样简单，只要思路对，就是手工活；小伙伴可以编写脚本自动执行哦；
接下来说说集群数据的存储；
数据存储简单分析
在Redis集群环境中，数据的存储位置是根据对Key的Hash计算进行指定的；Redis集群为了在节点改变时保证数据分布均匀，引入了槽(slot)作为迁移的基本单位，槽解耦了数据和实际节点的关系，使得实际节点数的改变对系统影响较小；
在整个集群中，槽(slot)总共有16384，会将其均匀分配到集群的主节点上，其中每一份槽对应一个存储空间(这里的存储空间可以理解为一个容器，是可以存很多数据的)，以上集群环境的槽分配如下：
存储数据的过程，如下：
连接6380主节点，执行如下操作：
具体过程如下：
简要说明：
客户端发起命令；
服务器将Key进行CRC16计算，并与总槽位计算出Key需要存储的位置；
这里模拟的Key为zoe，计算出的槽位为14588，不在6380这个节点上，集群节点会将其重定向到对应槽位的节点上；
然后找到6371上的14588槽位进行数据存储；（注，这里的6371已经是主节点了，因为上面做过一次故障转移模拟）；
那集群节点是如何知道其他节点的槽范围和其他信息呢？
那是因为各节点之间有通讯，通讯端口是对应的redis端口+10000，比如节点6371的集群通讯端口为16371（如果多台机器，别忘了防火墙放开这个端口哦），可以通过cluster nodes看到，如下：
并且将各节点的信息保存在自己对应的集群配置文件中，这个集群文件名是通过配置项cluster-config-file指定的，在集群节点启动时会检查该文件是否存在，如果不存在，会自动创建，如果存在，就加载里面的相关配置信息；里面有哪些信息，随便找个节点的配置文件看一下：
如上图所示，各节点的配置文件中记录了其他节点的主从关系，分配的槽位，各节点的状态；这样的话，集群关系就算重新启动也还存在。
集群伸缩(节点增删)演示
在实际应用场景中，会根据业务需要，对集群进行伸缩，即节点的增删；业务并发大了加节点进行扩展， 节点需要调整时可能需要进节点删除；
加节点
这里进行节点扩展，加一个6360主节点，6361作为6360的从节点；参照以上集群搭建时配置文件更改，然后将其都启动，如下：
6360节点
port 6360 # 指定Redis节点端口
pidfile /var/run/redis_6360.pid # 指定对应进程文件
dbfilename dump6360.rdb # 每个节点的rdb持久化文件
cluster-enabled yes # 开启集群，这个比较重要
cluster-config-file nodes-6360.conf #指定每个节点的集群配置文件，这个比较重要
6361节点
port 6361 # 指定Redis节点端口
pidfile /var/run/redis_6361.pid # 指定对应进程文件
dbfilename dump6361.rdb # 每个节点的rdb持久化文件
cluster-enabled yes # 开启集群，这个比较重要
cluster-config-file nodes-6361.conf #指定每个节点的集群配置文件，这个比较重要
两个节点都启动，然后将6360加入到集群主节点中，执行以下命令：
./redis-cli --cluster add-node 127.0.0.1:6360 127.0.0.1:6370
注：其中127.0.0.1:6360是需要加入的新增节点，127.0.0.1:6370是现有集群中的任意一个节点；
可以通过以下命令检测集群状态，如下：
./redis-cli --cluster check 127.0.0.1:6370 # 后面的地址是任意的集群节点
可以看到6360已经加入到集群环境中，但现在还没有从节点和槽分配，所以接下来先将6361作为6360的从节点加入，如下：
./redis-cli --cluster add-node --cluster-slave --cluster-master-id eaa814dc56beb0d5edb6a4fbb14f1384e78d4764 127.0.0.1:6361 127.0.0.1:6370
参数说明：
--cluster-slave : 意思就是加入的是从节点；
--cluster-master-id：后面紧跟主节点的id，这里就是6360的节点id；通过cluster nodes可以查看到节点id；
127.0.0.1:6361：需要加入的从节点；
127.0.0.1:6370：现有集群的任意主节点；
现在还差槽分配了，如果需要直接将16384个槽平均分配到所有节点话，直接执行以下命令即可：
./redis-cli --cluster rebalance --cluster-threshold 1 --cluster-use-empty-masters 127.0.0.1:6370
使用命令./redis-cli --cluster check 127.0.0.1:6370查看分配结果，如下图，只截了部分：
如果不想均匀分配，根据自定义需要进行配置，可以执行以下命令，会提示一步一步配置；
./redis-cli --cluster reshard 127.0.0.1:6360 #后面是新加入的主节点
# 也可以执行以下指令直接配置想要的数据
./redis-cli --cluster reshard --cluster-from all --cluster-to 需要分配槽的节点id --cluster-slots 1000 --cluster-yes 127.0.0.1:6370 # 1000 指分配的槽数
这里就不截图演示了，留给小伙伴自己动手操作吧；
删除节点
先对节点进行分片工作，防止数据丢失，即将指定节点上的槽分配到其他节点；
./redis-cli --cluster reshard 要删除节点ip:port移除节点，推荐先删除从节点，再删除主节点；
./redis-cli --cluster del-node 节点ip:port 节点id
集群配置项
cluster-enabled(是否开启集群模式)：设置为yes，将该节点开启为集群模式；
cluster-config-file(设置每个集群节点对应的配置文件名称)：文件是自动生成的，不用手动创建；
cluster-node-timeout(设置超时时间，即集群节点不可用的最大时间，如果超过这个时间就认为该节点不可用)：默认为15000(以毫秒为单位)；
cluster-migration-barrier(配置一个主机最少可用的从机的个数)：默认是1,表示一个主机的从机迁移之后，至少得有一个从机可用，否则不进行节点迁移；
cluster-require-full-coverage(配置集群服务的可用性)：默认yes开启，即集群没完全覆盖所有slot，集群就挂了；设置为no，就算槽没有全分配，也能提供服务，需要自己保证槽分配；
总结
到这集群的搭建就完啦，本来想着写着很简单的，没想到又干了4000字；对于集群，使用有一些限制，比如Keys命令只能针对当前节点，需要针对多节点的情况进行处理；集群中各节点只支持db0数据库，其他数据库不支持等等；所以使用要注意哦，后续抽时间单独整理一篇注意事项吧，篇幅有点长，不继续聊啦； 下篇说说熟悉的缓存穿透、缓存击穿、缓存雪崩吧；
一个被程序搞丑的帅小伙，关注"Code综艺圈"，跟我一起学~~~
