由于公司业务需要,花两周时间实现了一个小型的支付系统,麻雀虽小五脏俱全,各种必须的模块如账户加锁,事务性保证,流水对帐等都是有完整实现的,整个开发过程中有很多经验积累,再加上在网上搜索了一下,大部分都是些研究性的论文,对实际使用价值不大,所以这次特意拿出来和大家分享一下。

这个系统可以用作小型支付系统,也可以用做第三方应用接入开放平台时的支付流水系统。

原来的需求比较负责,我简化一点说:

  1. 对每个应用,对外需要提供 获取余额,支付设备,充值 等接口
  2. 后台有程序,每月一号进行清算
  3. 账户可以被冻结
  4. 需要记录每一次操作的流水,每天的流水都要和发起方进行对账

针对上面的需求,我们设置如下数据库:

详细解释如下:

  • tb_status 应用的状态表。负责账户是否被冻结,账户的类型是什么(真实的需求是应用可能有两种账户,这里为简单所以没有列出)
    • appid 应用id
    • freeze 是否冻结
    • create_time 创建时间
    • change_time 最后一次修改时间
  • tb_account_earn 应用的账户余额表
    • appid 应用id
    • balance 余额(单位为分,不要用小数存储,因为小数本身不精确;另外php要在64位机下才能支持bigint)
    • create_time 创建时间
    • change_time 最后一次修改时间
    • seqid 操作序列号(防并发,每次update都会+1)
  • tb_assign 分配流水id的表,tb_bill的bill_id必须是有tb_assign分配的
    • id 自增id
    • create_time 创建时间
  • tb_bill 流水表。负责记录每一条操作流水,这里的bill_id不是主键,因为同一个bill_id可能会有支付和回滚两条流水
    • id 自增序列号
    • bill_id 流水号
    • amt 操作的金额(这个是要区别正负的,主要是为了select all的时候可以直接计算出某段时间的金额变化)
    • bill_info 操作的详细信息,比如3台webserver,2台db
    • bill_user 操作用户
    • bill_time 流水时间
    • bill_type 流水类型,区分是加钱还是减钱
    • bill_channel 流水来源,如充值,支付,回滚,结算还是其他
    • bill_ret 流水的返回码,包括未处理、成功、失败,这里的逻辑会在后面讲解
    • appid 应用id
    • old_balance 操作发生前的账户余额
    • price_info 记录操作发生时,记录被支付物品的单价
    • src_ip 客户端ip
  • tb_price 单价表,记录了机器的单价
    • name 机器唯一标识
    • price 价格
    • info 描述
  • tb_applock 锁定表,这是为了避免并发对某一个应用进行写操作设计的,具体的代码会在后面展示
    • appid 应用id
    • lock_mode 锁定状态。为0则为锁定,为1则为锁定
    • change_time 最后一次修改时间

OK,库表设计出来之后,我们就来看一下最典型的几个操作.

一. 支付操作

我这里只列出了我目前实现的方式,可能不是最好的,但应该是最经济又满足需求的。

先说调用方这里,逻辑如下:

1

然后对应的支付系统内部逻辑如下(只列出支付操作,回滚逻辑差不多,流水检查是要检查对应的支付流水是否存在):

1

常用的错误返回码可能如下就足够了:

  1. 对于大于0的错误都算是逻辑错误,执行支付操作,调用方是不用记录流水的。因为账户并没有发生任何改变。
  2. 对于小于0的错误是系统内部错误,因为不知道是否发生了数据更改,所以调用方和支付系统都要记录流水。
  3. 对于等于0的返回,代表成功,两边也肯定要记录流水。

而在支付系统内部,之所以采用先写入流水,再进行账户更新的方式也是有原因的,简单来说就是尽量避免丢失流水。

最后总结一下,这种先扣钱,再发货,出问题再回滚的方式是一种模式;还有一种是先预扣,后发货,没有出问题则调用支付确认来扣款,出了问题就调用支付回滚来取消,如果预扣之后很长时间不做任何确认,那么金额会自动回滚。

二. 账户锁定的实现

这里利用了数据库的加锁机制,具体逻辑就不说了,代码如下:

为了防止死锁的问题,获取锁的逻辑中加入了超时时间的判断,大家看代码应该就能看懂

