redis源码之：redis-cli 集群命令

在集群命令执行前，需要先按上一章节的方式redis源码之：clion搭建cluster环境，启动四个新的redis节点，但不要执行cluster create命令，保持四个节点独立。

redis-cli的命令执行大抵流程差不多，下面以redis-cli --cluster create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 --cluster-replicas 0为例，进行代码分析：

一、命令解析

进入redis-cli的main方法，方法中通过parseOptions()，对命令的cmdname,和对应的参数进行解析，此处主要看cluster的，其他的本文不做介绍：

二、匹配命令执行方法proc

在redisvCommand(),先对命令进行封装，然后通过__redisBlockForReply()->redisGetReply()->redisBufferWrite()将命令内容写入对应socketfd的buffer；
组装发往服务端的命令，被服务端通过epoll接收请求并解析执行，具体可以看redis源码之：客户端命令执行Command

三、proc的执行

本文例子的proc就是create命令对应的clusterManagerCommandCreate()：

关于cluster set-config-epoch
configepoch主要用于cluster node之间的slot配置信息冲突的解决，如：A节点和B节点，同时宣称自己负责slot0,并向外发送自己的configepoch和负责的slots信息,此时如果C先接收到A的消息，则更新自己的server.cluster->slot[0]=A (如果此前该值为null),并记录A的configEpoch。接着，C又收到B的信息，发现B也说自己负责slot[0],此时，C对比B和A的configEpoch，如果B的configEpoch较大，则说明B的配置更新，C就更新自己的server.cluster->slot[0]=B，否则不变。
同时在redis主从选举，是通过currentEpoch完成主从选取的，主从选举时新的主会对currentEpoch+1，然后发送给其他的主节点。比如nodeA，B，C，分别有从节点A1，A2，B1,，B2，C1,C2,当A下线，A1，检测到主A下线，则自己成为新的主，将currentEpoch加1，并向B，C两个主节点发送选举信息，B和C同意A1选举为新的主，BC则将自身的currentEpoch修改A1发送过来的currentEpoch，同时将原本指向A的slots改为指向新的A1。此时A2也会将自身的currentEpoch加1发送同样的选举消息到BC，由于BC发现A2发过来的新configEpoch跟A1发过来的一样，或者小于A1发过来的，则拒绝A2的currentEpoch信息。

四、集群相关命令

在上面的分析中，主要使用过的命令有，cluster info，cluster nodes，cluster replicate、cluster meet、cluster addslots、cluster set-config-epoch等，通过redis源码之：客户端命令执行Command，
可以发现，最终在服务端处理会进入processCommand()—>clusterCommand()
在clusterCommand()方法中可以看到支持如下这些命令：

方法的后续会根据每种命令进行对应的处理