Redis 6 客户端缓存

小令童鞋 梅干菜你个小酥饼哦。 本文由博客端 https://www.zeekling.cn 主动推送
本贴最后更新于 279 天前,其中的信息可能已经物是人非

Redis 服务器辅助的客户端缓存

客户端缓存是一种用于创建高性能服务的技术。它利用应用服务器中的可用内存,这些服务器通常是与数据库节点不同的计算机,以便将数据库信息的某些子集直接存储在应用程序端。

通常当需要一些数据时,应用服务器会向数据库询问这些信息,如下图所示:

+-------------+                                +----------+
|             | ------- GET user:1234 -------> |          |
| Application |                                | Database |
|             | <---- username = Alice ------- |          |
+-------------+                                +----------+

当使用客户端缓存时,应用程序将直接在应用程序内存中存储流行查询的答复,以便以后可以重用这些答复,而无需再次联系数据库。

+-------------+                                +----------+
|             |                                |          |
| Application |       ( No chat needed )       | Database |
|             |                                |          |
+-------------+                                +----------+
| Local cache |
|             |
| user:1234 = |
| username    |
| Alice       |
+-------------+

虽然用于本地缓存的应用程序内存可能不是很大,但是访问本地计算机内存所需的时间比请求数据库之类的网络服务要小几个数量级。由于经常非常频繁地访问同一小部分数据,因此这种模式可以大大减少应用程序获取数据的延迟,同时也减少数据库端的负载。

此外,有许多数据集中的项很少更改。例如,社交网络中的大多数用户帖子要么是不可变的,要么很少被用户编辑。再加上一个事实,通常只有一小部分的帖子非常受欢迎,要么是因为一小部分用户有很多关注者,要么是因为最近的帖子有更多的可见性,这就很清楚为什么这种模式非常有用。

通常,客户端缓存的两个主要优点是:

存在问题

上述模式的一个问题是如何使应用程序所保存的信息无效,以避免向用户呈现过时的数据。例如,在上面的应用程序本地缓存用户:1234 信息,Alice 可能会将她的用户名更新为 Flora。然而,应用程序可能继续为用户 1234 提供旧用户名。

根据我们所建模的应用程序的具体情况,这个问题并不是什么大问题,因此客户机只会使用固定的最大“生存时间”来存储缓存的信息。一旦经过给定的时间,信息将不再被视为有效。在使用 Redis 时,更复杂的模式利用 Pub/Sub 系统向监听的客户端发送无效消息。这是可以实现的,但是从所使用的带宽的角度来看,这是非常棘手和昂贵的,因为这样的模式通常涉及到向应用程序中的每个客户端发送无效消息,即使某些客户端可能没有无效数据的任何副本。此外,每个更改数据的应用程序查询都需要使用 PUBLISH 命令,这会使数据库花费更多的 CPU 时间来处理该命令。

不管使用什么模式,有一个简单的事实:许多非常大的应用程序实现某种形式的客户端缓存,因为这是拥有快速存储或快速缓存服务器的下一个逻辑步骤。为此,redis6 实现了对客户端缓存的直接支持,以使该模式实现起来更简单、更易访问、更可靠、更高效。

客户端缓存的 Redis 实现

Redis 客户端缓存支持称为跟踪,有两种模式:

回顾一下,现在让我们暂时忘掉广播模式,集中讨论第一种模式。稍后我们将更详细地描述广播。

这是协议的一个例子:

Client 1 -> Server: CLIENT TRACKING ON
Client 1 -> Server: GET foo
(The server remembers that Client 1 may have the key "foo" cached)
(Client 1 may remember the value of "foo" inside its local memory)
Client 2 -> Server: SET foo SomeOtherValue
Server -> Client 1: INVALIDATE "foo"

从表面上看,这看起来很不错,但是如果你认为,在每一个长时间连接的故事中,有 10k 个连接的客户端都需要数百万个密钥,那么服务器最终会存储太多的信息。为此,Redis 使用了两个关键思想来限制服务器端的内存使用量,以及处理实现该功能的数据结构的 CPU 成本:

双连接方式

