前言

我们这里首先来看 redis 这边实现比较复杂的 cluster集群模式 

整个 cluster集群 中会包含多对 Master+Slave 的组合, 然后这多对 Master+Slave 来分解 16384 个 slot

然后 客户端这边 set, get 的时候, 先根据 key 计算对应存储的 slot, 然后 服务器这边响应 MOVED + 目标机器 给客户端, 然后客户端这边 重新连接目标机器, 然后 将原有的命令发送到 目标机器上面

服务器这边主要是如果目标slot在本机, 则进行业务处理, 否则进行一个 转发的处理

客户端这边的处理就是, 向服务器发送命令, 如果服务器正常响应, 则处理正常, 如果服务器返回 MOVED + 目标机器, 则连接目标机器, 然后发送命令 

所以 这个集群其实就是 转发 + 几对主从, 来实现的集群, 然后 主从本身提供了服务的高可用, 多备份, 完整性, 一致性 

转发 + 几对主从, 提升了集群的处理效率, 吞吐量等等 

 

 

客户端发送 set 命令

在客户端上面发送命令 “set name4 jerry”

 

 

服务器这边的 keyHash 处理

服务器这边的转发处理如下, 这里是转发的最终结果 

客户端目前连接的是 “192.168.220.132:7004”, 然后这里服务器根据 ”name4” 计算, 需要转发的机器是 “192.168.220.132:7005”, 以及 slot 是 8736

 

计算 slot 的方式如下, 传入 “name4” 然后根据 keyHashSlot 进行 slot 的计算, 具体的计算规则 我们可以不用关心, 只需要知道 一个 key 会计算到一个固定的 slot 就行 

 

计算的方式如下, 如果是包含 “{” 和 “}” 计算 之间的部分, 基于 crc16(str) % 16384

否则计算 crc16(key) % 16384

 

 

客户端这边的转发处理

这里打印了日志, 更新了 config.hostip, config.hostport 以及刷新了 prompt 的信息 

 

然后在外面的发送命令的循环中, 会重新和目标服务器建立间接, 然后重新发送命令 

 

然后转发到目标服务端这边的时候, 客户端这边 调用堆栈如下

 

 

目标服务端这边的业务处理

服务器这边的处理如下, 这个就是 常规意义上的真实的 set 命令的落地处理了 

 

在 processCommand 中, 调用真实业务处理的是在这里, 在处理的末尾了 

 

然后上面的计算 keyHash, 计算集群节点跳转的处理, 是在上面的地方 

如果是计算出来, 是其他节点, 才跳转, 否则 继续往后走, 走正常执行业务的处理 

 

 

完