內容來源：2017年4月22日，考拉理財的技術負責人鄧維在“2017年MongoDB中文社群深圳使用者組大會”進行《mongodb 在網際網路金融的應用》演講分享。IT 大咖說作為獨家視訊合作方，經主辦方和講者審閱授權釋出。
閱讀字數：1871 | 4分鐘閱讀
嘉賓演講視訊地址：suo.im/4rUHKy
摘要
本次分享主要講mongodb 在網際網路金融中交易與非交易部分如何實踐，金融行業涉及哪些注意點，又踩過的坑。
什麼是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可以作為一個很好的候選，前提是如果要做事務（區別好業務是強一致還是最終一致），做好程式上的最佳實踐。
我的分享就到這裡，謝謝大家！