NoSQL分類及ehcache memcache redis 三大緩存的對比

NoSQL分類

因爲NoSQL中沒有像傳統數據庫那樣定義數據的組織方式爲關係型的，因此只要內部的數據組織採用了非關係型的方式，就能夠稱之爲NoSQL數據庫。
目前，能夠將衆多的NoSQL數據庫按照內部的數據組織形式進行以下分類：

• Key/Value的NoSQL數據庫
• 面向文檔的NoSQL數據庫
• 面向列的NoSQL數據庫
• 面向圖的NoSQL數據庫

不一樣的數據組織適合於不一樣的應用場景，後面將進行介紹。

爲何要使用NoSQL
ＳＱＬ語言和關係型數據庫（My SQL、PostgreSQL、Oracle等） 是通用的數據解決方案，佔有絕大多數的市場。不過在最近興起的NoSQL運動中，涌現出一批具有高可用性、支持線性擴展、支持Map/Reduce操做等特性的數據產品，它們具備以下特性：

1. 頻繁的寫入操做、相對較少的讀取統計信息的操做（如網站訪問計數器），應該使用基於內存的Key/Value（鍵／值）存儲系統（如redis） 或者是具有本地更新特性的文檔存儲系統（如MongoDB）。
2. 海量數據（如數據倉庫中須要分析的數據） 適合存儲在一個結構鬆散、分佈式的文件存儲系統中，如Hadoop。
3. 存儲二進制文件（如mp3或者pdf文檔） 而且可以直接爲用戶的瀏覽器提供下載功能，可使用Amazon S3。
4. 臨時性的數據（如網站的session、緩存HＴＭＬ頁面信息等） 適合存儲在Memcache中。
5. 若是但願數據具有高可用性，而且可以將數據丟失的風險降到最低，同時整個系統具有線性擴展的能力，能夠考慮使用Cassandra和HBase。

Key/Value的NoSQL庫

1 memcached
memcached是國外社區網站LiveJournal開發的高性能的內存Key/Value緩存服務器，目的是經過緩存數據庫查詢結果，減小數據庫訪問次數，以提升動態Ｗeb應用的速度，從而提升系統的可擴展性。

2 redis
redis是一款先進的Key/Value存儲系統。它與Memcached相似，區別以下：
redis不只支持簡單的Key/Value類型的數據，同時還提供list、set、hash等數據結構的存儲。
redis支持數據的備份，即master slave模式的數據備份。
redis支持數據的持久化，能夠將內存中的數據保持在磁盤中，重啓的時候再次加載進行使用。
在redis中，並非全部的數據都一直存儲在內存中。redis只會緩存全部的Key的信息，若是redis發現內存的使用量超過了某個閾值，將觸發交換（swap） 的操做。redis根據「swappabillity=age*log(size_in_memory)」 計算出哪些Key對應的Value須要交換到磁盤，而後再將這些key對應的value持久化到磁盤中，同時在內存中清除。這種特性使得redis能夠保持超過其機器自己內存大小的數據。固然，機器自己的內存必需要可以保持全部的ｋey，畢竟這些數據是不會進行交換操做的。同時因爲redis將內存中的數據交換到磁盤中的時候，提供服務的主線程和進行交換操做的子線程會共享這部份內存，因此若是更新須要交換的數據，redis將阻塞這個操做，直到子線程完成交換操做後才能夠進行修改。
3 Dynamo
Dynamo是亞馬遜公司開發的一款分佈式Key/Value存儲系統，用於存儲用戶的購物車信息。Dynamo與傳統的Key/Value存儲系統相比，最大的優點在於無單點故障，整個系統的可用性很是高，同時具有數據的最終一致性。

面向文檔的NoSQL數據庫
1 MongoDB
　　MongoDB是一個高性能、開源、模式自由（schma free） 的文檔型數據庫，它在許多場景下可用於替代傳統的關係型數據庫或Key/Value存儲方式。MongoDB使用C++開發，具備如下特性：

1. 面向文檔的存儲，適合存儲對象及JＳＯＮ形式的數據。
2. 動態查詢，MongoDB支持豐富的查詢表達式。查詢指令使用JＳＯＮ形式的標記，可輕易查詢文檔中內嵌的對象及數組。
3. 完整的索引支持，包括文檔內嵌對象及數組。MongoDB的查詢優化器會分析查詢表達式，並生成一個高效的查詢計劃。
4. 查詢監視，MongoDB包含一個監視工具用於分析數據庫操做的性能。
5. 複製及自動故障轉移，MongoDB數據庫支持服務器之間的數據複製，支持主－從模式（Master/Slave）及服務器之間的相互複製。複製的主要目標是提供冗餘及自動故障轉移。
6. 高效的傳統存儲方式，支持二進制數據及大型對象（如照片或圖片）。
7. 自動分片以支持雲級別的伸縮性，自動分片功能支持水平的數據庫集羣，可動態添加額外的機器。
8. 模式自由，意味着對於存儲在MongoDB數據庫中的文件，咱們不須要知道它的任何結構定義。
9. 支持Map/Reduce計算，表明MongoDB具備強大的數據分析能力。

2 CouchDB
　　CouchDB是Apache社區中的一款文檔型數據庫服務器。與如今流行的關係數據庫服務器不一樣，CouchDB是圍繞一系列語義上自包含的文檔而組織的。CouchDB中的文檔是模式自由的，也就是說，並不要求文檔具備某種特定的結構。CouchDB的這種特性使得它相對於傳統的關係數據庫而言，有本身的適用範圍。通常來講，圍繞文檔來構建的應用都比較適合使用CouchDB做爲其後臺存儲。CouchDB強調其中所存儲的文檔，在語義上是自包含的。這種面向文檔的設計思路，更貼近不少應用的問題域的真實狀況。對於這類應用，使用CouchDB的文檔來進行建模，會更加天然和簡單。與此同時，CouchDB也提供基於Map/Reduce編程模型的視圖來對文檔進行查詢，能夠提供相似於關係數據庫中ＳＱＬ語句的能力。CouchDB對於不少應用來講，提供了關係數據庫以外的更好的選擇。

　面向列的NoSQL數據庫
1 Cassandra
Cassandra是一款面向列的NoSQL數據庫，和Google的Bigtable數據庫屬於同一類。此數據庫比一個相似Dynamo的Key/Value數據庫功能更多，但相比於面向文檔的數據庫（如MongoDB），它所支持的查詢類型要少。

1. Cassandra結合了Dynamo的Key/Value與Bigtable的面向列的特色。
2. 模式靈活：數據不須要像數據庫同樣使用預先設計的模式，增長或者刪除字段很是方便（ｏｎｔｈeｆｌy）。
3. 支持範圍查詢：能夠對任意Ｋey進行範圍查詢。
4. 支持二級索引查詢：能夠對任意列（Ｃｏｌuｍｎ）的值進行查詢。
5. 支持Map/Reduce計算：能夠對Cassandra中的數據批量進行復雜的分析計算。
6. 數據具有最終一致性，集羣總體的可用性很是高。
7. 高可用，可擴展：單點故障不影響集羣服務，集羣的性能可線性擴展。
8. 數據可靠性高：一旦數據寫入成功，數據就已經在機器的磁盤中完成了存儲，不容易丟失。

HBase
HBase是Hadoop項目中的數據庫。它用於須要對大量的數據進行隨機、實時的讀寫操做的場景中。HBase的目標就是處理數據量很是龐大的表，能夠用普通的計算機處理超過１０億行數據，還可處理有數百萬列元素的數據表。
HBase是一個開源的、分佈式的、支持多版本的、面向列存儲的GoogleBigtable實現。
HBase的實現基於Hadoop分佈式文件系統（HDFS），模仿並提供了基於Google文件系統的Bigtable數據庫的全部功能。HBase有以下特色：

1. 能夠直接從HBase中讀取數據運行Map/Reduce任務，並能夠將運行後的結果直接寫入HBase中。
2. 數據查詢過濾和掃描操做在服務器端進行。
3. 爲實時查詢作了特殊優化。
4. 使用高性能的Thrift通訊框架。
5. 支持REST、Protobuf以及二進制形式的數據交互。
6. 能夠與Cascading、Hive和Piｇ配合使用，從而提升使用的效率。
7. 提供可擴展的JRuby（JＩRＢ）的命令行工具。
8. 支持Ｇａｎｇｌiａ和JＭＸ，可以方便監視整個程序的運行狀態。

面向圖的NoSQL數據庫
Ｎeｏ４J是一個用Jａvａ實現、徹底兼容ＡＣＩＤ的圖形數據庫。數據以一種針對圖形網絡進行過優化的格式保存在磁盤上。Ｎeｏ４J的內核是一種極快的圖形引擎，具備數據庫產品指望的全部特性，如恢復、兩階段提交、符合ＸＡ等。自２００３年起，Ｎeｏ４J就已經做爲７２４的產品使用。該項目已經發布了１２版，它是關於伸縮性和社區測試的一個主要里程碑。經過聯機備份實現的高可用性和主從複製功能目前處於測試階段，預計在下一版本中發佈。Ｎeｏ４J既可做爲無須任何管理開銷的內嵌數據庫使用，也能夠做爲單獨的服務器使用，在這種使用場景下，它提供了普遍使用的REST接口，可以方便地集成到基於PHP、ＮＥＴ和JａvａＳｃｒiｐｔ的環境裏。
Ｎeｏ４J的特色以下：

1. 用直觀的圖模型取代了嚴格定義的表模型，從而可使用節點（ｎｏｄe）、關係（ｒeｌａｔiｏｎｓｈiｐ）、屬性（ｐｒｏｐeｒｔy）來表達複雜的數據模型，如圖１－２所示。
   
   
2. 針對磁盤存儲進行了特殊優化，使得其具有優異的性能和可擴展性。
3. 每一臺Ｎeｏ４J服務器均可以處理上１０億的數據，而且能夠經過水平拆分支持更大的數據量。
4. 包含高效的圖遍歷算法，大大提升了數據的查詢和分析能力。
5. 程序自己很是簡單小巧，核心功能的Jａｒ包大小隻有５００ＫＢ。
6. 具有簡單好用的編程接口，方便程序的開發。

 

示例：

如圖１－１所示，能夠在一個網站中使用４款數據產品來提供服務。

1. My SQL用於存儲敏感的數據，好比用戶的資料、交易的信息等。
2. MongoDB用於存儲大量的、相對不敏感的數據，好比博客文章的內容、文章訪問次數等。
3. Amazon S3用於存儲用戶上傳的文檔、圖片、音樂等數據。
4. Memcacheｄ用於存儲臨時性的信息，好比緩存HＴＭＬ頁面等。

選擇多樣的數據存儲方案一樣有利於提高咱們對NoSQL的數據產品的理解，幫助咱們從大量的解決方案中選擇最適用的產品，而不是把眼光僅僅放在某一款產品上。
核心的思想是：最適用的纔是最好的。

Redis與Memcached的比較

一、Redis和Memcache都是將數據存放在內存中，都是內存數據庫。不過memcache還可用於緩存其餘東西，例如圖片、視頻等等，而Redis，並非全部的數據都一直存儲在內存中的。
二、Redis不只僅支持簡單的k/v類型的數據，同時還提供list，set，hash等數據結構的存儲。
三、虛擬內存--Redis當物理內存用完時，能夠將一些好久沒用到的value 交換到磁盤
四、過時策略--memcache在set時就指定，例如set key1 0 0 8,即永不過時。Redis能夠經過例如expire 設定，例如expire name 10
五、分佈式--設定memcache集羣，利用magent作一主多從;redis能夠作一主多從。均可以一主一從
六、存儲數據安全--memcache掛掉後，數據沒了；redis能夠按期保存到磁盤（持久化），重啓的時候能夠再次加載進行使用。
七、災難恢復--memcache掛掉後，數據不可恢復; redis數據丟失後能夠經過aof恢復
八、Redis支持數據的備份，即master-slave模式的數據備份

Redis在不少方面具有數據庫的特徵，或者說就是一個數據庫系統，而Memcached只是簡單的K/V緩存

實現原理等不一樣：

1. 網絡IO模型

Memcached是多線程，非阻塞IO複用的網絡模型，分爲監聽主線程和worker子線程，監聽線程監聽網絡鏈接，接受請求後，將鏈接描述字pipe 傳遞給worker線程，進行讀寫IO, 網絡層使用libevent封裝的事件庫，多線程模型能夠發揮多核做用，可是引入了cache coherency和鎖的問題，好比，Memcached最經常使用的stats 命令，實際Memcached全部操做都要對這個全局變量加鎖，進行計數等工做，帶來了性能損耗。

（Memcached網絡IO模型）

Redis使用單線程的IO複用模型，本身封裝了一個簡單的AeEvent事件處理框架，主要實現了epoll、kqueue和select，對於單純只有IO操做來講，單線程能夠將速度優點發揮到最大，可是Redis也提供了一些簡單的計算功能，好比排序、聚合等，對於這些操做，單線程模型實際會嚴重影響總體吞吐量，CPU計算過程當中，整個IO調度都是被阻塞住的。

