一个典型支付系统的设计与实现

Published on 五月 27, 2011
4,516

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

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

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

CREATE TABLE `app_margin`.`tb_status` (
    `appid` int(10) UNSIGNED NOT NULL,
    `freeze` int(10) NOT NULL DEFAULT 0,
    `create_time` datetime NOT NULL,
    `change_time` datetime NOT NULL,
 
    PRIMARY KEY (`appid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 
CREATE TABLE `app_margin`.`tb_account_earn` (
    `appid` int(10) UNSIGNED NOT NULL,
    `create_time` datetime NOT NULL,
    `balance` bigint(20) NOT NULL,
    `change_time` datetime NOT NULL,
    `seqid` int(10) NOT NULL DEFAULT 500000000,
 
    PRIMARY KEY (`appid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 
CREATE TABLE `app_margin`.`tb_bill` (
    `id` int AUTO_INCREMENT NOT NULL,
    `bill_id` int(10) NOT NULL,
    `amt` bigint(20) NOT NULL,
    `bill_info` text,
 
    `bill_user` char(128),
    `bill_time` datetime NOT NULL,
    `bill_type` int(10) NOT NULL,
    `bill_channel` int(10) NOT NULL,
    `bill_ret` int(10) NOT NULL,
 
    `appid` int(10) UNSIGNED NOT NULL,
    `old_balance` bigint(20) NOT NULL,
    `price_info` text,
 
    `src_ip` char(128),
 
    PRIMARY KEY (`id`),
    UNIQUE KEY `unique_bill` (`bill_id`,`bill_channel`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 
CREATE TABLE `app_margin`.`tb_assign` (
    `id` int AUTO_INCREMENT NOT NULL,
    `assign_time` datetime NOT NULL,
 
    PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 
CREATE TABLE `app_margin`.`tb_price` (
    `name` char(128) NOT NULL,
    `price` int(10) NOT NULL,
    `info` text NOT NULL,
 
    PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 
CREATE TABLE `app_margin`.`tb_applock` (
    `appid` int(10) UNSIGNED NOT NULL,
    `lock_mode` int(10) NOT NULL DEFAULT 0,
    `change_time` datetime NOT NULL,
 
    PRIMARY KEY (`appid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 
INSERT `app_margin`.`tb_assign` (`id`,`assign_time`) VALUES (100000000,now());

详细解释如下:

  • 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
2
3
4
5
6
7
8
9
10
11
12
13
14

$g_site_error = array(
    -1 => '服务器繁忙',
    -2 => '数据库读取错误',
    -3 => '数据库写入错误',
 
    0 => '成功',
 
    1 => '没有数据',
    2 => '没有权限',
    3 => '余额不足',
    4 => '账户被冻结',
    5 => '账户被锁定',
    6 => '参数错误',
);
  1. 对于大于0的错误都算是逻辑错误，执行支付操作，调用方是不用记录流水的。因为账户并没有发生任何改变。
  2. 对于小于0的错误是系统内部错误，因为不知道是否发生了数据更改，所以调用方和支付系统都要记录流水。
  3. 对于等于0的返回，代表成功，两边也肯定要记录流水。

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

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

二. 账户锁定的实现

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164

class AppLock
{
    function __construct($appid)
    {
        $this->m_appid = $appid;
        //初始化数据
        $this->get();
    }
 
    function __destruct()
    {
        $this->free();
    }
 
 
    public function alloc()
    {
        if ($this->m_bGot == true)
        {
            return true;
        }
 
        $this->repairData();
 
        $appid = $this->m_appid;
        $ret = $this->update($appid,APPLOCK_MODE_FREE,APPLOCK_MODE_ALLOC);
        if ($ret === false)
        {
            app_error_log("applock alloc fail");
            return false;
        }
        if ($ret <= 0)
        {
            app_error_log("applock alloc fail,affected_rows:$ret");
            return false;
        }
        $this->m_bGot = true;
        return true;
    }
 
    public function free()
    {
        if ($this->m_bGot != true)
        {
            return true;
        }
 
        $appid = $this->m_appid;
        $ret = $this->update($appid,APPLOCK_MODE_ALLOC,APPLOCK_MODE_FREE);
        if ($ret === false)
        {
            app_error_log("applock free fail");
            return false;
        }
        if ($ret <= 0)
        {
            app_error_log("applock free fail,affected_rows:$ret");
            return false;
        }
        $this->m_bGot = false;
        return true;
    }
 
    function repairData()
    {
        $db = APP_DB();
 
        $appid = $this->m_appid;
 
        $now = time();
 
        $need_time = $now - APPLOCK_REPAIR_SECS;
 
        $str_need_time = date("Y-m-d H:i:s", $need_time);
 
        $db->where("appid",$appid);
        $db->where("lock_mode",APPLOCK_MODE_ALLOC);
        $db->where("change_time <=",$str_need_time);
 
        $db->set("lock_mode",APPLOCK_MODE_FREE);
        $db->set("change_time","NOW()",false);
 
        $ret = $db->update(TB_APPLOCK);
        if ($ret === false)
        {
            app_error_log("repair applock error,appid:$appid");
            return false;
        }
        return true;
    }
 
    private function get()
    {
        $db = APP_DB();
 
        $appid = $this->m_appid;
 
        $db->where('appid', $appid);
 
        $query = $db->get(TB_APPLOCK);
 
        if ($query === false)
        {
            app_error_log("AppLock get fail.appid:$appid");
            return false;
        }
 
        if (count($query->result_array()) <= 0)
        {
            $applock_data = array(
                'appid'=>$appid,
                'lock_mode'=>APPLOCK_MODE_FREE,
            );
            $db->set('change_time','NOW()',false);
            $ret = $db->insert(TB_APPLOCK, $applock_data);
            if ($ret === false)
            {
                app_error_log("applock insert fail:$appid");
                return false;
            }
 
            //重新获取数据
            $db->where('appid', $appid);
            $query = $db->get(TB_APPLOCK);
 
            if ($query === false)
            {
                app_error_log("AppLock get fail.appid:$appid");
                return false;
            }
            if (count($query->result_array()) <= 0)
            {
                app_error_log("AppLock not data,appid:$appid");
                return false;
            }
        }
        $applock_data = $query->row_array();
        return $applock_data;
    }
 
    private function update($appid,$old_lock_mode,$new_lock_mode)
    {
        $db = APP_DB();
 
        $db->where('appid',$appid);
        $db->where('lock_mode',$old_lock_mode);
 
        $db->set('lock_mode',$new_lock_mode);
        $db->set('change_time','NOW()',false);
 
        $ret = $db->update(TB_APPLOCK);
        if ($ret === false)
        {
            app_error_log("update applock error,appid:$appid,old_lock_mode:$old_lock_mode,new_lock_mode:$new_lock_mode");
            return false;
        }
        return $db->affected_rows();
    }
 
    //是否获取到了锁
    public $m_bGot = false;
 
    public $m_appid;
}

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

三. 对帐逻辑

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

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

1

select sum(amt) from tb_bill where appid=1;

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

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





原创文章，版权所有。转载请注明：转载自Vimer的程序世界 [ http://www.vimer.cn ]

本文链接地址: http://www.vimer.cn/?p=2193

Posted in: php by Dante,4,516 views Tags: , , , , , , ,


较旧一篇«
»较新一篇


16 个评论 在 “一个典型支付系统的设计与实现”

  1. mhsy2003 说：
    2011年05月29日 于 2:20 上午

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

    [回复]

    Dante 回复:
    五月 29th, 2011 at 11:36 上午

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

    [回复]

  2. rem1x 说：
    2011年05月30日 于 10:54 上午

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

    [回复]

    Dante 回复:
    五月 31st, 2011 at 12:13 上午

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

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

    [回复]

  3. 宁波公墓 说：
    2011年06月8日 于 1:30 下午

    看起来好复杂哦

    [回复]

  4. crazyhadoop 说：
    2011年06月9日 于 8:14 上午

    哇~很不错~学习一下~

    [回复]

  5. Mini CN 说：
    2011年06月10日 于 9:35 下午

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

    [回复]

  6. gy 说：
    2011年06月12日 于 1:04 上午

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

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

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

    [回复]

    Dante 回复:
    六月 13th, 2011 at 7:51 下午

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

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

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

    [回复]

    gy 回复:
    六月 16th, 2011 at 10:50 下午

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

    [回复]

    Dante 回复:
    六月 17th, 2011 at 5:12 下午

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

    [回复]

  7. imageby 说：
    2011年06月14日 于 12:21 下午

    太深奥了，哥看不懂

    [回复]

  8. 岭南六少 – 一朵在LAMP架构下挣扎的云 » 分享我收藏的Python和PHP技术站点 说：
    2011年09月29日 于 12:00 上午

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

  9. 匿名 说：
    2012年04月1日 于 2:04 下午

    ͼƬ

    [回复]

  10. dali 说：
    2012年04月1日 于 4:33 下午

    截图不显示啊！

    [回复]

    Dante 回复:
    四月 5th, 2012 at 9:40 上午

    图片加上了。

    [回复]

我要评论

*

*