MongoDB 或者 redis 可以替代 memcached 嗎?

01-03

mongodb和memcached不是一個範疇內的東西。mongodb是文檔型的非關係型資料庫，其優勢在於查詢功能比較強大，能存儲海量數據。mongodb和memcached不存在誰替換誰的問題。

和memcached更為接近的是redis。它們都是內存型資料庫，數據保存在內存中，通過tcp直接存取，優勢是速度快，並發高，缺點是數據類型有限，查詢功能不強，一般用作緩存。在我們團隊的項目中，一開始用的是memcached，後來用redis替代。

相比memcached：

1、redis具有持久化機制，可以定期將內存中的數據持久化到硬碟上。

2、redis具備binlog功能，可以將所有操作寫入日誌，當redis出現故障，可依照binlog進行數據恢復。

3、redis支持virtual memory，可以限定內存使用大小，當數據超過閾值，則通過類似LRU的演算法把內存中的最不常用數據保存到硬碟的頁面文件中。

4、redis原生支持的數據類型更多，使用的想像空間更大。

5、前面有位朋友所提及的一致性哈希，用在redis的sharding中，一般是在負載非常高需要水平擴展時使用。我們還沒有用到這方面的功能，一般的項目，單機足夠支撐並發了。redis 3.0將推出cluster，功能更加強大。

6、redis更多優點，請移步官方網站查詢。

Copy了一段，大家看看吧。

這兩年Redis火得可以，Redis也常常被當作Memcached的挑戰者被提到桌面上來。關於Redis與Memcached的比較更是比比皆是。然而，Redis真的在功能、性能以及內存使用效率上都超越了Memcached嗎？

下面內容來自Redis作者在stackoverflow上的一個回答，對應的問題是《Is memcached a dinosaur in comparison to Redis?》（相比Redis，Memcached真的過時了嗎？）

You should not care too much about performances. Redis is faster per core with small values, but memcached is able to use multiple cores with a single executable and TCP port without help from the client. Also memcached is faster with big values in the order of 100k. Redis recently improved a lot about big values (unstable branch) but still memcached is faster in this use case. The point here is: nor one or the other will likely going to be your bottleneck for the query-per-second they can deliver.
沒有必要過多的關心性能，因為二者的性能都已經足夠高了。由於Redis只使用單核，而Memcached可以使用多核，所以在比較上，平均每一個核上Redis在存儲小數據時比Memcached性能更高。而在100k以上的數據中，Memcached性能要高於Redis，雖然Redis最近也在存儲大數據的性能上進行優化，但是比起Memcached，還是稍有遜色。說了這麼多，結論是，無論你使用哪一個，每秒處理請求的次數都不會成為瓶頸。（比如瓶頸可能會在網卡）
You should care about memory usage. For simple key-value pairs memcached is more memory efficient. If you use Redis hashes, Redis is more memory efficient. Depends on the use case.
如果要說內存使用效率，使用簡單的key-value存儲的話，Memcached的內存利用率更高，而如果Redis採用hash結構來做key-value存儲，由於其組合式的壓縮，其內存利用率會高於Memcached。當然，這和你的應用場景和數據特性有關。
You should care about persistence and replication, two features only available in Redis. Even if your goal is to build a cache it helps that after an upgrade or a reboot your data are still there.
如果你對數據持久化和數據同步有所要求，那麼推薦你選擇Redis，因為這兩個特性Memcached都不具備。即使你只是希望在升級或者重啟系統後緩存數據不會丟失，選擇Redis也是明智的。
You should care about the kind of operations you need. In Redis there are a lot of complex operations, even just considering the caching use case, you often can do a lot more in a single operation, without requiring data to be processed client side (a lot of I/O is sometimes needed). This operations are often as fast as plain GET and SET. So if you don』t need just GEt/SET but more complex things Redis can help a lot (think at timeline caching).
當然，最後還得說到你的具體應用需求。Redis相比Memcached來說，擁有更多的數據結構和並支持更豐富的數據操作，通常在Memcached里，你需要將數據拿到客戶端來進行類似的修改再set回去。這大大增加了網路IO的次數和數據體積。在Redis中，這些複雜的操作通常和一般的GET/SET一樣高效。所以，如果你需要緩存能夠支持更複雜的結構和操作，那麼Redis會是不錯的選擇。

