關於 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、反向 Proxy、擷取的那些事兒 (2012-09-19 01:17)

8）電商課題：對付秒殺器等惡意訪問行為的簡單梳理 (2012-09-18 03:51)

9）電商課題VII：支付交易一般性準則 (2012-12-14 01:38)

贈圖一枚