mongoDB在互聯網金融的應用

內容來源：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能夠做爲一個很好的候選，前提是若是要作事務（區別好業務是強一致仍是最終一致），作好程序上的最佳實踐。

個人分享就到這裏，謝謝你們！