來源：Is memcached a dinosaur in comparison to Redis?（其他人的回答同樣值得一看）

查看原文：論述Redis和Memcached的差異-博客-雲棲社區-阿里雲

Redis 和 Memcache 都是基於內存的數據存儲系統。Memcached是高性能分散式內存緩存服務；Redis是一個開源的key-value存儲系統。與Memcached類似，Redis將大部分數據存儲在內存中，支持的數據類型包括：字元串、哈希表、鏈表、等數據類型的相關操作。下面我們來進行來看一下redis和memcached的區別。權威比較

Redis的作者Salvatore Sanfilippo曾經對這兩種基於內存的數據存儲系統進行過比較：

Redis支持伺服器端的數據操作：Redis相比Memcached來說，擁有更多的數據結構和並支持更豐富的數據操作，通常在Memcached里，你需要將數據拿到客戶端來進行類似的修改再set回去。這大大增加了網路IO的次數和數據體積。在Redis中，這些複雜的操作通常和一般的GET/SET一樣高效。所以，如果需要緩存能夠支持更複雜的結構和操作，那麼Redis會是不錯的選擇。
內存使用效率對比：使用簡單的key-value存儲的話，Memcached的內存利用率更高，而如果Redis採用hash結構來做key-value存儲，由於其組合式的壓縮，其內存利用率會高於Memcached。
性能對比：由於Redis只使用單核，而Memcached可以使用多核，所以平均每一個核上Redis在存儲小數據時比Memcached性能更高。而在100k以上的數據中，Memcached性能要高於Redis，雖然Redis最近也在存儲大數據的性能上進行優化，但是比起Memcached，還是稍有遜色。

具體為什麼會出現上面的結論，以下為收集到的資料：

1、數據類型支持不同

與Memcached僅支持簡單的key-value結構的數據記錄不同，Redis支持的數據類型要豐富得多。最為常用的數據類型主要由五種：String、Hash、List、Set和Sorted Set。Redis內部使用一個redisObject對象來表示所有的key和value。redisObject最主要的信息如圖所示：

type代表一個value對象具體是何種數據類型，encoding是不同數據類型在redis內部的存儲方式，比如：type=string代表value存儲的是一個普通字元串，那麼對應的encoding可以是raw或者是int，如果是int則代表實際redis內部是按數值型類存儲和表示這個字元串的，當然前提是這個字元串本身可以用數值表示，比如:」123″ 「456」這樣的字元串。只有打開了Redis的虛擬內存功能，vm欄位欄位才會真正的分配內存，該功能默認是關閉狀態的。

1）String

常用命令：set/get/decr/incr/mget等；

應用場景：String是最常用的一種數據類型，普通的key/value存儲都可以歸為此類；

實現方式：String在redis內部存儲默認就是一個字元串，被redisObject所引用，當遇到incr、decr等操作時會轉成數值型進行計算，此時redisObject的encoding欄位為int。

2）Hash

常用命令：hget/hset/hgetall等

應用場景：我們要存儲一個用戶信息對象數據，其中包括用戶ID、用戶姓名、年齡和生日，通過用戶ID我們希望獲取該用戶的姓名或者年齡或者生日；

