從以下幾個維度，對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:主要解決海量數據的訪問效率問題