版权声明：本文为博主原创文章，未经博主允许不得转载。 https://cloud.tencent.com/developer/article/1434181
今天想和大家谈谈类似余额宝功能的体系设计，用支付宝的人基本都知道余额宝这个功能体系，简单的来说就是，你把钱从余额转到余额宝中去的话，过几天之后就可以得到对应的收益。今天和大家介绍的，就有点类型这个模式。下们我们具体来看看是怎么设计实现的。
返还功能背景：
现在大部分商城平台的积分，大多数都很鸡肋，用户对积分的敏感程度也特别低，为了提升积分的价值，这边我们设计一个，类型余额宝分润功能，积分可以用来每天返现，返现的金额既可以用来购买商品，也可以提出出来。
返还需求：
用户在商城平台消费之后，会获得对应的积分，这个时候用户可以将账户里的积分转入到返还账户中（类似余额转余额宝），转入的积分都会有个收益生效时间，每天凌晨就会开始跑批，给平台所有用户分润对应的现金，分润的现金可以提现到银行卡中，也可以进行购买消费。返还账户中的积分也可以转出到账户中。大致的功能就这些，过程中返还比例之类都要求是可控的，原型图如下所示：
app功能就简单一点了，只有转入、转出、查看分润明细的功能。
返还流程图：
我们先来看一下积分返还现金流程图，这里面的应分等同于积分。
这里面有三个部分，一个是用户原有积分账户，一个是专门返还的账户，最后一个就是运营平台配置模块了。用户将积分转入返还账户中（会有一个最低转入金额），然后到达跑批时间时候，系统会去获取全局的返还配置信息和个人的返还配置信息，将对应的收益跑批到对应的用户中，最后流程结束。
返还功能设计：
根据需求和流程图，我们需要设计：一个表来存储返还账户信息，一个表用来存储返还配置信息，一个表用来存储返还分润明细信息，最后一个比较特殊：用来存储返还分润数据信息，因为每天凌晨我们会去跑每天积分对应的返还收益，这些数据需要从返还账户中快照到返还跑批任务表中，跑批完成后隔天删除这部分的数据。鉴于上面的分析，我们可以设计如下的表：
返还技术要点：
因为涉及到钱，所以技术分析的时候要全方位、各种可能的考虑。接口我们这边可以分为：查询类型接口、修改类型接口、跑批类型接口，下面我们来一一介绍。
1.查询类型接口
关于查询类接口，第一阶段我们主要考虑效率和数据正确性就可以，查询效率主要体现在app响应速度上面，这边我们可以先把对应索引加上去，如果数据量特别大的情况下可以采用分库分表来解决。
2.修改类型接口
修改类型接口一定要考虑接口的幂等，还有就是修改接口会不会有关联操作，需不需要加并发锁进行控制。比如上面流程中转入和转出操作就必须有这些限制，转入的时候需要判断账户余额是否够转入，还有转入的时候账户积分需要加锁冻结，不能同时有其它的操作。
3.跑批类型接口：
跑批类型接口一般指的是定时任务接口，我们这边有一个最核心的接口，就是上面的分润接口，我们需要计算平台所有用户的返还积分，算成钱之后，再给到对应的用户上面，如果平台有10w个用户，我们就必须执行10w次分润。如果数据量大的情况下，一台服务肯定跑不完，所以我们需要用分布式调度模式，起多个服务同时进行任务调度，这边大家可以参考elastic-job这个分布式任务调度框架。
总结：
大家在设计这个方案的时候一定要注意分润跑批执行的时候，要进行转入、转出限制，跑批时间内，不然会对增加项目复杂度和不可控性。复杂的操作可以放在后期优化升级中完成，一开始可以在产品上面做一些限制。还有就是转入、转出是，一定要进行先查询对应账户是否数值够扣，先select在update，千万不要拿app传过来的账户总额来判断。好了今天的内容就介绍到这边了，谢谢大家的阅读～
