J11、RedisCluster的限制原因，Redis 6.0

实例间的通信开销会随着实例规模增加而增大。

• Redis Cluster每个实例都会保存slot和实例的对应关系，以及自身的状态信息。
• 集群的每个实例都知道其他实例的信息，实例之间按照Gossip协议进行通信。
  • 每个实例按照一定频率，随机在集群中挑选一定实例，PING（封装了实例自身状态、部分其他实例信息，和Slot映射表），检测实例是否在线，交换彼此状态信息。
  • 实例在收到PING会发送一个PONG消息，PONG的内容和PING的信息一样。

开销受到通信消息大小和通信频率影响。

Gossip 消息大小

// Gossip 大小104字节
typedef struct {
 char nodename[CLUSTER_NAMELEN]; //40字节
 uint32_t ping_sent; //4字节
 uint32_t pong_received; //4字节
 char ip[NET_IP_STR_LEN]; //46字节
 uint16_t port; //2字节
 uint16_t cport; //2字节
 uint16_t flags; //2字节
 uint32_t notused1; //4字节
} clusterMsgDataGossip;

• PING消息还带有长度为16384bit的Bitmap,Bitmap的每一位对应一个slot,

实例间通信频率

• Redis Cluster 的实例启动后，默认会每秒从本地的实例列表中随机选出 5 个实例，再从这 5个实例中找出一个最久没有通信的实例，把 PING 消息发送给该实例。这是实例周期性发送PING 消息的基本做法。(有些实例一直没有被发送PING消息，导致维护的集群状态已经过期)。
• Redis Cluster 的实例会按照每 100ms 一次的频率，扫描本地的实例列表，如果发现有实例最近一次接收 PONG 消息的时间，已经大于配置项 cluster-node-timeout 的一半了（cluster-node-timeout/2）就会立刻给该实例发送 PING 消息，更新这个实例上的集群状态信息。
• 实例每秒发送的PING消息数量：1 + 10*实例数（最近一次接受PONG消息的时间超出cluster-node-timeout/2）

如何降低实例间的通信开销？

• 在大规模集群中，调大 cluster-node-timeout值，减少超时情况，大概20~25秒

6.0

从单线程处理网络请求到多线程处理

单个主线程处理网络请求的速度跟不上底层网络硬件的速度。

• 方法一：用户态网络协议栈取代内核网络协议栈，让请求在用户态完成。（要修改redis网络部分，容易不稳定，引入bug）
• 方法二：多个io线程处理网络请求，提高请求处理并行度。

多io处理请求，读写命令仍然使用单线程。
主线程和多IO线程协作分为四阶段。
一：主线程接受建立连接请求（客户端和实例建立Socket连接——》主线程会和客户端创建连接——》socket放入全局等待队列，主线程通过轮询把Socket连接分配给IO线程）。
二：主线程把Socket分配给IO线程，会进入阻塞，等待IO线程完成客户端请求和解析。
三：IO线程解析完后，主线程以单线程执行命令。

四：当主线程执行完请求操作后，会把需要返回的结果写入缓冲区，然后，主线程会阻塞等待 IO线程把这些结果回写到 Socket 中，并返回给客户端。等到 IO 线程回写 Socket 完毕，主线程会清空全局队列，等待客户端的后续请求。

实现服务端协助的客户端缓存

• 实现了服务端协助的客户端缓存功能，也称为跟踪（Tracking）功能。（业务应用中的 Redis 客户端就可以把读
  取的数据缓存在业务应用本地了）

如果数据被修改了或是失效了，如何通知客户端对缓存的数据做失效处理？

需要客户端使用 RESP 3 协议

• 第一种模式是普通模式。在这个模式下，实例会在服务端记录客户端读取过的 key，并监测key 是否有修改。一旦 key 的值发生变化，服务端会给客户端发送 invalidate 消息，通知客户端缓存失效了。（对key只会报告一次invalidate，下次再次修改也只会一次，再次读命令时，才会再次监测）
  CLIENT TRACKING ON|OFF 打开或关闭普通模式下的tracking
• 第二种模式是广播模式。服务端会给客户端广播所有 key 的失效情况，不过，这样做了之后，如果 key 被频繁修改，服务端会发送大量的失效广播消息，这就会消耗大量的网络带宽资源。即使客户端还没有读取过 key，但只要它注册了要跟踪的 key，服务端都会把 key 失效消息通知给这个客户端。

RESP 2 协议

• 重定向模式：向失效消息的频道 _redis_:invalidate发起订阅，用另一个客户端执行CLIENT TRACKING命令，将失效命令转发给RESP2客户端。

细粒度权限控制

• rename-command重命名高风险命令。
• 创建不同用户使用redis
• 以用户为粒度设置命令访问权限。

启用 RESP 3 协议

• resp2:客户端和服务端通过字节数组编码，客户端根据命令对传输解码。
• resp2:支持多种数据类型的区分编码。根据不同的开头字符区分不同的数据类型