关于 Multiget hole：spymemcached对此的实现方法

火丁说：

『

Multiget的无底洞问题

Facebook在Memcached的实际应用中，发现了Multiget无底洞问 题，具体表现为：出于效率的考虑，不少Memcached应用都已Multiget操做为主，随着访问量的增长，系统负载捉襟见肘，遇到此类问题，直觉通 常都是经过增长服务器来提高系统性能，可是在实际操做中却发现问题并不简单，新加的服务器好像被扔到了无底洞里同样毫无效果。

……

问题是不少客户端，包括Libmemcached在内，在处理Multiget多服务器请求时，使用的是串行的方式！也就是说，先请求一台服务器，而后等待响应结果，接着请求另外一台，结果致使客户端操做时间累加，请求堆积，性能降低。

』

那么，spymemcached 是如何实现 Multiget（即getBulk）的？

1. 给一组 key，[1，2，3，4，5]。
2. 先算一下这些key都落在哪些节点上（经过 KetamaNodeLocator 的 public Iterator<MemcachedNode> getSequence(String k)。Now that we know how many servers it breaks down into.）；
3. 此时，获得一个map：<Node1,[1,3]>;<Node2,[2,4]>;<Node3,[5]>；
4. 遍历这个map，从每个 mc node 读出对应的 keys（即单节点的multiget操做）；一个Node一个Node串行的；
5. 拼成一个大map<key,value>返回。

 

如火丁所言，此处很差优化，只能：

选择特殊键值进行散列，『保证相关的键只出如今一台服务器上』。

spymemcached 相关文章：

1） spymemcached 的 useNagle 问题与 TCP/IP延迟发送数据

2） spymemcached ：某个mc节点操做连续超时超过998次就 Auto-Reconnect 的特性

3） 关于 Multiget hole：spymemcached对此的实现方法

1） 55最佳实践系列：MongoDB最佳实践  (2012-12-15 15:48)
2） 55最佳实践系列：Logging最佳实践  (2012-12-15 16:43)

3） 最佳实践系列：前端代码标准和最佳实践  (2012-12-19 23:33)

1） 电商课题I：Throttle Limits for calls/requests in a clustered environment  (2012-11-17 22:14)

2） 电商课题V：分布式锁  (2012-11-17 22:16)

3） 电商课题：cookie防篡改  (2012-11-17 22:24)

4） 电商课题VI：分布式Session  (2012-11-17 22:30)

5） 电商课题：RBAC权限控制  (2012-11-17 22:47)

6） 电商课题：幂等性  (2012-11-22 23:52)

7） 电商课题：客户端的IP地址伪造、CDN、反向代理、获取的那些事儿  (2012-09-19 01:17)

8） 电商课题：对付秒杀器等恶意访问行为的简单梳理  (2012-09-18 03:51)

9） 电商课题VII：支付交易通常性准则  (2012-12-14 01:38)

赠图一枚