實現方式：Redis的Hash實際是內部存儲的Value為一個HashMap，並提供了直接存取這個Map成員的介面。如圖所示，Key是用戶ID, value是一個Map。這個Map的key是成員的屬性名，value是屬性值。這樣對數據的修改和存取都可以直接通過其內部Map的Key(Redis里稱內部Map的key為field), 也就是通過 key(用戶ID) + field(屬性標籤) 就可以操作對應屬性數據。當前HashMap的實現有兩種方式：當HashMap的成員比較少時Redis為了節省內存會採用類似一維數組的方式來緊湊存儲，而不會採用真正的HashMap結構，這時對應的value的redisObject的encoding為zipmap，當成員數量增大時會自動轉成真正的HashMap,此時encoding為ht。

3）List

常用命令：lpush/rpush/lpop/rpop/lrange等；

應用場景：Redis list的應用場景非常多，也是Redis最重要的數據結構之一，比如twitter的關注列表，粉絲列表等都可以用Redis的list結構來實現；

實現方式：Redis list的實現為一個雙向鏈表，即可以支持反向查找和遍歷，更方便操作，不過帶來了部分額外的內存開銷，Redis內部的很多實現，包括發送緩衝隊列等也都是用的這個數據結構。

4）Set

常用命令：sadd/spop/smembers/sunion等；

應用場景：Redis set對外提供的功能與list類似是一個列表的功能，特殊之處在於set是可以自動排重的，當你需要存儲一個列表數據，又不希望出現重複數據時，set是一個很好的選擇，並且set提供了判斷某個成員是否在一個set集合內的重要介面，這個也是list所不能提供的；

實現方式：set 的內部實現是一個 value永遠為null的HashMap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的原因。

5）Sorted Set

常用命令：zadd/zrange/zrem/zcard等；

應用場景：Redis sorted set的使用場景與set類似，區別是set不是自動有序的，而sorted set可以通過用戶額外提供一個優先順序(score)的參數來為成員排序，並且是插入有序的，即自動排序。當你需要一個有序的並且不重複的集合列表，那麼可以選擇sorted set數據結構，比如twitter 的public timeline可以以發表時間作為score來存儲，這樣獲取時就是自動按時間排好序的。

實現方式：Redis sorted set的內部使用HashMap和跳躍表(SkipList)來保證數據的存儲和有序，HashMap里放的是成員到score的映射，而跳躍表裡存放的是所有的成員，排序依據是HashMap里存的score,使用跳躍表的結構可以獲得比較高的查找效率，並且在實現上比較簡單。

2、內存管理機制不同

在Redis中，並不是所有的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別。當物理內存用完時，Redis可以將一些很久沒用到的value交換到磁碟。Redis只會緩存所有的key的信息，如果Redis發現內存的使用量超過了某一個閥值，將觸發swap的操作，Redis根據「swappability = age*log(size_in_memory)」計算出哪些key對應的value需要swap到磁碟。然後再將這些key對應的value持久化到磁碟中，同時在內存中清除。這種特性使得Redis可以保持超過其機器本身內存大小的數據。當然，機器本身的內存必須要能夠保持所有的key，畢竟這些數據是不會進行swap操作的。同時由於Redis將內存中的數據swap到磁碟中的時候，提供服務的主線程和進行swap操作的子線程會共享這部分內存，所以如果更新需要swap的數據，Redis將阻塞這個操作，直到子線程完成swap操作後才可以進行修改。當從Redis中讀取數據的時候，如果讀取的key對應的value不在內存中，那麼Redis就需要從swap文件中載入相應數據，然後再返回給請求方。這裡就存在一個I/O線程池的問題。在默認的情況下，Redis會出現阻塞，即完成所有的swap文件載入後才會相應。這種策略在客戶端的數量較小，進行批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程序中，這顯然是無法滿足大並發的情況的。所以Redis運行我們設置I/O線程池的大小，對需要從swap文件中載入相應數據的讀取請求進行並發操作，減少阻塞的時間。

