2019獨角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

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

?Ehcache

在java項目廣泛的使用。它是一個開源的、設(shè)計于提高在數(shù)據(jù)從RDBMS中取出來的高花費、高延遲采取的一種緩存方案。正因為Ehcache具有健壯性（基于java開發(fā)）、被認(rèn)證（具有apache 2.0 ?license）、充滿特色（稍后會詳細(xì)介紹），所以被用于大型復(fù)雜分布式web application的各個節(jié)點中。

什么特色？

?

1. ?夠快

Ehcache的發(fā)行有一段時長了，經(jīng)過幾年的努力和不計其數(shù)的性能測試，Ehcache終被設(shè)計于large, high concurrency systems.

?

2. 夠簡單

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

比如：hibernate

?

3.夠袖珍

關(guān)于這點的特性，官方給了一個很可愛的名字small foot print ，一般Ehcache的發(fā)布版本不會到2M，V 2.2.3 ?才 668KB。

?

4.?夠輕量

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

?

5.好擴展

Ehcache提供了對大數(shù)據(jù)的內(nèi)存和硬盤的存儲，最近版本允許多實例、保存對象高靈活性、提供LRU、LFU、FIFO淘汰算法，基礎(chǔ)屬性支持熱配置、支持的插件多

?

6.監(jiān)聽器

緩存管理器監(jiān)聽器 （CacheManagerListener）和 緩存監(jiān)聽器（CacheEvenListener）,做一些統(tǒng)計或數(shù)據(jù)一致性廣播挺好用的

如何使用？

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

貼一段基本使用代碼

CacheManager manager = CacheManager.newInstance("src/config/ehcache.xml"); Ehcache cache = new Cache("testCache", 5000, false, false, 5, 2); cacheManager.addCache(cache); 代碼中有個ehcache.xml文件，現(xiàn)在來介紹一下這個文件中的一些屬性

? ? ? ?name:緩存名稱。

???????maxElementsInMemory：緩存最大個數(shù)。

???????eternal:對象是否永久有效，一但設(shè)置了，timeout將不起作用。

???????timeToIdleSeconds：設(shè)置對象在失效前的允許閑置時間（單位：秒）。僅當(dāng)eternal=false對象不是永久有效時使用，可選屬性，默認(rèn)值是0，也就是可閑置時間無窮大。

???????timeToLiveSeconds：設(shè)置對象在失效前允許存活時間,最大時間介于創(chuàng)建時間和失效時間之間。僅當(dāng)eternal=false對象不是永久有效時使用，默認(rèn)是0.，也就是對象存活時 間無窮大。

???????overflowToDisk：當(dāng)內(nèi)存中對象數(shù)量達(dá)到maxElementsInMemory時，Ehcache將會對象寫到磁盤中。

???????diskSpoolBufferSizeMB：這個參數(shù)設(shè)置DiskStore（磁盤緩存）的緩存區(qū)大小。默認(rèn)是30MB。每個Cache都應(yīng)該有自己的一個緩沖區(qū)。

???????maxElementsOnDisk：硬盤最大緩存?zhèn)€數(shù)。

???????diskPersistent：是否緩存虛擬機重啟期數(shù)據(jù)?Whether?the?disk?store?persists?between?restarts?of?the?Virtual?Machine.?The?default?value?is?false.

? ? ? ?diskExpiryThreadIntervalSeconds：磁盤失效線程運行時間間隔，默認(rèn)是120秒。

???????memoryStoreEvictionPolicy：當(dāng)達(dá)到maxElementsInMemory限制時，Ehcache將會根據(jù)指定的策略去清理內(nèi)存。默認(rèn)策略是LRU。你可以設(shè)置為 FIFO或是LFU。

???????clearOnFlush：內(nèi)存數(shù)量最大時是否清除。

?

memcache

memcache 是一種高性能、分布式對象緩存系統(tǒng)，最初設(shè)計于緩解動態(tài)網(wǎng)站數(shù)據(jù)庫加載數(shù)據(jù)的延遲性，你可以把它想象成一個大的內(nèi)存HashTable，就是一個key-value鍵值緩存。Danga Interactive為了LiveJournal所發(fā)展的，以BSD license釋放的一套開放源代碼軟件。

?

1.依賴

memcache C語言所編寫，依賴于最近版本的GCC和libevent。GCC是它的編譯器，同事基于libevent做socket io。在安裝memcache時保證你的系統(tǒng)同事具備有這兩個環(huán)境。

?

2.多線程支持

memcache支持多個cpu同時工作，在memcache安裝文件下有個叫threads.txt中特別說明，By default, memcached is compiled as a single-threaded application.默認(rèn)是單線程編譯安裝，如果你需要多線程則需要修改./configure --enable-threads，為了支持多核系統(tǒng)，前提是你的系統(tǒng)必須具有多線程工作模式。開啟多線程工作的線程數(shù)默認(rèn)是4，如果線程數(shù)超過cpu數(shù)容易發(fā)生操作死鎖的概率。結(jié)合自己業(yè)務(wù)模式選擇才能做到物盡其用。

