缓存 vs. 会话存储

在保持低延迟的同时在全球范围内扩展，并更高效地缓存以降低成本：点击此处与 Redis Enterprise 团队交谈。

有句俗话说：“在硅谷，你随便朝哪个方向扔块石头，很可能会砸中一个软件工程师。”前几天我乘坐火车从圣何塞前往旧金山时，无意中听到两位软件工程师正在比较他们正在开发的产品速度。当我听到一位开发者说“我们的应用运行很快，因为我们缓存了所有的会话数据”时，我意识到即使是硅谷的工程师也可能没有意识到缓存和会话存储之间的细微差异。Redis 作为一种内存数据库，既可用于缓存场景，也可用于会话存储场景。让我们来看看这两种用例有何不同。

缓存

应用程序将数据存储在缓存中，以更快地响应未来的请求。通常，缓存存储位于 RAM 中，延迟低于毫秒。

在数据获取生命周期中，应用程序首先在缓存中查找数据。如果命中（即数据在缓存中），它会立即提供数据。反之，如果未命中，它会从永久存储中获取数据，将副本存储到缓存中，然后将数据提供给消费者。对于所有未来的请求，数据已存在于缓存中，因此提供速度更快。当应用程序更新数据时，它会同时更新缓存和永久存储。

这种生命周期非常适用于不同消费者在一段时间内请求相同数据的场景。还应注意，数据存储在应用程序级别，而不是用户级别。因此，存储在缓存中的数据在用户之间共享。图像、视频、静态 HTML 页面、JavaScript 库和样式表是经常存储在缓存中的数据示例。

会话存储

面向会话的应用程序（例如 Web 应用程序）在用户登录时启动一个会话，该会话一直处于活动状态，直到用户注销或会话超时。在此期间，应用程序将所有与会话相关的数据存储在主内存或会话存储中——会话存储是一种数据库，即使应用程序崩溃也不会丢失数据。会话数据可能包括用户个人资料信息、消息、个性化数据和主题、推荐、定向促销和折扣等。

图 1. 缓存 vs. 会话存储

以下几点将会话存储与缓存进行对比

在会话存储中，不同用户的会话之间不共享数据。解决方案架构必须确保数据在用户之间保持隔离。
如上图所示，数据在缓存和会话存储之间的生命周期不同。该图显示了一个直写式缓存，它同时写入缓存和后端数据存储。这降低了写操作的吞吐量。另一方面，会话存储依赖于对内存数据库的读写。它们无法承受在写操作性能上的妥协。
会话存储数据不是短暂的；会话处于活动状态时，它是唯一的数据来源。因此，它需要满足真正数据库的数据持久性要求。如果缓存中的数据丢失，永久存储中总会有一个副本。
会话存储需要复制、高可用性和数据持久性，以确保事务数据不会丢失。而缓存的高可用性要求则由操作需求驱动，旨在防止缓存雪崩。

使用 Redis Enterprise 设计缓存和会话存储

Redis Enterprise 是一个非常流行的数据库，非常适合缓存和会话存储用例，它既能提供缓存和会话存储场景所需的高可用性，也能通过内存复制提供会话存储所需的数据持久性。可以在单个设置中同时将 Redis Enterprise 用作缓存和会话存储，如下图所示。

图 2. 使用 Redis Enterprise 设计缓存和会话存储

在此设计中，应用层访问并维护缓存中的数据。因此，应用程序内部运行的所有会话都访问存储在缓存中的相同数据。

除了缓存中的数据外，每个会话都在 Redis Enterprise 中保存与会话相关的数据。如何确保会话不会访问彼此的数据呢？这里有一个解决方案：首先，每个会话都必须获取一个不与其他会话共享的随机会话 ID。其次，会话必须将该会话 ID 添加到键中。在下面的示例中，一个会话将个人信息存储在 Hash 数据结构中，将用户推荐存储在 Set 数据结构中。您可能会注意到，键中包含了会话 ID。这可以防止会话访问其他会话拥有的数据。

session_data:(session_id):personal_info name - John Smith email - [email protected] phone - 987-111-1111

session_data:(session_id):recommendations {“product a”, “product b”, “product c”,.....“product n”}

总之，缓存和会话存储是两种不同的用例。虽然高可用性对于缓存来说很重要，可以防止缓存雪崩等情况，但会话存储需要高可用性和持久性来支持事务数据和不间断的用户交互。通过适当的架构和设计，Redis Enterprise 的单个数据库实例既可用于缓存，也可用于会话数据用例，同时确保会话之间的数据隔离。