對於像Redis和Memcached這種基於內存的資料庫系統來說，內存管理的效率高低是影響系統性能的關鍵因素。傳統C語言中的malloc/free函數是最常用的分配和釋放內存的方法，但是這種方法存在著很大的缺陷：首先，對於開發人員來說不匹配的malloc和free容易造成內存泄露；其次頻繁調用會造成大量內存碎片無法回收重新利用，降低內存利用率；最後作為系統調用，其系統開銷遠遠大於一般函數調用。所以，為了提高內存的管理效率，高效的內存管理方案都不會直接使用malloc/free調用。Redis和Memcached均使用了自身設計的內存管理機制，但是實現方法存在很大的差異，下面將會對兩者的內存管理機制分別進行介紹。

Memcached默認使用Slab Allocation機制管理內存，其主要思想是按照預先規定的大小，將分配的內存分割成特定長度的塊以存儲相應長度的key-value數據記錄，以完全解決內存碎片問題。Slab Allocation機制只為存儲外部數據而設計，也就是說所有的key-value數據都存儲在Slab Allocation系統里，而Memcached的其它內存請求則通過普通的malloc/free來申請，因為這些請求的數量和頻率決定了它們不會對整個系統的性能造成影響Slab Allocation的原理相當簡單。如圖所示，它首先從操作系統申請一大塊內存，並將其分割成各種尺寸的塊Chunk，並把尺寸相同的塊分成組Slab Class。其中，Chunk就是用來存儲key-value數據的最小單位。每個Slab Class的大小，可以在Memcached啟動的時候通過制定Growth Factor來控制。假定圖中Growth Factor的取值為1.25，如果第一組Chunk的大小為88個位元組，第二組Chunk的大小就為112個位元組，依此類推。

當Memcached接收到客戶端發送過來的數據時首先會根據收到數據的大小選擇一個最合適的Slab Class，然後通過查詢Memcached保存著的該Slab Class內空閑Chunk的列表就可以找到一個可用於存儲數據的Chunk。當一條資料庫過期或者丟棄時，該記錄所佔用的Chunk就可以回收，重新添加到空閑列表中。

從以上過程我們可以看出Memcached的內存管理制效率高，而且不會造成內存碎片，但是它最大的缺點就是會導致空間浪費。因為每個Chunk都分配了特定長度的內存空間，所以變長數據無法充分利用這些空間。如圖所示，將100個位元組的數據緩存到128個位元組的Chunk中，剩餘的28個位元組就浪費掉了。

Redis的內存管理主要通過源碼中zmalloc.h和zmalloc.c兩個文件來實現的。Redis為了方便內存的管理，在分配一塊內存之後，會將這塊內存的大小存入內存塊的頭部。如圖所示，real_ptr是redis調用malloc後返回的指針。redis將內存塊的大小size存入頭部，size所佔據的內存大小是已知的，為size_t類型的長度，然後返回ret_ptr。當需要釋放內存的時候，ret_ptr被傳給內存管理程序。通過ret_ptr，程序可以很容易的算出real_ptr的值，然後將real_ptr傳給free釋放內存。

Redis通過定義一個數組來記錄所有的內存分配情況，這個數組的長度為ZMALLOC_MAX_ALLOC_STAT。數組的每一個元素代表當前程序所分配的內存塊的個數，且內存塊的大小為該元素的下標。在源碼中，這個數組為zmalloc_allocations。zmalloc_allocations[16]代表已經分配的長度為16bytes的內存塊的個數。zmalloc.c中有一個靜態變數used_memory用來記錄當前分配的內存總大小。所以，總的來看，Redis採用的是包裝的mallc/free，相較於Memcached的內存管理方法來說，要簡單很多。

3、數據持久化支持

Redis雖然是基於內存的存儲系統，但是它本身是支持內存數據的持久化的，而且提供兩種主要的持久化策略：RDB快照和AOF日誌。而memcached是不支持數據持久化操作的。

1）RDB快照

