現在的分散式專案基本都會用到redis和mongodb，可是redis和mongdb到底有什麼不同呢，今天我就基於我們公司的專案來具體介紹一下redis和mongodb的各自的應用場景。首先我們這個專案中有兩種應用場景：場景一：要求TPS（不知道的右轉百度）特別高的，比如我們專案有一個點讚的功能，這個點讚的功能促發頻率特別高，而且併發量也會特別大，但是它的資料量不會特別大。基於這種情況下，我們採用redis來實現點贊功能。場景二：專案中涉及評論的內容，而且這個評論表的資料後期會非常大（海量的資料），最後在資料量非常大的情況下還要求比較複雜的查詢。基於上述這些情況，我們採用mongodb作為評論表儲存資料庫。應用升級：現在在給大家介紹一下我們專案中關於redis和mongodb深入的應用，我們接著上面的應用場景繼續往下說。下面我們接著深入上面的這兩個場景，例如下面的這兩個場景：場景一：比如我們上面說到的場景一中點贊這個行為，因為我們專案對點贊這個資料的安全性要求特別高，而且取消點讚的過程種會涉及其它關聯的操作，而且必須保證是執行緒是安全的，最重要的是我們需要redis高可用性，不能輕易的掛掉。這個時候我們就用到了redis中資料持久化和分散式鎖的內容了，通過redis資料持久化，我們可以將快取的資料儲存到本地中來。利用redis分散式鎖，我們可以控制取消點贊資料安全問題。關於高可用性的話，我們可以採用redis叢集來實現，redis叢集我們採用rediscluster來實現，這樣我們就可以實現點贊這種場景的所有要求了。場景二：我們接著評論表的內容，剛開始評論表可能資料不是特別大，可是隨著時間的增長，評論表的資料會越來越大，但是我們查詢的時間要控制在一段的間內，不能太久才搜尋到相關的評論。最後也是同樣的要求，評論查詢的高可用性。基於這種場景我們可以採用mongodb中的分片來實現，通過mongodb的分片機制，我們可以將海量的資料查詢分別負載到不同的分片伺服器上面，最後將資料查詢的資料結果整合到一起。基於這種情況，不管資料量有多大，我們都可以實現快速的查詢功能，查詢時間約等於（資料量/分片數量）。分片其實本身就是一種高可用性的方案，因為每一個分片都保留著完整的一份資料，每次插入資料的時候，先插入一個主分片中，然後同步複製到所有從分片中，即使一個分片掛了，其餘分片也能自動升級為主分片，繼續工作。疑問點：

這邊可能會有人要問，既然每片的資料都一樣，那查詢的時間不肯定也一樣嗎，怎麼可能是（資料量/分片數量），不應該是（資料量*分片數量）時間嗎。關於這個疑問的話，大家可能得仔細研究一下mongodb分片的規則了，mongodb分片的同時也會把資料進行分片劃分，同樣一份資料但是每片查詢的區域是不一樣的，比如分片一

會查詢資料的前半截，然後分片二會查詢資料的後半截。這樣不就可以做到同樣的一份資料，但是每一份查詢的資料區域都是不一樣的。我這邊只是簡單的說明，想具體研究的話，可以自己百度百度研究研究。

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