Redis 创始人兼核心开发者 antirez 在博客介绍了将在 Redis 6 提供的新功能 —— Client side caching（客户端缓存）。
antirez 表示全新的 Redis 协议 RESP3 将是 Redis 6 中最重要的特性，并解释了他为何如此急切地改进 Redis 协议，原因主要有两个，一是因为希望能为客户端提供更多的语义化响应（semantical replies），以开发使用旧协议难以实现的功能；另一个原因也是 antirez 认为最重要的一个，实现 Client side caching（客户端缓存）功能。这个功能十分常见，但 Redis 尚未提供。
当使用者需要进行快速存储或快速取操作时，就需要在客户端内存中存储一小部分信息，这是为了降低程序获取数据时的延迟。此功能在大规模的应用程序上十分重要，因为数据离应用程序越近，程序就能更快获取到数据。
antirez 受 Ben Malec 演讲的启发，他想到可以将大部分需要频繁存和取的数据直接放在服务器的内存中，以便让 Redis 为客户端完成部分工作，并使客户端缓存更简单、更有效。这个就是 Client side caching（客户端缓存）的概念。
不过这个思路有一个需要解决的问题是，如何控制数据的有效时间？在程序允许的情况下，虽然可以直接设置数据的有效时间，让数据在一段时间后失效。但 antirez 表示，大多数的应用程序无法接受提供过时的数据的风险，因此必须找到更理想的方案来控制数据的失效时间。
所以 antirez 决定开发新的协议 RESP3，在协议中加入新特性来支持客户端缓存功能，保证存储在客户端内存的数据，在收到来自服务器的失效通知时才失效。
另外，当客户端和服务器的连接中断时，客户端无法接收到数据失效通知，这可能会导致服务出现问题。针对这种情况，一般的做法是重新建立客户端和服务器之间的连接，并更新客户端当前的缓存。antirez 表示可以一直保持连接是最好的情况，但为了降低风险，Redis 服务器在与客户端断开连接时，会将失效通知发送给其他客户端。
这项名为"Client side caching"的功能尚未正式确定名字，最后可能会被成为"Tracking"。Redis 作者还表示在 Redis 6 候选版发布之前，这些功能都会进行调整，希望社区能积极反馈意见。
由于 Client side caching 功能需要使用 RESP3 协议来支持实现，antirez 表示会想办法通过 RESP2 协议也能启用此功能。
猜你喜欢: