NoSQL分類及ehcache memcache redis 三大快取的對比

NO IMAGE
1 Star2 Stars3 Stars4 Stars5 Stars 給文章打分!
Loading...

NoSQL分類

由於NoSQL中沒有像傳統資料庫那樣定義資料的組織方式為關係型的,所以只要內部的資料組織採用了非關係型的方式,就可以稱之為NoSQL資料庫。
目前,可以將眾多的NoSQL資料庫按照內部的資料組織形式進行如下分類:

  • Key/Value的NoSQL資料庫
  • 面向文件的NoSQL資料庫
  • 面向列的NoSQL資料庫
  • 面向圖的NoSQL資料庫

不同的資料組織適合於不同的應用場景,後面將進行介紹。

為什麼要使用NoSQL
SQL語言和關係型資料庫(My SQL、PostgreSQL、Oracle等) 是通用的資料解決方案,佔有絕大多數的市場。不過在最近興起的NoSQL運動中,湧現出一批具備高可用性、支援線性擴充套件、支援Map/Reduce操作等特性的資料產品,它們具有如下特性:

  1. 頻繁的寫入操作、相對較少的讀取統計資訊的操作(如網站訪問計數器),應該使用基於記憶體的Key/Value(鍵/值)儲存系統(如redis) 或者是具備本地更新特性的文件儲存系統(如MongoDB)。
  2. 海量資料(如資料倉儲中需要分析的資料) 適合儲存在一個結構鬆散、分散式的檔案儲存系統中,如Hadoop。
  3. 儲存二進位制檔案(如mp3或者pdf文件) 並且能夠直接為使用者的瀏覽器提供下載功能,可以使用Amazon S3。
  4. 臨時性的資料(如網站的session、快取HTML頁面資訊等) 適合儲存在Memcache中。
  5. 如果希望資料具備高可用性,並且能夠將資料丟失的風險降到最低,同時整個系統具備線性擴充套件的能力,可以考慮使用Cassandra和HBase。

Key/Value的NoSQL庫

1 memcached
memcached是國外社群網站LiveJournal開發的高效能的記憶體Key/Value快取伺服器,目的是通過快取資料庫查詢結果,減少資料庫訪問次數,以提高動態Web應用的速度,從而提高系統的可擴充套件性。

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可以保持超過其機器本身記憶體大小的資料。當然,機器本身的記憶體必須要能夠保持所有的key,畢竟這些資料是不會進行交換操作的。同時由於redis將記憶體中的資料交換到磁碟中的時候,提供服務的主執行緒和進行交換操作的子執行緒會共享這部分記憶體,所以如果更新需要交換的資料,redis將阻塞這個操作,直到子執行緒完成交換操作後才可以進行修改。
3 Dynamo
Dynamo是亞馬遜公司開發的一款分散式Key/Value儲存系統,用於儲存使用者的購物車資訊。Dynamo與傳統的Key/Value儲存系統相比,最大的優勢在於無單點故障,整個系統的可用性非常高,同時具備資料的最終一致性。

面向文件的NoSQL資料庫
1 MongoDB
  MongoDB是一個高效能、開源、模式自由(schma free) 的文件型資料庫,它在許多場景下可用於替代傳統的關係型資料庫或Key/Value儲存方式。MongoDB使用C 開發,具有以下特性:

  1. 面向文件的儲存,適合儲存物件及JSON形式的資料。
  2. 動態查詢,MongoDB支援豐富的查詢表示式。查詢指令使用JSON形式的標記,可輕易查詢文件中內嵌的物件及陣列。
  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程式設計模型的檢視來對文件進行查詢,可以提供類似於關聯式資料庫中SQL語句的能力。CouchDB對於很多應用來說,提供了關聯式資料庫之外的更好的選擇。

 面向列的NoSQL資料庫
1 Cassandra
Cassandra是一款面向列的NoSQL資料庫,和Google的Bigtable資料庫屬於同一類。此資料庫比一個類似Dynamo的Key/Value資料庫功能更多,但相比於面向文件的資料庫(如MongoDB),它所支援的查詢型別要少。

  1. Cassandra結合了Dynamo的Key/Value與Bigtable的面向列的特點。
  2. 模式靈活:資料不需要像資料庫一樣使用預先設計的模式,增加或者刪除欄位非常方便(onthefly)。
  3. 支援範圍查詢:可以對任意Key進行範圍查詢。
  4. 支援二級索引查詢:可以對任意列(Column)的值進行查詢。
  5. 支援Map/Reduce計算:可以對Cassandra中的資料批量進行復雜的分析計算。
  6. 資料具備最終一致性,叢集整體的可用性非常高。
  7. 高可用,可擴充套件:單點故障不影響叢集服務,叢集的效能可線性擴充套件。
  8. 資料可靠性高:一旦資料寫入成功,資料就已經在機器的磁碟中完成了儲存,不容易丟失。

