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