轉載自https://www.cnblogs.com/457248499-qq-com/p/7392653.html
觀點一：
1、Redis和Memcache都是將數據存放在內存中，都是內存數據庫。不過memcache還可用於緩存其他東西，例如圖片、視頻等等；
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的區別，大多數都會得到以下觀點：
1 Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，hash等數據結構的存儲。
2 Redis支持數據的備份，即master-slave模式的數據備份。
3 Redis支持數據的持久化，可以將內存中的數據保持在磁盤中，重啓的時候可以再次加載進行使用。
在Redis中，並不是所有的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別（我個人是這麼認爲的）。
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特有內存模型前後的情況對比：
VM off: 300k keys, 4096 bytes values: 1.3G used
VM on: 300k keys, 4096 bytes values: 73M used
VM off: 1 million keys, 256 bytes values: 430.12M used
VM on: 1 million keys, 256 bytes values: 160.09M used
VM on: 1 million keys, values as large as you want, still: 160.09M used
當 從Redis中讀取數據的時候，如果讀取的key對應的value不在內存中，那麼Redis就需要從swap文件中加載相應數據，然後再返回給請求方。 這裏就存在一個I/O線程池的問題。在默認的情況下，Redis會出現阻塞，即完成所有的swap文件加載後纔會相應。這種策略在客戶端的數量較小，進行 批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程序中，這顯然是無法滿足大併發的情況的。所以Redis運行我們設置I/O線程 池的大小，對需要從swap文件中加載相應數據的讀取請求進行併發操作，減少阻塞的時間。
redis、memcache、mongoDB 對比
從以下幾個維度，對redis、memcache、mongoDB 做了對比，歡迎拍磚
1、性能
都比較高，性能對我們來說應該都不是瓶頸
總體來講，TPS方面redis和memcache差不多，要大於mongodb
2、操作的便利性
memcache數據結構單一
redis豐富一些，數據操作方面，redis更好一些，較少的網絡IO次數
mongodb支持豐富的數據表達，索引，最類似關係型數據庫，支持的查詢語言非常豐富
3、內存空間的大小和數據量的大小
redis在2.0版本後增加了自己的VM特性，突破物理內存的限制；可以對key value設置過期時間（類似memcache）
memcache可以修改最大可用內存,採用LRU算法
mongoDB適合大數據量的存儲，依賴操作系統VM做內存管理，吃內存也比較厲害，服務不要和別的服務在一起
4、可用性（單點問題）
對於單點問題，
redis，依賴客戶端來實現分佈式讀寫；主從複製時，每次從節點重新連接主節點都要依賴整個快照,無增量複製，因性能和效率問題，
所以單點問題比較複雜；不支持自動sharding,需要依賴程序設定一致hash 機制。
一種替代方案是，不用redis本身的複製機制，採用自己做主動複製（多份存儲），或者改成增量複製的方式（需要自己實現），一致性問題和性能的權衡
Memcache本身沒有數據冗餘機制，也沒必要；對於故障預防，採用依賴成熟的hash或者環狀的算法，解決單點故障引起的抖動問題。
mongoDB支持master-slave,replicaset（內部採用paxos選舉算法，自動故障恢復）,auto sharding機制，對客戶端屏蔽了故障轉移和切分機制。
5、可靠性（持久化）
對於數據持久化和數據恢復，
redis支持（快照、AOF）：依賴快照進行持久化，aof增強了可靠性的同時，對性能有所影響
memcache不支持，通常用在做緩存,提升性能；
MongoDB從1.8版本開始採用binlog方式支持持久化的可靠性
6、數據一致性（事務支持）
Memcache 在併發場景下，用cas保證一致性
redis事務支持比較弱，只能保證事務中的每個操作連續執行
mongoDB不支持事務
7、數據分析
mongoDB內置了數據分析的功能(mapreduce),其他不支持
8、應用場景
redis：數據量較小的更性能操作和運算上
memcache：用於在動態系統中減少數據庫負載，提升性能;做緩存，提高性能（適合讀多寫少，對於數據量比較大，可以採用sharding）
MongoDB:主要解決海量數據的訪問效率問題