PHP imitates the effect of sending red envelopes and receiving red envelopes on WeChat-PHP Tutorial-php.cn

Recent project development requires the implementation of a red envelope function, imitating WeChat (excluding messages), but only the balance can be used to send red envelopes. The editor below will share with you the effect of sending red envelopes and receiving red envelopes using PHP imitating WeChat. Friends who are interested should take a look.

Recent projects need to add a new red envelope function based on chat. Requirements: imitating WeChat (excluding messages) ), but only the remaining balance can be used to send red envelopes. So I used WeChat red envelopes many times to understand various interactive interfaces and business needs, such as display information, classification (individual, group ordinary, group lucky), number limit (100), amount limit (200), expiration time (24 hours) ) and so on, and then start development. The interfaces mentioned below are basically all provided to the app side. After all, I am a phper.

1. The design data table is as follows

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;;

Copy after login

2. Send red envelopes

Since the red envelope is sent to the chat interface immediately after the payment is successful, when "Putting money into the red envelope" in the picture on the left, Insert the red envelope information into the red_packet table (the payment status is not paid), allocate the amount, calculate the luck, and insert it into the red_packet_log table (the recipient and collection time are empty). After the "Confirm Payment" is successful in the picture on the right, update the red_packet table Payment status, and then send a red envelope.

3. Receive red envelopes (only group red envelopes are analyzed here)

## Please make up your own mind on the various prerequisite verifications for receiving red envelopes. Here is a concurrency problem of grabbing red envelopes from a group (dozens of people in the group grab several red envelopes), which can be solved by introducing MQ. When sending red envelopes, first write the number of red envelopes into MQ in sequence. For example, if you send 3 red envelopes, write 1, 2, and 3 in sequence. When grabbing a red envelope, get the value from MQ. The number obtained indicates which red envelope you grabbed, which corresponds to the red envelope in the red_packet_log table. The next step is to update the recipient and collection time of the red_packet_log table, and add money to the balance. And the business such as recording turnover is processed, and then returns to collect the results; if the number cannot be obtained, of course it means that the red envelope is not grabbed, and the "I am slow" interface will appear directly. In the early stage, we considered writing the primary key of the red_packet_log table into MQ, which would eliminate the need to sort and retrieve the log records. However, this would make updating the "receipt consumption time" field more troublesome; using MQ to store numbers, you can directly compare whether It is the last red envelope (the number obtained, etc. and the number of red envelopes), and then the elapsed time is updated.

There are many types of WeChat red envelope receiving result pages (i.e., viewing luck pages): individual and group results are different, the person who sends the red envelope and the person who receives the red envelope see different results, and the individual and group red envelopes expire. After that, the prompts are different and so on. I won’t list them one by one here. They basically just check the database based on the interface.

4. Changes in requirements, adding third-party payment

When it comes to third-party payment, we need to mention synchronous and asynchronous callbacks, as well as the callback time difference. When the synchronization callback on the app side is successful, the red envelope will be sent out (the payment synchronization callback on the app side calls the callback directly). If the asynchronous callback is delayed by one or two seconds at this time, the user will grab the payment status. 0 red envelope. If the app calls the long connection interface to check whether the asynchronous callback has been successful and then sends a red envelope, the user experience will be poor.

# 引入中间状态
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`;

Copy after login

When the user grabs the red envelope, the value of is_into_account is determined based on pay_status;

When the callback is synchronized to the app side, the interface is called The payment status pay_status changes to 2;

When the asynchronous callback is made to the server, the payment status pay_status changes to 1, and the red_packet_log record of is_into_account=1 is found for processing.

But the above three steps must perform FOR UPDATE operations on the red_packet query, otherwise there will be execution time and sequence problems, resulting in some red_packet_log records not arriving is_into_account=0; in addition, the lock mechanism will also cause users to grab Red envelopes become very slow because they have to wait for the lock to be released.

Improvements are as follows: (No FOR UPDATE in the whole process)

When the user grabs the red envelope, the value of is_into_account is determined based on pay_status;

When calling back to the app synchronously, call the interface to change the payment status pay_status to 2;

When calling back asynchronously to the server, change the payment status pay_status to 1, and put the red envelope id (red_packet primary key) into MQ;

Background automatic script, after getting the red envelope ID from MQ, process the record of the red envelope is_into_account=0, and then delay for 5 seconds to write the red envelope ID to MQ again for secondary processing to ensure All data has arrived.

5. Return of expired red envelopes

Here is an automatic script that determines whether it has exceeded 24 hours and the money has not been collected based on the pay_time of the red_packet table, and returns the user's balance.

The above is the entire content of this article, I hope it will be helpful to everyone's study.

Related recommendations:

Detailed explanation of PHP half search algorithm case

phpClass automatic loading, chain operation, magic method implementation code_phpTips

PHP ordered table search interpolation search algorithm steps Detailed explanation

The above is the detailed content of PHP imitates the effect of sending red envelopes and receiving red envelopes on WeChat. For more information, please follow other related articles on the PHP Chinese website!