ehcache memcache redis 三大緩存對比

最近項目組有用到這三個緩存，去各自的官方看了下,覺得還真的各有千秋！今天特意歸納下各個緩存的優缺點，僅供參考！

 ehcache

在java項目廣泛的使用。它是一個開源的、設計于提高在資料從rdbms中取出來的高花費、高延遲采取的一種緩存方案。正因為ehcache具有健壯性（基于java開發）、被認證（具有apache 2.0  license）、充滿特色（稍後會詳細介紹），是以被用于大型複雜分布式web application的各個節點中。

什麼特色？

1.  夠快

ehcache的發行有一段時長了，經過幾年的努力和不計其數的性能測試，ehcache終被設計于large, high concurrency systems.

2. 夠簡單

開發者提供的接口非常簡單明了，從ehcache的搭建到運用運作僅僅需要的是你寶貴的幾分鐘。其實很多開發者都不知道自己用在用ehcache，ehcache被廣泛的運用于其他的開源項目

比如：hibernate

3.夠袖珍

關于這點的特性，官方給了一個很可愛的名字small foot print ，一般ehcache的釋出版本不會到2m，v 2.2.3  才 668kb。

4. 夠輕量

核心程式僅僅依賴slf4j這一個包，沒有之一！

5.好擴充

ehcache提供了對大資料的記憶體和硬碟的存儲，最近版本允許多執行個體、儲存對象高靈活性、提供lru、lfu、fifo淘汰算法，基礎屬性支援熱配置、支援的插件多

6.監聽器

緩存管理器監聽器 （cachemanagerlistener）和 緩存監聽器（cacheevenlistener）,做一些統計或資料一緻性廣播挺好用的

如何使用？

夠簡單就是ehcache的一大特色，自然用起來just so easy!

貼一段基本使用代碼

       name:緩存名稱。

       maxelementsinmemory：緩存最大個數。

       eternal:對象是否永久有效，一但設定了，timeout将不起作用。

       timetoidleseconds：設定對象在失效前的允許閑置時間（機關：秒）。僅當eternal=false對象不是永久有效時使用，可選屬性，預設值是0，也就是可閑置時間無窮大。

       timetoliveseconds：設定對象在失效前允許存活時間,最大時間介于建立時間和失效時間之間。僅當eternal=false對象不是永久有效時使用，預設是0.，也就是對象存活時 間無窮大。

       overflowtodisk：當記憶體中對象數量達到maxelementsinmemory時，ehcache将會對象寫到磁盤中。

       diskspoolbuffersizemb：這個參數設定diskstore（磁盤緩存）的緩存區大小。預設是30mb。每個cache都應該有自己的一個緩沖區。

       maxelementsondisk：硬碟最大緩存個數。

       diskpersistent：是否緩存虛拟機重新開機期資料 whether the disk store persists between restarts of the virtual machine. the default value is false.

       diskexpirythreadintervalseconds：磁盤失效線程運作時間間隔，預設是120秒。

       memorystoreevictionpolicy：當達到maxelementsinmemory限制時，ehcache将會根據指定的政策去清理記憶體。預設政策是lru。你可以設定為 fifo或是lfu。

       clearonflush：記憶體數量最大時是否清除。

memcache

memcache 是一種高性能、分布式對象緩存系統，最初設計于緩解動态網站資料庫加載資料的延遲性，你可以把它想象成一個大的記憶體hashtable，就是一個key-value鍵值緩存。danga interactive為了livejournal所發展的，以bsd license釋放的一套開放源代碼軟體。

1.依賴

memcache c語言所編寫，依賴于最近版本的gcc和libevent。gcc是它的編譯器，同僚基于libevent做socket io。在安裝memcache時保證你的系統同僚具備有這兩個環境。

2.多線程支援

memcache支援多個cpu同時工作，在memcache安裝檔案下有個叫threads.txt中特别說明，by default, memcached is compiled as a single-threaded application.預設是單線程編譯安裝，如果你需要多線程則需要修改./configure --enable-threads，為了支援多核系統，前提是你的系統必須具有多線程工作模式。開啟多線程工作的線程數預設是4，如果線程數超過cpu數容易發生操作死鎖的機率。結合自己業務模式選擇才能做到物盡其用。

3.高性能

通過libevent完成socket 的通訊，理論上性能的瓶頸落在網卡上。

簡單安裝：

1.分别把memcached和libevent下載下傳回來，放到 /tmp 目錄下：

# cd /tmp

# wget http://www.danga.com/memcached/dist/memcached-1.2.0.tar.gz

# wget http://www.monkey.org/~provos/libevent-1.2.tar.gz

2.先安裝libevent：

