PHP支付系统设计与典型案例分享

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

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

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

rush:sql;"> 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,balance bigint(20) 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,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,库表设计出来之后,我们就来看一下最典型的几个操作.

一. 支付操作

我这里只列出了我目前实现的方式,可能不是最好的,但应该是最经济又满足需求的。 先说调用方这里,逻辑如下:

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

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

'服务器繁忙',-2 => '数据库读取错误',-3 => '数据库写入错误',0 => '成功',1 => '没有数据',2 => '没有权限',3 => '余额不足',4 => '账户被冻结',5 => '账户被锁定',6 => '参数错误',);

对于大于0的错误都算是逻辑错误,执行支付操作,调用方是不用记录流水的。因为账户并没有发生任何改变。 对于小于0的错误是系统内部错误,因为不知道是否发生了数据更改,所以调用方和支付系统都要记录流水。 对于等于0的返回,代表成功,两边也肯定要记录流水。 而在支付系统内部,之所以采用先写入流水,再进行账户更新的方式也是有原因的,简单来说就是尽量避免丢失流水。 最后总结一下,这种先扣钱,再发货,出问题再回滚的方式是一种模式;还有一种是先预扣,后发货,没有出问题则调用支付确认来扣款,出了问题就调用支付回滚来取消,如果预扣之后很长时间不做任何确认,那么金额会自动回滚。

二. 账户锁定的实现

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

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',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的值累加起来,看得到的结果是否和余额相同。如果不相同应该就是出问题了。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持编程之家。

相关文章

统一支付是JSAPI/NATIVE/APP各种支付场景下生成支付订单,返...
统一支付是JSAPI/NATIVE/APP各种支付场景下生成支付订单,返...
前言 之前做了微信登录,所以总结一下微信授权登录并获取用户...
FastAdmin是我第一个接触的后台管理系统框架。FastAdmin是一...
之前公司需要一个内部的通讯软件,就叫我做一个。通讯软件嘛...
统一支付是JSAPI/NATIVE/APP各种支付场景下生成支付订单,返...