1. 內存管理方面

Memcached使用預分配的內存池的方式，使用slab和大小不一樣的chunk來管理內存，Item根據大小選擇合適的chunk存儲，內存池的方式能夠省去申請/釋放內存的開銷，而且能減少內存碎片產生，但這種方式也會帶來必定程度上的空間浪費，而且在內存仍然有很大空間時，新的數據也可能會被剔除，緣由能夠參考Timyang的文章：http://timyang.net/data/Memcached-lru-evictions/

Redis使用現場申請內存的方式來存儲數據，而且不多使用free-list等方式來優化內存分配，會在必定程度上存在內存碎片，Redis跟據存儲命令參數，會把帶過時時間的數據單獨存放在一塊兒，並把它們稱爲臨時數據，非臨時數據是永遠不會被剔除的，即使物理內存不夠，致使swap也不會剔除任何非臨時數據（但會嘗試剔除部分臨時數據），這點上Redis更適合做爲存儲而不是cache。

1. 數據一致性問題

Memcached提供了cas命令，能夠保證多個併發訪問操做同一份數據的一致性問題。 Redis沒有提供cas 命令，並不能保證這點，不過Redis提供了事務的功能，能夠保證一串 命令的原子性，中間不會被任何操做打斷。

1. 存儲方式及其它方面

Memcached基本只支持簡單的key-value存儲，不支持枚舉，不支持持久化和複製等功能

Redis除key/value以外，還支持list,set,sorted set,hash等衆多數據結構，提供了KEYS

進行枚舉操做，但不能在線上使用，若是須要枚舉線上數據，Redis提供了工具能夠直接掃描其dump文件，枚舉出全部數據，Redis還同時提供了持久化和複製等功能。

1. 關於不一樣語言的客戶端支持

在不一樣語言的客戶端方面，Memcached和Redis都有豐富的第三方客戶端可供選擇，不過由於Memcached發展的時間更久一些，目前看在客戶端支持方面，Memcached的不少客戶端更加成熟穩定，而Redis因爲其協議自己就比Memcached複雜，加上做者不斷增長新的功能等，對應第三方客戶端跟進速度可能會趕不上，有時可能須要本身在第三方客戶端基礎上作些修改才能更好的使用。

根據以上比較不難看出，當咱們不但願數據被踢出，或者須要除key/value以外的更多數據類型時，或者須要落地功能時，使用Redis比使用Memcached更合適。

關於Redis的一些周邊功能

Redis除了做爲存儲以外還提供了一些其它方面的功能，好比聚合計算、pubsub、scripting等，對於此類功能須要瞭解其實現原理，清楚地瞭解到它的侷限性後，才能正確的使用，好比pubsub功能，這個實際是沒有任何持久化支持的，消費方鏈接閃斷或重連之間過來的消息是會所有丟失的，又好比聚合計算和scripting等功能受Redis單線程模型所限，是不可能達到很高的吞吐量的，須要謹慎使用。

總的來講Redis做者是一位很是勤奮的開發者，能夠常常看到做者在嘗試着各類不一樣的新鮮想法和思路，針對這些方面的功能就要求咱們須要深刻了解後再使用。

總結：

1. Redis使用最佳方式是所有數據in-memory。
2. Redis更多場景是做爲Memcached的替代者來使用。
3. 當須要除key/value以外的更多數據類型支持時，使用Redis更合適。
4. 當存儲的數據不能被剔除時，使用Redis更合適。

後續關於Redis文章計劃：

1. Redis數據類型與容量規劃。
2. 如何根據業務場景搭建穩定，可靠，可擴展的Redis集羣。
3. 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!

貼一段基本使用代碼

CacheManager manager = CacheManager.newInstance("src/config/ehcache.xml");
Ehcache cache = new Cache("testCache", 5000, false, false, 5, 2);
cacheManager.addCache(cache);

代碼中有個ehcache.xml文件，如今來介紹一下這個文件中的一些屬性

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

# cd /tmp

# tar zxvf memcached-1.2.0.tar.gz

# cd memcached-1.2.0

# ./configure -with-libevent=/usr

# make

# make install

若是中間出現報錯，請仔細檢查錯誤信息，按照錯誤信息來配置或者增長相應的庫或者路徑。

安裝完成後會把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

啓動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

 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 的強大操做功能息息相關

 3.高性能

   這點跟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的方向開發來緩解其性能上的弊端，說白了就是縱向不行，橫向提升。