關於 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)

贈圖一枚