使用 Redis 6 支持的新版 Redis 协议 RESP3,可以在同一连接中运行数据查询和接收失效消息。然而,许多客户端实现可能更喜欢使用两个独立的连接来实现客户端缓存:一个用于数据,另一个用于无效消息。因此,当客户端启用跟踪时,它可以指定通过指定不同连接的“客户端 ID”将无效消息重定向到另一个连接。许多数据连接可以将无效消息重定向到同一个连接,这对于实现连接池的客户端很有用。双连接模型是唯一支持 RESP2 的模型(它缺乏在同一连接中复用不同类型信息的能力)。

我们将展示一个例子,这一次在旧的 RRESP2 模式下使用实际的 Redis 协议,如何完成会话,包括以下步骤:启用跟踪重定向到另一个连接,请求密钥,以及在该密钥被修改后获得无效消息。

首先,客户机打开第一个将用于失效的连接,请求连接 ID,并通过 Pub/Sub 订阅用于在 RESP2 模式下获取失效消息的特殊通道(记住 RESP2 是通常的 Redis 协议,而不是可以与 Redis 一起使用的更高级的协议)6 使用 HELLO 命令):

(Connection 1 -- used for invalidations)
CLIENT ID
:4
SUBSCRIBE __redis__:invalidate
*3
$9
subscribe
$20
__redis__:invalidate
:1

现在我们可以从数据连接启用跟踪:

(Connection 2 -- data connection)
CLIENT TRACKING on REDIRECT 4
+OK

GET foo
$3
bar

客户机可能决定在本地内存中缓存“foo”=>“bar”。

另一个客户端现在将修改“foo”键的值:

(Some other unrelated connection)
SET foo bar
+OK

因此,失效连接将接收一条消息,使指定的键失效。

(Connection 1 -- used for invalidations)
*3
$7
message
$20
__redis__:invalidate
*1
$3
foo

客户端将检查这种缓存槽中是否有缓存的密钥,并将逐出不再有效的信息。

请注意,发布/订阅消息的第三个元素不是一个键,而是一个只有一个元素的 Redis 数组。因为我们发送了一个数组,如果有一组键要失效,我们可以在一条消息中完成。

要了解 RESP2 使用的客户端缓存和用于读取无效消息的 Pub/Sub 连接的一个非常重要的事情是,为了重用旧的客户端实现,使用 Pub/Sub 完全是一个技巧,但实际上消息并不是真正发送到一个通道并由订阅它的所有客户端接收。只有我们在 CLIENT 命令的 REDIRECT 参数中指定的连接才会真正接收 Pub/Sub 消息,这使得特性更具可伸缩性。

当改为使用 RESP3 时,无效消息将作为推送消息发送(在同一连接中,或者在使用重定向时在辅助连接中发送)(有关详细信息,请阅读 RESP3 规范)。

什么跟踪记录

默认情况下,客户机不需要告诉服务器它们正在缓存哪些密钥。服务器会跟踪只读命令上下文中提到的每个键,因为它可以被缓存。

这样做的明显优点是不需要客户机告诉服务器它在缓存什么。此外,在许多客户机实现中,这正是您所希望的,因为一个好的解决方案可以是使用先进先出的方法缓存所有尚未缓存的对象:我们可能希望缓存固定数量的对象,我们检索到的每一个新数据都可以缓存它,丢弃最旧的缓存对象。更高级的实现可能会放弃使用最少的对象或类似对象。

请注意,不管怎样,如果服务器上有写流量,缓存槽将在这段时间内失效。一般情况下,当服务器假定我们得到的东西也要缓存时,我们正在权衡:

  • 翻译
    53 引用 • 81 回帖
  • Redis

    Redis 是一个开源的使用 ANSI C 语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库,并提供多种语言的 API。从 2010 年 3 月 15 日起,Redis 的开发工作由 VMware 主持。从 2013 年 5 月开始,Redis 的开发由 Pivotal 赞助。

    250 引用 • 244 回帖 • 568 关注
  • 转载

    转载的帖子不会出现在社区全局列表上。

    9 引用 • 62 回帖

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...