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能够做为一个很好的候选，前提是若是要作事务（区别好业务是强一致仍是最终一致），作好程序上的最佳实践。

个人分享就到这里，谢谢你们！