Redis集群启动和停止流程那事儿，重新理顺下其实挺有必要的

开始）

之前我们聊过Redis集群的搭建，但回过头想想，光是知道怎么把命令敲进去还不够，得把集群从无到有、再从有到无的这个过程里，每个节点到底在干嘛给理顺了，这事儿挺有必要，不然出了问题都不知道从哪儿下手，咱们今天就抛开那些复杂的术语,用大白话把这事儿捋清楚。

先说说集群是怎么“活”起来的。

启动一个Redis集群，可不是简单地挨个把六个Redis服务启动就完事儿了，它更像是一场需要协调的“集体舞”,得按步骤来。

第一步，你得先把“舞台”搭好，也就是把每个节点实例单独启动起来，这时候，每个节点都是光杆司令，谁也不认识谁，你通过redis-server命令启动每个节点，并配上各自的配置文件，配置文件里最关键的是要把cluster-enabled选项设为yes，这就等于告诉这个Redis实例：“喂，你不是单打独斗了，准备加入集群模式。” 每个节点有自己的cluster-config-file，这个文件可以理解成这个节点的“身份证”和“通讯录”,但现在它还是一片空白。

第二步，也是最核心的一步，叫“握手”或者“组建集群”，光把节点启动起来，它们之间还是老死不相往来的状态，这时候就需要一个“介绍人”来牵线搭桥，这个介绍人就是Redis源码包里的redis-cli --cluster create命令，你把这个命令指向所有节点的地址和端口,它就会开始干活。

这个“介绍人”会做几件大事：它挨个联系你指定的这些节点，检查它们是不是都准备好了（处于待命状态），它会主导一场“权力分配大会”，也就是槽位（slots）分配，Redis集群总共有16384个槽位，可以想象成一个大楼里的16384个房间，数据就是根据key被哈希后分配到不同的房间里。redis-cli --cluster create命令会自动地把这16384个房间平均分配给前面三个主节点（如果你是用三主三从的模式），节点A管0-5460号房间，节点B管5461-10922号房间，节点C管10923-16383号房间。

分配方案定下来之后，“介绍人”会把这份“管理责任书”发送给每一个主节点，告诉它们：“以后你就负责这几个房间了。” 它还会设置主从关系，指定哪些节点是哪些主节点的“备份”（从节点），当所有这些信息都在所有节点之间同步完毕，整个集群就会开启一个唯一的、共同的标识符——集群配置纪元（config epoch），这个纪元号可以理解为集群配置的版本号，每次集群状态有重大变化（比如主节点挂了重新选主）这个数字都会增加，用来判断哪个消息更新，至此，集群就算正式组建成功,可以对外提供服务了。

说完了启动，再聊聊怎么让集群“安全地睡去”。

停止集群可不能想当然地直接kill -9把进程干掉，那样可能会导致数据丢失或者集群状态混乱，正确的做法是“优雅关闭”。

最稳妥的办法是逐个节点地进行关闭，你可以先用redis-cli连接到集群的任意一个节点，执行CLUSTER INFO命令，确认一下整个集群的状态是ok的,所有槽位都已经分配到位。

选择一个从节点开始关，连接到这个从节点，执行SHUTDOWN命令，这个命令会让节点先停止接受新的请求，然后把内存中的数据持久化到磁盘（如果配置了持久化的话），最后再退出,这样能最大程度保证数据不丢失。

关掉一个从节点后，集群依然能正常工作，只是少了一个备份,你可以用同样的方式关闭其他的从节点。

当所有从节点都安全关闭后，再来处理主节点，关主节点要格外小心，同样是用redis-cli连上主节点，执行SHUTDOWN，由于从节点已经关了，所以这个主节点下线后，集群会检测到有主节点不可用，但因为已经没有从节点可以顶替上来了，所以整个集群会最终变为失败（fail） 状态，无法继续提供服务，这是符合预期的,因为你是主动在关闭集群。

按照从从节点到主节点的顺序关闭，可以避免不必要的故障转移，如果你先关主节点，集群会误以为主节点故障了，就会自动触发故障转移流程，让它的从节点升级成新的主节点，这个过程中会有短暂的不可用，而且增加了不必要的复杂度,按顺序关是最省心的。

启动集群就像组织一场会议：先通知所有人到场（启动节点），然后由会议主持人（redis-cli工具）安排座位、分配任务（分配槽位、主从关系），最后会议正式开始（集群生效），而停止集群则像散会：让参会者（从节点）先有序离场，最后再请主席台的人（主节点）离开，确保会议纪要（数据）都保存好了，这样下次开会才能无缝衔接。 结束）