Redis支持將當前數據的快照存成一個數據文件的持久化機制，即RDB快照。但是一個持續寫入的資料庫如何生成快照呢？Redis藉助了fork命令的copy on write機制。在生成快照時，將當前進程fork出一個子進程，然後在子進程中循環所有的數據，將數據寫成為RDB文件。我們可以通過Redis的save指令來配置RDB快照生成的時機，比如配置10分鐘就生成快照，也可以配置有1000次寫入就生成快照，也可以多個規則一起實施。這些規則的定義就在Redis的配置文件中，你也可以通過Redis的CONFIG SET命令在Redis運行時設置規則，不需要重啟Redis。

Redis的RDB文件不會壞掉，因為其寫操作是在一個新進程中進行的，當生成一個新的RDB文件時，Redis生成的子進程會先將數據寫到一個臨時文件中，然後通過原子性rename系統調用將臨時文件重命名為RDB文件，這樣在任何時候出現故障，Redis的RDB文件都總是可用的。同時，Redis的RDB文件也是Redis主從同步內部實現中的一環。RDB有他的不足，就是一旦資料庫出現問題，那麼我們的RDB文件中保存的數據並不是全新的，從上次RDB文件生成到Redis停機這段時間的數據全部丟掉了。在某些業務下，這是可以忍受的。

2）AOF日誌

AOF日誌的全稱是append only file，它是一個追加寫入的日誌文件。與一般資料庫的binlog不同的是，AOF文件是可識別的純文本，它的內容就是一個個的Redis標準命令。只有那些會導致數據發生修改的命令才會追加到AOF文件。每一條修改數據的命令都生成一條日誌，AOF文件會越來越大，所以Redis又提供了一個功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一條記錄的操作只會有一次，而不像一份老文件那樣，可能記錄了對同一個值的多次操作。其生成過程和RDB類似，也是fork一個進程，直接遍曆數據，寫入新的AOF臨時文件。在寫入新文件的過程中，所有的寫操作日誌還是會寫到原來老的AOF文件中，同時還會記錄在內存緩衝區中。當重完操作完成後，會將所有緩衝區中的日誌一次性寫入到臨時文件中。然後調用原子性的rename命令用新的AOF文件取代老的AOF文件。

AOF是一個寫文件操作，其目的是將操作日誌寫到磁碟上，所以它也同樣會遇到我們上面說的寫操作的流程。在Redis中對AOF調用write寫入後，通過appendfsync選項來控制調用fsync將其寫到磁碟上的時間，下面appendfsync的三個設置項，安全強度逐漸變強。

appendfsync no 當設置appendfsync為no的時候，Redis不會主動調用fsync去將AOF日誌內容同步到磁碟，所以這一切就完全依賴於操作系統的調試了。對大多數Linux操作系統，是每30秒進行一次fsync，將緩衝區中的數據寫到磁碟上。
appendfsync everysec 當設置appendfsync為everysec的時候，Redis會默認每隔一秒進行一次fsync調用，將緩衝區中的數據寫到磁碟。但是當這一次的fsync調用時長超過1秒時。Redis會採取延遲fsync的策略，再等一秒鐘。也就是在兩秒後再進行fsync，這一次的fsync就不管會執行多長時間都會進行。這時候由於在fsync時文件描述符會被阻塞，所以當前的寫操作就會阻塞。所以結論就是，在絕大多數情況下，Redis會每隔一秒進行一次fsync。在最壞的情況下，兩秒鐘會進行一次fsync操作。這一操作在大多數資料庫系統中被稱為group commit，就是組合多次寫操作的數據，一次性將日誌寫到磁碟。
appednfsync always 當設置appendfsync為always時，每一次寫操作都會調用一次fsync，這時數據是最安全的，當然，由於每次都會執行fsync，所以其性能也會受到影響。

對於一般性的業務需求，建議使用RDB的方式進行持久化，原因是RDB的開銷並相比AOF日誌要低很多，對於那些無法忍數據丟失的應用，建議使用AOF日誌。

4、集群管理的不同

