金融实时算息服务揭秘

一、背景：金融类产品的用户对自己在APP的资产信息都极为敏感，确保用户资产高准确性，高实时，高稳定已经成为一项重要的系统化需求，比如用户下单，支付，提现等操作都会发生大量资产变动情况，如何能保证订单变动后的资产实时计算，变动消息处理顺序与用户操作顺序强一致性都是我们要面临的问题。

二、算息服务技术选型：

2-1.为满足高实时性要求我们选择canal监控mysql binlog的方式去收集用户操作订单的轨迹，这样可以第一时间计算出用户的资产变动情况。
2-2.订单变动记录数据量巨大，我们选择性能较高的Kafka作为消息中间件

中间件对比
2-3.为满足高实时性要求我们选择Storm实时计算用户资产信息

大数据计算系统对比
2-4.为满足订单变动的顺序一致性和高效率读取需求我们选择redis作为分布式锁的实现和用户资产第一层存储，Mysql作为第二层存储。
算息服务整体架构：
算息架构
三、一些问题和解决方式：
3-1. 订单每日都会产生收益，这一点是无用户触发的，所以加入了elastic-job定时触发订单收益计算的跑批任务。
3-2. 订单变动处理时必须严格按照用户的触发顺序去处理，否则会导致资产计算错误，例如一笔订单支付状态的两个变动：待支付和支付成功，如果待支付后被处理的话，就会出现资产错误的情况如图：

消息顺序

图中可看出消息的生产者都是单实例产出的，可以保证消息的顺讯性，但是当有多个消费者时，相当于多个线程在处理消息，所以顺讯一致性被打破。
针对这一问题我们采用redis锁的方式来实现消息处理的一致性，在生产者发送消息时在redis存放固定key的消息序号，key的形式为：memberId#orderNo，value则是序号 + 处理结束标示，每次消息处理判断上次的序号是否是本次序号-1且处理结束标示为已结束。如果满足则开始处理逻辑
。

3-3.监控，除了基础的队列监控和系统异常监控外，我们增加了利息不一致实施修复和告警等方式确保资产准确性。
四、具体实现
4-1. canal server每次分析mysql binlog只能有一个实例是running，其他处于standby状态，canal通过zookeeper创建的临时节点并选举出master执行者，具体实现请参阅canal文档，该层我们部署三个实例保证数据读取稳定性，
每次订单变动后组建出记录before和after的全部数据，发送至kafka供计算平台分析计算。
图片来源：https://agapple.iteye.com/blog/1796633
4-2.数据计算阶段通过kafkaSpout接收到消息后首先通过JsonFunction解析消息内容通过基础数据判断出当前消息是否有重要字段变更，例如订单状态，金额等，当订单状态符合收益变动时，更新数据库和redis。
4-3.每日收益的计算通过调度系统触发凌晨的定时任务，匹配出需要计算收益的所有订单，组建数据后发送到数据计算层按不同订单类型和收益率计算出当日用户收益。
4-4.web服务层由springboot搭建提供APP需要的所有资产信息，包括第三方服务资产，如果全部同步查询将是一个漫长的过程，所有采用Future异步加载各个渠道的资产信息然后聚合数据并存放到redis缓存，以此方式提高接口服务效率。

五、最后
目前这一套算息系统运行稳定，但还存在一些问题，例如当订单被全量修改一个update_time时将会导致大量无用数据涌入队列并到达storm计算，会严重影响正常业务的计算，会导致用户资产在下完单后没有变化的情况。还有以后随着后续订单量和用户量逐步上升系统压力也随之变大，这都是之后要面临的问题，提前做好预备方案势在必行。