一次调试去了解redis集群的slot机制

某次我在压测redis集群（该redis集群使用一批intel性能硬件aep），为了上线前摸清性能上限。于是就有了后面的故事。

正常情况下，因为我没有那么多机器去打redis集群，于是去寻求测试部门压测平台的帮助，去获取到大流量（为了尽量模拟真实线上，使用了旁路录制的流量进行重放），但是由于压测平台是对业务服务的（请求pb格式是业务定制的），而没有这种redis的读写压测功能。所以还是得靠服务，但是服务机器我旁路测试环境又没有多台。于是就有了大数据同学的建议，你们的数据可不可以都打到同一台slot。

好吧这个redis的slot有耳闻，但是还不是特别了解，因为平时的连接我只需要一个url+端口就搞定了。比如以下配置

于是乎，使用gdb打开服务进程，去内部窥探下slot是怎么运作的

gdb --args ./SearchUserFeatureServer --flagfile=conf/gflags.conf

设置好断点，可以按r，开始探索之旅

首先我发现初始化连接的时候，redis会响应，返回类似这种连接信息

f2a9484ec91a9007863d015e2f72146940477efb 10.194.88.141:[email protected] master - 0 1656591917000 33 connected 656-1311

复制

描述了

<id><ip:port><flags><master><ping-sent><pong-recv><config-epoch><link-state><slot><slot>...<slot>

于是我的代码会去找这个slot，然后进行slot的redis node节点的映射。最后会把这个16384个元素的数组填充满。

就是代码中的int slot_ipport_index_vec[16384]。

首先我连的这个集群有24个node，其中一个node信息如下：他的起始slot是656，终止slot是1311

每段slot区间是656，这个656是根据16384个slot数/24个node得到的。观察这个16384个数组，他里面均匀分布着24个node。每个node独占一段slot。

首先会去和redis连接，然后他会告诉你redis有多少个node

然后这个node数量会作为除数，16384/node数=slot区间

然后每个slot区间都是放同一个节点的连接。把这16384分割成0-655，656-1311，…

之后的请求就会根据key的crc32算出一个hash值，投射到这个hash环上，决定用哪个节点

这个是请求key进来，根据crc16做简单散列值计算

请求会根据hash算出落在16384个元素的数组的最终节点，好比一个hash环，node投射一遍，请求key投射一遍，然后找交集

不过我看到的这个是和redis建立init的过程，不知道后面如果新增或者减少node是怎么处理的，这个待进一步研究～