_php example of the effect of PHP imitation micro-letter red Envelope

Recent projects need to chat on the basis of the new red envelope function, demand: imitation micro-letter (excluding messages), but only use the balance of red envelopes. So many times using the micro-letter red envelopes to understand the various interactive interface and business needs, such as display information, classification (individual, group common, group Spell luck), number limit (100), amount limit (200), Expiration time (24 hours), and so on, and then proceed to develop, the following mentioned basic is provided to the app end of the interface, After all, I'm phper.

First, the design data sheet is as follows

CREATE TABLE ' red_packet ' (' id ' int ' unsigned NOT null auto_increment, ' user_id ' int (a) unsigned NOT null DEFAULT ' 0 ' COMMENT ' user ID ', ' for_id ' int () unsigned not NULL DEFAULT ' 0 ' COMMENT ' issue object (user or group ID) ', ' pay_status ' tinyint (1) unsigned Not null default ' 0 ' COMMENT ' payment status: 0 unpaid, 1 paid ', ' type ' tinyint (1) unsigned NOT null default ' 0 ' COMMENT ' type: 1, Personal, 2, group Common, 3, group fight Luck ', ' intro ' varchar (255) NOT null default ' COMMENT ' profile ', ' number ' tinyint (1) unsigned NOT null default ' 0 ' COMMENT ' , ' Total_money ' decimal (10,2) unsigned not NULL DEFAULT ' 0.0 ' COMMENT ' total amount ', ' Single_money ' decimal (10,2) unsigned not NUL L DEFAULT ' 0.0 ' COMMENT ' single Red envelope amount (0 for group Luck) ', ' Return_money ' decimal (10,2) unsigned not NULL DEFAULT ' 0.0 ' COMMENT ' refund amount ', ' I S_cli_handle ' tinyint (1) unsigned not NULL DEFAULT ' 0 ' COMMENT ' is processed via CLI refund: 0 No, 1 is ', ' Expend_time ' mediumint (1) unsigned NO T null default ' 0 ' COMMENT ' Collect consumption time ', ' add_time ' int (a) unsigned not NULL default ' 0 ' COMMENT ' creation time ', ' pay_time ' int (a) U nsigned not NULL DEFAULT ' 0 ' COMMENT ' payment time ', PRIMARY key (' ID '), key ' user_id ' (' user_id '), key ' Pay_status ' (' pay_status '), key ' Pay_time ' (' Pay_
Time ') Engine=innodb DEFAULT Charset=utf8 comment= ' Red envelope release form '; CREATE TABLE ' Red_packet_log ' (' id ' int ' unsigned NOT null auto_increment, ' rp_id ' int (a) unsigned NOT null DEFAULT ' 0 ' COMMENT ' Red envelope id ', ' user_id ' int (a) unsigned not NULL DEFAULT ' 0 ' COMMENT ' recipient id ', ' Money ' decimal (10,2) unsigned not NUL L default ' 0.0 ' COMMENT ' collect amount ', ' is_good ' tinyint (1) unsigned not NULL DEFAULT ' 0 ' COMMENT ' is the best luck: 0 No, 1 is ', ' add_time ' int ( unsigned NOT NULL default ' 0 ' COMMENT ' Add Time ', ' update_time ' int (a) unsigned NOT null default ' 0 ' COMMENT ' pick time ', PRIM ARY key (' ID '), key ' rp_id ' (' rp_id ') engine=innodb DEFAULT Charset=utf8 comment= ' red envelope to collect the log table ';

Second, send red envelopes

Since the payment was successful, red envelopes are immediately sent to the chat interface, so in the left picture "stuffed into red envelopes", the red envelope information inserted into the Red_packet table (payment status is not paid), and allocate the amount of money, calculate the hand upset after inserting the Red_packet_log table (pick and pick time is empty), On the right, after the "confirm payment" succeeds, update the payment status of the Red_packet table and issue a red envelope.

Third, collect red envelopes (only for the group of Red Envelopes for analysis)

A variety of prerequisites for receiving red envelopes please own brain, here said a robbery group of the concurrent problem (group of dozens of people rob a few red envelopes), introduced MQ to solve. In the red envelopes, first the number of red packets into the MQ, such as 3 red envelopes, then write 1, 2, 3. Grab a red envelope when the value from MQ, get to the number that you are the first few to grab the red envelopes, corresponding to the Red_packet_log table of the first few red envelopes, the next is to update the Red_packet_log form of the recipient and pick up the time, as well as the balance plus money and the flow of business processing, Then return to pick up the results, not to get the number of course does not rob the red envelopes, directly out of the "Hange" interface. Prior to considering the Red_packet_log table's primary key to MQ, you can omit the sort to take a few log records, but this will make the "Pick up time" this field of the update more trouble; using MQ save number, you can directly compare to whether the last red envelopes (the number of numbers, etc. and the number of red envelopes), Then the update consumes time.

There are many kinds of receipt results page (that is, to view the Luck page) of the micro-credit red envelopes: a single and group results are not the same, red envelopes and the people who receive red envelopes are not the same, a single and group of red envelopes after the expiration of the hint is not the same, here are not enumerated, basically are based on the interface to check the database.

Iv. requirements Change, add third party payment

When it comes to third-party payments, you mention synchronous and asynchronous callbacks, as well as a callback lag. App end when the sync callback succeeds, it sends out the red envelopes (app-side payment synchronization callback is called callback directly), if the asynchronous callback is slow for two seconds, then the user will grab the red envelope with a payment status of 0. If the app end calls the long connection interface to find out if the asynchronous callback has been successful, and then send a red envelope, the user experience is poor.

# Introduce intermediate state
ALTER TABLE ' red_packet '
MODIFY COLUMN ' pay_status ' tinyint (1) UNSIGNED not NULL DEFAULT 0 COMMENT ' payment status: 0 unpaid, 1 paid, 2 waiting to account ' after ' for_id ',
ADD COLUMN ' pay_type ' tinyint (1) not NULL DEFAULT 0 COMMENT ' payment method: 0 unknown, 1 Alipay, 2 micro-letter, 3 UnionPay ' A fter ' Pay_status ',
ADD COLUMN ' trade_no ' varchar not NULL DEFAULT ' COMMENT ' third party payment transaction number ' after ' Pay_type ';
ALTER TABLE ' red_packet_log '
ADD COLUMN ' is_into_account ' tinyint (1) UNSIGNED not NULL DEFAULT 0 COMMENT ' to account: 0 No, 1 is ' After ' Is_good ';

When the user grabbed the red envelope, according to Pay_status to determine the value of is_into_account;

When a synchronous callback is made to the app end, the calling interface changes the payment status Pay_status to 2;

When an asynchronous callback is made to the server, the payment status is Pay_status to 1 and the Is_into_account=1 Red_packet_log record is processed.

However, the above three steps to the Red_packet query for UPDATE operations, or there will be execution time and sequence problems, resulting in some red_packet_log records are not accounted for is_into_account= 0 In addition, the lock mechanism will also make the user to rob red envelopes become very slow, because to wait for the lock release.

Improvements are as follows: (Not for UPDATE in full)

When the user grabbed the red envelope, according to Pay_status to determine the value of is_into_account;

When a synchronous callback is made to the app end, the calling interface changes the payment status Pay_status to 2;

Asynchronous callback to the server, the payment status Pay_status into 1, and the Red envelope ID (red_packet primary key) into the MQ;

Background automatic script, from MQ to get the red envelope ID, the red envelope is_into_account=0 record processing, and then delay 5 seconds to write the red envelope ID again MQ, two times processing, to ensure that the data all to account.

Five, the red envelope expired refund

Here is an automatic script, according to the Red_packet table Pay_time judge whether more than 24 hours and did not receive the money, return the user balance.