Redis和Mongodb應用場景研究

現在的分佈式項目基本都會用到redis和mongodb，可是redis和mongdb到底有什麼不同呢，今天我就基於我們公司的項目來具體介紹一下redis和mongodb的各自的應用場景。

首先我們這個項目中有兩種應用場景：

場景一：要求TPS（不知道的右轉百度）特別高的，比如我們項目有一個點讚的功能，這個點讚的功能促發頻率特別高，而且併發量也會特別大，但是它的數據量不會特別大。基於這種情況下，我們採用 redis來實現點贊功能。

場景二：項目中涉及評論的內容，而且這個評論表的數據後期會非常大（海量的數據），最後在數據量非常大的情況下還要求比較複雜的查詢。基於上述這些情況，我們採用 mongodb作爲評論表存儲數據庫。

redis和mongodb相同點和不同點我這邊就不進行過多的描述，網上的文章滿地都是，比如這篇文章： https://zhidao.baidu.com/question/178866950875265404.html

應用升級：現在在給大家介紹一下我們項目中關於redis和mongodb深入的應用，我們接着上面的應用場景繼續往下說。下面我們接着深入上面的這兩個場景，例如下面的這兩個場景：

場景一：比如我們上面說到的場景一中點贊這個行爲，因爲我們項目對點贊這個數據的安全性要求特別高，而且取消點讚的過程種會涉及其它關聯的操作，而且必須保證是線程是安全的，最重要的是我們需要redis高可用性，不能輕易的掛掉。這個時候我們就用到了 redis中數據持久化和分佈式鎖的內容了，通過redis數據持久化，我們可以將緩存的數據保存到本地中來。利用redis分佈式鎖，我們可以控制取消點贊數據安全問題。關於高可用性的話，我們可以採用redis集羣來實現，redis集羣我們採用 rediscluster來實現，這樣我們就可以實現點贊這種場景的所有要求了。

場景二：我們接着評論表的內容，剛開始評論表可能數據不是特別大，可是隨着時間的增長，評論表的數據會越來越大，但是我們查詢的時間要控制在一段的間內，不能太久才搜索到相關的評論。最後也是同樣的要求，評論查詢的高可用性。基於這種場景我們可以採用 mongodb中的分片來實現，通過mongodb的分片機制，我們可以將海量的數據查詢分別負載到不同的分片服務器上面，最後將數據查詢的數據結果整合到一起。基於這種情況，不管數據量有多大，我們都可以實現快速的查詢功能，查詢時間約等於 （數據量/分片數量）。分片其實本身就是一種高可用性的方案，因爲每一個分片都保留着完整的一份數據，每次插入數據的時候，先插入一個主分片中，然後同步複製到所有從分片中，即使一個分片掛了，其餘分片也能自動升級爲主分片，繼續工作。

疑問點：

這邊可能會有人要問，既然每片的數據都一樣，那查詢的時間不肯定也一樣嗎，怎麼可能是（數據量/分片數量），不應該是（數據量*分片數量）時間嗎。關於這個疑問的話，大家可能得仔細研究一下mongodb分片的規則了，mongodb分片的同時也會把數據進行分片劃分，同樣一份數據但是每片查詢的區域是不一樣的，比如分片一會查詢數據的前半截，然後分片二會查詢數據的後半截。這樣不就可以做到同樣的一份數據，但是每一份查詢的數據區域都是不一樣的。我這邊只是簡單的說明，想具體研究的話，可以自己百度百度研究研究。

想要更多幹貨、技術猛料的孩子，快點拿起手機掃碼關注我，我在這裏等你哦~