缓存与会话存储

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

有句谚语说：“在硅谷，你朝任何方向扔一块石头，都可能会砸到一名软件工程师。” 前几天，我从圣何塞坐火车去旧金山，听到两位软件工程师比较他们开发的产品的速度。当我听到一位开发人员说：“我们的应用程序运行很快，因为我们缓存了所有会话数据。” 时，我意识到，即使是硅谷的工程师也可能不知道缓存和会话存储之间的细微差别。 Redis 作为内存数据库，用于缓存和会话存储场景。让我们看看这些用例有何不同。

缓存

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

在数据获取生命周期中，应用程序首先在缓存中查找数据。如果命中（即数据在缓存中），则会立即提供数据。相反，如果未命中，则会从永久存储中获取数据，将副本存储在缓存中，并将数据提供给消费者。对于所有未来的请求，数据已经存在于缓存中，并且可以更快地提供。当应用程序更新数据时，它会更新缓存和永久存储。

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

会话存储

面向会话的应用程序（例如 Web 应用程序）在用户登录时启动会话，并在用户注销或会话超时之前处于活动状态。在此期间，应用程序将所有与会话相关的数据存储在主内存或会话存储中——一种数据库，当应用程序关闭时不会丢失数据。会话数据可能包括用户配置文件信息、消息、个性化数据和主题、推荐、目标促销和折扣等。

图 1. 缓存与会话存储

以下几点对比了会话存储与缓存

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

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

Redis Enterprise 是一种流行的数据库，非常适合缓存和会话存储用例，既能提供缓存和会话存储场景所需的高可用性，又能提供会话存储所需的持久性，并具有内存复制功能。可以使用 Redis Enterprise 在单个设置中作为缓存和会话存储，如下图所示。

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

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

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

session_data:(session_id):personal_info name - John Smith email - john@smith.com phone - 987-111-1111

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

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