缓存准入策略对修剪分布式缓存写入有用吗
Can cache admission strategy be useful to prune distributed cache writes
假设一些分布式 CRUD 服务使用非通读的分布式缓存（只是一些与数据库无关的键值存储）。所以有 n 个服务器节点连接到 m 个缓存节点（轮询作为路由）。缓存应该缓存存储在数据库层中的数据。
所以默认的检索顺序好像是：
- 检查数据是否在缓存中，如果是 return 数据
- 否则从数据库中获取
- 将数据发送到缓存（缓存逐出）
- return数据
问题是各个服务节点是否可以更智能地了解将哪些数据发送到缓存，以降低缓存容量成本（以更少的缓存存储实现类似的命中率 space）。
鉴于最近关于最佳 eviction/admission 策略 (in particular LFU) 的基准测试，一些新的缓存如果被认为太不经常使用，甚至可能不会存储数据，也许应用程序节点可以做一些尽力而为的猜测。
所以我的想法是，各个服务节点可以根据LFU之类的算法评估是否应该将从数据库中获取的数据发送到分布式缓存，从而减少服务和缓存之间的网络流量。我正在考虑本地检查（在冷启动时缺乏有效性），但也可以考虑对缓存密钥的共享列表进行检查。
所以顺序是
- 检查数据是否在缓存中，如果是 return 数据
- 否则从数据库中获取
- 检查data key是否被频繁使用
- 如果是，将数据发送到缓存（缓存进行逐出）。否则不行。
- return数据
这样可行吗，合理吗，有没有做过？
在数据库、搜索和分析产品中很常见的是用过滤器来保护他们的 LRU 缓存，以避免扫描造成的污染。例如，参见 Postgres 的 Buffer Ring Replacement Strategy and ElasticSearch's filter cache。这些是与缓存本身分离的准入策略，如果它们的缓存算法更智能，则可以替换它们。听起来你的想法很相似，除了一个分布式版本。
大多数远程/分布式缓存使用经典的逐出策略（LRU、LFU）。这没关系，因为它们通常过大，例如Twitter 需要 99.9% hit rate 作为他们的 SLA 目标。这意味着他们可能不会掉落最近的物品，因为惩罚太高而且太大，以至于受害者是古代人。
但是，breaks down 当批处理作业 运行 并污染远程缓存层时。在这些情况下，禁用缓存填充以避免影响用户请求的情况并不少见。这就是上述 Postgres 问题的分布式变体。
您的想法最大的缺点是检查商品的受欢迎程度。这可能只是本地的，它经常出现冷启动问题，或者是添加网络跃点的远程调用。该远程呼叫比运送物品的流量便宜，但您不太可能受到带宽限制。可能您的目标是通过更高的命中率来降低容量成本，但如果您的 SLA 需要近乎完美的命中率，那么您无论如何都会过度配置。这完全取决于通过减少缓存端填充操作获得的收益是否值得实施工作。我怀疑大多数情况下都没有。
假设一些分布式 CRUD 服务使用非通读的分布式缓存（只是一些与数据库无关的键值存储）。所以有 n 个服务器节点连接到 m 个缓存节点（轮询作为路由）。缓存应该缓存存储在数据库层中的数据。
所以默认的检索顺序好像是：
- 检查数据是否在缓存中，如果是 return 数据
- 否则从数据库中获取
- 将数据发送到缓存（缓存逐出）
- return数据
问题是各个服务节点是否可以更智能地了解将哪些数据发送到缓存，以降低缓存容量成本（以更少的缓存存储实现类似的命中率 space）。 鉴于最近关于最佳 eviction/admission 策略 (in particular LFU) 的基准测试，一些新的缓存如果被认为太不经常使用，甚至可能不会存储数据，也许应用程序节点可以做一些尽力而为的猜测。
所以我的想法是，各个服务节点可以根据LFU之类的算法评估是否应该将从数据库中获取的数据发送到分布式缓存，从而减少服务和缓存之间的网络流量。我正在考虑本地检查（在冷启动时缺乏有效性），但也可以考虑对缓存密钥的共享列表进行检查。
所以顺序是
- 检查数据是否在缓存中，如果是 return 数据
- 否则从数据库中获取
- 检查data key是否被频繁使用
- 如果是，将数据发送到缓存（缓存进行逐出）。否则不行。
- return数据
这样可行吗，合理吗，有没有做过？
在数据库、搜索和分析产品中很常见的是用过滤器来保护他们的 LRU 缓存，以避免扫描造成的污染。例如，参见 Postgres 的 Buffer Ring Replacement Strategy and ElasticSearch's filter cache。这些是与缓存本身分离的准入策略，如果它们的缓存算法更智能，则可以替换它们。听起来你的想法很相似，除了一个分布式版本。
大多数远程/分布式缓存使用经典的逐出策略（LRU、LFU）。这没关系，因为它们通常过大，例如Twitter 需要 99.9% hit rate 作为他们的 SLA 目标。这意味着他们可能不会掉落最近的物品，因为惩罚太高而且太大，以至于受害者是古代人。
但是，breaks down 当批处理作业 运行 并污染远程缓存层时。在这些情况下，禁用缓存填充以避免影响用户请求的情况并不少见。这就是上述 Postgres 问题的分布式变体。
您的想法最大的缺点是检查商品的受欢迎程度。这可能只是本地的，它经常出现冷启动问题，或者是添加网络跃点的远程调用。该远程呼叫比运送物品的流量便宜，但您不太可能受到带宽限制。可能您的目标是通过更高的命中率来降低容量成本，但如果您的 SLA 需要近乎完美的命中率，那么您无论如何都会过度配置。这完全取决于通过减少缓存端填充操作获得的收益是否值得实施工作。我怀疑大多数情况下都没有。