NoSQL分类及ehcache memcache redis 三大缓存的对比
NoSQL分類
由于NoSQL中沒有像傳統數據庫那樣定義數據的組織方式為關系型的，所以只要內部的數據組織采用了非關系型的方式，就可以稱之為NoSQL數據庫。
目前，可以將眾多的NoSQL數據庫按照內部的數據組織形式進行如下分類：
- Key/Value的NoSQL數據庫
- 面向文檔的NoSQL數據庫
- 面向列的NoSQL數據庫
- 面向圖的NoSQL數據庫
不同的數據組織適合于不同的應用場景，后面將進行介紹。
為什么要使用NoSQL
ＳＱＬ語言和關系型數據庫（My SQL、PostgreSQL、Oracle等） 是通用的數據解決方案，占有絕大多數的市場。不過在最近興起的NoSQL運動中，涌現出一批具備高可用性、支持線性擴展、支持Map/Reduce操作等特性的數據產品，它們具有如下特性：
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++開發，具有以下特性：
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），它所支持的查詢類型要少。
HBase
HBase是Hadoop項目中的數據庫。它用于需要對大量的數據進行隨機、實時的讀寫操作的場景中。HBase的目標就是處理數據量非常龐大的表，可以用普通的計算機處理超過１０億行數據，還可處理有數百萬列元素的數據表。
HBase是一個開源的、分布式的、支持多版本的、面向列存儲的GoogleBigtable實現。
HBase的實現基于Hadoop分布式文件系統（HDFS），模仿并提供了基于Google文件系統的Bigtable數據庫的所有功能。HBase有如下特點：
面向圖的NoSQL數據庫
Ｎeｏ４J是一個用Jａvａ實現、完全兼容ＡＣＩＤ的圖形數據庫。數據以一種針對圖形網絡進行過優化的格式保存在磁盤上。Ｎeｏ４J的內核是一種極快的圖形引擎，具有數據庫產品期望的所有特性，如恢復、兩階段提交、符合ＸＡ等。自２００３年起，Ｎeｏ４J就已經作為７２４的產品使用。該項目已經發布了１２版，它是關于伸縮性和社區測試的一個主要里程碑。通過聯機備份實現的高可用性和主從復制功能目前處于測試階段，預計在下一版本中發布。Ｎeｏ４J既可作為無須任何管理開銷的內嵌數據庫使用，也可以作為單獨的服務器使用，在這種使用場景下，它提供了廣泛使用的REST接口，能夠方便地集成到基于PHP、ＮＥＴ和JａvａＳｃｒiｐｔ的環境里。
Ｎeｏ４J的特點如下：
?
示例：
如圖１－１所示，可以在一個網站中使用４款數據產品來提供服務。
選擇多樣的數據存儲方案同樣有利于提升我們對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緩存
實現原理等不同：
Memcached是多線程，非阻塞IO復用的網絡模型，分為監聽主線程和worker子線程，監聽線程監聽網絡連接，接受請求后，將連接描述字pipe 傳遞給worker線程，進行讀寫IO, 網絡層使用libevent封裝的事件庫，多線程模型可以發揮多核作用，但是引入了cache coherency和鎖的問題，比如，Memcached最常用的stats 命令，實際Memcached所有操作都要對這個全局變量加鎖，進行計數等工作，帶來了性能損耗。
（Memcached網絡IO模型）
Redis使用單線程的IO復用模型，自己封裝了一個簡單的AeEvent事件處理框架，主要實現了epoll、kqueue和select，對于單純只有IO操作來說，單線程可以將速度優勢發揮到最大，但是Redis也提供了一些簡單的計算功能，比如排序、聚合等，對于這些操作，單線程模型實際會嚴重影響整體吞吐量，CPU計算過程中，整個IO調度都是被阻塞住的。
Memcached使用預分配的內存池的方式，使用slab和大小不同的chunk來管理內存，Item根據大小選擇合適的chunk存儲，內存池的方式可以省去申請/釋放內存的開銷，并且能減小內存碎片產生，但這種方式也會帶來一定程度上的空間浪費，并且在內存仍然有很大空間時，新的數據也可能會被剔除，原因可以參考Timyang的文章：http://timyang.net/data/Memcached-lru-evictions/
Redis使用現場申請內存的方式來存儲數據，并且很少使用free-list等方式來優化內存分配，會在一定程度上存在內存碎片，Redis跟據存儲命令參數，會把帶過期時間的數據單獨存放在一起，并把它們稱為臨時數據，非臨時數據是永遠不會被剔除的，即便物理內存不夠，導致swap也不會剔除任何非臨時數據（但會嘗試剔除部分臨時數據），這點上Redis更適合作為存儲而不是cache。
Memcached提供了cas命令，可以保證多個并發訪問操作同一份數據的一致性問題。 Redis沒有提供cas 命令，并不能保證這點，不過Redis提供了事務的功能，可以保證一串 命令的原子性，中間不會被任何操作打斷。
Memcached基本只支持簡單的key-value存儲，不支持枚舉，不支持持久化和復制等功能
Redis除key/value之外，還支持list,set,sorted set,hash等眾多數據結構，提供了KEYS
進行枚舉操作，但不能在線上使用，如果需要枚舉線上數據，Redis提供了工具可以直接掃描其dump文件，枚舉出所有數據，Redis還同時提供了持久化和復制等功能。
在不同語言的客戶端方面，Memcached和Redis都有豐富的第三方客戶端可供選擇，不過因為Memcached發展的時間更久一些，目前看在客戶端支持方面，Memcached的很多客戶端更加成熟穩定，而Redis由于其協議本身就比Memcached復雜，加上作者不斷增加新的功能等，對應第三方客戶端跟進速度可能會趕不上，有時可能需要自己在第三方客戶端基礎上做些修改才能更好的使用。
根據以上比較不難看出，當我們不希望數據被踢出，或者需要除key/value之外的更多數據類型時，或者需要落地功能時，使用Redis比使用Memcached更合適。
關于Redis的一些周邊功能
Redis除了作為存儲之外還提供了一些其它方面的功能，比如聚合計算、pubsub、scripting等，對于此類功能需要了解其實現原理，清楚地了解到它的局限性后，才能正確的使用，比如pubsub功能，這個實際是沒有任何持久化支持的，消費方連接閃斷或重連之間過來的消息是會全部丟失的，又比如聚合計算和scripting等功能受Redis單線程模型所限，是不可能達到很高的吞吐量的，需要謹慎使用。
總的來說Redis作者是一位非常勤奮的開發者，可以經常看到作者在嘗試著各種不同的新鮮想法和思路，針對這些方面的功能就要求我們需要深入了解后再使用。
總結：
后續關于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的方向開發來緩解其性能上的弊端，說白了就是縱向不行，橫向提高。
轉載于:https://www.cnblogs.com/duanxz/p/5215274.html
總結
以上是生活随笔為你收集整理的NoSQL分类及ehcache memcache redis 三大缓存的对比的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Luogu P4114 Qtree1
- 下一篇： 基于 PVE + TrueNAS 的私有