PHP は、WeChat での赤い封筒の送信と受信の効果を模倣します。-PHPチュートリアル-php.cn

最近のプロジェクト開発では、WeChat（メッセージを除く）を模倣した赤い封筒機能の実装が必要ですが、赤い封筒の送信に使用できるのは残高のみです。以下のエディターが、WeChat を模倣した PHP を使用した赤い封筒の送信と受信の効果を共有します。興味のある友達は一緒に見てください。

最近のプロジェクトでは、チャットに基づいた赤い封筒機能を追加する必要があります。 WeChat (メッセージを除く) を模倣していますが、残高を使用して赤い封筒を送信できるのはあなただけです。そこで、WeChatの赤い封筒を何度も使用して、表示情報、分類（個人、グループ普通、グループ幸運）、数制限（100）、数量制限（200）、有効期限（24時間）など、さまざまなインタラクティブインターフェイスとビジネスニーズを理解しました。 ) などを作成して開発を開始します。結局のところ、私は phper です。

1. デザインデータ表は以下の通りです

CREATE TABLE `red_packet` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`user_id` int(10) unsigned NOT NULL DEFAULT &#39;0&#39; COMMENT &#39;用户id&#39;,
`for_id` int(10) unsigned NOT NULL DEFAULT &#39;0&#39; COMMENT &#39;发放对象（用户或群id）&#39;,
`pay_status` tinyint(1) unsigned NOT NULL DEFAULT &#39;0&#39; COMMENT &#39;支付状态：0未支付，1已支付&#39;,
`type` tinyint(1) unsigned NOT NULL DEFAULT &#39;0&#39; COMMENT &#39;类型：1、个人，2、群普通，3、群拼手气&#39;,
`intro` varchar(255) NOT NULL DEFAULT &#39;&#39; COMMENT &#39;简介&#39;,
`number` tinyint(1) unsigned NOT NULL DEFAULT &#39;0&#39; COMMENT &#39;个数&#39;,
`total_money` decimal(10,2) unsigned NOT NULL DEFAULT &#39;0.0&#39; COMMENT &#39;总金额&#39;,
`single_money` decimal(10,2) unsigned NOT NULL DEFAULT &#39;0.0&#39; COMMENT &#39;单个红包金额（群拼手气时为0）&#39;,
`return_money` decimal(10,2) unsigned NOT NULL DEFAULT &#39;0.0&#39; COMMENT &#39;退还金额&#39;,
`is_cli_handle` tinyint(1) unsigned NOT NULL DEFAULT &#39;0&#39; COMMENT &#39;是否经过cli退款处理：0否，1是&#39;,
`expend_time` mediumint(1) unsigned NOT NULL DEFAULT &#39;0&#39; COMMENT &#39;领取消耗时间&#39;,
`add_time` int(10) unsigned NOT NULL DEFAULT &#39;0&#39; COMMENT &#39;创建时间&#39;,
`pay_time` int(10) unsigned NOT NULL DEFAULT &#39;0&#39; COMMENT &#39;支付时间&#39;,
PRIMARY KEY (`id`),
KEY `user_id` (`user_id`),
KEY `pay_status` (`pay_status`),
KEY `pay_time` (`pay_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT=&#39;红包发放表&#39;;
CREATE TABLE `red_packet_log` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`rp_id` int(10) unsigned NOT NULL DEFAULT &#39;0&#39; COMMENT &#39;红包id&#39;,
`user_id` int(10) unsigned NOT NULL DEFAULT &#39;0&#39; COMMENT &#39;领取人id&#39;,
`money` decimal(10,2) unsigned NOT NULL DEFAULT &#39;0.0&#39; COMMENT &#39;领取金额&#39;,
`is_good` tinyint(1) unsigned NOT NULL DEFAULT &#39;0&#39; COMMENT &#39;是否手气最佳：0否，1是&#39;,
`add_time` int(10) unsigned NOT NULL DEFAULT &#39;0&#39; COMMENT &#39;添加时间&#39;,
`update_time` int(10) unsigned NOT NULL DEFAULT &#39;0&#39; COMMENT &#39;领取时间&#39;,
PRIMARY KEY (`id`),
KEY `rp_id` (`rp_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT=&#39;红包领取日志表&#39;;

ログイン後にコピー

2. 赤い封筒を送る

チャットインターフェイスがすぐに表示されるので、左の図のように「赤い封筒にお金を詰める」場合、red_packetテーブルに赤い封筒の情報を挿入し（支払いステータスは未払い）、金額を割り当て、運を計算し、挿入しますそれを red_packet_log テーブルに追加します (受信者と収集時刻は空です)。右側の図は「支払いの確認」を示しています。成功したら、red_packet テーブルの支払いステータスを更新し、赤い封筒を送信します。

3. 赤い封筒を受信します (これはグループの赤い封筒についてのみ分析されます)

赤い封筒を受信するためのさまざまな前提条件の検証については、独自に決定してください。これは同時実行の問題です。グループの赤い封筒をつかみ (グループの数十人が赤い封筒をいくつかつかみます)、それを解決するために MQ を導入します。赤い封筒を送るときは、まず赤い封筒の番号を順番に MQ に書き込みます。たとえば、赤い封筒を 3 枚送る場合は、1、2、3 と順番に書き込みます。赤いエンベロープを取得するときに、MQ から値を取得します。取得された番号は、red_packet_log テーブルの赤いエンベロープに対応する、どの赤いエンベロープを取得したかを示します。次のステップは、red_packet_log テーブルの受信者と収集時間を更新することです。残高にお金を追加し、売上高の記録などの処理が行われ、数字が取得できない場合は、当然、赤い封筒がつかまれていないことを意味し、「遅い」となります。インターフェイスが直接表示されます。初期段階では、red_packet_log テーブルの主キーを MQ に書き込むことを検討しました。これにより、ログレコードのソートと取得が不要になります。ただし、これにより、MQ を使用して「受信消費時間」フィールドを更新するのがより面倒になります。番号を保存すると、最後の赤封筒かどうか（取得した番号などと赤封筒の数）を直接比較し、経過時間が更新されます。

WeChat の赤い封筒の受信結果ページ (幸運のページの表示など) にはさまざまな種類があります。個人とグループの結果は異なり、赤い封筒を送る人と受け取る人では異なる結果が表示され、その後のプロンプトも異なります。個人とグループの赤い封筒の有効期限は異なります。ここでは 1 つずつ列挙しませんが、基本的にはインターフェイスに基づいてデータベースをチェックするだけです。

4. 要件の変更、サードパーティ支払いの追加

サードパーティ支払いに関しては、同期コールバックと非同期コールバック、およびコールバック時間の違いについて言及する必要があります。アプリ側の同期コールバックが成功すると、赤い封筒が送信されます（アプリ側の支払い同期コールバックがコールバックを直接呼び出します）このとき、非同期コールバックが 1 ～ 2 秒遅れる場合、ユーザーは、 0 の赤い封筒を取得します。アプリが長時間接続インターフェイスを呼び出して非同期コールバックが成功したかどうかを確認し、その後赤いエンベロープを送信すると、ユーザーエクスペリエンスは低下します。

# 引入中间状态
ALTER TABLE `red_packet`
MODIFY COLUMN `pay_status` tinyint(1) UNSIGNED NOT NULL DEFAULT 0 COMMENT &#39;支付状态：0未支付，1已支付，2等待到账&#39; AFTER `for_id`,
ADD COLUMN `pay_type` tinyint(1) NOT NULL DEFAULT 0 COMMENT &#39;支付方式：0未知，1支付宝，2微信，3银联&#39; AFTER `pay_status`,
ADD COLUMN `trade_no` varchar(30) NOT NULL DEFAULT &#39;&#39; COMMENT &#39;第三方支付交易号&#39; AFTER `pay_type`;
ALTER TABLE `red_packet_log`
ADD COLUMN `is_into_account` tinyint(1) UNSIGNED NOT NULL DEFAULT 0 COMMENT &#39;是否到账：0否，1是&#39; AFTER `is_good`;

ログイン後にコピー

ユーザーが赤い封筒を掴むと、is_into_account の値が pay_status に基づいて決定されます。

アプリに同期的にコールバックすると、呼び出し側インターフェイスは支払いステータス pay_status を 2 に変更します。非同期でサーバーに戻り、支払いステータス pay_status を 1 に変更し、処理のために is_into_account=1 の red_packet_log レコードを見つけます。

ただし、上記の 3 つの手順では red_packet クエリに対して FOR UPDATE 操作を実行する必要があります。そうしないと、実行時間とシーケンスの問題が発生し、一部の red_packet_log レコードが到着しなくなり、さらに、ロックメカニズムによってユーザーが次のようになります。赤い封筒をつかむときに混乱します。ロックが解除されるまで待たなければならないため、非常に遅くなります。

改善点は次のとおりです: (プロセス全体で FOR UPDATE はありません)

ユーザーが赤い封筒を取得すると、is_into_account の値は pay_status に基づいて決定されます。アプリでは、インターフェースが呼び出されて支払いステータス pay_status が 2 に変更されます。

サーバーに対して非同期コールバックが行われると、支払いステータス pay_status が 1 に変更され、赤いエンベロープ ID (red_packet 主キー) が MQ に追加されます。 ;

バックグラウンドの自動スクリプトは、MQ から赤いエンベロープ ID を取得した後、赤いエンベロープ is_into_account=0 を配置します。レコードが処理され、5 秒の遅延で赤いエンベロープ ID が再度 MQ に書き込まれ、二次処理が行われます。すべてのデータが確実に受信されるようにするために実行されます。

5.期限切れの赤い封筒の返却

これは red_packet テーブルの pay_time に基づいて、24 時間を超えてお金が回収されていないかどうかを判断し、ユーザーの残高を返します。

以上がこの記事の全内容です、皆様の学習のお役に立てれば幸いです。