Memcached學習筆記

 

1.簡介

      Memcached是一款高性能的分佈式內存緩存服務器,最初由Brad Fitzpatrick編寫,目前在Github上已開源,最近的版本是1.4.24。node

      11區的Mixi株式會社在memcached的使用上算是走在前列,Mixi是日本最大的社交網站,相似facebook。運營組的長野雅廣負責其平常運營工做,並在日本的報紙上刊登了memcached的使用開發技術文章《memcached を知り盡くす》。linux

      memcached有以下feature:git

  • 協議簡單:
    • 採用基於文本行的協議,而不是其餘複雜的格式。
  • 基於libevent的事件處理機制  
    • Memcached使用了基於libevent的事件處理,它將Linux的epoll、BSD的kqueue等事件處理功能封裝成統一接口,即便對服務器 的鏈接數增長,也能發揮O(1)的性能。 libevent是一個基於事件驅動的,可用於開發可擴展服務的網絡庫,具備輕量級、跨平臺等特色。
  • 有本身的內存存儲方式
    • memcached使用了相似linux內核中的slab內存管理機制,可以儘可能減小內存頁間碎片,然而並不能很好的解決頁內碎片的問題,這是目前存在的一個比較大的問題,因爲還未對源碼進行比較細緻的研究,所以並不能十分確定當前最新版本是否解決了這一問題。
  • memcached不互相通訊的分佈式
    • 雖然memcached是分佈式緩存服務器,但memcached之間並不互相通訊,服務端也並無分佈式功能。

 2.基本架構

        咱們知道使用緩存服務器的目的是經過緩存數據庫查詢結果,從緩存或內存中直接讀取數據而不是硬盤,減小數據庫訪問次數,減小I/O次數,從這個開源軟件的名稱就可見一斑。(這裏就應該想到須要解決一致性問題)Memcached的數據原理以下圖,首次訪問數據時,經過RDBMS讀取到瀏覽器(圖中藍色箭頭所示),此時會將讀取結果保存到memcached,之後的讀取將從memcached獲取數據(如綠色箭頭所示),避免過多的數據庫訪問。客戶端會經過數據的key來決定保存數據的memcached服務器,服務器選定後將保存數據的鍵和值。獲取數據時也是選擇一樣的算法,經過將key傳遞給數據庫,根據key選擇服務器,就能選中與保存時相同的服務器,而後發送get命令獲取數據。github

 

figure1算法

 

3.分佈式算法

        Memcached最使人腦洞大開的地方是其分佈式算法。分佈式算法有不少種,首先最容易想到的是hash函數,給定一個hash函數,經過計算數據的hash值,來判斷數據須要存儲到哪一個對應的節點上。最多見的hash算法就是除留餘數法,以服務器的臺數爲除數,而且經過一些設計上的改進使得數據可以儘可能均勻分佈到各個節點上,避免單個節點負載太重。Memcached的做者也提供了相應算法庫,hash函數採用CRC32,算法以下所示:數據庫

 1 use strict;
 2 use warnings;
 3 use String::CRC32;
 4 
 5 my @nodes = (‘node1’, ‘node2’, ‘node3’);
 6 my @keys = (‘tokyo’, ‘kanagawa’, ‘chiba’, ‘saitama’, ‘gunma’);
 7 
 8 foreach my $key (@keys) {
 9    my $crc = crc32($key);
10    my $mod = $crc % ( $#nodes +1);
11    my $server = $nodes[ $mod ];
12    printf%s = > %s\n」,$key, $server;
13 }

       這種算法一看彷佛並無什麼問題,但是若是由於數據量的增大,咱們須要在系統中增長服務器臺數的話,那麼全部數據的分佈均須要從新計算,並且因爲服務器臺數增長將會致使同一數據在新的系統中存儲的節點號改變,大量數據須要遷移,代價將十分巨大,數據部署的原則之一就是儘可能減小遷移,儘量均勻分佈,所以單純使用除留餘數法並非一種合適的方式。瀏覽器

       來看另一種算法:Consistent hashing緩存

      如figure2所示, Consistent hashing首先求出memcached服務器(節點)的哈希值,並將其配置到0~232的圓上。而後用一樣的方法求出存儲數據的key的hash值,並映射到圓上。而後從數據映射到的位置按順時針方向查找,將數據保存到找到的第一個臨近服務器上。若是超過232仍然找不到服務器,就會默認保存到第一臺memcached服務器上。服務器

            

               figure2               網絡

  

 figure3

       當數據增長,須要在node2和node4之間增長一個服務器節點時,如figure3所示,根據上述算法,node5以前的數據本來須要存儲在node4中,此時,會將這些數據遷移到node5中,而並不影響其餘數據的分佈,node5以後的數據依舊分佈在node4中,這樣遷移代價大大下降,從而不失爲一種高效的分佈式算法。並且即便一臺memcached服務器發生故障後,也不會影響其餘的緩存,只是某些應當存儲在故障節點的數據須要遷移到臨近的下一節點上。不得不說看到這種分佈算法真是大開腦洞,爲了減小數據的從新分佈,居然能在實際應用中使用這種算法,開發者的智慧和潛力可謂無限巨大。固然memcached的hash算法並不止這麼兩種,只是我暫時只看了兩種,另外,memcached的內存分配、管理機制也有獨特之處,因爲我的對這塊比較熟,因此暫不討論。

       讀完這本ebook,感受如今11區的軟件開發人員正在超越歐美,又如Ruby的做者是日本人松本弘行 。這本ebook一共才36頁,一個上午不到就看完了,然而比我以前專門賣的國內的一些關於分佈式、運維相關的書得到的收穫都要大,由於其對一些常見的概念,一些並不複雜的算法均可以一兩句話闡述清楚,這纔是高手以及一個心態正常的Dev應該寫出來的東西。反觀國內的一些技術書籍,雜亂無章,故意將簡單概念和算法複雜化以體現自身水平,其實拔苗助長,深刻淺出和淺入深出的差距,呵呵。

       本文算是《memcached全面剖析》的讀書筆記,我的淺見,若是有誤,但願不吝指正,下一步打算仔細研究下源碼。

 

References

1.memcached官網地址:http://memcached.org/

2.memcached的Github地址: https://github.com/memcached/memcached

3.MIXI:https://mixi.jp/

4.翻譯地址:http://blog.charlee.li/memcached-pdf/

5.博客原文:http://gihyo.jp/dev/feature/01/memcached/0004?page=2

相關文章
相關標籤/搜索