一個典型PHP支付系統的設計與實現

來源:互聯網
上載者:User

 

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

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

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

  1. 對每個應用,對外需要提供 擷取餘額,支付裝置,儲值 等介面
  2. 後台有程式,每月一號進行清算
  3. 賬戶可以被凍結
  4. 需要記錄每一次操作的流水,每天的流水都要和發起方進行對賬

針對上面的需求,我們設定如下資料庫:

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

一. 支付操作

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

先說調用方這裡,邏輯如下:

然後對應的支付系統內部邏輯如下(只列出支付操作,復原邏輯差不多,流水檢查是要檢查對應的支付流水是否存在):

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

1234567891011121314
$g_site_error = array(    -1 => '伺服器繁忙',    -2 => '資料庫讀取錯誤',    -3 => '資料庫寫入錯誤',     0 => '成功',     1 => '沒有資料',    2 => '沒有許可權',    3 => '餘額不足',    4 => '賬戶被凍結',    5 => '賬戶被鎖定',    6 => '參數錯誤',);
  1. 對於大於0的錯誤都算是邏輯錯誤,執行支付操作,調用方是不用記錄流水的。因為賬戶並沒有發生任何改變。
  2. 對於小於0的錯誤是系統內部錯誤,因為不知道是否發生了資料更改,所以調用方和支付系統都要記錄流水。
  3. 對於等於0的返回,代表成功,兩邊也肯定要記錄流水。

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

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

二. 賬戶鎖定的實現

這裡利用了資料庫的加鎖機制,具體邏輯就不說了,代碼如下:

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

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

所以這也是為什麼我在流水表中,amt欄位是要區分正負的原因。

OK,整篇文章寫的很長,希望對堅持讀完的同學有所協助。



相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。