主要观点：介绍了 Redis 中的服务器辅助客户端缓存，包括其优势、存在的问题及解决方法等。
关键信息：

• 客户端缓存可利用应用服务器内存存储数据库部分信息，减少延迟和数据库负载。
• 存在如何使应用缓存信息失效以避免提供陈旧数据的问题，Redis 6 实现了对客户端缓存的直接支持。
• Redis 客户端缓存支持有两种模式：默认模式和广播模式，分别在服务器端和客户端有不同的处理方式。
• 可使用两个连接模式，一个用于数据查询，一个用于接收失效消息，且 RESP3 支持在同一连接中处理，RESP2 需使用两个连接。
• 介绍了跟踪（Tracking）的相关内容，包括默认模式下服务器记住客户端访问的键及发送失效消息等，还提到了两种连接模式下的具体操作。
• 有可选的准入（Opt-in）和退出（Opt-out）缓存方式，分别用于控制客户端缓存的键。
• 广播模式下，客户端通过指定前缀启用缓存，服务器使用前缀表处理失效消息。
• 可使用 NOLOOP 选项避免客户端收到自身修改键的失效消息。
• 要注意避免在重定向失效消息连接时出现竞态条件，以及丢失与服务器的连接时可能导致缓存数据陈旧的问题。
• 客户端应考虑缓存经常请求且变化合理的键，同时注意处理 TTL 等问题以合理使用内存。
  重要细节：
• 通常客户端缓存的两个优势是数据延迟小和数据库系统接收的查询少。
• 在默认模式下，服务器记住每个客户端在连接生命周期内请求的键，键修改时向可能缓存该键的客户端发送失效消息。
• 服务器用一个名为无效表（Invalidation Table）的全局表记录可能缓存给定键的客户端列表，以限制内存使用和处理数据结构的 CPU 成本。
• 在广播模式中，客户端订阅键前缀，每次匹配前缀的键被修改时接收失效消息，服务器使用前缀表处理，可优化为对订阅同一前缀的所有客户端发送相同回复以降低 CPU 使用率。
• 当使用两个连接模式时，可在启用跟踪时指定将失效消息重定向到另一个连接，RESP2 和 RESP3 在处理失效消息的方式上有所不同。
• 准入缓存方式下，客户端需显式告知服务器要缓存的键，使用 CLIENT CACHING YES 命令；退出缓存方式下，默认自动缓存所有键，可使用 CLIENT UNTRACKING 命令排除特定键。
• 为避免竞态条件，在发送 GET 命令时可先在客户端缓存中设置占位符，收到失效消息后再删除。
• 失去与服务器的连接时，要确保刷新本地缓存，定期 ping 无效通道，若无法接收回复则关闭连接并刷新缓存。
• 客户端应运行内部统计以了解缓存键的使用情况，简单客户端可通过随机抽样等方式处理缓存数据。
• 实现客户端库时要注意处理 TTL，为每个键设置最大 TTL 以防数据陈旧，同时要限制客户端使用的内存量。