# tar zxvf libevent-1.2.tar.gz

# cd libevent-1.2

# ./configure -prefix=/usr

# make （如果遇到提示gcc 沒有安裝則先安裝gcc)

# make install

3.測試libevent是否安裝成功：

# ls -al /usr/lib | grep libevent

lrwxrwxrwx 1 root root 21 11?? 12 17:38 libevent-1.2.so.1 -> libevent-1.2.so.1.0.3

-rwxr-xr-x 1 root root 263546 11?? 12 17:38 libevent-1.2.so.1.0.3

-rw-r-r- 1 root root 454156 11?? 12 17:38 libevent.a

-rwxr-xr-x 1 root root 811 11?? 12 17:38 libevent.la

lrwxrwxrwx 1 root root 21 11?? 12 17:38 libevent.so -> libevent-1.2.so.1.0.3

還不錯，都安裝上了。

4.安裝memcached，同時需要安裝中指定libevent的安裝位置：

# tar zxvf memcached-1.2.0.tar.gz

# cd memcached-1.2.0

# ./configure -with-libevent=/usr

# make

如果中間出現報錯，請仔細檢查錯誤資訊，按照錯誤資訊來配置或者增加相應的庫或者路徑。

安裝完成後會把memcached放到 /usr/local/bin/memcached ，

5.測試是否成功安裝memcached：

# ls -al /usr/local/bin/mem*

-rwxr-xr-x 1 root root 137986 11?? 12 17:39 /usr/local/bin/memcached

-rwxr-xr-x 1 root root 140179 11?? 12 17:39 /usr/local/bin/memcached-debug

啟動memcache服務

啟動memcached服務：

1.啟動memcache的伺服器端：

# /usr/local/bin/memcached -d -m 8096 -u root -l 192.168.77.105 -p 12000 -c 256 -p /tmp/memcached.pid

-d選項是啟動一個守護程序，

-m是配置設定給memcache使用的記憶體數量，機關是mb，我這裡是8096mb，

-u是運作memcache的使用者，我這裡是root，

-l是監聽的伺服器ip位址，如果有多個位址的話，我這裡指定了伺服器的ip位址192.168.77.105，

-p是設定memcache監聽的端口，我這裡設定了12000，最好是1024以上的端口，

-c選項是最大運作的并發連接配接數，預設是1024，我這裡設定了256，按照你伺服器的負載量來設定，

-p是設定儲存memcache的pid檔案，我這裡是儲存在 /tmp/memcached.pid，

2.如果要結束memcache程序，執行：

# cat /tmp/memcached.pid 或者 ps -aux | grep memcache   （找到對應的程序id号）

# kill 程序id号

也可以啟動多個守護程序，不過端口不能重複。

 memcache 的連接配接

telnet  ip   port 

注意連接配接之前需要再memcache服務端把memcache的防火牆規則加上

-a rh-firewall-1-input -m state --state new -m tcp -p tcp --dport 3306 -j accept 

重新加載防火牆規則

service iptables restart

ok ,現在應該就可以連上memcache了

在用戶端輸入stats 檢視memcache的狀态資訊

pid              memcache伺服器的程序id

uptime      伺服器已經運作的秒數

time           伺服器目前的unix時間戳

version     memcache版本

pointer_size         目前作業系統的指針大小（32位系統一般是32bit）

rusage_user          程序的累計使用者時間

rusage_system    程序的累計系統時間

curr_items            伺服器目前存儲的items數量

total_items           從伺服器啟動以後存儲的items總數量

bytes                       目前伺服器存儲items占用的位元組數

curr_connections        目前打開着的連接配接數

total_connections        從伺服器啟動以後曾經打開過的連接配接數

connection_structures          伺服器配置設定的連接配接構造數

cmd_get get指令          （擷取）總請求次數

cmd_set set指令          （儲存）總請求次數

get_hits          總命中次數

get_misses        總未命中次數

evictions     為擷取空閑記憶體而删除的items數（配置設定給memcache的空間用滿後需要删除舊的items來得到空間配置設定給新的items）

bytes_read    讀取位元組數（請求位元組數）

bytes_written     總發送位元組數（結果位元組數）

limit_maxbytes     配置設定給memcache的記憶體大小（位元組）

threads         目前線程數

 redis是在memcache之後編寫的，大家經常把這兩者做比較，如果說它是個key-value store 的話但是它具有豐富的資料類型，我想暫時把它叫做緩存資料流中心，就像現在物流中心那樣，order、package、store、classification、distribute、end。現在還很流行的lamp php架構 不知道和 redis+mysql 或者 redis + mongodb的性能比較（聽群裡的人說mongodb分片不穩定）。

先說說reidis的特性

