快捷導(dǎo)航

PHP支付系統(tǒng)設(shè)計與典型案例分享

更新時間：2016年08月02日 14:12:09 投稿：lijiao

這篇文章主要為大家詳細介紹了PHP支付系統(tǒng)設(shè)計與典型案例，可以用作小型支付系統(tǒng)，也可以用做第三方應(yīng)用接入開放平臺時的支付流水系統(tǒng)，具有一定的參考價值，感興趣的小伙伴們可以參考一下

由于公司業(yè)務(wù)需要，花兩周時間實現(xiàn)了一個小型的支付系統(tǒng)，麻雀雖小五臟俱全，各種必須的模塊如賬戶加鎖，事務(wù)性保證，流水對帳等都是有完整實現(xiàn)的，整個開發(fā)過程中有很多經(jīng)驗積累，再加上在網(wǎng)上搜索了一下，大部分都是些研究性的論文，對實際使用價值不大，所以這次特意拿出來和大家分享一下。
這個系統(tǒng)可以用作小型支付系統(tǒng)，也可以用做第三方應(yīng)用接入開放平臺時的支付流水系統(tǒng)。
原來的需求比較負責(zé)，我簡化一點說:

對每個應(yīng)用，對外需要提供獲取余額，支付設(shè)備，充值等接口
后臺有程序，每月一號進行清算
賬戶可以被凍結(jié)
需要記錄每一次操作的流水，每天的流水都要和發(fā)起方進行對賬

針對上面的需求，我們設(shè)置如下數(shù)據(jù)庫:

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 應(yīng)用的狀態(tài)表。負責(zé)賬戶是否被凍結(jié)，賬戶的類型是什么（真實的需求是應(yīng)用可能有兩種賬戶，這里為簡單所以沒有列出）
appid 應(yīng)用id
freeze 是否凍結(jié)
create_time 創(chuàng)建時間
change_time 最后一次修改時間
tb_account_earn 應(yīng)用的賬戶余額表
appid 應(yīng)用id
balance 余額（單位為分，不要用小數(shù)存儲，因為小數(shù)本身不精確；另外php要在64位機下才能支持bigint）
create_time 創(chuàng)建時間
change_time 最后一次修改時間
seqid 操作序列號（防并發(fā)，每次update都會+1）
tb_assign 分配流水id的表，tb_bill的bill_id必須是有tb_assign分配的
id 自增id
create_time 創(chuàng)建時間
tb_bill 流水表。負責(zé)記錄每一條操作流水，這里的bill_id不是主鍵，因為同一個bill_id可能會有支付和回滾兩條流水
id 自增序列號
bill_id 流水號
amt 操作的金額（這個是要區(qū)別正負的，主要是為了select all的時候可以直接計算出某段時間的金額變化）
bill_info 操作的詳細信息，比如3臺webserver，2臺db
bill_user 操作用戶
bill_time 流水時間
bill_type 流水類型，區(qū)分是加錢還是減錢
bill_channel 流水來源，如充值，支付，回滾，結(jié)算還是其他
bill_ret 流水的返回碼，包括未處理、成功、失敗，這里的邏輯會在后面講解
appid 應(yīng)用id
old_balance 操作發(fā)生前的賬戶余額
price_info 記錄操作發(fā)生時，記錄被支付物品的單價
src_ip 客戶端ip
tb_price 單價表，記錄了機器的單價
name 機器唯一標(biāo)識
price 價格
info 描述
tb_applock 鎖定表，這是為了避免并發(fā)對某一個應(yīng)用進行寫操作設(shè)計的，具體的代碼會在后面展示
appid 應(yīng)用id
lock_mode 鎖定狀態(tài)。為0則為鎖定，為1則為鎖定
change_time 最后一次修改時間
OK，庫表設(shè)計出來之后，我們就來看一下最典型的幾個操作.

一. 支付操作
我這里只列出了我目前實現(xiàn)的方式，可能不是最好的，但應(yīng)該是最經(jīng)濟又滿足需求的。
先說調(diào)用方這里，邏輯如下:

然后對應(yīng)的支付系統(tǒng)內(nèi)部邏輯如下（只列出支付操作，回滾邏輯差不多，流水檢查是要檢查對應(yīng)的支付流水是否存在）:

常用的錯誤返回碼可能如下就足夠了:

$g_site_error = array( 
-1 => '服務(wù)器繁忙', 
-2 => '數(shù)據(jù)庫讀取錯誤', 
-3 => '數(shù)據(jù)庫寫入錯誤', 
  
0 => '成功', 
  
1 => '沒有數(shù)據(jù)', 
2 => '沒有權(quán)限', 
3 => '余額不足', 
4 => '賬戶被凍結(jié)', 
5 => '賬戶被鎖定', 
6 => '參數(shù)錯誤', 
);

對于大于0的錯誤都算是邏輯錯誤，執(zhí)行支付操作，調(diào)用方是不用記錄流水的。因為賬戶并沒有發(fā)生任何改變。
對于小于0的錯誤是系統(tǒng)內(nèi)部錯誤，因為不知道是否發(fā)生了數(shù)據(jù)更改，所以調(diào)用方和支付系統(tǒng)都要記錄流水。
對于等于0的返回，代表成功，兩邊也肯定要記錄流水。
而在支付系統(tǒng)內(nèi)部，之所以采用先寫入流水，再進行賬戶更新的方式也是有原因的，簡單來說就是盡量避免丟失流水。
最后總結(jié)一下，這種先扣錢，再發(fā)貨，出問題再回滾的方式是一種模式；還有一種是先預(yù)扣，后發(fā)貨，沒有出問題則調(diào)用支付確認來扣款，出了問題就調(diào)用支付回滾來取消，如果預(yù)扣之后很長時間不做任何確認，那么金額會自動回滾。

二. 賬戶鎖定的實現(xiàn)
這里利用了數(shù)據(jù)庫的加鎖機制，具體邏輯就不說了，代碼如下:

class AppLock 
{ 
function __construct($appid) 
{ 
$this->m_appid = $appid; 
//初始化數(shù)據(jù) 
$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; 
} 
  
//重新獲取數(shù)據(jù) 
$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; 
}

為了防止死鎖的問題，獲取鎖的邏輯中加入了超時時間的判斷，大家看代碼應(yīng)該就能看懂

三. 對帳邏輯
如果按照上面的系統(tǒng)來設(shè)計，那么對帳的時候，只要對一下兩邊成功（即bill_ret=0）的流水即可，如果完全一致那么賬戶應(yīng)該是沒有問題的，如果不一致，那就要去查問題了。
關(guān)于保證賬戶正確性這里，也有同事跟我說，之前在公司做的時候，是采取只要有任何寫操作之前，都先取一下流水表中所有的流水記錄，將amt的值累加起來，看得到的結(jié)果是否和余額相同。如果不相同應(yīng)該就是出問題了。
select sum(amt) from tb_bill where appid=1;
所以這也是為什么我在流水表中，amt字段是要區(qū)分正負的原因。

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

您可能感興趣的文章: