caching - 构造唯一性由 6 个属性定义的缓存键的最佳方法

Question

目前，我的任务是为价格取决于许多因素的类似电子商务的系统修复缓存。缓存后端是redis。对于给定的产品，影响价格的因素是:

库存

channel

子 channel

计划

日期

目前redis中缓存的结构是这样的:

product1_channel1_subchannel1:  {sku_1:  {plan1: {2019-03-18: 2000}}}

API 可满足对多种产品、SKU 和上述所有因素的请求。所以他们决定查询一个 product_channel_subchannel 级别的所有数据，并过滤非常慢的应用程序中的数据。他们还决定，在缓存未命中时，他们将为所有 SKU 构建 90 天数据的缓存。这样只有一个请求将面临愤怒，而其他请求则从中受益(唯一的问题是现在我们更频繁地破坏缓存，这也拖累了系统)

在键中包含所有这些因素的缺点是键太多。大概有 400 种产品，每种产品由 20 个 SKU 组成，具有 20 个 channel 、200 个子 channel 、3 种计划和 400 天的定价。为了避免在某个地方出现这么多键，我们必须对数据进行分组。

系统目前收到大约 10 个 rps，必须在 100 毫秒内做出响应。

问题是:

上面的缓存结构可以吗？或者我们如何着手扁平化这种结构？

缓存通常如何存储在定价系统中。我觉得这是一项非常微不足道的任务，但我发现很难证明我的方法是正确的

为大量数据牺牲一个热缓存请求是否可以？还是有缓存预热策略更好？

Answer 1

任何类型的缓存策略都需要权衡取舍。您需要做出的精确权衡取决于复杂的领域逻辑，您在尝试之前无法预测。

这意味着无论您实现什么，都应该基于数据，并且应该足够灵活，能够随着业务的变化而随时间变化。特别是这些问题的答案:

Is it okay to sacrifice one request to warm cache for bulk of the data? Or is it better to have a cache warming strategy?

取决于您的用户将如何查询数据以及缓存未命中需要多长时间。如果查询倾向于以可预测的方式聚集在某些 SKU 或某些日期周围，那么您应该使用该信息来帮助指导缓存命中和未命中。

如果不进行适当的实验，我或其他任何人都无法给您正确的答案，但我们可以为您提供一些指导。

以下是我在使用 Redis 进行缓存时推荐的一些最佳实践:

1. 如果瓶颈是将数据从 redis 发送到 api，那么请考虑使用 lua 脚本在任何数据离开 redis 之前进行简单处理。但是，请注意不要让脚本过于复杂，因为长时间运行的 lua 脚本会阻塞 redis 的所有其他部分

2. 看起来您正在使用简单的获取/设置键来存储您的数据。考虑使用更复杂的东西:

   一个。如果您想按日期更好地访问数据(使用日期作为分数)，请使用排序集(zsets)。b.使用哈希集来更细粒度地访问 skus

3. 根据您的问题，您似乎将拥有大约 160 万个 key 。这不是一个很大的数量，但是您需要确保 redis 有足够的内存来将所有内容存储在 ram 中，而无需将任何内容交换到磁盘。这是我们必须通过艰难的方式学习的东西。如果您在 Linux 上运行您的 Redis 实例，您必须将系统的 swappiness 设置为 0，以确保永远不会使用交换。

但是，最重要的是，您需要尝试一切，直到找到好的解决方案。