三. 对帐逻辑

如果按照上面的系统来设计,那么对帐的时候,只要对一下两边成功(即bill_ret=0)的流水即可,如果完全一致那么账户应该是没有问题的,如果不一致,那就要去查问题了。

关于保证账户正确性这里,也有同事跟我说,之前在公司做的时候,是采取只要有任何写操作之前,都先取一下流水表中所有的流水记录,将amt的值累加起来,看得到的结果是否和余额相同。如果不相同应该就是出问题了。

所以这也是为什么我在流水表中,amt字段是要区分正负的原因。

OK,整篇文章写的很长,希望对坚持读完的同学有所帮助。

暂无相关产品

21则回应给“一个典型支付系统的设计与实现”

  1. mhsy2003说道:

    这个博客跟VIM越来越没啥关系了。

    [回复]

    Dante 回复:

    哈哈,不要这样想嘛,vim毕竟是我们创造价值的工具,用好工具是为了更好的创造价值,所以分享一些有价值的东西我觉得也挺好的~

    [回复]

  2. rem1x说道:

    tb_status 和 tb_account_earn 可以合成一张 tb_account表。
    支付回滚我还以为是事务回滚呢,原来是指交易取消。
    tb_bill表可以添加一个字段,用于标记该笔流水是否对过账。也许还可以添加一个字段用于区分交易的类型,是账务性的(涉及资金操作)还是非账务性的(查询、账户状态修改等)
    建议用会计的借贷表示资金方向。

    [回复]

    Dante 回复:

    呃,文章中有说不合并的原因哈,因为会有两种不同类型的账户。

    嗯,加一个流水是否对过帐这个建议确实不错~

    [回复]

  3. 宁波公墓说道:

    看起来好复杂哦

    [回复]

  4. crazyhadoop说道:

    哇~很不错~学习一下~

    [回复]

  5. Mini CN说道:

    来你这里散散步,虽然不用,看看也挺好

    [回复]

  6. gy说道:

    每个账户应该有个明细表,这样方便查询,(流水表太大)
    账户余额表最好还要有昨日余额,这样方便统计今日发生额,这样可能就会涉及到日切了

    对锁不太理解, 我们维护的银行核心,都是通过数据库事务实现控制的,当然遇到一个大事务会导致另外一些事务超时

    支付回滚是否就是 交易撤销或者交易冲正的意思呢?

    [回复]

    Dante 回复:

    嗯,昨日余额这里确实如果需要出报表的话会方便很多~

    锁的话,其实是直接锁定了这个应用对应的所有表,对数据库用的很少,所以自己给做了。。。不清楚数据库是不是能做。。

    支付回滚就是交易冲正~~

    [回复]

    gy 回复:

    交易冲正如果从银行会计的角度来理解的话,就是再做一笔负金额的交易,达到修改余额,使余额正确的目的.原流水状态不变,跟撤销不一样
    从文中的流程图看, 回滚是不是就是数据库事务rollback了啊
    何不对所有的失败交易调用统一的数据库事务rollback接口呢

    [回复]

    Dante 回复:

    嗯,是我没说清楚,是在做一笔负金额的操作。这笔的流水也会被记录下来。

    [回复]

  7. imageby说道:

    太深奥了,哥看不懂

    [回复]

  8. [...] 一个典型支付系统的设计与实现 | Vimer的程序世界 [...]

  9. 匿名说道:

    ͼƬ

    [回复]

  10. dali说道:

    截图不显示啊!

    [回复]

    Dante 回复:

    图片加上了。

    [回复]

  11. kenny说道:

    有性能测试么?支持什么样的规模,并发

    [回复]

  12. [...] 一个典型支付系统的设计与实现 | Vimer的程序世界 [...]

  13. […] 最近工作和游戏系统关系比较多,所以研究一些网上关于游戏内支付系统文章,发现几篇比较不错的博客,从系统设计到代码实现都有涉及介绍。查看这3篇博文:博文1 博文2 博文3 […]

  14. […] 一个典型支付系统的设计与实现 | Vimer的程序世界 […]

  15. 黄胜刚说道:

    讲得很好,感谢分享!

    [回复]

发表评论