Memcached是全內存的數據緩衝系統，Redis雖然支持數據的持久化，但是全內存畢竟才是其高性能的本質。作為基於內存的存儲系統來說，機器物理內存的大小就是系統能夠容納的最大數據量。如果需要處理的數據量超過了單台機器的物理內存大小，就需要構建分散式集群來擴展存儲能力。

Memcached本身並不支持分散式，因此只能在客戶端通過像一致性哈希這樣的分散式演算法來實現Memcached的分散式存儲。下圖給出了Memcached的分散式存儲實現架構。當客戶端向Memcached集群發送數據之前，首先會通過內置的分散式演算法計算出該條數據的目標節點，然後數據會直接發送到該節點上存儲。但客戶端查詢數據時，同樣要計算出查詢數據所在的節點，然後直接向該節點發送查詢請求以獲取數據。

相較於Memcached只能採用客戶端實現分散式存儲，Redis更偏向於在伺服器端構建分散式存儲。最新版本的Redis已經支持了分散式存儲功能。Redis Cluster是一個實現了分散式且允許單點故障的Redis高級版本，它沒有中心節點，具有線性可伸縮的功能。下圖給出Redis Cluster的分散式存儲架構，其中節點與節點之間通過二進位協議進行通信，節點與客戶端之間通過ascii協議進行通信。在數據的放置策略上，Redis Cluster將整個key的數值域分成4096個哈希槽，每個節點上可以存儲一個或多個哈希槽，也就是說當前Redis Cluster支持的最大節點數就是4096。Redis Cluster使用的分散式演算法也很簡單：crc16( key ) % HASH_SLOTS_NUMBER。

為了保證單點故障下的數據可用性，Redis Cluster引入了Master節點和Slave節點。在Redis Cluster中，每個Master節點都會有對應的兩個用於冗餘的Slave節點。這樣在整個集群中，任意兩個節點的宕機都不會導致數據的不可用。當Master節點退出後，集群會自動選擇一個Slave節點成為新的Master節點。

redis可以代替memcached，並且在效率方面可能比memcached更高一點。

兩者都是典型的key value store，且都是內存型資料庫。由於redis可以持久化到文件系統，在緩存方面可以比memcached做的更好。

現在的項目中完全用redis取代了memcached，效果良好。

項目是rails的，使用redis-store代替memcache-store。

MongoDB不多說，不是一個類型的東西，Redis相對Memcached來說功能和特性上的優勢已經很明顯了。而對於性能，Redis作者的說法是平均到單個核上的性能，在單條數據不大的情況下Redis更好。為什麼這麼說呢，理由就是Redis是單線程運行的。

因為是單線程運行，所以和Memcached的多線程相比，整體性能肯定會偏低。

因為是單線程運行，所以IO是串列化的，網路IO和內存IO，因此當單條數據太大時，由於需要等待一個命令的所有IO完成才能進行後續的命令，所以性能會受影響。

而就內存使用上來說，目前Redis結合了tcmalloc和jemalloc兩個內存分配器，基本上和Memcached不相伯仲。如果是簡單且有規律的key value存儲，那麼用Redis的hash結構來做，內存使用上會驚人的變小，優勢是很明顯的。

參考：

《Memcached真的過時了嗎？》http://blog.nosqlfan.com/html/3729.html

《節約內存：Instagram的Redis實踐》http://blog.nosqlfan.com/html/3379.html

為啥大家對於MongoDB都是「不多說」的態度。。。

本人MongoDB新手，前兩天做測試的時候，500W條嵌套式(embedded document)數據，根據子內容條件查詢獲取父內容的操作只需要一次I/O，平均耗時1ms（未進行cluster，條件欄位有索引，整個Collection體積將近10G）。

上述操作對於Memcached＋Mysql組合通常需要2-3次I/O（區別於具體設計），即：通過子內容條件查詢到子內容主鍵，然後從Memcached中緩存的entity獲取關聯的父內容主鍵，然後從Memcached中獲取父內容。

