支付系统经常使用设计原则

参考：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、用户名，姓名、年龄、地址等等信息，但经常使用的可能只有用户名、姓名。那么若是咱们将全部的字段放在一块儿会带来没必要要的效率损失，好比查询出来大量无用字段，此时就能够拆成两张表，经常使用字段放到一张表，不经常使用的放到另一张，而且是采用同一个主键。

二 可靠性

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

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