PHP支付系統的設計與實現典型案例

由於自己項目需要，花兩週時間實現了一個小型的支付系統，麻雀雖小五臟俱全，各種必須的模塊如賬戶加鎖，事務性保證，流水對帳等都是有完整實現的，整個開發過程中有很多經驗積累，再加上在網上搜索了一下，大部分都是些研究性的論文，對實際使用價值不大，所以這次特意拿出來和大家分享一下。

這個系統可以用作小型支付系統，也可以用做第三方應用接入開放平臺時的支付流水系統。

原來的需求比較負責，我簡化一點說:

對每個應用，對外需要提供獲取餘額，支付設備，充值等接口
後臺有程序，每月一號進行清算
賬戶可以被凍結
需要記錄每一次操作的流水，每天的流水都要和發起方進行對賬

針對上面的需求，我們設置如下數據庫:

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，庫表設計出來之後，我們就來看一下最典型的幾個操作.

一. 支付操作

我這裏只列出了我目前實現的方式，可能不是最好的，但應該是最經濟又滿足需求的。

先說調用方這裏，邏輯如下:

然後對應的支付系統內部邏輯如下（只列出支付操作，回滾邏輯差不多，流水檢查是要檢查對應的支付流水是否存在）:

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

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

對於大於0的錯誤都算是邏輯錯誤，執行支付操作，調用方是不用記錄流水的。因爲賬戶並沒有發生任何改變。
對於小於0的錯誤是系統內部錯誤，因爲不知道是否發生了數據更改，所以調用方和支付系統都要記錄流水。
對於等於0的返回，代表成功，兩邊也肯定要記錄流水。

而在支付系統內部，之所以採用先寫入流水，再進行賬戶更新的方式也是有原因的，簡單來說就是儘量避免丟失流水。

最後總結一下，這種先扣錢，再發貨，出問題再回滾的方式是一種模式；還有一種是先預扣，後發貨，沒有出問題則調用支付確認來扣款，出了問題就調用支付回滾來取消，如果預扣之後很長時間不做任何確認，那麼金額會自動回滾。

二. 賬戶鎖定的實現

這裏利用了數據庫的加鎖機制，具體邏輯就不說了，代碼如下:

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的值累加起來，看得到的結果是否和餘額相同。如果不相同應該就是出問題了。

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

所以這也是爲什麼我在流水錶中，amt字段是要區分正負的原因。

PHP支付系統的設計與實現典型案例

主從遇到的各種問題的詳細解決方法

PHP實現定時器任務（Timer）

mysql 主從配置詳解

mysql 主從配置詳解2（主庫有數據從庫熱備份和冷備份）

PHP+mysql+ajax輕量級聊天室

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結