发现自己经常会一篇文章写了（一）之后，很久都不写（二），搞得最后自己都快要忘记了，所以这次赶紧把统一支付的文章给补上。

上次的文章中将统一支付的v1版本已经讲解ok了，但是还剩下两个问题：

• 服务器端没有办法做分布式
• 客户端对支付sdk进行插件式管理十分困难

我们一个个来说

一. 解决服务器端分布式的问题

解决这个问题的核心思路比较简单：

之前我们是把event的通知放在进程内存中，现在我们做成网络通信

由于支付的请求量本身不属于高并发，所以就放弃了打算直接写通知server的想法，转而看一下有没有什么简单的解决方案。

而由于自己之前redis的使用经历，恰好知道redis有一个pubsub模式，很适合做这种监听和通知的工作。

python的实现示例代码如下：

import time
import config
from share.vals import rds
from share.utils import safe_str
from gevent.timeout import Timeout
from urllib import quote, unquote

class RedisPubSub(object):
    """
    用redis订阅/发布消息
    """
    # 订阅频道
    sub_key ...

其实想跟大家分享这套支付系统的架构已经很久了，今天总算有时间写出来了。

先说说这套系统的需求由来吧：

1. 笔者公司的游戏产品已经有几款了，每次上各种渠道都是要搭配不同的计费方式，并且每开发游戏都要重复一遍痛苦的接入sdk流程
2. 游戏的支付需要出各种报表以及统计，每个游戏单独去做对人力的消耗巨大

基于以上几点，我这边设计了统一支付系统。

这个系列一共会分两篇文章，分别对应系统的v1版和v2版，我们这一篇先从v1起介绍。

在仔细分析了国内的大多数支付sdk之后，我们梳理出游戏的支付流程大体可以实现为两类：

• 第三方sdk服务器进行支付结果通知
• 第三方sdk客户端直接返回支付结果通知，没有服务器支付结果通知。

对于调用方而言，这两种方式各有好处。

• 第一种方式更加安全，但是支付调用的时间相对较长
• 第二种方式速度更快，但是很容易被不怀好意的人破解。参见之前的文章：google支付接口被刷以及解决方案

接下来，我们来看一下我这边设计的统一支付流程。

客户端:

服务器端：

简单解释一下：

• 每次支付开始，都要让服务器生成一个订单作为此次支付的记录，订单的id即为 bill_id。订单有4中状态：订单生成，支付失败，支付成功，发货成功。
• pay_server即为统一支付系统的服务器端，考虑到调用量和方便调试，使用了简单的http协议+json+sign的方式

对于服务器内部，唯一麻烦的一点是，《等待pay_server支付结果通知》这个接口。因为这个http请求需要支持挂起，在第三方支付服务器通知了pay_server之后，pay_server 根据通知里面透传的bill_id 将订单状态修改后，再给客户端结果 ...

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

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

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

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

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

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 ...