Redis和MongoDB的區別以及應用場景
項目中用的是MongoDB，但是為什么用其實當時選型的時候也沒有太多考慮，只是認為數據量比較大，所以采用MongoDB。
最近又想起為什么用MongoDB，就查閱一下，匯總匯總：
之前也用過redis，當時是用來存儲一些熱數據，量也不大，但是操作很頻繁。現在項目中用的是MongoDB，目前是百萬級的數據，將來會有千萬級、億級。
就Redis和MongoDB來說，大家一般稱之為Redis緩存、MongoDB數據庫。這也是有道有理有根據的，
Redis主要把數據存儲在內存中，其“緩存”的性質遠大於其“數據存儲“的性質，其中數據的增刪改查也只是像變量操作一樣簡單；
MongoDB卻是一個“存儲數據”的系統，增刪改查可以添加很多條件，就像SQL數據庫一樣靈活，這一點在面試的時候很受用。
Mongodb與Redis應用指標對比
MongoDB和Redis都是NoSQL，采用結構型數據存儲。二者在使用場景中，存在一定的區別，這也主要由於
二者在內存映射的處理過程，持久化的處理方法不同。MongoDB建議集群部署，更多的考慮到集群方案，Redis
更偏重於進程順序寫入，雖然支持集群，也僅限於主-從模式。
| 指標 | MongoDB(v2.4.9) | Redis(v2.4.17) | 比較說明 |
|---|---|---|---|
| 實現語言 | C++ | C/C++ | - |
| 協議 | BSON、自定義二進制 | 類Telnet | - |
| 性能 | 依賴內存，TPS較高 | 依賴內存，TPS非常高 | Redis優於MongoDB |
| 可操作性 | 豐富的數據表達、索引；最類似於關系數據庫，支持豐富的查詢語言 | 數據豐富，較少的IO | MongoDB優於Redis |
| 內存及存儲 | 適合大數據量存儲，依賴系統虛擬內存管理，采用鏡像文件存儲；內存占有率比較高，官方建議獨立部署在64位系統（32位有最大2.5G文件限制，64位沒有改限制） | Redis2.0后增加虛擬內存特性，突破物理內存限制；數據可以設置時效性，類似於memcache | 不同的應用角度看，各有優勢 |
| 可用性 | 支持master-slave,replicaset（內部采用paxos選舉算法，自動故障恢復）,auto sharding機制，對客戶端屏蔽了故障轉移和切分機制 | 依賴客戶端來實現分布式讀寫；主從復制時，每次從節點重新連接主節點都要依賴整個快照,無增量復制；不支持自動sharding,需要依賴程序設定一致hash機制 | MongoDB優於Redis；單點問題上，MongoDB應用簡單，相對用戶透明，Redis比較復雜，需要客戶端主動解決。（MongoDB 一般會使用replica sets和sharding功能結合，replica sets側重高可用性及高可靠性，而sharding側重於性能、易擴展） |
| 可靠性 | 從1.8版本后，采用binlog方式（MySQL同樣采用該方式）支持持久化，增加可靠性 | 依賴快照進行持久化；AOF增強可靠性；增強可靠性的同時，影響訪問性能 | MongoDB優於Redis |
| 一致性 | 不支持事物，靠客戶端自身保證 | 支持事物，比較弱，僅能保證事物中的操作按順序執行 | Redis優於MongoDB |
| 數據分析 | 內置數據分析功能（mapreduce） | 不支持 | MongoDB優於Redis |
| 應用場景 | 海量數據的訪問效率提升 | 較小數據量的性能及運算 | MongoDB優於Redis |
Redis和Mongodb應用場景
現在的分布式項目基本都會用到redis和mongodb，可是redis和mongdb到底有什么不同呢，今天我就基於我們公司的項目來具體介紹一下redis和mongodb的各自的應用場景。
首先我們這個項目中有兩種應用場景：
場景一：要求TPS（不知道的右轉百度）特別高的，比如我們項目有一個點贊的功能，這個點贊的功能促發頻率特別高，而且並發量也會特別大，但是它的數據量不會特別大。基於這種情況下，我們采用redis來實現點贊功能。
場景二：項目中涉及評論的內容，而且這個評論表的數據后期會非常大（海量的數據），最后在數據量非常大的情況下還要求比較復雜的查詢。基於上述這些情況，我們采用mongodb作為評論表存儲數據庫。
應用升級：
現在在給大家介紹一下我們項目中關於redis和mongodb深入的應用，我們接着上面的應用場景繼續往下說。下面我們接着深入上面的這兩個場景，例如下面的這兩個場景：
場景一：比如我們上面說到的場景一中點贊這個行為，因為我們項目對點贊這個數據的安全性要求特別高，而且取消點贊的過程種會涉及其它關聯的操作，而且必須保證是線程是安全的，最重要的是我們需要redis高可用性，不能輕易的掛掉。這個時候我們就用到了redis中數據持久化和分布式鎖的內容了，通過redis數據持久化，我們可以將緩存的數據保存到本地中來。利用redis分布式鎖，我們可以控制取消點贊數據安全問題。關於高可用性的話，我們可以采用redis集群來實現，redis集群我們采用rediscluster來實現，這樣我們就可以實現點贊這種場景的所有要求了。
場景二：我們接着評論表的內容，剛開始評論表可能數據不是特別大，可是隨着時間的增長，評論表的數據會越來越大，但是我們查詢的時間要控制在一段的間內，不能太久才搜索到相關的評論。最后也是同樣的要求，評論查詢的高可用性。基於這種場景我們可以采用mongodb中的分片來實現，通過mongodb的分片機制，我們可以將海量的數據查詢分別負載到不同的分片服務器上面，最后將數據查詢的數據結果整合到一起。基於這種情況，不管數據量有多大，我們都可以實現快速的查詢功能，查詢時間約等於（數據量/分片數量）。分片其實本身就是一種高可用性的方案，因為每一個分片都保留着完整的一份數據，每次插入數據的時候，先插入一個主分片中，然后同步復制到所有從分片中，即使一個分片掛了，其余分片也能自動升級為主分片，繼續工作。
疑問點：
這邊可能會有人要問，既然每片的數據都一樣，那查詢的時間不肯定也一樣嗎，怎么可能是（數據量/分片數量），不應該是（數據量*分片數量）時間嗎。關於這個疑問的話，大家可能得仔細研究一下mongodb分片的規則了，mongodb分片的同時也會把數據進行分片划分，同樣一份數據但是每片查詢的區域是不一樣的，比如分片一會查詢數據的前半截，然后分片二會查詢數據的后半截。這樣不就可以做到同樣的一份數據，但是每一份查詢的數據區域都是不一樣的。我這邊只是簡單的說明，想具體研究的話，可以自己百度百度研究研究。