1. 支援持久化

     redis的本地持久化支援兩種方式：rdb和aof。rdb 在redis.conf配置檔案裡配置持久化觸發器，aof指的是redis沒增加一條記錄都會儲存到持久化檔案中（儲存的是這條記錄的生成指令），如果不是用redis做db用的話還會不要開aof ，資料太龐大了，重新開機恢複的時候是一個巨大的工程！

2.豐富的資料類型

    redis 支援 string 、lists、sets、sorted sets、hashes 多種資料類型,新浪微網誌會使用redis做nosql主要也是它具有這些類型，時間排序、職能排序、我的微網誌、發給我的這些功能list 和 sorted set

   的強大操作功能息息相關

   這點跟memcache很想象，記憶體操作的級别是毫秒級的比硬碟操作秒級操作自然高效不少，較少了磁頭尋道、資料讀取、頁面交換這些高開銷的操作！這也是nosql冒出來的原因吧，應該是高性能

  是基于rdbms的衍生産品，雖然rdbms也具有緩存結構，但是始終在app層面不是我們想要的那麼操控的。

4.replication

    redis提供主從複制方案，跟mysql一樣增量複制而且複制的實作都很相似，這個複制跟aof有點類似複制的是新增記錄指令，主庫新增記錄将新增腳本發送給從庫，從庫根據腳本生成記錄，這個過程非常快，就看網絡了，一般主從都是在同一個區域網路，是以可以說redis的主從近似及時同步，同僚它還支援一主多從，動态添加從庫，從庫數量沒有限制。 主從庫搭建，我覺得還是采用網狀模式，如果使用鍊式（master-slave-slave-slave-slave·····）如果第一個slave出現當機重新開機，首先從master 接收 資料恢複腳本，這個是阻塞的，如果主庫資料幾tb的情況恢複過程得花上一段時間，在這個過程中其他的slave就無法和主庫同步了。

5.更新快

   這點好像從我接觸到redis到目前為止 已經發了大版本就4個，小版本沒算過。redis作者是個非常積極的人，無論是郵件提問還是論壇發帖，他都能及時耐心的為你解答，維護度很高。有人維護的話，讓我們用的也省心和放心。目前作者對redis 的主導開發方向是redis的叢集方向。

redis的安裝

redis的安裝其實還是挺簡單的，總的來說就三步：下載下傳tar包，解壓tar包，安裝。

不過最近我在2.6.7後用centos 5.5 32bit 時碰到一個安裝問題，下面我就用圖檔分享下安裝過程碰到的問題，在redis 檔案夾内執行make時有個如下的錯 undefined reference to '__sync_add_and_fetch_4'

上網找了了好多最後在  https://github.com/antirez/redis/issues/736 找到解決方案，write cflags= -march=i686 on src/makefile head!

記得要把剛安裝失敗的檔案删除，重新解壓新的安裝檔案，修改makefile檔案，再make安裝。就不會發現原來那個錯誤了

關于redis的一些屬性注釋和基本類型操作在上一篇redis 的開胃菜有詳細的說明，這裡就不再重複累贅了（實質是想偷懶 ，哈哈！）

最後，把memcache和redis放在一起不得不會讓人想到兩者的比較，誰快誰好用啊，群裡面已經為這個事打架很久了，我就把我看到的在這裡跟大家分享下。

在别人發了一個memcache性能比redis好很多後，redis 作者 antirez 發表了一篇博文，主要是說到如何給redis 和 memcache 做壓力測試，文中講到有個人說許多開源軟體都應該丢進廁所，因為他們的壓力測試腳本太2了，作者對這個說明了一番。redis  vs  memcache is  definitely an apple to apple comparison。 呵呵，很明确吧，兩者的比較是不是有點雞蛋挑骨頭的效果，作者在相同的運作環境做了三次測試取多好的值，得到的結果如下圖:

需要申明的是此次測試在單核心處理的過程的資料，memcache是支援多核心多線程操作的（預設沒開）是以在預設情況下上圖具有參考意義，若然則memcache快于redis。那為什麼redis不支援多線程多核心處理呢？作者也發表了一下自己的看法，首先是多線程不變于bug的修複，其實是不易軟體的擴充，還有資料一緻性問題因為redis所有的操作都是原子操作，作者用到一個詞nightmare 噩夢，呵呵！  當然不支援多線程操作，肯定也有他的弊端的比如性能想必必然差，作者從2.2版本後專注redis cluster的方向開發來緩解其性能上的弊端，說白了就是縱向不行，橫向提高。

特别說明：尊重作者的勞動成果，轉載請注明出處哦~~~http://blog.yemou.net/article/query/info/tytfjhfascvhzxcyt268