支付系统常用设计原则

参考：http://www.jianshu.com/p/65b1...

一 表结构设计

用户资产表：CustomerBalanceAsset

储存用户余额资产。比如返现活动等，例如评价返现30元，一般我们都是返到用户余额；另外一些项目有充值需求，也可以把第三方支付结构或者银行机构内的资金充值到余额中。

资产变动记录表： CustomerBalanceAssetLog

储存用户余额资产变动记录。因为资产肯定会发生变动（增减），必须需要log表例如customer_balance_log（可以业务代码实现写入也可以通过数据库的event实现，建议采用前者）记录所有的资金变动详情，方便对账补偿差错。

红包表：CustomerCouponAsset

储存用户红包资产，用户参加红包活动，领取红包资产，会记录到这张表中。

红包日志表： CustomerCouponAssetLog

储存用户红包资产变动记录，消费，过期等
...... 另外一些积分，抵扣券可以沿用类似逻辑

支付信息表：Payment

储存用户支付行为信息。关键字段有总支付金额，支付创建人，支付状态等。多个订单可能合并成一个支付，或者一个订单分拆成多个支付，所以需要和Order表多对多映射

流水表：Transaction

储存用户资金单据（流水），关键字段为支付渠道，支付金额，支付时间，支付状态等。其与Payment为多对一关系。但是不同的Transaction有不同的字段，例如微信支付有商户订单号，预支付单号等，这些字段是余额资金单据不需要的，如果设计一个大Transaction表的话，不利于扩展，也会造成不少记录会出现空字段。

因此可以根据不同的资金单据设置不同的数据模型，比如
资产流水表：BalanceTransactionInfo
红包流水表：CouponTransactionInfo
微信流水表：WeixinTransactionInfo字表
支付宝流水表：AlipayTransactionInfo表
......
以共享主键的方式与Transaction表建立一对一关系。
共享主键
为了提高数据库性能。比如我们有一张user表，有id、用户名，姓名、年龄、地址等等信息，但常用的可能只有用户名、姓名。那么如果我们将所有的字段放在一起会带来不必要的效率损失，比如查询出来大量无用字段，此时就可以拆成两张表，常用字段放到一张表，不常用的放到另外一张，并且是采用同一个主键。

二 可靠性

存在调用支付接口支付成功，回来之后你要更新表状态啥的，万一更新失败了呢？抛异常了，你是给用户反馈支付成功了还是失败了？调用支付接口成功后当然是已经支付成功喽，那么这个时候就应该直接返回给用户支付成功，而后可以使用消息队列将付款后的一系列操作扔到消息队列里去，让它自己去玩。

同样的道理适用于与供应商交互，当有一些关键操作时，都可以使用异步队列来确保执行完成。