Implementation of a packet sending function (Redis+mysql+quartz)

This article is mainly for six months ago to develop the red envelope module to organize, the main design ideas and specific implementation of the program to introduce, such as design and implementation of the defects, or there are loopholes, please criticize correct!

Red envelope function Everyone is very familiar with, that here is a simple description of the function of red envelopes ...

Function Description: The main function of red envelope business includes four parts, which are red envelopes, red envelopes, red envelopes, and red envelopes.

1) Red envelopes Send: Sender account, red envelopes middle layer

2) Red Envelope Reception: The recipient account in the middle of the red envelope

3) Red Envelope recovery: Red envelopes in the middle tier if there is a red envelope retained more than 24 hours, it will be recycled, the middle of the red envelope, sender account

Functional description After a general understanding, then the next step is to implement the solution ...

First of all, the design process, this part will be sent to the red envelopes, red envelopes receive, red envelope recycling process Analysis ...

1. Design process

The first is the red envelope send function, take the group red envelope as an example, its flowchart is as follows:

Figure 1 Red Packet sending flowchart

First, a Gaussian distribution based method, the amount of 100 randomly allocated to 8 copies, and then the 8 copies of the data into the Redis cache queue (list), while the queue expiration time set to 24h; Considering the problem of repeated robbery when the red envelopes are robbed, The de-duplication scenario used here is to maintain an assigned set (set) in the Redis cache, which stores the user ID that has already received the red envelopes, and, in the case of a large number of users who rob red envelopes at the same time, for optimization reasons, At the same time reduce the access pressure on the database (consider this: a period of time, a large number of users in the red envelope, the red envelope has been allocated after the time of arrival of the request, will give the database a certain amount of access pressure), it is in the Redis cache to maintain a red envelope has been allocated mark (Key-value) , there are 0 (allocated)/1 (has been allocated) two States, thereby playing a certain limit on the effect of the current.

Following the cache level, the next is the database plane, which generates a record in the Red Packet sending table (account_coin_records_user_coin_package_send) in MySQL. At the same time, 8 copies of the above Gaussian distribution method are inserted into the Red envelope distribution table (account_coin_records_user_coin_package_assign), the initial allocation tag is 0 (unassigned), so far, the whole process of sending the red envelope is completed.

Then is the red packet receive function, its flowchart is as follows:

Figure 2 Red Packet receiving flowchart

The red Envelope receiver initiates the request (the request contains the Red envelope ID, the requester's user ID) to rob the red envelopes, the first need a series of verification, this verification operation is based on the Redis cache and the data in the MySQL database to verify, mainly to verify the red envelope ID corresponding to the existence of red packets, Whether the red envelopes have been allocated, whether the red envelopes have expired, the recipients of the red envelopes repeatedly receive red envelopes and so on. If the verification passed, then this user is allowed to receive the red envelopes, the next is the account synchronization (red envelopes, user accounts, transaction processing), if the success of the database operation, the red Packet received success, otherwise failed, to this point, red envelopes receive the overall process completed.

Finally, the red envelope recovery function, the flowchart is as follows:

Figure 3 Red Envelope Recycling flowchart

Red Packet Recycling is initiated by the timing scheduling strategy, the time interval of 5min uninterrupted polling access to the MySQL database, query whether to be recycled red envelopes (red envelopes in the middle of the red envelope has been more than 24h, and the red envelopes are not allocated), if there is a need to recover red envelopes, this time based on efficiency considerations, Using a multithreaded scheme for recycling, each red envelope for a thread, the policy is: a thread, a request, a transaction (this scheme only applies to the number of red packets to be collected is not a lot of cases). (Note: If you need to reclaim a lot of red envelopes, if the continuous application of threads, may cause memory overflow problem, this time specific analysis, you can consider the producer-consumer model); Distributed architecture, remote call, next processing the red Packet recycling server received a red packet recovery request, Account synchronization and Red Envelope status flag (marked as reclaimed), if the database transaction is abnormal, then the transaction rollback, at this time, the red packet is not recycled successfully, can only wait for the next 5min to be recycled again.

Here, the process is basically finished, then the next introduction to the data Model ...

2. Data Model

MySQL is used in the database. The red envelope record is persisted for querying the red envelope allocation record and the later history query. The data model for the red envelope allocation is as follows:

Figure 4 Red envelope allocation data model

Figure 4 shows some of the more important data information, the association between the table is based on the red envelope ID set up, red envelope records and status indicators have been identified in the map, do not introduce each.

At the database level, the reception of red envelopes is a high concurrency problem, then the following is a brief introduction of how to deal with the concurrency ...

3. Concurrent Processing

How do you deal with high concurrency problems?

Analysis:

First, because the amount of the red envelope is stored in the Redis cache queue, because Redis is single-threaded, there is no concurrency problem in the phase of getting red envelopes ...

Then, the next step is the MySQL database a series of update operations, there are high concurrency problems ...

Finally, the record is saved, the insert operation, and there is no concurrency problem ...

In the database update operation, mainly applies the optimistic lock and the X lock two ways to guarantee the data consistency.

4. Concurrency testing

For a period of time in the concurrent test, the test passed, there will be no data inconsistency problem, red envelope recovery function can be normal.

Currently in the concurrency, at least support the same time concurrency of 3000 of the red envelope operation will not be the problem.

Summary, due to the limited capacity and technology, the current program is basically applicable to the user is not a large application scenario, later with the increase in user volume, will be further optimized ...

Implementation of a packet sending function (Redis+mysql+quartz)