?

3.高性能

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

?

簡單安裝：

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的安裝位置：

# cd /tmp

# tar zxvf memcached-1.2.0.tar.gz

# cd memcached-1.2.0

# ./configure -with-libevent=/usr

# make

# make install

如果中間出現(xiàn)報錯，請仔細(xì)檢查錯誤信息，按照錯誤信息來配置或者增加相應(yīng)的庫或者路徑。

安裝完成后會把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服務(wù)

?

啟動Memcached服務(wù)：

?

1.啟動Memcache的服務(wù)器端：

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

-d選項是啟動一個守護(hù)進(jìn)程，

-m是分配給Memcache使用的內(nèi)存數(shù)量，單位是MB，我這里是8096MB，

-u是運行Memcache的用戶，我這里是root，

-l是監(jiān)聽的服務(wù)器IP地址，如果有多個地址的話，我這里指定了服務(wù)器的IP地址192.168.77.105，

-p是設(shè)置Memcache監(jiān)聽的端口，我這里設(shè)置了12000，最好是1024以上的端口，

-c選項是最大運行的并發(fā)連接數(shù)，默認(rèn)是1024，我這里設(shè)置了256，按照你服務(wù)器的負(fù)載量來設(shè)定，

-P是設(shè)置保存Memcache的pid文件，我這里是保存在 /tmp/memcached.pid，

?

2.如果要結(jié)束Memcache進(jìn)程，執(zhí)行：

# cat?/tmp/memcached.pid 或者 ps -aux | grep memcache ? （找到對應(yīng)的進(jìn)程id號）

# kill 進(jìn)程id號

也可以啟動多個守護(hù)進(jìn)程，不過端口不能重復(fù)。

?memcache 的連接

telnet ?ip ? port?

注意連接之前需要再memcache服務(wù)端把memcache的防火墻規(guī)則加上

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 3306 -j ACCEPT?

重新加載防火墻規(guī)則

service iptables restart

OK ,現(xiàn)在應(yīng)該就可以連上memcache了

在客戶端輸入stats 查看memcache的狀態(tài)信息

?

pid ? ? ? ? ? ? ?memcache服務(wù)器的進(jìn)程ID

uptime ? ? ?服務(wù)器已經(jīng)運行的秒數(shù)

time ? ? ? ? ? 服務(wù)器當(dāng)前的unix時間戳

version ? ? memcache版本

pointer_size ? ? ? ? 當(dāng)前操作系統(tǒng)的指針大小（32位系統(tǒng)一般是32bit）

rusage_user ? ? ? ? ?進(jìn)程的累計用戶時間

rusage_system ? ?進(jìn)程的累計系統(tǒng)時間

curr_items ? ? ? ? ? ?服務(wù)器當(dāng)前存儲的items數(shù)量

total_items ? ? ? ? ? 從服務(wù)器啟動以后存儲的items總數(shù)量

bytes ? ? ? ? ? ? ? ? ? ? ? 當(dāng)前服務(wù)器存儲items占用的字節(jié)數(shù)

curr_connections ? ? ? ?當(dāng)前打開著的連接數(shù)

total_connections ? ? ? ?從服務(wù)器啟動以后曾經(jīng)打開過的連接數(shù)

connection_structures ? ? ? ? ?服務(wù)器分配的連接構(gòu)造數(shù)

cmd_get get命令 ? ? ? ? ?（獲取）總請求次數(shù)

cmd_set set命令 ? ? ? ? ?（保存）總請求次數(shù)

get_hits ? ? ? ? ?總命中次數(shù)

get_misses ? ? ? ?總未命中次數(shù)

evictions ? ? 為獲取空閑內(nèi)存而刪除的items數(shù)（分配給memcache的空間用滿后需要刪除舊的items來得到空間分配給新的items）

bytes_read ? ?讀取字節(jié)數(shù)（請求字節(jié)數(shù)）

bytes_written ? ? 總發(fā)送字節(jié)數(shù)（結(jié)果字節(jié)數(shù)）

limit_maxbytes ? ? 分配給memcache的內(nèi)存大小（字節(jié)）

threads ? ? ? ? 當(dāng)前線程數(shù)

?

redis

?redis是在memcache之后編寫的，大家經(jīng)常把這兩者做比較，如果說它是個key-value store 的話但是它具有豐富的數(shù)據(jù)類型，我想暫時把它叫做緩存數(shù)據(jù)流中心，就像現(xiàn)在物流中心那樣，order、package、store、classification、distribute、end。現(xiàn)在還很流行的LAMP PHP架構(gòu) 不知道和 redis+mysql 或者 redis + mongodb的性能比較（聽群里的人說mongodb分片不穩(wěn)定）。

先說說reidis的特性

