在集群命令执行前，需要先按上一章节的方式redis源码之：clion搭建cluster环境，启动四个新的redis节点，但不要执行cluster create命令，保持四个节点独立。
redis-cli的命令执行大抵流程差不多，下面以为例，进行代码分析：
进入redis-cli的main方法，方法中通过parseOptions()，对命令的cmdname,和对应的参数进行解析，此处主要看cluster的，其他的本文不做介绍：
在redisvCommand(),先对命令进行封装，然后通过__redisBlockForReply()->redisGetReply()->redisBufferWrite()将命令内容写入对应socketfd的buffer；
组装发往服务端的命令，被服务端通过epoll接收请求并解析执行，具体可以看redis源码之：客户端命令执行Command
本文例子的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()方法中可以看到支持如下这些命令：
方法的后续会根据每种命令进行对应的处理
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/rfx/69317.html