前言
我们这里首先来看 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, 计算集群节点跳转的处理, 是在上面的地方
如果是计算出来, 是其他节点, 才跳转, 否则 继续往后走, 走正常执行业务的处理
完
