PHP決済システムの設計と代表的なケース（推奨）
- 墨辰丷オリジナル
- 2018-06-01 15:56:021979ブラウズ
この記事では、主に PHP 決済システムの設計と典型的なケースを詳しく紹介します。これは、小規模な決済システムとして、またはサードパーティのアプリケーションがオープン プラットフォームに接続されている場合の決済フロー システムとして使用できます。ご興味がありましたら、ぜひご参照ください
会社のビジネスニーズのため、小規模な決済システムの実装には 2 週間かかりました。小規模ではありますが、アカウントのロックや取引保証など、必要なモジュールがすべて備わっています。それらはすべて完全に実装されており、開発プロセス全体で多くの経験が蓄積されています。また、インターネットで検索したところ、ほとんどが実用的価値のない研究論文であるため、特別に説明しました。今回はみんなにシェアするために持ち出しました。
このシステムは、小規模な支払いシステムとして、またはサードパーティのアプリケーションがオープンプラットフォームに接続されている場合の支払いフローシステムとして使用できます。
本来の要求はもっと責任のあるものなので、少し単純化してみましょう:
アプリケーションごとに、外部インターフェースを提供する必要があります 残高の取得、機器の支払い、再チャージおよびその他のインターフェースを提供する必要があります
バックグラウンドにプログラムがあります、清算は毎月1日に実行されます
アカウントは凍結される可能性があります
各操作の流れを記録する必要があり、一日の流れを開始者と調整する必要があります
上記の要件に応じてでは、次のデータベースをセットアップします:
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 アプリケーションステータステーブル。アカウントが凍結されているかどうか、およびそのアカウントの種類を担当します (実際の要件は、アプリケーションが 2 つのアカウントを持つことができるため、わかりやすくするためにここにはリストされていません)
appid アプリケーション ID
freeze 凍結するかどうか
create_time 作成時間
change_time 最終変更時刻
tb_account_earn アプリケーションのアカウント残高テーブル
appid アプリケーション ID
残高残高 (単位はセント、小数自体は正確ではないため、保存には小数を使用しないでください。また、php は 64 ビット マシンでサポートされている必要があります) bigint)
create_time 作成時刻
change_time 最終更新時刻
seqid 操作シーケンス番号 (同時実行を防ぐため、更新ごとに +1 されます)
tb_assign パイプライン ID を割り当てるテーブル tb_bill の bill_id は tb_assign によって割り当てられる必要があります
id Auto- increment id
create_time 作成時間
tb_bill パイプライン テーブル。各操作フローの記録を担当します。同じ bill_id に支払いとロールバックの 2 つのフローがある可能性があるため、
bill_id はシリアル番号です。操作の量 (これは正と負を区別する必要があります)、主にすべてを選択した場合に一定期間内の量の変化を直接計算します)
bill_info 操作の詳細情報 (3 つの Web サーバー、2 つのデータベースなど)
bill_user 操作ユーザー
bill_time 請求時間
bill_type 請求タイプ、違いは金額または損失を追加することです
bill_channel リチャージ、支払い、ロールバック、決済などのトランザクションのソース
bill_ret を含むトランザクションのリターン コード未処理、成功、失敗のロジックは後述します
appid アプリケーション ID
old_balance 操作が発生します
price_info レコード操作が発生したときに支払ったアイテムの単価を記録します
src_ip client ip
tb_price 単価テーブル、マシンの単価を記録します
名前 マシンの一意の識別子
価格 価格
情報の説明
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 中国語 Web サイトの他の関連記事を参照してください。