所以MongoDB一次 I/O 1ms的成績即便是面對內存級別的Memcached也是很有競爭力的，所以是否能代替Memcached＋Mysql就只是業務場景的問題了。

一些類似於Blog的實現場景，MongoDB的嵌套結構（文章主題為父內容，嵌套評論，用戶信息獨立collection）和大欄位存取能力還是有不小優勢的，畢竟MySql實現需要多表關聯，還要部署緩存，使得開發成本略微提高。

Redis我了解不多，工作中也只是充當「有很多數據結構」的Memcached來使用。。。(Memcached作為資料庫一級緩存，Redis作為業務場景二級緩存)

不過據說國外有一些網站的緩存＋持久化是完全使用Redis支撐的，可見Redis的特性（豐富數據結構＋持久化支持）賦予了它比Memcached更寬泛的使用場景。

所以對於題主的問題，只能說先去了解一下三個工具各自的特性，無所謂誰替代誰，畢竟在最恰當的場景使用最恰當的工具才是最好的選擇

以上

功能上可以，但是僅僅用來替代memcached未免有點大材小用了，也不是作者最初設計的目的。

1.mongodb 和memcached不具可比性,一個是基於磁碟的資料庫,只是緩存熱點數據數據在內存中,一個是全內存cache;

2. memcached支持過期策略,而mongodb僅有一個capped collection(適合存儲日誌)的策略可以丟棄先存儲的歷史數據;

3. redis可以做cache,但redis更多是作為內存資料庫的角色存在,且一致性哈希的實現還不成熟,如果memcached已經能實現你的需求,沒有必要採用不夠成熟穩定的redis.

mongodb 是文檔資料庫，用於方便懶人替代mysql等關係資料庫的。不過mongodb在內存足夠的情況下讀寫性能不錯，大部分應用可以省去cache這一層了。

redis 是分散式的數據結構伺服器，功能上覆蓋了memcached, 可以代替memcached.

當然memcached也有優勢，memcached是多線程的，這樣可以充分利用多核能力。redis是單核，要想在那麼多數據結構基礎上支持多線程，光加鎖就會讓人瘋掉，性能也會下降。

memcache出現比較早，用法也及其簡單，get/set/mget, 用來作資料庫的緩存真是又方便又快捷，特別是開發的時候，不需要配置，重啟既可以數據清零。

redis拿來時還需要改下配置，取消snapshot和log這些持久化方法，而且方法那麼多，誘惑人使用各種數據結構了，但是我們知道數據一般是持久化在資料庫里，在redis里再來一份，為了維護這倆的一致性，得加不少代碼來。所以redis更建議在成形的項目中作為性能優化部件。

nosql也分類型的；redis、memcached這樣的KeyValue天然適合做緩存，相互替代比較容易，優缺點彼此爭論不一；mongo屬於文檔型，介於nosql與關係型資料庫之間，相比其他nosql，具有強大的查詢語句，在一定程度上可以用來存儲海量、需要多條件查詢同時又不需要關係型資料庫特性的「文檔」，反正我用他來存日誌。

@王憲偉@seamon

真心請教：從關係型資料庫來到NoSQL的第一個問題：如何利用redis做類似在mysql中的級聯查詢？

1.需求場景：用戶表，文章表，贊表，用戶寫的文章被贊，根據文章被贊的數量降序（如果被贊的數量相同按照文章創建時間升序）排序top100文章

2.三張表的表關係：

user(id,username,figure) &<----------------------------------------

—————↑—————————————————— |

article(id,user_id,title,content,create_time) ————-- |

———————————↑———————————— |

praise(id,create_time,artical_id,user_id) --------------------|

3.當然用SQL語句來做是很容易的，那麼現在需要用redis的NoSQL來做該需求，該怎麼做呢？（ps：允許重新設計，只要能完成該功能即可）

謝謝！

MongoDB 是一個基於文檔的資料庫，所有數據是從磁碟上進行讀寫的。MongoDB善長的是對無模式JSON數據的查詢。