?

1. 支持持久化

? ? ?redis的本地持久化支持兩種方式：RDB和AOF。RDB 在redis.conf配置文件里配置持久化觸發(fā)器，AOF指的是redis沒增加一條記錄都會保存到持久化文件中（保存的是這條記錄的生成命令），如果不是用redis做DB用的話還會不要開AOF ，數(shù)據(jù)太龐大了，重啟恢復(fù)的時候是一個巨大的工程！

?

2.豐富的數(shù)據(jù)類型

? ? redis 支持 String 、Lists、sets、sorted sets、hashes 多種數(shù)據(jù)類型,新浪微博會使用redis做nosql主要也是它具有這些類型，時間排序、職能排序、我的微博、發(fā)給我的這些功能List 和 sorted set

? ?的強大操作功能息息相關(guān)

?

3.高性能

? ?這點跟memcache很想象，內(nèi)存操作的級別是毫秒級的比硬盤操作秒級操作自然高效不少，較少了磁頭尋道、數(shù)據(jù)讀取、頁面交換這些高開銷的操作！這也是NOSQL冒出來的原因吧，應(yīng)該是高性能

? 是基于RDBMS的衍生產(chǎn)品，雖然RDBMS也具有緩存結(jié)構(gòu)，但是始終在app層面不是我們想要的那么操控的。

?

4.replication

? ? redis提供主從復(fù)制方案，跟mysql一樣增量復(fù)制而且復(fù)制的實現(xiàn)都很相似，這個復(fù)制跟AOF有點類似復(fù)制的是新增記錄命令，主庫新增記錄將新增腳本發(fā)送給從庫，從庫根據(jù)腳本生成記錄，這個過程非常快，就看網(wǎng)絡(luò)了，一般主從都是在同一個局域網(wǎng)，所以可以說redis的主從近似及時同步，同事它還支持一主多從，動態(tài)添加從庫，從庫數(shù)量沒有限制。 主從庫搭建，我覺得還是采用網(wǎng)狀模式，如果使用鏈?zhǔn)?#xff08;master-slave-slave-slave-slave·····）如果第一個slave出現(xiàn)宕機重啟，首先從master 接收 數(shù)據(jù)恢復(fù)腳本，這個是阻塞的，如果主庫數(shù)據(jù)幾TB的情況恢復(fù)過程得花上一段時間，在這個過程中其他的slave就無法和主庫同步了。

?

5.更新快

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

redis的安裝

?

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

不過最近我在2.6.7后用centos 5.5 32bit 時碰到一個安裝問題，下面我就用圖片分享下安裝過程碰到的問題，在redis 文件夾內(nèi)執(zhí)行make時有個如下的錯?undefined reference to '__sync_add_and_fetch_4'

上網(wǎng)找了了好多最后在 ?https://github.com/antirez/redis/issues/736 找到解決方案，write CFLAGS= -march=i686 on src/Makefile head!

記得要把剛安裝失敗的文件刪除，重新解壓新的安裝文件，修改Makefile文件，再make安裝。就不會發(fā)現(xiàn)原來那個錯誤了

關(guān)于redis的一些屬性注釋和基本類型操作在上一篇redis 的開胃菜有詳細(xì)的說明，這里就不再重復(fù)累贅了（實質(zhì)是想偷懶 ，哈哈！）

?

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

在別人發(fā)了一個memcache性能比redis好很多后，redis 作者 antirez 發(fā)表了一篇博文，主要是說到如何給redis 和 memcache 做壓力測試，文中講到有個人說許多開源軟件都應(yīng)該丟進(jìn)廁所，因為他們的壓力測試腳本太2了，作者對這個說明了一番。redis ?vs ?memcache is??definitely an apple to apple comparison。 呵呵，很明確吧，兩者的比較是不是有點雞蛋挑骨頭的效果，作者在相同的運行環(huán)境做了三次測試取多好的值，得到的結(jié)果如下圖:

需要申明的是此次測試在單核心處理的過程的數(shù)據(jù)，memcache是支持多核心多線程操作的（默認(rèn)沒開）所以在默認(rèn)情況下上圖具有參考意義，若然則memcache快于redis。那為什么redis不支持多線程多核心處理呢？作者也發(fā)表了一下自己的看法，首先是多線程不變于bug的修復(fù)，其實是不易軟件的擴展，還有數(shù)據(jù)一致性問題因為redis所有的操作都是原子操作，作者用到一個詞nightmare 噩夢，呵呵！ ?當(dāng)然不支持多線程操作，肯定也有他的弊端的比如性能想必必然差，作者從2.2版本后專注redis cluster的方向開發(fā)來緩解其性能上的弊端，說白了就是縱向不行，橫向提高。

轉(zhuǎn)載于:https://my.oschina.net/yizhichao/blog/1549206

總結(jié)

以上是生活随笔為你收集整理的ehcache memcache redis 三大缓存的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。