jinfeng_wang

          G-G-S,D-D-U!

          BlogJava 首頁 新隨筆 聯系 聚合 管理
            400 Posts :: 0 Stories :: 296 Comments :: 0 Trackbacks

           轉載請注明出處哈:http://carlosfu.iteye.com/blog/2269678


            最近有點忙,一直沒更新博客,繼續堅持下去。大笑

           

          一、背景 

            1. 什么是緩存無底洞問題:

          Facebook的工作人員反應2010年已達到3000個memcached節點,儲存數千G的緩存。
          他們發現一個問題--memcached的連接效率下降了,于是添加memcached節點,添加完之后,并沒有好轉。稱為“無底洞”現象

                

           2. 緩存無底洞產生的原因:

             鍵值數據庫或者緩存系統,由于通常采用hash函數將key映射到對應的實例,造成key的分布與業務無關,但是由于數據量、訪問量的需求,需要使用分布式后(無論是客戶端一致性哈性、redis-cluster、codis),批量操作比如批量獲取多個key(例如redis的mget操作),通常需要從不同實例獲取key值,相比于單機批量操作只涉及到一次網絡操作,分布式批量操作會涉及到多次網絡io。

              

              

              

           

          3. 無底洞問題帶來的危害:

            (1) 客戶端一次批量操作會涉及多次網絡操作,也就意味著批量操作會隨著實例的增多,耗時會不斷增大。

            (2) 服務端網絡連接次數變多,對實例的性能也有一定影響。

           
          4. 結論:

            用一句通俗的話總結:更多的機器不代表更多的性能,所謂“無底洞”就是說投入越多不一定產出越多。

            分布式又是不可以避免的,因為我們的網站訪問量和數據量越來越大,一個實例根本坑不住,所以如何高效的在分布式緩存和存儲批量獲取數據是一個難點。

           

          二、哈希存儲與順序存儲

             在分布式存儲產品中,哈希存儲與順序存儲是兩種重要的數據存儲和分布方式,這兩種方式不同也直接決定了批量獲取數據的不同,所以這里需要對這兩種數據的分布式方式進行簡要說明:

             1. hash分布:

             hash分布應用于大部分key-value系統中,例如memcache, redis-cluster, twemproxy,即使像mysql在分庫分表時候,也經常會用user%100這樣的方式。

             hash分布的主要作用是將key均勻的分布到各個機器,所以它的一個特點就是數據分散度較高,實現方式通常是hash(key)得到的整數再和分布式節點的某臺機器做映射,以redis-cluster為例子:

              

             問題:和業務沒什么關系,不支持范圍查詢。

            2. 順序分布

            

           

           3. 兩種分布方式的比較:

          分布方式特點典型產品
          哈希分布

          1. 數據分散度高

          2.鍵值分布與業務無關

          3.無法順序訪問

          4.支持批量操作

          一致性哈希memcache

          redisCluster

          其他緩存產品

          順序分布

          1.數據分散度易傾斜

          2.鍵值分布與業務相關

          3.可以順序訪問

          4.支持批量操作

          BigTable

          Hbase

           

           

           

          三、分布式緩存/存儲四種Mget解決方案

           

          1. IO的優化思路:

            (1) 命令本身的效率:例如sql優化,命令優化

            (2) 網絡次數:減少通信次數

            (3) 降低接入成本:長連/連接池,NIO等。

            (4) IO訪問合并:O(n)到O(1)過程:批量接口(mget),

           

          2.  如果只考慮減少網絡次數的話,mget會有如下模型

           

           

          3. 四種解決方案:

          (1).串行mget

          將Mget操作(n個key)拆分為逐次執行N次get操作, 很明顯這種操作時間復雜度較高,它的操作時間=n次網絡時間+n次命令時間,網絡次數是n,很顯然這種方案不是最優的,但是足夠簡單。

           

           

          (2). 串行IO

              將Mget操作(n個key),利用已知的hash函數算出key對應的節點,這樣就可以得到一個這樣的關系:Map<node, somekeys>,也就是每個節點對應的一些keys

              它的操作時間=node次網絡時間+n次命令時間,網絡次數是node的個數,很明顯這種方案比第一種要好很多,但是如果節點數足夠多,還是有一定的性能問題。

           

           

          (3). 并行IO

             此方案是將方案(2)中的最后一步,改為多線程執行,網絡次數雖然還是nodes.size(),但網絡時間變為o(1),但是這種方案會增加編程的復雜度。

             它的操作時間=1次網絡時間+n次命令時間

           

           

          (4). hash-tag實現。

              第二節提到過,由于hash函數會造成key隨機分配到各個節點,那么有沒有一種方法能夠強制一些key到指定節點到指定的節點呢?

              redis提供了這樣的功能,叫做hash-tag。什么意思呢?假如我們現在使用的是redis-cluster(10個redis節點組成),我們現在有1000個k-v,那么按照hash函數(crc16)規則,這1000個key會被打散到10個節點上,那么時間復雜度還是上述(1)~(3)

                

              那么我們能不能像使用單機redis一樣,一次IO將所有的key取出來呢?hash-tag提供了這樣的功能,如果將上述的key改為如下,也就是用大括號括起來相同的內容,那么這些key就會到指定的一個節點上。

             例如:

              

             

          Java代碼  收藏代碼
          1. user1,user2,user3......user1000  
          2. {user}1,{user}2,{user}3.......{user}1000  

           

           

           

          例如下圖:它的操作時間=1次網絡時間+n次命令時間

           

           

          3. 四種批量操作解決方案對比:

          方案優點缺點網絡IO
          串行mget

          1.編程簡單

          2.少量keys,性能滿足要求

          大量keys請求延遲嚴重o(keys)
          串行IO

          1.編程簡單

          2.少量節點,性能滿足要求

          大量node延遲嚴重

          o(nodes)
          并行IO

          1.利用并行特性

          2.延遲取決于最慢的節點

          1.編程復雜

          2.超時定位較難

          o(max_slow(node))
          hash tags性能最高

          1.tag-key業務維護成本較高

          2.tag分布容易出現數據傾斜

          o(1)

           

           

           

           

          四、總結和建議

           

              無底洞問題對資源和性能有一定影響,但是其實大部分系統不需要考慮這個問題,因為

              1. 99%公司的數據和流量無法和facebook相比。

              2. redis/memcache的分布式集群通常來講是按照項目組做隔離的,以我們經驗來看一般不會超過50對主從。   

              所以這里只是提供了一種優化的思路,開闊一下視野。

              

           

          五、參考文獻

          1. Facebook's Memcached Multiget Hole: More machines != More Capacity  
          2. Multiget的無底洞問題
          3. 再說memcache的multiget hole(無底洞)
          posted on 2016-12-20 17:19 jinfeng_wang 閱讀(235) 評論(0)  編輯  收藏 所屬分類: 2016-REDIS
          主站蜘蛛池模板: 北碚区| 应用必备| 文登市| 达州市| 军事| 宣城市| 诏安县| 海城市| 浪卡子县| 项城市| 阿合奇县| 临泉县| 井研县| 德昌县| 惠水县| 沧源| 灯塔市| 临沂市| 广州市| 札达县| 西贡区| 昌平区| 贡山| 从江县| 华亭县| 囊谦县| 平凉市| 达州市| 舒城县| 体育| 墨玉县| 临清市| 积石山| 安陆市| 阿克陶县| 莎车县| 于都县| 马龙县| 积石山| 乳山市| 宝兴县|