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