Mass concurrent registration solution
By setting the registration peak QPS threshold and downgrade channel, combined with the asynchronous consumption mechanism of Redis and MQ, the registration failure caused by sudden traffic under high concurrent registration is solved, and the user's unsensible registration success and system performance improvement is achieved.
Patent Information
- Application Number
- CN202411327409.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-23
- Publication Date
- 2024-12-27
AI Technical Summary
The prior art cannot effectively handle sudden traffic in high concurrent registration scenarios, resulting in user registration failure, resulting in incomplete dirty data, affecting the user experience, especially in activities that require login.
Set the peak QPS threshold for registration, traffic enters the downgrade channel, ensure that the data is not inserted through transactions and capture exceptions, temporarily stored in Redis, and use MQ asynchronously for consumption registration, ensure that users can obtain login tickets in a timely manner, and the system executes asynchronously in batches. Registration process to prevent users from perceiving registration failure.
Ensure normal registration and access of users under sudden traffic, ensure successful registration and return of tickets, the user has no perception throughout the entire process, improving the overall performance and user experience of the system.
Smart Images
Figure CN119211366A_ABST
Abstract
Description
Technical Field
[0001] The invention relates to a solution to massive concurrent registration, and belongs to the technical field of massive concurrent registration application. Background Art
[0002] With the development and expansion of the Internet, network traffic has also increased. The continuous growth in the number of users means more active users and leads. At this time, the stability of interface performance becomes crucial. In this case, how to ensure the successful registration of a sudden increase in new users when holding large-scale events has become an extremely important link.
[0003] At present, the industry uses the Sentinel+Gateway approach to limit the flow of circuit breaking, and develops a massive concurrent registration solution based on the needs of its own projects to ensure that users can register normally and access the app when the QPS is higher than the threshold. The conventional registration process has the following shortcomings: it cannot support high concurrent registration. When the traffic surges, user registration will fail, resulting in a poor experience. Failed users may generate incomplete dirty data that affects re-registration. Failure to register will prevent users from participating in some activities that require login, resulting in a poor user experience. Summary of the invention
[0004] In this embodiment, a massive concurrent registration solution is provided to solve the problem of the industry using the Sentinel+Gateway method to limit the flow and fuse in the prior art. A massive concurrent registration solution is developed in combination with the needs of the project to ensure that users can register and access the app normally when the QPS is higher than the threshold. The conventional registration process has the following disadvantages: it cannot support high concurrent registration. When the traffic suddenly increases, user registration fails, and the experience is very poor. Failed users may generate incomplete dirty data that affects re-registration. Failure to register prevents users from participating in some activities that require login, resulting in a poor user experience.
[0005] The present invention achieves the above-mentioned purpose through the following technical scheme, a massive concurrent registration solution, which comprises the following steps:
[0006] S1. Set the registration peak QPS threshold. When the traffic reaches the peak, the traffic will enter the degradation channel interface.
[0007] S2. Ensure that no dirty data is inserted into multiple tables through transactions and exception capture;
[0008] S3. User data that enters the downgrade channel process is temporarily stored in redis, and asynchronously uses MQ for successful consumption registration, so that users can get login tickets in time without affecting the registration experience.
[0009] Preferably, the QPS threshold is set in Sentinel.
[0010] Preferably, the Redis caches registered users, captures fuse exceptions through the Spring Cloud Gateway, generates user IDs globally, and produces tickets in advance.
[0011] Preferably, the MQ stores downgraded registered user requests and asynchronously consumes MQ messages to add new users in batches.
[0012] Preferably, a unique index is set in the database for the field that needs to be unique, to ensure the uniqueness of the data and to quickly return an error when duplication occurs.
[0013] Preferably, the database adopts one-click login, and the login registration can adopt three-party registration, mobile phone number registration and ticketless user registration.
[0014] Preferably, the peak QPS threshold is controlled by a set current limiting console to control the degradation channel.
[0015] Preferably, the database can be split into multiple libraries or tables according to business needs and data volume to disperse query and write pressure. Horizontal library and table sharding can be used to perform sharding according to fields such as user ID and timestamp.
[0016] Preferably, the database disperses the read and write pressure of the database by read-write separation, the master database is responsible for write operations, and the slave database is responsible for read operations, thereby improving the overall performance of the system.
[0017] Preferably, the exception is captured by the gateway so that the interface enters the corresponding downgraded interface, and the system asynchronously executes the registration process in batches to ensure that the user registration is successful and the ticket is returned.
[0018] The beneficial effects of the present invention are: the massive concurrent registration solution in the present invention is to ensure that users can register and access the app normally in the case of a sudden increase in traffic, and to ensure that the registration of new users is not affected by a sudden increase in traffic. The massive concurrent registration solution does not block access requests when traffic downgrades, but instead captures exceptions through the gateway, so that the interface enters the corresponding downgraded interface. The system asynchronously executes the registration process in batches to ensure that the user registration is successful and the ticket is returned. The user is completely unaware of the entire process. The solution has broad market prospects and is suitable for promotion and use. BRIEF DESCRIPTION OF THE DRAWINGS
[0019] Figure 1 The figure is a flow chart of the method of the present invention. DETAILED DESCRIPTION
[0020] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0021] Embodiment 1:
[0022] A solution to massive concurrent registrations, the solution to massive concurrent registrations comprises the following steps:
[0023] S1. Set the registration peak QPS threshold. When the traffic reaches the peak, the traffic will enter the degradation channel interface.
[0024] S2. Ensure that no dirty data is inserted into multiple tables through transactions and exception capture;
[0025] S3. User data that enters the downgrade channel process is temporarily stored in redis, and asynchronously uses MQ for successful consumption registration, so that users can get login tickets in time without affecting the registration experience.
[0026] Preferably, the QPS threshold is set in Sentinel.
[0027] Preferably, the Redis caches registered users, captures fuse exceptions through the Spring Cloud Gateway, generates user IDs globally, and produces tickets in advance.
[0028] Preferably, the MQ stores downgraded registered user requests and asynchronously consumes MQ messages to add new users in batches.
[0029] Preferably, a unique index is set in the database for the field that needs to be unique, to ensure the uniqueness of the data and to quickly return an error when duplication occurs.
[0030] Preferably, the database adopts one-click login, and the login registration can adopt three-party registration, mobile phone number registration and ticketless user registration.
[0031] Preferably, the peak QPS threshold is controlled by a set current limiting console to control the degradation channel.
[0032] Preferably, the database can be split into multiple libraries or tables according to business needs and data volume to disperse query and write pressure. Horizontal library and table sharding can be used to perform sharding according to fields such as user ID and timestamp.
[0033] Preferably, the database disperses the read and write pressure of the database by read-write separation, the master database is responsible for write operations, and the slave database is responsible for read operations, thereby improving the overall performance of the system.
[0034] Preferably, the exception is captured by the gateway so that the interface enters the corresponding downgraded interface, and the system asynchronously executes the registration process in batches to ensure that the user registration is successful and the ticket is returned.
[0035] The above-mentioned massive concurrent registration solution is to ensure that users can register and access the app normally in the case of sudden traffic increases, and to ensure that new user registration is not affected by sudden traffic increases. The massive concurrent registration solution does not block access requests when traffic downgrades, but instead captures exceptions through the gateway, allowing the interface to enter the corresponding downgraded interface. The system asynchronously executes the registration process in batches to ensure that user registration is successful and tickets are returned. Users are completely unaware of the entire process.
[0036] Embodiment 2:
[0037] A solution to massive concurrent registrations, the solution to massive concurrent registrations comprises the following steps:
[0038] S1. Set the registration peak QPS threshold. When the traffic reaches the peak, the traffic will enter the degradation channel interface.
[0039] S2. Ensure that no dirty data is inserted into multiple tables through transactions and exception capture;
[0040] S3. User data that enters the downgrade channel process is temporarily stored in redis, and asynchronously uses MQ for successful consumption registration, so that users can get login tickets in time without affecting the registration experience.
[0041] Preferably, the QPS threshold is set in Sentinel.
[0042] Preferably, the Redis caches registered users, captures fuse exceptions through the Spring Cloud Gateway, generates user IDs globally, and produces tickets in advance.
[0043] Preferably, the MQ stores downgraded registered user requests and asynchronously consumes MQ messages to add new users in batches.
[0044] Preferably, a unique index is set in the database for the field that needs to be unique, to ensure the uniqueness of the data and to quickly return an error when duplication occurs.
[0045] Preferably, the database adopts one-click login, and the login registration can adopt three-party registration, mobile phone number registration and ticketless user registration.
[0046] Preferably, the peak QPS threshold is controlled by a set current limiting console to control the degradation channel.
[0047] Preferably, the database can be split into multiple libraries or tables according to business needs and data volume to disperse query and write pressure. Horizontal library and table sharding can be used to perform sharding according to fields such as user ID and timestamp.
[0048] Preferably, the database disperses the read and write pressure of the database by read-write separation, the master database is responsible for write operations, and the slave database is responsible for read operations, thereby improving the overall performance of the system.
[0049] Preferably, the exception is captured by the gateway so that the interface enters the corresponding downgraded interface, and the system asynchronously executes the registration process in batches to ensure that the user registration is successful and the ticket is returned.
[0050] The above-mentioned massive concurrent registration solution is to ensure that users can register and access the app normally in the case of sudden traffic increases, and to ensure that new user registration is not affected by sudden traffic increases. The massive concurrent registration solution does not block access requests when traffic downgrades, but instead captures exceptions through the gateway, allowing the interface to enter the corresponding downgraded interface. The system asynchronously executes the registration process in batches to ensure that user registration is successful and tickets are returned. Users are completely unaware of the entire process.
[0051] Embodiment three:
[0052] A solution to massive concurrent registrations, the solution to massive concurrent registrations comprises the following steps:
[0053] S1. Set the registration peak QPS threshold. When the traffic reaches the peak, the traffic will enter the degradation channel interface.
[0054] S2. Ensure that no dirty data is inserted into multiple tables through transactions and exception capture;
[0055] S3. User data that enters the downgrade channel process is temporarily stored in redis, and asynchronously uses MQ for successful consumption registration, so that users can get login tickets in time without affecting the registration experience.
[0056] Preferably, the QPS threshold is set in Sentinel.
[0057] Preferably, the Redis caches registered users, captures fuse exceptions through the Spring Cloud Gateway, generates user IDs globally, and produces tickets in advance.
[0058] Preferably, the MQ stores downgraded registered user requests and asynchronously consumes MQ messages to add new users in batches.
[0059] Preferably, a unique index is set in the database for the field that needs to be unique, to ensure the uniqueness of the data and to quickly return an error when duplication occurs.
[0060] Preferably, the database adopts one-click login, and the login registration can adopt three-party registration, mobile phone number registration and ticketless user registration.
[0061] Preferably, the peak QPS threshold is controlled by a set current limiting console to control the degradation channel.
[0062] Preferably, the database can be split into multiple libraries or tables according to business needs and data volume to disperse query and write pressure. Horizontal library and table sharding can be used to perform sharding according to fields such as user ID and timestamp.
[0063] Preferably, the database disperses the read and write pressure of the database by read-write separation, the master database is responsible for write operations, and the slave database is responsible for read operations, thereby improving the overall performance of the system.
[0064] Preferably, the exception is captured by the gateway so that the interface enters the corresponding downgraded interface, and the system asynchronously executes the registration process in batches to ensure that the user registration is successful and the ticket is returned.
[0065] The above-mentioned massive concurrent registration solution is to ensure that users can register and access the app normally in the case of sudden traffic increases, and to ensure that new user registration is not affected by sudden traffic increases. The massive concurrent registration solution does not block access requests when traffic downgrades, but instead captures exceptions through the gateway, allowing the interface to enter the corresponding downgraded interface. The system asynchronously executes the registration process in batches to ensure that user registration is successful and tickets are returned. Users are completely unaware of the entire process.
[0066] It will be apparent to those skilled in the art that the invention is not limited to the details of the exemplary embodiments described above and that the invention can be implemented in other specific forms without departing from the spirit or essential features of the invention. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description, and it is intended that all variations falling within the meaning and scope of the equivalent elements of the claims be included in the invention. Any reference numeral in a claim should not be considered as limiting the claim to which it relates.
[0067] In addition, it should be understood that although the present specification is described according to implementation modes, not every implementation mode contains only one independent technical solution. This description of the specification is only for the sake of clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment may also be appropriately combined to form other implementation modes that can be understood by those skilled in the art.
Claims
1. A solution for massive concurrent registration, characterized by: The massive concurrent registration solution includes the following steps: S1. Set the registration peak QPS threshold. When the traffic reaches the peak, the traffic will enter the degradation channel interface. S2. Ensure that no dirty data is inserted into multiple tables through transactions and exception capture; S3. User data that enters the downgrade channel process is temporarily stored in redis, and asynchronously uses MQ for successful consumption registration, so that users can get login tickets in time without affecting the registration experience.
2. The massive concurrent registration solution according to claim 1, characterized in that: The QPS threshold is set in Sentinel.
3. The massive concurrent registration solution according to claim 1, characterized in that: The Redis cache has registered users, captures fuse exceptions through the Spring Cloud Gateway gateway, generates user ids globally, and produces tickets in advance.
4. The massive concurrent registration solution according to claim 1, characterized in that: The MQ stores downgraded registered user requests and asynchronously consumes MQ messages to add new users in batches.
5. The massive concurrent registration solution according to claim 1, characterized in that: In the database, a unique index is set for the field that needs to be unique, so as to ensure the uniqueness of the data and quickly return an error when duplication occurs.
6. The massive concurrent registration solution according to claim 1, characterized in that: The database uses one-click login, and login registration can be done by three-party registration, mobile phone number registration, and ticketless user registration.
7. The massive concurrent registration solution according to claim 1, characterized in that: The peak QPS threshold is controlled by the current limiting console set to control the degradation channel.
8. The massive concurrent registration solution according to claim 1, characterized in that: The database can be split into multiple libraries or tables according to business needs and data volume to disperse query and write pressure. Horizontal library and table sharding can be used to perform sharding based on fields such as user ID and timestamp.
9. The massive concurrent registration solution according to claim 1, characterized in that: The database disperses the read and write pressure of the database by separating read and write. The master database is responsible for write operations and the slave database is responsible for read operations, thereby improving the overall performance of the system.
10. The method for solving the massive concurrent registration problem according to claim 1, characterized in that: The exception is captured by the gateway, so that the interface enters the corresponding downgrade interface, and the system asynchronously executes the registration process in batches to ensure that the user registration is successful and the ticket is returned.