而Redis是一個基於內存的鍵值資料庫，它由C語言實現的，與Nginx/ NodeJS工作原理近似，同樣以單線程非同步的方式工作，先讀寫內存再非同步同步到磁碟，讀寫速度上比MongoDB有巨大的提升。因此目前很多超高並發的網站/應用都使用Redis做緩存層，普遍認為其性能明顯好於MemoryCache。當並發達到一定程度時，即可考慮使用Redis來緩存數據和持久化Session。

如果你的NodeJS網站上的所有緩存數據都轉移到了Redis後，就可做到完全狀態無關，按需擴展網站的規模。

可水平擴展的網站伺服器集群（非 cluster模塊不同，它們是相互獨立的，可分布在不同的物理伺服器上），這樣的架構，對於應對超大規模並發也是有好處的。

相關文章：在nodejs使用Redis緩存和查詢數據及Session持久化(Express)

3個場景完全不同的東西。1.memcached：單一鍵值對內存緩存的，做對象緩存無可替代的分散式緩存；2.redis：是演算法和數據結構的集合，快速的數據結構操作是他最大的特點，支持數據持久化；3.mongodb是bson結構、介於rdb和nosql之間的，更鬆散更靈活的，但是不支持事務，只用作非重要數據存儲。

redis 和 memcache 都是好的緩存方案，各有各的優缺點

redis最強的地方是有比較豐富的數據結構，可以在緩存層玩出很多花樣，比如：通過列表做消息隊列，通過mget,mset可以讀多個值進行操作等等，sina,instagram都是比較好的利用了它的這些優點，單點問題沒有太好的解決方案，有待提高

memcache的強項是分散式比較成熟，對多核cpu的應用，yutube，大多數電子商務網站都是它的用戶，比較成熟，穩定。

個人經驗，他倆的性能不是問題，如果出了問題，估計也是系統架構設計問題

mongodb 為代表的nosql應該是傳統資料庫的有益的補充，目前看來還無法取代他們地位，比較適合web端快速開發，python ,ruby, js開發起來比較爽

(memcached, radis) 和 (mongoDB) 的區別有兩維

一是key value store vs. document database

一是內存型vs.硬碟型.

具體能不能替代, 還要看題主的活兒是什麼.

radis和memcached基本是一回事, 應該可以替代.

如果memcached用的原因就是系統小+懶, 現在系統長大了不好用了要找permanent solution, mongoDB也不一定不是個好東西.

mongodb和redis是作為資料庫的，並不是作為mc一樣的緩存。應用領域不同。

如果說用mongodb做緩存？太消耗磁碟空間了。據我實驗感覺，頻繁讀寫對於mongodb並不是優點。mongodb的優點是解決類似like "%%"這樣的查詢時候用的。

至於redis可能是比較合適的替換工具了。但據我所知，redis有其資料庫特性：日誌，恢復等功能。單單從存儲性能的角度來講，應該是不如mc的。

個人感覺，mc是作為緩存而不是斷電後存儲用的。特性不同哦。

哈哈哈哈

這算是一個最佳例子

同一個問題，隨著時間的推移，答案就該不同了

如今 MongoDB 支持 in-memory 模式

這種模式下的 MongoDB 是可以用作緩存的。

當下的redis cluster 3.2.0已很強了，個人覺得完全可以替代memcached，沒必要在新的業務中再使用memcached。為redis cluster增加監控也是非常容易的事，因為基於命令對它的各項數據訪問十分便利。hash/sorted set/list等功能十分好用，新加入的GEO功能在移動互聯網時代用處也大。

我來了，秒殺

System Properties Comparison Memcached vs. MongoDB vs. Redis

Memcached vs. MongoDB vs. Redis Comparison

不建議MongoDb替代memcached，因為是不同的應用場景。

但是強烈建議使用Redis替換Memached，使用Redis存在以下幾個好處：

1、性能快

2、單個緩存可以突破Memcached 1M的限制