Memcached之无底洞现象

背景以及概念

无底洞现象是facebook的工作人员反应的，facebook在2010年左右，memcached已经达到3000个，存储着数千G的缓存。
他们发现一个问题：memcached连接频繁，效率下降了，于是加memcached服务器节点，添加后发现因为连接频率导致的问题仍然存在，并没有好转 ===> 称之为“无底洞效应”。

原文见：Facebook’s Memcached Multiget Hole: More Machines != More Capacity

举例说明无底洞现象

memcached在存储数据时，只考虑了Key-Value对，并没有考虑多种Key-Value对之间存在着隐藏的联系；

以会员信息为例：
‘user-133-age’ 22
‘user-133-height’ 170
‘user-89-age’ 60
‘user-89-height’ 182
将上面2个人的数据，采用Key-Value对的方式存放在2个memcached、4个memcached的图示，见下图：

分析存储结果图可以看到 ==>
以用户为例：user-133-age，user-133-height … …N个key，当服务器增多，133号用户的信息也被散落在更多的服务器节点，所以，由于同一个人的信息散落到不同的服务器节点，虽然是访问同一个人的信息，也需要连接更多的服务器节点，因此性能并没有随着服务器节点的增多而降低。

无底洞问题带来的危害：客户端一次批量操作会涉及多次网络操作，也就意味着性能并不会由于memcached服务器节点的增多而提高。（因为服务端网络连接次数变多，对实例的性能也有一定影响。）

解决方案

把某一组key，按照公同的前缀,来分布，比如 user-133-age,user-133-name,user-133-height这个3个key，在用分布式算法求节点时,应该可以用user-133来计算而不是以 user-133-age来计算,这样3个关于个人的信息的key都落到了同一个节点上，点击的访问个人主页的时,只需要连接1个节点。

总结和建议

无底洞问题对资源和性能有一定影响，但是其实大部分系统不需要考虑这个问题，因为

1. 99%公司的数据和流量无法和facebook相比。
2. redis/memcache的分布式集群通常来讲是按照项目组做隔离的，以我们经验来看一般不会超过50对主从。

所以这里只是提供了一种优化的思路，开阔一下视野。