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

来源:互联网 发布:sql server进阶 编辑:程序博客网 时间:2024/06/05 11:05

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

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

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

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

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

[sql] view plaincopy
  1. CREATE TABLE `app_margin`.`tb_status` (    
  2.     `appid` int(10) UNSIGNED NOT NULL,    
  3.     `freeze` int(10) NOT NULL DEFAULT 0,    
  4.     `create_time` datetime NOT NULL,    
  5.     `change_time` datetime NOT NULL,    
  6.     PRIMARY KEY (`appid`)    
  7. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;   
  8. CREATE TABLE `app_margin`.`tb_account_earn` (    
  9.     `appid` int(10) UNSIGNED NOT NULL,    
  10.     `create_time` datetime NOT NULL,    
  11.     `balance` bigint(20) NOT NULL,    
  12.     `change_time` datetime NOT NULL,    
  13.     `seqid` int(10) NOT NULL DEFAULT 500000000,    
  14.     PRIMARY KEY (`appid`)    
  15. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;   
  16. CREATE TABLE `app_margin`.`tb_bill` (    
  17.     `id` int AUTO_INCREMENT NOT NULL,    
  18.     `bill_id` int(10) NOT NULL,    
  19.     `amt` bigint(20) NOT NULL,    
  20.     `bill_info` text,    
  21.     `bill_user` char(128),    
  22.     `bill_time` datetime NOT NULL,    
  23.     `bill_type` int(10) NOT NULL,    
  24.     `bill_channel` int(10) NOT NULL,    
  25.     `bill_ret` int(10) NOT NULL,    
  26.     `appid` int(10) UNSIGNED NOT NULL,    
  27.     `old_balance` bigint(20) NOT NULL,    
  28.     `price_info` text,    
  29.     `src_ip` char(128),    
  30.     PRIMARY KEY (`id`),    
  31.     UNIQUE KEY `unique_bill` (`bill_id`,`bill_channel`)    
  32. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;    
  33. CREATE TABLE `app_margin`.`tb_assign` (    
  34.     `id` int AUTO_INCREMENT NOT NULL,    
  35.     `assign_time` datetime NOT NULL,    
  36.     PRIMARY KEY (`id`)    
  37. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;    
  38. CREATE TABLE `app_margin`.`tb_price` (    
  39.     `namechar(128) NOT NULL,    
  40.     `price` int(10) NOT NULL,    
  41.     `info` text NOT NULL,    
  42.     PRIMARY KEY (`name`)    
  43. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;    
  44. CREATE TABLE `app_margin`.`tb_applock` (    
  45.     `appid` int(10) UNSIGNED NOT NULL,    
  46.     `lock_mode` int(10) NOT NULL DEFAULT 0,    
  47.     `change_time` datetime NOT NULL,    
  48.     PRIMARY KEY (`appid`)    
  49. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;    
  50. 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,库表设计出来之后,我们就来看一下最典型的几个操作.

一. 支付操作

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

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


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


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

[php] view plaincopy
  1. $g_site_error = array(  
  2.     -1 => '服务器繁忙',  
  3.     -2 => '数据库读取错误',  
  4.     -3 => '数据库写入错误',   
  5.     0 => '成功',  
  6.     1 => '没有数据',  
  7.     2 => '没有权限',  
  8.     3 => '余额不足',  
  9.     4 => '账户被冻结',  
  10.     5 => '账户被锁定',  
  11.     6 => '参数错误',  
  12. );  

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

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

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

二. 账户锁定的实现

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

[php] view plaincopy
  1. class AppLock  
  2. {  
  3.     function __construct($appid)  
  4.     {  
  5.         $this->m_appid = $appid;  
  6.         //初始化数据  
  7.         $this->get();  
  8.     }  
  9.     function __destruct()  
  10.     {  
  11.         $this->free();  
  12.     }  
  13.     public function alloc()  
  14.     {  
  15.         if ($this->m_bGot == true)  
  16.         {  
  17.             return true;  
  18.         }  
  19.         $this->repairData();  
  20.         $appid = $this->m_appid;  
  21.         $ret = $this->update($appid,APPLOCK_MODE_FREE,APPLOCK_MODE_ALLOC);  
  22.         if ($ret === false)  
  23.         {  
  24.             app_error_log("applock alloc fail");  
  25.             return false;  
  26.         }  
  27.         if ($ret <= 0)  
  28.         {  
  29.             app_error_log("applock alloc fail,affected_rows:$ret");  
  30.             return false;  
  31.         }  
  32.         $this->m_bGot = true;  
  33.         return true;  
  34.     }  
  35.     public function free()  
  36.     {  
  37.         if ($this->m_bGot != true)  
  38.         {  
  39.             return true;  
  40.         }  
  41.         $appid = $this->m_appid;  
  42.         $ret = $this->update($appid,APPLOCK_MODE_ALLOC,APPLOCK_MODE_FREE);  
  43.         if ($ret === false)  
  44.         {  
  45.             app_error_log("applock free fail");  
  46.             return false;  
  47.         }  
  48.         if ($ret <= 0)  
  49.         {  
  50.             app_error_log("applock free fail,affected_rows:$ret");  
  51.             return false;  
  52.         }  
  53.         $this->m_bGot = false;  
  54.         return true;  
  55.     }  
  56.     function repairData()  
  57.     {  
  58.         $db = APP_DB();  
  59.         $appid = $this->m_appid;  
  60.         $now = time();  
  61.         $need_time = $now - APPLOCK_REPAIR_SECS;  
  62.         $str_need_time = date("Y-m-d H:i:s"$need_time);  
  63.         $db->where("appid",$appid);  
  64.         $db->where("lock_mode",APPLOCK_MODE_ALLOC);  
  65.         $db->where("change_time <=",$str_need_time);  
  66.         $db->set("lock_mode",APPLOCK_MODE_FREE);  
  67.         $db->set("change_time","NOW()",false);  
  68.         $ret = $db->update(TB_APPLOCK);  
  69.         if ($ret === false)  
  70.         {  
  71.             app_error_log("repair applock error,appid:$appid");  
  72.             return false;  
  73.         }  
  74.         return true;  
  75.     }  
  76.     private function get()  
  77.     {  
  78.         $db = APP_DB();  
  79.         $appid = $this->m_appid;  
  80.         $db->where('appid'$appid);  
  81.         $query = $db->get(TB_APPLOCK);  
  82.         if ($query === false)  
  83.         {  
  84.             app_error_log("AppLock get fail.appid:$appid");  
  85.             return false;  
  86.         }  
  87.         if (count($query->result_array()) <= 0)  
  88.         {  
  89.             $applock_data = array(  
  90.                 'appid'=>$appid,  
  91.                 'lock_mode'=>APPLOCK_MODE_FREE,  
  92.             );  
  93.             $db->set('change_time','NOW()',false);  
  94.             $ret = $db->insert(TB_APPLOCK, $applock_data);  
  95.             if ($ret === false)  
  96.             {  
  97.                 app_error_log("applock insert fail:$appid");  
  98.                 return false;  
  99.             }  
  100.             //重新获取数据  
  101.             $db->where('appid'$appid);  
  102.             $query = $db->get(TB_APPLOCK);  
  103.             if ($query === false)  
  104.             {  
  105.                 app_error_log("AppLock get fail.appid:$appid");  
  106.                 return false;  
  107.             }  
  108.             if (count($query->result_array()) <= 0)  
  109.             {  
  110.                 app_error_log("AppLock not data,appid:$appid");  
  111.                 return false;  
  112.             }  
  113.         }  
  114.         $applock_data = $query->row_array();  
  115.         return $applock_data;  
  116.     }  
  117.     private function update($appid,$old_lock_mode,$new_lock_mode)  
  118.     {  
  119.         $db = APP_DB();  
  120.         $db->where('appid',$appid);  
  121.         $db->where('lock_mode',$old_lock_mode);  
  122.         $db->set('lock_mode',$new_lock_mode);  
  123.         $db->set('change_time','NOW()',false);  
  124.         $ret = $db->update(TB_APPLOCK);  
  125.         if ($ret === false)  
  126.         {  
  127.             app_error_log("update applock error,appid:$appid,old_lock_mode:$old_lock_mode,new_lock_mode:$new_lock_mode");  
  128.             return false;  
  129.         }  
  130.         return $db->affected_rows();  
  131.     }  
  132.     //是否获取到了锁  
  133.     public $m_bGot = false;  
  134.     public $m_appid;  
  135. }  

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

三. 对帐逻辑

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

关于保证账户正确性这里,也有同事跟我说,之前在公司做的时候,是采取只要有任何写操作之前,都先取一下流水表中所有的流水记录,将amt的值累加起来,看得到的结果是否和余额相同。如果不相同应该就是出问题了。
select sum(amt) from tb_bill where appid=1;
  所以这也是为什么我在流水表中,amt字段是要区分正负的原因。
OK,整篇文章写的很长,希望对坚持读完的同学有所帮助。

2 0
原创粉丝点击