很多同学可能熟知Memcached的LRU淘汰算法，它是在slab内部进行的，如果所有空间都被slabs分配，即使另外一个slab里面有空位，仍然存在踢数据可能。你可以把slab理解为教室，如果你的教室满了，即使别的教室有空位你的教室也只能踢人才能进人。
本文介绍的却是另外一种现象。今天监控发现线上一memcached发生数据被踢现象，用stats命令看evictions>0,因为以前也出现过此问题，后来对这个参数增加了一个监控，所以这次主动就发现了。由于给memcached分配的内存远大于业务存储数据所需内存，因此初步判断是“灵异现象”。
第一步，netstat查看所有连接，排除是否被一些未规划的client使用，经排查后断定无此可能。
第二步，用tcpdump抽样检查set的指令，排除是否有忘记设cache过期时间的client，初步检查所有典型的业务都有expire time。
第三步，Google，未果
第四步，看源代码，了解evictions计数器增加时的具体细节，oh, no…
in items.c, memcached-1.2.8,
125 for (search = tails[id]; tries > 0 && search != NULL; tries--, search=search->prev) {
126 if (search->refcount == 0) {
127 if (search->exptime == 0 || search->exptime > current_time) {
128 itemstats[id].evicted++;
129 itemstats[id].evicted_time = current_time - search->time;
130 STATS_LOCK();
131 stats.evictions++;
132 STATS_UNLOCK();
133 }
134 do_item_unlink(search);
135 break;
136 }
137 }
从源代码发现踢数据只判断一个条件，if (search->refcount == 0)，这个refcount是多线程版本计数用，在当前服务器未启用多线程情况下，refcount应该始终为0,因此初步判断memcached是从访问队列尾部直接踢数据。
为了证实想法，设计以下场景：
- 部署一个memcached测试环境，分配比较小的内存，比如8M
- 设置1条永远不过期的数据到memcached中，然后再get一次，这条数据后续应该存在LRU队尾。
- 每隔1S向memcached set(并get一次) 1,000条数据，过期时间设为3秒。
- 一段时间后，stats命令显示evictions=1
按我以前的理解，第2步的数据是永远不会被踢的，因为有足够过期的数据空间可以给新来的数据用，LRU淘汰算法应该跳过没过期的数据，但结果证实这种判断是错误的。以上业务的服务器发生被踢的现象是由于保存了大量存活期短的key/value,且key是不重复的。另外又有一业务保存了小量不过期的数据，因此导致不过期的数据惨遭被挤到队列踢出。
本来这个问题就告一段落了，但在写完这篇文章后，顺便又看了新一代memcached 1.4.1的源代码，很惊喜发现以下代码被增加。
items.c, memcached 1.4.1
107 /* do a quick check if we have any expired items in the tail.. */
108 int tries = 50;
109 item *search;
110
111 for (search = tails[id];
112 tries > 0 && search != NULL;
113 tries--, search=search->prev) {
114 if (search->refcount == 0 &&
115 (search->exptime != 0 && search->exptime < current_time)) {
116 it = search;
117 /* I don't want to actually free the object, just steal
118 * the item to avoid to grab the slab mutex twice ;-)
119 */
120 it->refcount = 1;
121 do_item_unlink(it);
122 /* Initialize the item block: */
123 it->slabs_clsid = 0;
124 it->refcount = 0;
125 break;
126 }
127 }
重复进行上述测试，未发生evictions。
9/8 Update: 注意到L108的tries=50没有？试想把测试第2步设置51条不过期数据到cache中，情况会怎样？因此新版的Memcached也同样存在本文描述问题。
几条总结：
- 过期的数据如果没被显式调用get，则也要占用空间。
- 过期的不要和不过期的数据存在一起，否则不过期的可能被踢。
- 从节约内存的角度考虑，即使数据会过期，也不要轻易使用随机字符串作为key，尽量使用定值如uid，这样占用空间的大小相对固定。
- 估算空间大小时候请用slab size计算，不要按value长度去计算。
- 不要把cache当作更快的key value store来用, cache不是storage。
如果每个应用都有自己独立的memcache集群就不会触发这个问题。
不过运维复杂了。
晕。memcached文档中都有写，lazy expiration logic。expires与LRU无关。
事实上你后面的补充是错误的吧，哪怕把测试第2步设置51条不过期数据到cache中，也不会发生数据被踢现象的，测试证明。原因在于do_item_unlink(it);
调用的条件原来只判断refcount，现在还加上了(search->exptime != 0 && search->exptime < current_time)，变成了同一个if语句，而非原来的两个。
咳咳，原因说错了，是因为没有统计
stats.evictions++;
才对。
请问下楼主有没有遇到过，memcache 的连接不断开的，就是请求完数据，连接不断开，导致httpd进程不断增多
楼上的原因是因为客户端没有调用quit命令吧。看过memcached的源码好像没有自动断开连接的。
是啊 我就设置了永不过期， 一天以后就失效了！ 原来是这样子！
memcached-1.4.15 变成了只检查一个了，注意最后边的break
/* We walk up *only* for locked items. Never searching for expired.
* Waste of CPU for almost all deployments */
for (; tries > 0 && search != NULL; tries–, search=search->prev) {
uint32_t hv = hash(ITEM_key(search), search->nkey, 0);
…
break;
}
所以不过期的数据还是不要跟过期数据放一起好
这个refcount是多线程版本计数用，在当前服务器未启用多线程情况下，refcount应该始终为0。这个理解有问题吧！！！
refcount表示引用计数，即使是单线程也不可能永远为0的。
明智的人决不坐下来为失败而哀号，他们一定乐观地寻找办法来加以挽救。
如果每个应用都有自己独立的memcache集群就不会触发这个问题. 咳咳，原因说错了，是因为没有统计
如果每个应用都有自己独立的memcache集群就不会触发这个问题. 咳咳，原因说错了，是因为没有统计
楼上的原因是因为客户端没有调用quit命令吧。看过memcached的源码好像没有自动断开连接的。
refcount应该始终为0。这个理解有问题吧！！！
refcount表示引用计数，即使是单线程也不可能永远为0的。
如果每个应用都有自己独立的memcache集群就不会触发这个问题。
당신이 공유하는 것들은 훌륭합니다. 나는 모든 좋은 것들이 당신에게 올 것이기를 바랍니다. 감사합니다.
顺便又看了新一代memcached 1.4.1的源代码，很惊喜发现以下代码被增加。
I feel completely satisfied after reading your post,Your posts makes me internally happy and gives me lots of the pleasure.
Some of the nutrients that certain superfoods contain include antioxidants, thought to ward off cancer; healthy fats, thought to prevent heart disease; fiber, thought to prevent diabetes and digestive problems; or phytochemicals, the chemicals in plants responsible for deep colors and smells, which can have numerous health benefits.
Blueberries
Your share is the great knowledge I have gathered, you are an important person I admire, thank you
There are no words that can express my thanks to you. If words could be hugs I would send you pages. Thank you for this amazing post. We must find time to stop and thank the people who make a difference in our lives. Once Again Thank You So Much!
If each of the machines has its own independent memcache cluster the problem will not triggered for sure.
Machines need a memcache to act independently
事实上你后面的补充是错误的吧，哪怕把测试第2步设置51条不过期数据到cache中，也不会发生数据被踢现象的，测试证明。原因在于do_item_unlink(it);
调用的条件原来只判断refcount，现在还加上了(search->exptime != 0 && search->exptime < current_time)，变成了同一个if语句，而非原来的两个。
Great post! I agree that reading and commenting on a lot of blogs really helps move your blog along.
good post
Great post! I agree that reading and commenting on a lot of blogs really helps move your blog along.
Good Quality Cotnent
good post.
“Samguk Jeongbeol” is a web strategy game that enables strategic play at the national level, such as forming a corps centered on the masters of the Three Kingdoms and attacking several regions at the same time or defending an area of Lineage 투데이서버
Thank you for being the reason I smile
https://printdailycalendar.com/cute-september-2022-calendar/
great post. https://www.towingbelleville.com/trenton-towing-24/7 thanks
Thank you for being the reason I smile.
https://printdailycalendar.com/october-2022-calendar-template/
Thank you for this amazing post. We must find time to stop and thank the people who make a difference in our lives. interior house painting contractor Philadelphia Pennsylvania
Great post. This is valuable information and it did help me! Thanks
Staircase Style
Thanks for enlightening me on the memcached cluster issues.
Retaining Wall Construction
This is big help for my assignment! Thanks for article!
Nanaimo Retaining
I think you did a great approach to solve this. Great job!
Margarita | https://www.drywallaugusta
Fantastic data. This helps me with my current situation right now Anchored Retaining Wall
Quality articles, rich in information, well-researched, and deep analyzes!!! Thank you for all the posts you share in your ARTICLE St Louis Property Management Company
Great Content. Valuable information!
Amazing information. Content is top notch! Construction Project
Just a heads up – if you have a separate memcache cluster for each application, you can avoid this problem altogether. However, it’s worth noting that fixing a website and managing multiple clusters can be a bit of a hassle.
Dish soap and car wash soap are both good options. However, car wash soap may be more economical and easier to use. pressure cleaning after flood
If each application has its own independent memcache cluster, this problem will not be triggered.
Fred
https://www.montgomerydrywall
i cant believe this. such a wonderful to actually be able to read. i wish blind people were to see this masterpiece
This is amazing thanks for sharing this blog I have become a fan of your blogs now. This blog is so interesting and informative.
素晴らしい分析です！MemcachedのLRU削除における重要なニュアンス、すなわち期限切れデータがメモリ使用と削除に影響を与えることが浮き彫りになっています。このソースコードの詳細な調査は、削除がどのように発生するかを明確にするとともに、不要なデータ損失を防ぐためのキャッシュ戦略の最適化に役立つ洞察を提供しています。
I feel so smart by following your tips! Cheers from Marietta!