我想知道 memcached 中的短超时（60 秒）是否会对性能产生任何负面影响，VS 更长的超时，但忽略返回的值（如果它是在 60 秒前存储的）。
有很多缓存未命中（如果该项目已被删除）会对性能产生影响吗？
快速说明：如果缓存未命中，我不会重新设置值，只是检查它是否存在
考虑在您的网站上，您希望防止双重操作的情况（例如，在您的网站上单击两次付款按钮，这会注册两次付款。在我们的案例中，我们不处理付款）。
一个简单的技巧是将用户操作在 Memcached 中保留一小段时间——当然有更好的方法可以做到这一点——并检查在最后几秒钟内是否进行了相同的调用。
现在，您可以将缓存设置为短时间，然后检查缓存中是否存在用户的相同操作。或者，将last_user_action缓存设置很长一段时间，以及操作的时间，应用程序可以根据预期的时间段检查时间。
短期的警告是有很多缓存删除（过期键）和很多缓存未命中（因为项目已被删除）。更长的时间只会使用更多的内存。
所以，我想知道大量删除（过期元素）和缓存未命中的开销。
不要对 Lazy Slab 撒谎
您的超时应该与您的应用程序希望返回条目的超时完全匹配（只要您可以接受 1-2 秒的不确定性。）您不会显着增加内存缓存内部遇到的缓存未命中数量，或者在许多条目过期时导致某种形式的阻塞同时。但是您将允许 memcache 停止处理并返回您的应用程序只需要丢弃的项目。
您可以在监控中找到对 memcached 行为的描述：为什么 curr_items 在项目过期时不减少？本质上，它对过期条目没有任何作用，而是：
过期物品遇到：
得到
不要退回并标记为免费
店铺
总是先运行获取逻辑，所以现在它可以重用项目的空间
LRU 驱逐（由存储在完整缓存上触发）
不要增加驱逐统计数据，因为该项目已过期。
Motivated Slab Crawler 寻求 CPU 和锁竞争？
常见问题解答没有提到您现在可以选择拥有一个 LRU 爬虫线程，但是平板分配器的本质是该线程具有相对较小的开销“释放”过期条目，并且通过简化其后续遍历来回报工作.
不要忘记 memcache 是一个 LRU 缓存
始终警惕触发不必要的 LRU 驱逐：
如果您还共享具有相似大小但寿命更长的条目的缓存，您可能会导致它们被驱逐（这是可选爬虫旨在防止的。）
如果您允许ops * seconds * slab_size(entry)接近缓存大小，条目将在到期日期之前开始消失。
但是您可以在驱逐统计中观察到这一点，并且可以使用人工流量和/或按比例减少缓存空间进行测试。
如果它重新启动，（或您的配置更改，或在应用程序实例之间不同步，或......？）您可能找不到在缓存用例中不是问题的条目，但在您的情况下，您会有小心在延迟期间禁止操作。
鉴于 (1) 和 (2)，我可能不会分享一个特殊用例，即该项目不受通用缓存的安全可重复操作的支持。