NoSQL分类及ehcache memcache redis 三大缓存的对比
NoSQL分類(lèi)
由于NoSQL中沒(méi)有像傳統(tǒng)數(shù)據(jù)庫(kù)那樣定義數(shù)據(jù)的組織方式為關(guān)系型的，所以只要內(nèi)部的數(shù)據(jù)組織采用了非關(guān)系型的方式，就可以稱(chēng)之為NoSQL數(shù)據(jù)庫(kù)。
目前，可以將眾多的NoSQL數(shù)據(jù)庫(kù)按照內(nèi)部的數(shù)據(jù)組織形式進(jìn)行如下分類(lèi)：
- Key/Value的NoSQL數(shù)據(jù)庫(kù)
- 面向文檔的NoSQL數(shù)據(jù)庫(kù)
- 面向列的NoSQL數(shù)據(jù)庫(kù)
- 面向圖的NoSQL數(shù)據(jù)庫(kù)
不同的數(shù)據(jù)組織適合于不同的應(yīng)用場(chǎng)景，后面將進(jìn)行介紹。
為什么要使用NoSQL
ＳＱＬ語(yǔ)言和關(guān)系型數(shù)據(jù)庫(kù)（My SQL、PostgreSQL、Oracle等） 是通用的數(shù)據(jù)解決方案，占有絕大多數(shù)的市場(chǎng)。不過(guò)在最近興起的NoSQL運(yùn)動(dòng)中，涌現(xiàn)出一批具備高可用性、支持線性擴(kuò)展、支持Map/Reduce操作等特性的數(shù)據(jù)產(chǎn)品，它們具有如下特性：
Key/Value的NoSQL庫(kù)
1 memcached
memcached是國(guó)外社區(qū)網(wǎng)站LiveJournal開(kāi)發(fā)的高性能的內(nèi)存Key/Value緩存服務(wù)器，目的是通過(guò)緩存數(shù)據(jù)庫(kù)查詢結(jié)果，減少數(shù)據(jù)庫(kù)訪問(wèn)次數(shù)，以提高動(dòng)態(tài)Ｗeb應(yīng)用的速度，從而提高系統(tǒng)的可擴(kuò)展性。
2 redis
redis是一款先進(jìn)的Key/Value存儲(chǔ)系統(tǒng)。它與Memcached類(lèi)似，區(qū)別如下：
redis不僅支持簡(jiǎn)單的Key/Value類(lèi)型的數(shù)據(jù)，同時(shí)還提供list、set、hash等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)。
redis支持?jǐn)?shù)據(jù)的備份，即master slave模式的數(shù)據(jù)備份。
redis支持?jǐn)?shù)據(jù)的持久化，可以將內(nèi)存中的數(shù)據(jù)保持在磁盤(pán)中，重啟的時(shí)候再次加載進(jìn)行使用。
在redis中，并不是所有的數(shù)據(jù)都一直存儲(chǔ)在內(nèi)存中。redis只會(huì)緩存所有的Key的信息，如果redis發(fā)現(xiàn)內(nèi)存的使用量超過(guò)了某個(gè)閾值，將觸發(fā)交換（swap） 的操作。redis根據(jù)“swappabillity=age*log(size_in_memory)” 計(jì)算出哪些Key對(duì)應(yīng)的Value需要交換到磁盤(pán)，然后再將這些key對(duì)應(yīng)的value持久化到磁盤(pán)中，同時(shí)在內(nèi)存中清除。這種特性使得redis可以保持超過(guò)其機(jī)器本身內(nèi)存大小的數(shù)據(jù)。當(dāng)然，機(jī)器本身的內(nèi)存必須要能夠保持所有的ｋey，畢竟這些數(shù)據(jù)是不會(huì)進(jìn)行交換操作的。同時(shí)由于redis將內(nèi)存中的數(shù)據(jù)交換到磁盤(pán)中的時(shí)候，提供服務(wù)的主線程和進(jìn)行交換操作的子線程會(huì)共享這部分內(nèi)存，所以如果更新需要交換的數(shù)據(jù)，redis將阻塞這個(gè)操作，直到子線程完成交換操作后才可以進(jìn)行修改。
3 Dynamo
Dynamo是亞馬遜公司開(kāi)發(fā)的一款分布式Key/Value存儲(chǔ)系統(tǒng)，用于存儲(chǔ)用戶的購(gòu)物車(chē)信息。Dynamo與傳統(tǒng)的Key/Value存儲(chǔ)系統(tǒng)相比，最大的優(yōu)勢(shì)在于無(wú)單點(diǎn)故障，整個(gè)系統(tǒng)的可用性非常高，同時(shí)具備數(shù)據(jù)的最終一致性。
面向文檔的NoSQL數(shù)據(jù)庫(kù)
1 MongoDB
MongoDB是一個(gè)高性能、開(kāi)源、模式自由（schma free） 的文檔型數(shù)據(jù)庫(kù)，它在許多場(chǎng)景下可用于替代傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)或Key/Value存儲(chǔ)方式。MongoDB使用C++開(kāi)發(fā)，具有以下特性：
2 CouchDB
CouchDB是Apache社區(qū)中的一款文檔型數(shù)據(jù)庫(kù)服務(wù)器。與現(xiàn)在流行的關(guān)系數(shù)據(jù)庫(kù)服務(wù)器不同，CouchDB是圍繞一系列語(yǔ)義上自包含的文檔而組織的。CouchDB中的文檔是模式自由的，也就是說(shuō)，并不要求文檔具有某種特定的結(jié)構(gòu)。CouchDB的這種特性使得它相對(duì)于傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)而言，有自己的適用范圍。一般來(lái)說(shuō)，圍繞文檔來(lái)構(gòu)建的應(yīng)用都比較適合使用CouchDB作為其后臺(tái)存儲(chǔ)。CouchDB強(qiáng)調(diào)其中所存儲(chǔ)的文檔，在語(yǔ)義上是自包含的。這種面向文檔的設(shè)計(jì)思路，更貼近很多應(yīng)用的問(wèn)題域的真實(shí)情況。對(duì)于這類(lèi)應(yīng)用，使用CouchDB的文檔來(lái)進(jìn)行建模，會(huì)更加自然和簡(jiǎn)單。與此同時(shí)，CouchDB也提供基于Map/Reduce編程模型的視圖來(lái)對(duì)文檔進(jìn)行查詢，可以提供類(lèi)似于關(guān)系數(shù)據(jù)庫(kù)中ＳＱＬ語(yǔ)句的能力。CouchDB對(duì)于很多應(yīng)用來(lái)說(shuō)，提供了關(guān)系數(shù)據(jù)庫(kù)之外的更好的選擇。
面向列的NoSQL數(shù)據(jù)庫(kù)
1 Cassandra
Cassandra是一款面向列的NoSQL數(shù)據(jù)庫(kù)，和Google的Bigtable數(shù)據(jù)庫(kù)屬于同一類(lèi)。此數(shù)據(jù)庫(kù)比一個(gè)類(lèi)似Dynamo的Key/Value數(shù)據(jù)庫(kù)功能更多，但相比于面向文檔的數(shù)據(jù)庫(kù)（如MongoDB），它所支持的查詢類(lèi)型要少。
HBase
HBase是Hadoop項(xiàng)目中的數(shù)據(jù)庫(kù)。它用于需要對(duì)大量的數(shù)據(jù)進(jìn)行隨機(jī)、實(shí)時(shí)的讀寫(xiě)操作的場(chǎng)景中。HBase的目標(biāo)就是處理數(shù)據(jù)量非常龐大的表，可以用普通的計(jì)算機(jī)處理超過(guò)１０億行數(shù)據(jù)，還可處理有數(shù)百萬(wàn)列元素的數(shù)據(jù)表。
HBase是一個(gè)開(kāi)源的、分布式的、支持多版本的、面向列存儲(chǔ)的GoogleBigtable實(shí)現(xiàn)。
HBase的實(shí)現(xiàn)基于Hadoop分布式文件系統(tǒng)（HDFS），模仿并提供了基于Google文件系統(tǒng)的Bigtable數(shù)據(jù)庫(kù)的所有功能。HBase有如下特點(diǎn)：
面向圖的NoSQL數(shù)據(jù)庫(kù)
Ｎeｏ４J是一個(gè)用Jａvａ實(shí)現(xiàn)、完全兼容ＡＣＩＤ的圖形數(shù)據(jù)庫(kù)。數(shù)據(jù)以一種針對(duì)圖形網(wǎng)絡(luò)進(jìn)行過(guò)優(yōu)化的格式保存在磁盤(pán)上。Ｎeｏ４J的內(nèi)核是一種極快的圖形引擎，具有數(shù)據(jù)庫(kù)產(chǎn)品期望的所有特性，如恢復(fù)、兩階段提交、符合ＸＡ等。自２００３年起，Ｎeｏ４J就已經(jīng)作為７２４的產(chǎn)品使用。該項(xiàng)目已經(jīng)發(fā)布了１２版，它是關(guān)于伸縮性和社區(qū)測(cè)試的一個(gè)主要里程碑。通過(guò)聯(lián)機(jī)備份實(shí)現(xiàn)的高可用性和主從復(fù)制功能目前處于測(cè)試階段，預(yù)計(jì)在下一版本中發(fā)布。Ｎeｏ４J既可作為無(wú)須任何管理開(kāi)銷(xiāo)的內(nèi)嵌數(shù)據(jù)庫(kù)使用，也可以作為單獨(dú)的服務(wù)器使用，在這種使用場(chǎng)景下，它提供了廣泛使用的REST接口，能夠方便地集成到基于PHP、ＮＥＴ和JａvａＳｃｒiｐｔ的環(huán)境里。
Ｎeｏ４J的特點(diǎn)如下：
?
示例：
如圖１－１所示，可以在一個(gè)網(wǎng)站中使用４款數(shù)據(jù)產(chǎn)品來(lái)提供服務(wù)。
選擇多樣的數(shù)據(jù)存儲(chǔ)方案同樣有利于提升我們對(duì)NoSQL的數(shù)據(jù)產(chǎn)品的理解，幫助我們從大量的解決方案中選擇最適用的產(chǎn)品，而不是把眼光僅僅放在某一款產(chǎn)品上。
核心的思想是：最適用的才是最好的。
Redis與Memcached的比較
1、Redis和Memcache都是將數(shù)據(jù)存放在內(nèi)存中，都是內(nèi)存數(shù)據(jù)庫(kù)。不過(guò)memcache還可用于緩存其他東西，例如圖片、視頻等等，而Redis，并不是所有的數(shù)據(jù)都一直存儲(chǔ)在內(nèi)存中的。
2、Redis不僅僅支持簡(jiǎn)單的k/v類(lèi)型的數(shù)據(jù)，同時(shí)還提供list，set，hash等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)。
3、虛擬內(nèi)存--Redis當(dāng)物理內(nèi)存用完時(shí)，可以將一些很久沒(méi)用到的value 交換到磁盤(pán)
4、過(guò)期策略--memcache在set時(shí)就指定，例如set key1 0 0 8,即永不過(guò)期。Redis可以通過(guò)例如expire 設(shè)定，例如expire name 10
5、分布式--設(shè)定memcache集群，利用magent做一主多從;redis可以做一主多從。都可以一主一從
6、存儲(chǔ)數(shù)據(jù)安全--memcache掛掉后，數(shù)據(jù)沒(méi)了；redis可以定期保存到磁盤(pán)（持久化），重啟的時(shí)候可以再次加載進(jìn)行使用。
7、災(zāi)難恢復(fù)--memcache掛掉后，數(shù)據(jù)不可恢復(fù); redis數(shù)據(jù)丟失后可以通過(guò)aof恢復(fù)
8、Redis支持?jǐn)?shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份
Redis在很多方面具備數(shù)據(jù)庫(kù)的特征，或者說(shuō)就是一個(gè)數(shù)據(jù)庫(kù)系統(tǒng)，而Memcached只是簡(jiǎn)單的K/V緩存
實(shí)現(xiàn)原理等不同：
Memcached是多線程，非阻塞IO復(fù)用的網(wǎng)絡(luò)模型，分為監(jiān)聽(tīng)主線程和worker子線程，監(jiān)聽(tīng)線程監(jiān)聽(tīng)網(wǎng)絡(luò)連接，接受請(qǐng)求后，將連接描述字pipe 傳遞給worker線程，進(jìn)行讀寫(xiě)IO, 網(wǎng)絡(luò)層使用libevent封裝的事件庫(kù)，多線程模型可以發(fā)揮多核作用，但是引入了cache coherency和鎖的問(wèn)題，比如，Memcached最常用的stats 命令，實(shí)際Memcached所有操作都要對(duì)這個(gè)全局變量加鎖，進(jìn)行計(jì)數(shù)等工作，帶來(lái)了性能損耗。
（Memcached網(wǎng)絡(luò)IO模型）
Redis使用單線程的IO復(fù)用模型，自己封裝了一個(gè)簡(jiǎn)單的AeEvent事件處理框架，主要實(shí)現(xiàn)了epoll、kqueue和select，對(duì)于單純只有IO操作來(lái)說(shuō)，單線程可以將速度優(yōu)勢(shì)發(fā)揮到最大，但是Redis也提供了一些簡(jiǎn)單的計(jì)算功能，比如排序、聚合等，對(duì)于這些操作，單線程模型實(shí)際會(huì)嚴(yán)重影響整體吞吐量，CPU計(jì)算過(guò)程中，整個(gè)IO調(diào)度都是被阻塞住的。
Memcached使用預(yù)分配的內(nèi)存池的方式，使用slab和大小不同的chunk來(lái)管理內(nèi)存，Item根據(jù)大小選擇合適的chunk存儲(chǔ)，內(nèi)存池的方式可以省去申請(qǐng)/釋放內(nèi)存的開(kāi)銷(xiāo)，并且能減小內(nèi)存碎片產(chǎn)生，但這種方式也會(huì)帶來(lái)一定程度上的空間浪費(fèi)，并且在內(nèi)存仍然有很大空間時(shí)，新的數(shù)據(jù)也可能會(huì)被剔除，原因可以參考Timyang的文章：http://timyang.net/data/Memcached-lru-evictions/
Redis使用現(xiàn)場(chǎng)申請(qǐng)內(nèi)存的方式來(lái)存儲(chǔ)數(shù)據(jù)，并且很少使用free-list等方式來(lái)優(yōu)化內(nèi)存分配，會(huì)在一定程度上存在內(nèi)存碎片，Redis跟據(jù)存儲(chǔ)命令參數(shù)，會(huì)把帶過(guò)期時(shí)間的數(shù)據(jù)單獨(dú)存放在一起，并把它們稱(chēng)為臨時(shí)數(shù)據(jù)，非臨時(shí)數(shù)據(jù)是永遠(yuǎn)不會(huì)被剔除的，即便物理內(nèi)存不夠，導(dǎo)致swap也不會(huì)剔除任何非臨時(shí)數(shù)據(jù)（但會(huì)嘗試剔除部分臨時(shí)數(shù)據(jù)），這點(diǎn)上Redis更適合作為存儲(chǔ)而不是cache。
Memcached提供了cas命令，可以保證多個(gè)并發(fā)訪問(wèn)操作同一份數(shù)據(jù)的一致性問(wèn)題。 Redis沒(méi)有提供cas 命令，并不能保證這點(diǎn)，不過(guò)Redis提供了事務(wù)的功能，可以保證一串 命令的原子性，中間不會(huì)被任何操作打斷。
Memcached基本只支持簡(jiǎn)單的key-value存儲(chǔ)，不支持枚舉，不支持持久化和復(fù)制等功能
Redis除key/value之外，還支持list,set,sorted set,hash等眾多數(shù)據(jù)結(jié)構(gòu)，提供了KEYS
進(jìn)行枚舉操作，但不能在線上使用，如果需要枚舉線上數(shù)據(jù)，Redis提供了工具可以直接掃描其dump文件，枚舉出所有數(shù)據(jù)，Redis還同時(shí)提供了持久化和復(fù)制等功能。
在不同語(yǔ)言的客戶端方面，Memcached和Redis都有豐富的第三方客戶端可供選擇，不過(guò)因?yàn)镸emcached發(fā)展的時(shí)間更久一些，目前看在客戶端支持方面，Memcached的很多客戶端更加成熟穩(wěn)定，而Redis由于其協(xié)議本身就比Memcached復(fù)雜，加上作者不斷增加新的功能等，對(duì)應(yīng)第三方客戶端跟進(jìn)速度可能會(huì)趕不上，有時(shí)可能需要自己在第三方客戶端基礎(chǔ)上做些修改才能更好的使用。
根據(jù)以上比較不難看出，當(dāng)我們不希望數(shù)據(jù)被踢出，或者需要除key/value之外的更多數(shù)據(jù)類(lèi)型時(shí)，或者需要落地功能時(shí)，使用Redis比使用Memcached更合適。
關(guān)于Redis的一些周邊功能
Redis除了作為存儲(chǔ)之外還提供了一些其它方面的功能，比如聚合計(jì)算、pubsub、scripting等，對(duì)于此類(lèi)功能需要了解其實(shí)現(xiàn)原理，清楚地了解到它的局限性后，才能正確的使用，比如pubsub功能，這個(gè)實(shí)際是沒(méi)有任何持久化支持的，消費(fèi)方連接閃斷或重連之間過(guò)來(lái)的消息是會(huì)全部丟失的，又比如聚合計(jì)算和scripting等功能受Redis單線程模型所限，是不可能達(dá)到很高的吞吐量的，需要謹(jǐn)慎使用。
總的來(lái)說(shuō)Redis作者是一位非常勤奮的開(kāi)發(fā)者，可以經(jīng)常看到作者在嘗試著各種不同的新鮮想法和思路，針對(duì)這些方面的功能就要求我們需要深入了解后再使用。
總結(jié)：
后續(xù)關(guān)于Redis文章計(jì)劃：
最近項(xiàng)目組有用到這三個(gè)緩存，去各自的官方看了下,覺(jué)得還真的各有千秋！今天特意歸納下各個(gè)緩存的優(yōu)缺點(diǎn)，僅供參考！
?Ehcache
在java項(xiàng)目廣泛的使用。它是一個(gè)開(kāi)源的、設(shè)計(jì)于提高在數(shù)據(jù)從RDBMS中取出來(lái)的高花費(fèi)、高延遲采取的一種緩存方案。正因?yàn)镋hcache具有健壯性（基于java開(kāi)發(fā)）、被認(rèn)證（具有apache 2.0 ?license）、充滿特色（稍后會(huì)詳細(xì)介紹），所以被用于大型復(fù)雜分布式web application的各個(gè)節(jié)點(diǎn)中。
什么特色？
1. ?夠快
Ehcache的發(fā)行有一段時(shí)長(zhǎng)了，經(jīng)過(guò)幾年的努力和不計(jì)其數(shù)的性能測(cè)試，Ehcache終被設(shè)計(jì)于large, high concurrency systems.
2. 夠簡(jiǎn)單
開(kāi)發(fā)者提供的接口非常簡(jiǎn)單明了，從Ehcache的搭建到運(yùn)用運(yùn)行僅僅需要的是你寶貴的幾分鐘。其實(shí)很多開(kāi)發(fā)者都不知道自己用在用Ehcache，Ehcache被廣泛的運(yùn)用于其他的開(kāi)源項(xiàng)目
比如：hibernate
3.夠袖珍
關(guān)于這點(diǎn)的特性，官方給了一個(gè)很可愛(ài)的名字small foot print ，一般Ehcache的發(fā)布版本不會(huì)到2M，V 2.2.3 ?才 668KB。
4.?夠輕量
核心程序僅僅依賴(lài)slf4j這一個(gè)包，沒(méi)有之一！
5.好擴(kuò)展
Ehcache提供了對(duì)大數(shù)據(jù)的內(nèi)存和硬盤(pán)的存儲(chǔ)，最近版本允許多實(shí)例、保存對(duì)象高靈活性、提供LRU、LFU、FIFO淘汰算法，基礎(chǔ)屬性支持熱配置、支持的插件多
6.監(jiān)聽(tīng)器
緩存管理器監(jiān)聽(tīng)器 （CacheManagerListener）和 緩存監(jiān)聽(tīng)器（CacheEvenListener）,做一些統(tǒng)計(jì)或數(shù)據(jù)一致性廣播挺好用的
如何使用？
夠簡(jiǎn)單就是Ehcache的一大特色，自然用起來(lái)just so easy!
貼一段基本使用代碼
CacheManager manager = CacheManager.newInstance("src/config/ehcache.xml"); Ehcache cache = new Cache("testCache", 5000, false, false, 5, 2); cacheManager.addCache(cache); 代碼中有個(gè)ehcache.xml文件，現(xiàn)在來(lái)介紹一下這個(gè)文件中的一些屬性 name:緩存名稱(chēng)。maxElementsInMemory：緩存最大個(gè)數(shù)。eternal:對(duì)象是否永久有效，一但設(shè)置了，timeout將不起作用。timeToIdleSeconds：設(shè)置對(duì)象在失效前的允許閑置時(shí)間（單位：秒）。僅當(dāng)eternal=false對(duì)象不是永久有效時(shí)使用，可選屬性，默認(rèn)值是0，也就是可閑置時(shí)間無(wú)窮大。timeToLiveSeconds：設(shè)置對(duì)象在失效前允許存活時(shí)間,最大時(shí)間介于創(chuàng)建時(shí)間和失效時(shí)間之間。僅當(dāng)eternal=false對(duì)象不是永久有效時(shí)使用，默認(rèn)是0.，也就是對(duì)象存活時(shí) 間無(wú)窮大。overflowToDisk：當(dāng)內(nèi)存中對(duì)象數(shù)量達(dá)到maxElementsInMemory時(shí)，Ehcache將會(huì)對(duì)象寫(xiě)到磁盤(pán)中。diskSpoolBufferSizeMB：這個(gè)參數(shù)設(shè)置DiskStore（磁盤(pán)緩存）的緩存區(qū)大小。默認(rèn)是30MB。每個(gè)Cache都應(yīng)該有自己的一個(gè)緩沖區(qū)。maxElementsOnDisk：硬盤(pán)最大緩存?zhèn)€數(shù)。diskPersistent：是否緩存虛擬機(jī)重啟期數(shù)據(jù) Whether the disk store persists between restarts of the Virtual Machine. The default value is false.diskExpiryThreadIntervalSeconds：磁盤(pán)失效線程運(yùn)行時(shí)間間隔，默認(rèn)是120秒。memoryStoreEvictionPolicy：當(dāng)達(dá)到maxElementsInMemory限制時(shí)，Ehcache將會(huì)根據(jù)指定的策略去清理內(nèi)存。默認(rèn)策略是LRU。你可以設(shè)置為 FIFO或是LFU。clearOnFlush：內(nèi)存數(shù)量最大時(shí)是否清除。?
memcache
memcache 是一種高性能、分布式對(duì)象緩存系統(tǒng)，最初設(shè)計(jì)于緩解動(dòng)態(tài)網(wǎng)站數(shù)據(jù)庫(kù)加載數(shù)據(jù)的延遲性，你可以把它想象成一個(gè)大的內(nèi)存HashTable，就是一個(gè)key-value鍵值緩存。Danga Interactive為了LiveJournal所發(fā)展的，以BSD license釋放的一套開(kāi)放源代碼軟件。
1.依賴(lài)
memcache C語(yǔ)言所編寫(xiě)，依賴(lài)于最近版本的GCC和libevent。GCC是它的編譯器，同事基于libevent做socket io。在安裝memcache時(shí)保證你的系統(tǒng)同事具備有這兩個(gè)環(huán)境。
2.多線程支持
memcache支持多個(gè)cpu同時(shí)工作，在memcache安裝文件下有個(gè)叫threads.txt中特別說(shuō)明，By default, memcached is compiled as a single-threaded application.默認(rèn)是單線程編譯安裝，如果你需要多線程則需要修改./configure --enable-threads，為了支持多核系統(tǒng)，前提是你的系統(tǒng)必須具有多線程工作模式。開(kāi)啟多線程工作的線程數(shù)默認(rèn)是4，如果線程數(shù)超過(guò)cpu數(shù)容易發(fā)生操作死鎖的概率。結(jié)合自己業(yè)務(wù)模式選擇才能做到物盡其用。
3.高性能
通過(guò)libevent完成socket 的通訊，理論上性能的瓶頸落在網(wǎng)卡上。
簡(jiǎn)單安裝：
1.分別把memcached和libevent下載回來(lái)，放到 /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 沒(méi)有安裝則先安裝gcc)
# make install
3.測(cè)試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
還不錯(cuò)，都安裝上了。
4.安裝memcached，同時(shí)需要安裝中指定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)報(bào)錯(cuò)，請(qǐng)仔細(xì)檢查錯(cuò)誤信息，按照錯(cuò)誤信息來(lái)配置或者增加相應(yīng)的庫(kù)或者路徑。
安裝完成后會(huì)把memcached放到 /usr/local/bin/memcached ，
5.測(cè)試是否成功安裝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
啟動(dòng)Memcached服務(wù)：
1.啟動(dòng)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選項(xiàng)是啟動(dòng)一個(gè)守護(hù)進(jìn)程，
-m是分配給Memcache使用的內(nèi)存數(shù)量，單位是MB，我這里是8096MB，
-u是運(yùn)行Memcache的用戶，我這里是root，
-l是監(jiān)聽(tīng)的服務(wù)器IP地址，如果有多個(gè)地址的話，我這里指定了服務(wù)器的IP地址192.168.77.105，
-p是設(shè)置Memcache監(jiān)聽(tīng)的端口，我這里設(shè)置了12000，最好是1024以上的端口，
-c選項(xiàng)是最大運(yùn)行的并發(fā)連接數(shù)，默認(rèn)是1024，我這里設(shè)置了256，按照你服務(wù)器的負(fù)載量來(lái)設(shè)定，
-P是設(shè)置保存Memcache的pid文件，我這里是保存在 /tmp/memcached.pid，
?
2.如果要結(jié)束Memcache進(jìn)程，執(zhí)行：
# cat?/tmp/memcached.pid 或者 ps -aux | grep memcache ? （找到對(duì)應(yīng)的進(jìn)程id號(hào)）
# kill 進(jìn)程id號(hào)
也可以啟動(dòng)多個(gè)守護(hù)進(jìn)程，不過(guò)端口不能重復(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)運(yùn)行的秒數(shù)
time ? ? ? ? ? 服務(wù)器當(dāng)前的unix時(shí)間戳
version ? ? memcache版本
pointer_size ? ? ? ? 當(dāng)前操作系統(tǒng)的指針大小（32位系統(tǒng)一般是32bit）
rusage_user ? ? ? ? ?進(jìn)程的累計(jì)用戶時(shí)間
rusage_system ? ?進(jìn)程的累計(jì)系統(tǒng)時(shí)間
curr_items ? ? ? ? ? ?服務(wù)器當(dāng)前存儲(chǔ)的items數(shù)量
total_items ? ? ? ? ? 從服務(wù)器啟動(dòng)以后存儲(chǔ)的items總數(shù)量
bytes ? ? ? ? ? ? ? ? ? ? ? 當(dāng)前服務(wù)器存儲(chǔ)items占用的字節(jié)數(shù)
curr_connections ? ? ? ?當(dāng)前打開(kāi)著的連接數(shù)
total_connections ? ? ? ?從服務(wù)器啟動(dòng)以后曾經(jīng)打開(kāi)過(guò)的連接數(shù)
connection_structures ? ? ? ? ?服務(wù)器分配的連接構(gòu)造數(shù)
cmd_get get命令 ? ? ? ? ?（獲取）總請(qǐng)求次數(shù)
cmd_set set命令 ? ? ? ? ?（保存）總請(qǐng)求次數(shù)
get_hits ? ? ? ? ?總命中次數(shù)
get_misses ? ? ? ?總未命中次數(shù)
evictions ? ? 為獲取空閑內(nèi)存而刪除的items數(shù)（分配給memcache的空間用滿后需要?jiǎng)h除舊的items來(lái)得到空間分配給新的items）
bytes_read ? ?讀取字節(jié)數(shù)（請(qǐng)求字節(jié)數(shù)）
bytes_written ? ? 總發(fā)送字節(jié)數(shù)（結(jié)果字節(jié)數(shù)）
limit_maxbytes ? ? 分配給memcache的內(nèi)存大小（字節(jié)）
threads ? ? ? ? 當(dāng)前線程數(shù)
redis
?redis是在memcache之后編寫(xiě)的，大家經(jīng)常把這兩者做比較，如果說(shuō)它是個(gè)key-value store 的話但是它具有豐富的數(shù)據(jù)類(lèi)型，我想暫時(shí)把它叫做緩存數(shù)據(jù)流中心，就像現(xiàn)在物流中心那樣，order、package、store、classification、distribute、end。現(xiàn)在還很流行的LAMP PHP架構(gòu) 不知道和 redis+mysql 或者 redis + mongodb的性能比較（聽(tīng)群里的人說(shuō)mongodb分片不穩(wěn)定）。
先說(shuō)說(shuō)reidis的特性
1. 支持持久化
? ? ?redis的本地持久化支持兩種方式：RDB和AOF。RDB 在redis.conf配置文件里配置持久化觸發(fā)器，AOF指的是redis每增加一條記錄都會(huì)保存到持久化文件中（保存的是這條記錄的生成命令），如果不是用redis做DB用的話還會(huì)不要開(kāi)AOF ，數(shù)據(jù)太龐大了，重啟恢復(fù)的時(shí)候是一個(gè)巨大的工程！
2.豐富的數(shù)據(jù)類(lèi)型
? ? redis 支持 String 、Lists、sets、sorted sets、hashes 多種數(shù)據(jù)類(lèi)型,新浪微博會(huì)使用redis做nosql主要也是它具有這些類(lèi)型，時(shí)間排序、職能排序、我的微博、發(fā)給我的這些功能List 和 sorted set?的強(qiáng)大操作功能息息相關(guān)
?3.高性能
? ?這點(diǎn)跟memcache很相像，內(nèi)存操作的級(jí)別是毫秒級(jí)的比硬盤(pán)操作秒級(jí)操作自然高效不少，較少了磁頭尋道、數(shù)據(jù)讀取、頁(yè)面交換這些高開(kāi)銷(xiāo)的操作！這也是NOSQL冒出來(lái)的原因吧，應(yīng)該是高性能是基于RDBMS的衍生產(chǎn)品，雖然RDBMS也具有緩存結(jié)構(gòu)，但是始終在app層面不是我們想要的那么操控的。
4.replication
? ? redis提供主從復(fù)制方案，跟mysql一樣增量復(fù)制而且復(fù)制的實(shí)現(xiàn)都很相似，這個(gè)復(fù)制跟AOF有點(diǎn)類(lèi)似復(fù)制的是新增記錄命令，主庫(kù)新增記錄將新增腳本發(fā)送給從庫(kù)，從庫(kù)根據(jù)腳本生成記錄，這個(gè)過(guò)程非常快，就看網(wǎng)絡(luò)了，一般主從都是在同一個(gè)局域網(wǎng)，所以可以說(shuō)redis的主從近似及時(shí)同步，同事它還支持一主多從，動(dòng)態(tài)添加從庫(kù)，從庫(kù)數(shù)量沒(méi)有限制。 主從庫(kù)搭建，我覺(jué)得還是采用網(wǎng)狀模式，如果使用鏈?zhǔn)?#xff08;master-slave-slave-slave-slave·····）如果第一個(gè)slave出現(xiàn)宕機(jī)重啟，首先從master 接收數(shù)據(jù)恢復(fù)腳本，這個(gè)是阻塞的，如果主庫(kù)數(shù)據(jù)幾TB的情況恢復(fù)過(guò)程得花上一段時(shí)間，在這個(gè)過(guò)程中其他的slave就無(wú)法和主庫(kù)同步了。
5.更新快
? ?這點(diǎn)好像從我接觸到redis到目前為止 已經(jīng)發(fā)了大版本就4個(gè)，小版本沒(méi)算過(guò)。redis作者是個(gè)非常積極的人，無(wú)論是郵件提問(wèn)還是論壇發(fā)帖，他都能及時(shí)耐心的為你解答，維護(hù)度很高。有人維護(hù)的話，讓我們用的也省心和放心。目前作者對(duì)redis 的主導(dǎo)開(kāi)發(fā)方向是redis的集群方向。
redis的安裝
redis的安裝其實(shí)還是挺簡(jiǎn)單的，總的來(lái)說(shuō)就三步：下載tar包，解壓tar包，安裝。
不過(guò)最近我在2.6.7后用centos 5.5 32bit 時(shí)碰到一個(gè)安裝問(wèn)題，下面我就用圖片分享下安裝過(guò)程碰到的問(wèn)題，在redis 文件夾內(nèi)執(zhí)行make時(shí)有個(gè)如下的錯(cuò)?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安裝。就不會(huì)發(fā)現(xiàn)原來(lái)那個(gè)錯(cuò)誤了
關(guān)于redis的一些屬性注釋和基本類(lèi)型操作在上一篇redis 的開(kāi)胃菜有詳細(xì)的說(shuō)明，這里就不再重復(fù)累贅了（實(shí)質(zhì)是想偷懶 ，哈哈！）
?
最后，把memcache和redis放在一起不得不會(huì)讓人想到兩者的比較，誰(shuí)快誰(shuí)好用啊，群里面已經(jīng)為這個(gè)事打架很久了，我就把我看到的在這里跟大家分享下。
在別人發(fā)了一個(gè)memcache性能比redis好很多后，redis 作者 antirez 發(fā)表了一篇博文，主要是說(shuō)到如何給redis 和 memcache 做壓力測(cè)試，文中講到有個(gè)人說(shuō)許多開(kāi)源軟件都應(yīng)該丟進(jìn)廁所，因?yàn)樗麄兊膲毫y(cè)試腳本太2了，作者對(duì)這個(gè)說(shuō)明了一番。redis ?vs ?memcache is??definitely an apple to apple comparison。 呵呵，很明確吧，兩者的比較是不是有點(diǎn)雞蛋挑骨頭的效果，作者在相同的運(yùn)行環(huán)境做了三次測(cè)試取多好的值，得到的結(jié)果如下圖:
需要申明的是此次測(cè)試在單核心處理的過(guò)程的數(shù)據(jù)，memcache是支持多核心多線程操作的（默認(rèn)沒(méi)開(kāi)）所以在默認(rèn)情況下上圖具有參考意義，若然則memcache快于redis。那為什么redis不支持多線程多核心處理呢？作者也發(fā)表了一下自己的看法，首先是多線程不變于bug的修復(fù)，其實(shí)是不易軟件的擴(kuò)展，還有數(shù)據(jù)一致性問(wèn)題因?yàn)閞edis所有的操作都是原子操作，作者用到一個(gè)詞nightmare 噩夢(mèng)，呵呵！ ?當(dāng)然不支持多線程操作，肯定也有他的弊端的比如性能想必必然差，作者從2.2版本后專(zhuān)注redis cluster的方向開(kāi)發(fā)來(lái)緩解其性能上的弊端，說(shuō)白了就是縱向不行，橫向提高。
轉(zhuǎn)載于:https://www.cnblogs.com/duanxz/p/5215274.html
總結(jié)
以上是生活随笔為你收集整理的NoSQL分类及ehcache memcache redis 三大缓存的对比的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： Luogu P4114 Qtree1
- 下一篇： powerdesigner中如何在自动生