假设某些分布式CRUD服务使用非直通的分布式缓存（只是某些键值存储与数据库无关）。因此，有n个服务器节点连接到m个缓存节点（循环作为路由）。缓存应该缓存存储在DB层中的数据。
因此默认检索序列似乎是：
问题在于各个服务节点是否可以更智能地发送到缓存的数据，以降低缓存容量成本（实现类似的命中率和较少的所需缓存存储空间）。 鉴于最近关于最佳驱逐/准入策略的基准（in particular LFU），如果认为某些新缓存被认为过于频繁使用，可能甚至不会存储数据，也许应用程序节点可以做出最大努力的猜测。
所以我的想法是各个服务节点可以评估从数据库获取的数据是否应该基于LFU等算法发送到分布式缓存，从而减少服务和缓存之间的网络流量。我正在考虑本地检查（在冷启动时缺乏有效性），但也可以考虑对共享的缓存密钥列表进行检查。
所以序列将是
这是否可行，合理，是否已经完成？
答案 0 :(得分：1)
在数据库，搜索和分析产品中，通常使用过滤器来保护其LRU缓存以避免扫描造成的污染。例如，请参阅Postgres'Buffer Ring Replacement Strategy和ElasticSearch的{{3}}。这些是与缓存本身分离的准入策略，如果它们的缓存算法更加智能化，则可以替换它们。听起来你的想法是相似的，除了分布式版本。
大多数远程/分布式缓存使用经典驱逐策略（LRU，LFU）。这是可以的，因为它们通常过大，例如Twitter需要filter cache作为其SLA目标。这意味着他们可能不会放弃最近的物品，因为惩罚太高而且超大，以致受害者是古老的。
但是，批处理作业运行时会99.9% hit rate并污染远程缓存层。在这些情况下，禁用缓存填充以避免影响用户请求的情况并不少见。这是上述Postgres问题的分布式变体。
您的想法最大的缺点是检查项目的受欢迎程度。这可能只是本地的，有频繁的冷启动问题，或者是远程调用，它会增加网络跃点。该远程呼叫将比运送该项目的流量便宜，但您不太可能受带宽限制。可能你的目标是通过更高的命中率来降低容量成本，但是如果你的SLA需要接近完美的命中率，那么无论如何你都会过度配置。这一切都取决于减少缓存离开人口操作的收益是否值得实施。我怀疑大多数情况都没有。