HBase
HBase是Hadoop專案中的資料庫。它用於需要對大量的資料進行隨機、實時的讀寫操作的場景中。HBase的目標就是處理資料量非常龐大的表,可以用普通的計算機處理超過10億行資料,還可處理有數百萬列元素的資料表。
HBase是一個開源的、分散式的、支援多版本的、面向列儲存的GoogleBigtable實現。
HBase的實現基於Hadoop分散式檔案系統(HDFS),模仿並提供了基於Google檔案系統的Bigtable資料庫的所有功能。HBase有如下特點:

  1. 可以直接從HBase中讀取資料執行Map/Reduce任務,並可以將執行後的結果直接寫入HBase中。
  2. 資料查詢過濾和掃描操作在伺服器端進行。
  3. 為實時查詢做了特殊優化。
  4. 使用高效能的Thrift通訊框架。
  5. 支援REST、Protobuf以及二進位制形式的資料互動。
  6. 可以與Cascading、Hive和Pig配合使用,從而提高使用的效率。
  7. 提供可擴充套件的JRuby(JIRB)的命令列工具。
  8. 支援Ganglia和JMX,能夠方便監視整個程式的執行狀態。

面向圖的NoSQL資料庫
Neo4J是一個用Java實現、完全相容ACID的圖形資料庫。資料以一種針對圖形網路進行過優化的格式儲存在磁碟上。Neo4J的核心是一種極快的圖形引擎,具有資料庫產品期望的所有特性,如恢復、兩階段提交、符合XA等。自2003年起,Neo4J就已經作為724的產品使用。該專案已經發布了12版,它是關於伸縮性和社群測試的一個主要里程碑。通過聯機備份實現的高可用性和主從複製功能目前處於測試階段,預計在下一版本中釋出。Neo4J既可作為無須任何管理開銷的內嵌資料庫使用,也可以作為單獨的伺服器使用,在這種使用場景下,它提供了廣泛使用的REST介面,能夠方便地整合到基於PHP、NET和JavaScript的環境裡。
Neo4J的特點如下:

  1. 用直觀的圖模型取代了嚴格定義的表模型,從而可以使用節點(node)、關係(relationship)、屬性(property)來表達複雜的資料模型,如圖1-2所示。

  2. 針對磁碟儲存進行了特殊優化,使得其具備優異的效能和可擴充套件性。
  3. 每一臺Neo4J伺服器都可以處理上10億的資料,並且可以通過水平拆分支援更大的資料量。
  4. 包含高效的圖遍歷演算法,大大提高了資料的查詢和分析能力。
  5. 程式本身非常簡單小巧,核心功能的Jar包大小隻有500KB。
  6. 具備簡單好用的程式設計介面,方便程式的開發。

 

示例:

如圖1-1所示,可以在一個網站中使用4款資料產品來提供服務。

  1. My SQL用於儲存敏感的資料,比如使用者的資料、交易的資訊等。
  2. MongoDB用於儲存大量的、相對不敏感的資料,比如部落格文章的內容、文章訪問次數等。
  3. Amazon S3用於儲存使用者上傳的文件、圖片、音樂等資料。
  4. Memcached用於儲存臨時性的資訊,比如快取HTML頁面等。

選擇多樣的資料儲存方案同樣有利於提升我們對NoSQL的資料產品的理解,幫助我們從大量的解決方案中選擇最適用的產品,而不是把眼光僅僅放在某一款產品上。
核心的思想是:最適用的才是最好的。

Redis與Memcached的比較

1、Redis和Memcache都是將資料存放在記憶體中,都是記憶體資料庫。不過memcache還可用於快取其他東西,例如圖片、視訊等等,而Redis,並不是所有的資料都一直儲存在記憶體中的。
2、Redis不僅僅支援簡單的k/v型別的資料,同時還提供list,set,hash等資料結構的儲存。
3、虛擬記憶體–Redis當實體記憶體用完時,可以將一些很久沒用到的value 交換到磁碟
4、過期策略–memcache在set時就指定,例如set key1 0 0 8,即永不過期。Redis可以通過例如expire 設定,例如expire name 10
5、分散式–設定memcache叢集,利用magent做一主多從;redis可以做一主多從。都可以一主一從
6、儲存資料安全–memcache掛掉後,資料沒了;redis可以定期儲存到磁碟(持久化),重啟的時候可以再次載入進行使用。
7、災難恢復–memcache掛掉後,資料不可恢復; redis資料丟失後可以通過aof恢復
8、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的方向開發來緩解其效能上的弊端,說白了就是縱向不行,橫向提高。

程式語言 最新文章