PHP 決済システムの設計と典型的なケース Sharing_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 db など)
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、ライブラリ テーブルを設計した後、最も一般的な操作を見てみましょう。

1.

私が現在実装している方法を列挙しただけです。これが最善ではないかもしれませんが、最も経済的でニーズを満たすはずです。
最初に呼び出し元について説明します。ロジックは次のとおりです。

次に、支払いシステムの対応する内部ロジックは次のとおりです (支払い操作のみがリストされ、ロールバック ロジックは同様で、フロー チェックは次のとおりです)。対応する支払いフローが存在するかどうかを確認してください):

一般的に使用されるエラー戻りコードは次のとおりです:

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

支払い操作を実行するとき、呼び出し元は論理エラーとみなされません。取引を記録する必要がある。アカウントは変わっていないので。

0 未満のエラーは内部システム エラーです。データ変更が発生したかどうかは不明であるため、呼び出し元と支払いシステムの両方がフローを記録する必要があります。

リターンが 0 の場合は成功を意味し、双方ともフローを記録する必要があります。
決済システムにおいて、トランザクションが最初に書き込まれてからアカウントが更新されるのには理由があります。簡単に言えば、トランザクションの損失を避けるためです。
最後に、要約すると、最初にお金を差し引いてから発送し、問題があればロールバックするという方法は 1 つのモデルであり、最初に保留してから発送するという別の方法もあります。問題がなければ、支払いの確認が行われます。何らかの問題が発生した場合は、支払いロールバックを呼び出してキャンセルしてください。源泉徴収後、長期間確認が行われない場合、金額は自動的にロールバックされます。

2. アカウントロックの実装

ここでは、データベースのロックメカニズムについては説明しません。コードは次のとおりです。

デッドロックの問題を防ぐために、ロックを取得するロジックにタイムアウト判定を追加しています

3. リコンシリエーションロジック
に従って設計されている場合。この際、両方の成功したトランザクション (つまり bill_ret=0) を確認するだけで済みます。それらが完全に一致していれば、アカウントに問題はありません。問題を確認する必要があります。
アカウントの正確性の確保に関して、同僚は、私が会社で働いていたとき、書き込み操作の前に、トランザクション テーブル内のすべてのトランザクション レコードが最初に取得され、amt の値が結果は残高と同じですか？それらが同じでない場合は、何かが間違っています。
select sum(amt) from tb_bill where appid=1;
これが、私のフロー テーブルで amt フィールドが正と負を区別する必要がある理由です。

上記がこの記事の全内容です。その他の関連コンテンツについては、PHP 中国語 Web サイト (www.php.cn) をご覧ください。