摘要

本次分享主要講mongodb 在互聯網金融中交易與非交易部分如何實踐，金融行業涉及哪些注意點，又踩過的坑。

內容來源：2017年4月22日，考拉理財的技術負責人鄧維在「2017年MongoDB中文社區深圳用戶組大會」進行《mongodb 在互聯網金融的應用》演講分享。IT 大咖說作為獨家視頻合作方，經主辦方和講者審閱授權發布。

閱讀字數：1871 | 4分鐘閱讀

嘉賓演講視頻回顧及PPT：http://t.cn/RQkmO8Z

什麼是P2P

P2P是一種網上的借貸模式，放款人可以通過P2P公司選擇認為比較靠譜的借款人進行投資。這個模式的缺點就是借款人很有可能會卷錢跑路，甚至還存在整個P2P平台全部跑路的風險，放款人的資金將無從追回。

投資到多個P2P平台

所以我們更為推崇的理財方式就是分散理財。那麼如果要將全部資金都投入P2P，分散在各個平台裡面，應該怎麼做？

如上圖所示，左邊是放款人，右邊是借款人。通過投資各種不同的平台中的各個借款，通過這種模式達到分散理財的效果。這樣資金就不會出現比較大的風險，可以比較安穩一點。

但這種模式同樣也有一個問題，要同時管理這麼多平台的賬戶會很麻煩，這是第一個問題。全國大概有2000家P2P Platform，如何甄別好壞，這是第二個問題。

什麼是（類）P2P Fund

於是我們推出了P2P fund概念，用戶可以看的到產品背後是什麼，只需要關心這個產品就可以了。

關於考拉理財

考拉理財就是一個類P2P Fund，類似於基金的概念。我們是為懶人理財服務，通過極致的分散理財，達到風險和收益的平衡。

我們對外通常介紹兩個數字，交易額30億，用戶量有70萬。投資用戶大概在20萬左右，管理的資金有7個億。

這樣的業務下面，Mongodb支撐了我們核心的業務。

需求：變動的需求

我們有很多P2P平台，需要和很多平台的數據對接、或者做數據爬取。我們各個P2P平台的信息完全是結構不一致的，結構比較稀疏（有些有，有些沒有）。

每個子行業提供的P2P平台信息不同，市場的營銷需求變化也很多。

目前，我們較大的collection,其 Doucment count大概在1000萬至1億，我們後台有各種各樣的報表和分析。

在金融方面還有一點特殊的需求，就是數據不能丟失、不能刪除，在安全方面有很高的要求，備份也需要很完整。

我們最初版本的Mongodb部署很簡單，三個節點在IDC機房部署一個讀寫分離的架構。

後續碰到過一些誤刪除的坑，加了一個延時的節點，數據延時一個小時。同時根據不同的表、庫的特點，有些會做每3~6小時備份、每天備份，保留一段時間，再自動刪除比較久遠時間的備份。

隨著業務複雜的增加，阿里雲機房部署了類似兩個數據中心的節點，後來我們在公司裡面也部署了這樣一個節點，用於讓數據分析員在本地分析各種報表。

我們現在還沒有用到阿里雲或騰訊雲的結構，考慮到SLA的要求，後續我們從IDC機房遷到阿里雲，將IDC轉為備用數據中心。

備份的總結

我們當前有以下的備份、恢復策略：將使用Oplog的形式恢復到指定節點、Full backup每六個小時在別的機器、30天內每天的備份，以及延時一小時的備份。

技術棧

MongoDB是我們主要的資料庫,也有MySQL、Hadoop，語言上我們用了Node.js、Python、R。R和SQL是給數據分析員去做的，以及少部分的Java。其餘各互聯網公司大概類似：Docker、Jenkins、ELK、Grafana、一些BI工具等等。

需要事務

事實上，我們對業務沒有強一致性的要求，但是需要準確性。

需要事務MongoDB的事務問題的解決方案

官方提供大概兩個解決方案，一個以嵌套的形式來保證事務的設計。它的更新和查詢速度很快，和業務需求要較好的配合。

另一個Solution就是兩步提交，它的缺點是代碼比較複雜。

其它的解決方案

針對資料庫層面來說，傳統的是用Mysql，或者是Hybrid 的MySQL+MongoDB。SequoiaDB類似於mongoDB，但是它目前還沒有很完善的社區支持，我們沒有採用。

早已熟悉的Hybrid解決方案

如圖所示，左邊是需要交易的部分，右邊是其它非交易部分。如果要用這套混合模式，中間必須要做到同步。

為了保證數據不丟失，我們會用MQ或其它的來保證數據接收的穩定性。

早已熟悉的Hybrid解決方案問題

我們引用了多一個DB在生產環境，引入了MQ、同步機制，疑問著維護成本、延時。

還需要考慮Foreign Key或者Join Tables的問題，但是如果內部能夠處理好這一塊，就可以去做。創業公司不建議考慮這個方案。

其他僅用MongoDB的解決方案: Events Sourcing

把所有的東西都記錄成一個Event，都是通過Event去驅動業務。所有的Event都可以重放(REPLAY)，重放要求對於系統必定是無傷害性的。

我們的解決方案

賬戶設計會考慮內嵌式的文檔設計，同時造了一套類似事務的機制去實現。

上圖就是事務的邏輯。

上圖用代碼簡化內部來說明：先記錄一下要做什麼，如果成功就結束了，如果失敗就回撤。下圖是代碼的應用簡化的實例。

關於交易最佳實踐的要求

所有涉及到交易的部分必定是可重入的（冪等），再執行一遍對系統不會造成傷害。

主動查詢第三方訂單是否支付完成，如果已經支付了就主動確認。

進行交易的前有嚴格的schema 驗證程序。

用戶操作級別提供操作鎖、限制併發。

還有一些與MongoDB無關，但是我們認為比較有效的：在操作前做一個檢查，以及利用Unit Test以保證代碼質量。

MongoDB可以作為一個很好的候選，前提是如果要做事務（區別好業務是強一致還是最終一致），做好程序上的最佳實踐。

我的分享就到這裡，謝謝大家！

編者：IT大咖說，轉載請標明版權和出處