CN114363264B - Service reservation method - Google Patents
Service reservation method Download PDFInfo
- Publication number
- CN114363264B CN114363264B CN202111581983.9A CN202111581983A CN114363264B CN 114363264 B CN114363264 B CN 114363264B CN 202111581983 A CN202111581983 A CN 202111581983A CN 114363264 B CN114363264 B CN 114363264B
- Authority
- CN
- China
- Prior art keywords
- reservation
- service
- server
- inventory
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 25
- 230000003068 static effect Effects 0.000 claims abstract description 22
- 238000012790 confirmation Methods 0.000 claims abstract description 21
- 238000009877 rendering Methods 0.000 claims abstract description 15
- 230000000694 effects Effects 0.000 claims description 13
- 230000007246 mechanism Effects 0.000 claims description 11
- 238000004422 calculation algorithm Methods 0.000 claims description 9
- 230000008859 change Effects 0.000 claims description 9
- 238000012795 verification Methods 0.000 claims description 8
- 230000002159 abnormal effect Effects 0.000 claims description 7
- 230000008569 process Effects 0.000 claims description 6
- 238000012544 monitoring process Methods 0.000 claims description 2
- 238000012216 screening Methods 0.000 claims description 2
- 238000012545 processing Methods 0.000 abstract description 6
- 230000006399 behavior Effects 0.000 description 8
- 230000005856 abnormality Effects 0.000 description 3
- 230000015556 catabolic process Effects 0.000 description 3
- 238000004140 cleaning Methods 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 238000006731 degradation reaction Methods 0.000 description 2
- 230000001934 delay Effects 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 241000283690 Bos taurus Species 0.000 description 1
- 241001522296 Erithacus rubecula Species 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 238000001125 extrusion Methods 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 238000003860 storage Methods 0.000 description 1
- 229960005486 vaccine Drugs 0.000 description 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
Landscapes
- Computer And Data Communications (AREA)
Abstract
The invention discloses a service reservation method, which is characterized in that an operation server performs configuration on various reservation services, the configured operation services are rendered into static pages through a rendering server, static data are respectively pushed to an Nginx server and a CDN cache server which is relatively close to a user, when the user accesses, screened user reservation requests are dispersed to each reservation server for processing in a polling mode, and the reservation server utilizes integral current limiting and service current limiting to finish removing redundant reservation service requests. The reservation request for completing the reservation is formally confirmed to reserve after confirmation of the user, and the reservation quantity is configured through reservation inventory service provision arranged in a segmented mode. The service reservation method can effectively cope with sudden events such as sudden increase of instantaneous flow, interference or surge of attack flow in the service reservation period, and can provide stable reservation service for a large data volume group.
Description
Technical Field
The invention belongs to the field of computer application, and particularly relates to a service reservation method.
Background
In the internet era, service providers are offering different types of urban services covering very popular convenience projects including water fee payment, electronic registration, housekeeping, vaccine reservation, and reservation of other service numbers. The business can be reserved for handling by logging in the webpage end through a mobile phone app or a pc end, so that a great deal of queuing time is saved, and the overall handling efficiency is more efficient.
As more and more people reserve and pay through the pc end and the mobile phone end along with popularization of the internet and the mobile phone, high performance and high availability in the traditional reservation system cannot be guaranteed, and hundreds of thousands or even more than millions of requests for access cannot be carried. For the above scenario, the reservation system needs to have some of the following features: 1. various reservation activities and services can be flexibly configured. 2. The method can support simultaneous use of a large number of people and solve the problems that the reservation number exceeds reservation and the like. 3. Can effectively prevent various hackers from attacking. 4. High performance and high availability of the overall system are ensured.
However, in the prior art, the conventional reservation service system cannot achieve high performance and high availability from the overall architecture. Functionally, the problem of concurrent access of massive users cannot be solved, a bottleneck of concurrent access exists, and when the instantaneous flow is suddenly increased, great pressure is caused on a server. Resulting in a system lock-up once a large number of users access concurrently. The attack access behavior of some malicious people cannot be resisted, so that the use experience of normal other formal users is affected. The instantaneous flow and the interference flow can cause the extrusion of the request, directly or indirectly cause the breakdown of the system, the whole system also has the problem of single-point faults, the whole reservation system has high requirements on the consistency of data, and if the reservation number is reserved, but the reservation number cannot be provided with service, the complaint of the relevant masses can be caused.
Disclosure of Invention
The invention aims to: the invention aims to provide a service reservation method.
The technical scheme is as follows: the service reservation method of the invention is characterized in that: the method comprises the following steps:
(1) After the configuration of the reservation activity information is completed, the reservation activity information is pushed to a reservation server and cache servers in different areas, and reservation inventory information is stored through a Redis cluster;
(2) The client sends a reservation request to the reservation server after screening;
(3) The reservation request is received by the reservation server after global current limit and business current limit, and deduction is carried out from the reservation inventory when the reservation server processes the reservation request;
(4) And after confirming the reservation information, the client finishes the service reservation.
Preferably, the change information of the reservation activity information in the step (1) is sent to a message middleware, the reservation inventory server and the reservation page rendering server judge whether a message of the reservation service change exists or not through a monitoring message middleware, and when the reservation page rendering server monitors the reservation service message change, the dynamic reservation activity information is solidified to form static data and pushed to the Nginx server and CDN cache servers in different areas.
Preferably, the reserved inventory configured in the dis cluster in step (1) includes an inventory of reserved services, a locked inventory of services to be confirmed, and a determined inventory that has been paid for.
Preferably, when the reservation request of the client in the step (2) is sent to the DNS server, the overall flow cleaning of the service request is performed through the DDos high security, the reservation request of the client is sent to the CDN cache server nearby, and static data in the CDN cache server is read.
Preferably, in step (2), when the reservation dynamic data needs to be acquired, the reservation request sent by the client is forwarded to the LVS server, and the LVS server forwards the request to the designated nmginx server, and the nmginx server forwards the reservation request determined as a non-abnormal user to the reservation server.
Preferably, in the step (3), the nmginx server performs a limiting operation on the burst reservation request traffic through a token bucket algorithm to complete global current limiting; when the service is limited, by using an atomic operation in the Redis, the service request is refused after the reservation request exceeds the actual reservation service number.
Preferably, in step (3), the inventory reservation service numbers are distributed in a plurality of servers, and after inventory in any server is deducted, the servers in the dis cluster are added to a blacklist for avoiding access of service reservation requests.
Preferably, in the step (3), the client, the reserved inventory server, the reserved page rendering server and the reserved server are all communicated with the time service system to ensure that the system time is consistent; before the reservation service starts, the client receives a real reservation address, and the reservation address is encrypted; after the reservation service starts, the client needs to verify the verification code and set the request sending interval when sending the reservation service request.
Preferably, in step (4), after the client side succeeds in ordering reservation in the reservation server, the reservation message is sent to the confirmation module through the message middleware, the reservation can be ensured to be processed correctly through the retry mechanism and the ack mechanism, and after the client side confirms, the inventory service is invoked to reduce the locked inventory by 1, and the inventory plus 1 is determined.
Further, in step (1), the reservation activity information includes a name of the reservation service, a reservation service start time, a reservation service end time, the number of reservation services, and how many reservation service numbers each reservation service can provide.
Further, the message middleware notifies the reserved page rendering server of the reserved activity configuration change message, and the reserved page rendering server reads the latest reserved activity data from the database, reads the template information of the page and renders the page based on the template. After rendering is completed, the relevant static data is pushed to the Nginx server, the static data is cached in the Nginx server, and the pushing system also pushes the relevant static resources to a CDN cache server which is relatively close to the user. The access delay of the user request can be reduced by selecting a closer CDN cache server for caching; access can be accelerated by caching at both the ng inx server and the CDN cache server. And configuring source station address information in the Nginx in the CDN cache server, and pulling the static resource by clicking a preheating and refreshing button on an operation interface of the CDN. A large number of user requests in the later period can directly hit static resources in the CDN, and the pressure of a server side is relieved. The server pressure of the CDN cache servers scattered at different spatial geographic positions is utilized to be dispersed, wherein network delays of machine rooms at different positions are different, for example, the delays of machine rooms in Beijing and Shanghai are different.
Furthermore, the client performs service reservation by logging in the reservation page through the APP or the webpage, the client sends a request of the user to the global load balancer GSLB through related information such as GPS and IP address, the GSLB forwards the request of the user to a CDN cache server which is close to the geographic position of the user, and the user can read static html information related to the reservation service through the CDN cache server and can cache the static information to the local. After the static data is acquired, an ajax asynchronous request can be sent according to the dynamic elements in the page, and the dynamic data of the reservation server can be loaded from other systems. The client periodically refreshes time service data, ensures the consistency of system time between the client and each server, and provides a basis for the countdown service of the client. And all the servers are calibrated all the time through the ntp time server and Beijing time, and perform centralized synchronous operation. In the process of checking the time, the real address of the reservation server is returned to the user, so that the reservation server is protected in the early stage. In order to prevent a malicious user from disguising a client for attack, an MD5 random encryption string is added on the returned URL, the MD5 encrypted random string is stored in a Redis cluster, and a Lua script is used by Nginx in the later stage to verify the random string. When the reservation request is sent in the real later period, if the MD5 random character string comparison is unsuccessful, reservation cannot be carried out, and thus attack of a hacker is effectively prevented.
Furthermore, when the inventory server carries out reservation service information configuration, the reservation number of the reservation service is entered into the reservation service inventory management system through the MQ message middleware, the relevant information of the whole inventory data is a Hash data structure, and the data information is stored in a Redis cluster. By storing different types of reserved service number segments in different servers, load balancing is carried out on the requests, and the access pressure of a single point in the Redis cluster is reduced. Meanwhile, redis is based on a single-threaded memory architecture, and the overall operation is atomic and high in concurrency, so that very high performance support is provided.
The inventory deduction mode is completed by executing eval script through the Jeddis client, inventory deduction of service reservation numbers is carried out, the logic of the bottom layer is that the quantity of locked inventory is increased by 1, and the quantity of inventory capable of reserving service is reduced by 1. After the above operation is completed, the reserved inventory service can monitor a message queue of which service confirmation is successful, wherein idempotent verification can be added, and the reserved service number can not be repeatedly processed. If the reservation service number confirmation is successful, the number of the locking stock is reduced by 1, the number of the stock is determined to be increased by 1, if the reservation stock fails, the number of the locking stock is reduced by 1, and the number of the stock of the reserved service is increased by 1.
Further, when the countdown reaches the set time, the client prevents the bill from being brushed and limiting the current by sliding the verification code or the verification code modes such as characters, numbers and the like at the moment of initiating the request when the client makes a reservation. In order to avoid the repeated clicking, it is generally set that the repeated clicking cannot be performed within a set time period, and the sudden increase of the flow rate is further prevented.
When the reservation request of the client is sent to the DNS server, the hacker is prevented from attacking through the high security system of the DDos, the flow cleaning operation is carried out, and the malicious flow in the reservation request is cleaned out. The request filtered by DDos with high protection against products is mostly a real request, which is forwarded to a separate secondary domain name by DNS service, followed by a separate lvs+nginx server. The process of judging whether the user is abnormal by the Nginx server is as follows: after the traffic enters the Nginx server, the Lua script is used for checking whether the URL address provided before contains the MD5 random character string and whether the MD5 character string is correct, and after the user behavior passes the security check, a big data-based anti-cheating system is called to judge whether the user has the loyalty problem in the behavior of reserving the service number before, such as reservation before, but the user does not go to the site in practice, and the actions such as cheating and refreshing are solved. If the user has a belief act, the user's service subscription is disqualified.
Further, after malicious requests and cheating invalid requests of hackers are removed, a token bucket algorithm is adopted to intensively limit the flow of the requests, each server puts tokens into the bucket according to a set speed, and each time a request comes, the server takes the tokens from the token bucket, the request for taking the tokens can be released, and otherwise, the request can be refused. After the request after centralized flow limiting reaches the back end through the token bucket algorithm, the requests exceeding the number of the preset service numbers are filtered through the atomic operation of the incryby in the Redis. Allowing a certain number of requests to reach the back end for reservation of service numbers.
Furthermore, as the reservation server and the Redis server have a plurality of servers, the Nginx load balancer can uniformly distribute the requests to different machines by adopting a polling strategy, so that the load balancing operation of the requests is ensured. The reservation service inventory of the bottom layer adopts a storage mode of segmented inventory, and each machine can store a certain amount of inventory. When one server node is not in stock enough, the server node is blacklisted, so that the machine is not accessed in later access, and other servers are directly accessed.
Further, after the reservation is successful, a reservation success message is sent to the message middleware. The reservation confirmation server creates a payment or confirmed order for the client, and the reservation foreground continuously polls the order to wait for the payment or confirmation of the order. The third party platform may be called during this period because of the different confirmation or payment modes, and when confirmation or payment is successful, the reservation order system is called back to inform that the reservation order has been confirmed or paid successfully. The reservation confirmation system sends a notification to the inventory system to update the inventory according to the client message.
Furthermore, keepalive is adopted during LVS dual-machine deployment, high availability is guaranteed when access is requested, and load balancing of application layer access is achieved by matching with LVS dual-machine deployment and Nginx high availability service, so that a large amount of request traffic can be borne. The reservation server adopts multi-machine redundancy deployment, and uses Nginx to carry out load balancing operation, so that high availability of the reservation service is ensured. The independent deployment is significant in that if a single node is deployed, other application services are not affected by excessive traffic of the reserved service.
The cache reservation service number information adopts a Redis cluster, each node in the Redis cluster is a Master node, and a part of inventory information is stored in each Master node. And through the encapsulation accessed by the client, sequentially accessing the Master node of each Redis, if an abnormality occurs to an individual node, attempting to deduct inventory from other nodes, if all nodes crash, uniformly and upwardly throwing the abnormality when processing related information, and performing degradation processing after capturing a specific abnormality. Writing the state of the reservation service into a local disk, setting the state as the reservation, pulling up a thread at the back end, continuously polling, judging whether the Redis cluster is restored, if so, reading the local backlog request from the local file, and then writing the local backlog request into the Redis.
Further, the message middleware is used for decoupling the reservation service and the reservation confirmation service, the message middleware is deployed in a cluster deployment and multi-copy redundancy mode, if the message middleware crashes, the message is written into the local disk, and then the background thread tries to read the message from the local disk until the message of the local disk is sent out. If the reservation server crashes, the reservation server blocks the push thread, and after the set time is blocked, the reservation system is tried to be called.
Further, when GC or anomaly occurs in downstream service, the ability to consume messages becomes weak, and when backlog occurs in reservation messages, a large number of reservation messages are blocked, so that a user cannot check a confirmation order, and further, the user repeatedly submits the confirmation order, so that the original slower system becomes slower. Therefore, when the reservation message is backlogged, if the notice of successful order placement is not pulled beyond the set time, the interface is directly jumped, the reservation failure is indicated, and the order placement is performed again. And the back end adds a sent time stamp to each reservation message, and if the latest reservation success notification and the notification in the message middleware are found to be more than set time in the whole reservation service, the message middleware is proved to have serious message backlog, and the degradation service is automatically started. The degraded service is essentially a quick release of inventory of reserved numbers, which is much faster than traditionally done with Mysql, since reserved inventory is operating Redis. The backlog information is released and completed in a short time, the reservation state is updated to be the reservation failure, the front-end page polls the reservation state of the background, when the reservation state is detected to be failed, the user is directly informed of the failure, the user is enabled to reserve again, the user with the failure front-end can find that the back-end has released the stock, the user can try to reserve again because of the new stock, and the reservation service time is staggered because of the time difference of the stock release, so that the re-centralization of the reservation behavior is avoided.
Further, in order to prevent the reserved quantity from exceeding the inventory, the Lua script is used to cooperate with the segmentation mechanism, and the Lua script is used to submit the request to the Redis for execution, so that the Redis can ensure that the Lua script is executed sequentially, and each script is atomic. And packaging and inquiring the inventory quantity in the Lua script, and updating the reserved inventory quantity to judge whether the service can be reserved or not. And making each reserved service number into a sectional lock, performing data slicing operation, using a round robin polling strategy, establishing a temporary blacklist mechanism, putting a server into the blacklist when reserved inventory of the server is empty, and not accessing the server, and directly requesting the server with the inventory by a subsequent request to realize deduction of the corresponding inventory.
Furthermore, in order to solve the problem of data loss, the production end needs to support the function of message retry, the message middleware needs to write a disk synchronously after receiving the message, and configures master-slave multiple copies to perform synchronous copying. Only after the successful consumption, an ack request can be sent, ensuring that the message consumption is successful. In each reserved service number, a field capable of determining the uniqueness of the reserved service number, such as a session, a service type and a reserved service number, is added, the uniqueness of the reserved service number is used for guaranteeing the idempotency, and after all interfaces guarantee the idempotency, each message can be guaranteed to be consumed only once.
The beneficial effects are that: according to the technical scheme, on the premise of ensuring the consistency of reservation request data, sudden events such as sudden increase, interference or surge of attack flow of instantaneous flow in the service reservation period can be effectively treated, and stable reservation service can be provided for a large data volume group.
Drawings
FIG. 1 is a flow chart of reservation service information configuration and rendering in accordance with the present invention;
FIG. 2 is a general reservation flow chart of a reservation service in the present invention;
FIG. 3 is a flow chart of the internal processing of the reservation server according to the present invention;
fig. 4 is a diagram of reservation confirmation processing in the present invention.
Detailed Description
The technical scheme of the invention is further described in detail below with reference to the accompanying drawings and examples.
A service reservation method comprises the steps of starting a reservation server, a reservation rendering server, a reservation inventory server and a reservation confirmation server, and simultaneously building a Redis cluster in the form of three masters and three slaves.
When starting the reservation service, the user is required to configure the reservation service information and render, as shown in fig. 1, the specific steps are as follows:
step 1.1, a user configures reservation service types on a page, and stores reservation service related information into a database, wherein the reservation service related information comprises service names of reservation services, the number of reservation service numbers provided, the starting time and the ending time of each reservation service and the like;
step 1.2, after the reservation service is configured, service reservation configuration change information is sent to the message middleware, and a reservation inventory server and a reservation page rendering server monitor whether a message of reservation service change occurs in the message middleware;
step 1.3, after the reservation page rendering server monitors a reservation service event, firstly reading information from a page template in reservation activity, and adding dynamic data into the page template;
and step 1.4, after the data addition is completed, pushing the whole solidified static data to the Nginx server and CDN cache servers in different areas.
And step 1.5, after the reservation inventory server monitors the reservation configuration service, setting inventory information in the Redis cluster.
In this embodiment, the relevant information of the whole inventory in the reserved inventory server is a Hash data structure, and the data information is stored in the Redis. The first type is the inventory of the reserved service, which represents the inventory quantity reserved by no person; the second type is a locked inventory of services to be validated, representing the amount of inventory that has been preempted but has not yet been validated or paid for; the third category is the determined inventory that has been paid, representing the amount of inventory that has been paid or confirmed.
In this embodiment, a total of 500 service numbers capable of being reserved are provided for a certain reserved service, and when the reserved inventory server is 3 servers, the reserved service number of each machine of the first two servers is 500/3, and the last server is 500/3+500- (500/3) x 3 service numbers capable of being reserved. The inventory deduction mode is completed by executing eval script through the Jeddis client, inventory deduction of service reservation numbers is carried out, the logic of the bottom layer is that the quantity of locked inventory is increased by 1, and the quantity of inventory capable of reserving service is reduced by 1. After the above operation is completed, the reserved inventory service can monitor a message queue of which service confirmation is successful, wherein idempotent verification can be added, and the reserved service number can not be repeatedly processed. If the reservation service number is confirmed successfully, the number of the locking stock is increased by 1, the number of the determining stock is increased by 1, and if the reservation stock fails, the number of the locking stock is decreased by 1, and the number of the reserved stock of the reserved service is increased by 1.
In this embodiment, when the client performs the reservation service, as shown in fig. 2, specific steps are as follows:
step 2.1, a user logs in through a client side App to check related services which need to be reserved;
step 2.2, before the reservation service starts, the client side App communicates with the time service system every 1 minute, so that the time of the client side is ensured to be consistent with the time of the server, and the time synchronization is carried out on the whole reservation server and the time service system through the NTP time server;
step 2.3, before the reservation service is about to start, the reservation server sends the real reservation address to the client, and adds the MD5 random encrypted character string to the URL address;
step 2.4, after the reservation service is started, the user uses the sliding verification code to effectively prevent the bill from being brushed and the current from being limited, and once the user clicks the reservation, repeated clicking can not be carried out within 10 seconds;
step 2.5, the user request is forwarded to a DNS server of an operator, and the operator provides DDos high-protection traffic cleaning service to clean malicious attack traffic;
step 2.6, after filtering the abnormal traffic, forwarding the reservation request to a nearby CDN cache server, and reading the static resource content in the CDN cache server;
step 2.7, when the dynamic information needs to be acquired, the reservation request is forwarded to a LVS server at the back end, and the LVS server is deployed into a double machine in cooperation with the keepalive;
and 2.8, the LVS forwards the request to a designated Nginx service, load balancing is carried out through the Nginx service, the core content of the reservation request is acquired through a Lua script in the Nginx service, behavior detection is carried out through big data, whether the reservation request is an abnormal user or not is detected, if the reservation request is the abnormal user, the access request is refused, if the reservation request is not the abnormal user, the request is forwarded to a reservation server, and the later related reservation behavior operation is carried out.
In this embodiment, the client sends the request of the user to the global load balancer GSLB through related information such as GPS and IP address, and the GSLB forwards the request of the user to the CDN cache server closer to the geographic location of the user, where the user may read static html information about the reservation service through the CDN cache server, and may cache the static information locally. After the static data is acquired, an ajax asynchronous request can be sent according to the dynamic elements in the page, and the dynamic data of the reservation server can be loaded from other systems.
In this embodiment, the multi-machine deployment of the reservation server is performed according to the estimated actual number of reservation requests, and each server can resist approximately 5000/s qps, and when 50000/s qps is needed to be carried, 10 machines need to be deployed. The thread pool mechanism is adopted in each server, so that the overhead problems of thread allocation and thread starting are reduced.
In this embodiment, after the malicious request is filtered out. The LVS is matched with the Nginx to bear mass concurrent reservation requests of users. The Nginx middle acquires basic information of the reservation request through the Lua script, judges whether the request is a bill and cheating action through a big data technology, and filters invalid requests.
In this embodiment, after receiving the reservation request, the reservation server, as shown in fig. 3, specifically includes the following steps:
step 3.1, after the Nginx receives a request sent by the front end, performing global current limiting and service current limiting operations through the Lua script;
step 3.2, the overall current limiting limits the burst flow through a token bucket algorithm, so that only the flow which can be borne by the reservation server can be processed by the reservation server through the current limiter;
step 3.3, after the global current limit, carrying out service current limit on reserved numbers which are only opened in a specific quantity actually, adopting atomic operation using incryby in Redis, and after the actual reserved service numbers are exceeded, rejecting the service request;
step 3.4, after global current limiting and business current limiting, the reservation service formally starts to process the request, and inventory fragmentation polling deduction strategies are adopted to sequentially deduct inventory from each Redis;
step 3.5, because the number of the servers is not necessarily divided, when any server has inventory deduction, a temporary blacklist is established, when the temporary inventory of the server is deducted, the current Redis server is added into the blacklist, and the subsequent reservation request does not access the server until all the inventory deductions are completed.
In the embodiment, a token bucket algorithm is adopted to intensively limit the reservation request, so that only about 10000/s of QPS can request to reach a background reservation server. In the token bucket algorithm, 10000 reservation requests are limited per second, the reservation requests are evenly distributed to 10 servers, each machine needs to limit 1000 reservation requests per second, the method is equivalent to a back-end service thread of each server, tokens are put into the bucket at the rate of one token per millisecond, 1000 tokens are just put into the bucket for 1s, the tokens are taken out of the token bucket every time a request comes, the taking is released, and otherwise the rejection is carried out.
In this embodiment, since there are only 2000 reservation service numbers, 10000 or so reservation requests are actually filtered out by the atomic operation of incryby in Redis, so that a specific reservation request can reach the reservation server to reserve.
In this embodiment, after completing the reservation, the user needs to confirm again, as shown in fig. 4, and the specific steps are as follows:
step 4.1, after the reservation server issues a reservation successfully, the user sends a reservation message to the reservation confirmation server through a message middleware, and the message is ensured not to be lost through a retry mechanism of a producer and an ack mechanism of a consumption end during the period;
step 4.2, the reservation confirmation server monitors events in the message queue, and once the service number receives the reservation request, the message is ensured not to be consumed repeatedly through the idempotent operation principle of the service number;
step 4.3, calling reservation inventory service through analyzing the message event, subtracting 1 from the frozen inventory, and adding 1 to the reservation success inventory;
and 4.4, reminding the client of successful reservation after the operation is finished.
In summary, the operation server configures various reservation services, the rendering server renders the configured reservation services into static pages, static data are respectively pushed to the Nginx server and the CDN cache server which is relatively close to the user, and the caches of the CDN cache server and the Nginx are fully utilized, so that network overhead of the user for accessing the back-end reservation server can be greatly reduced. When a user accesses, the user can locate the GSLB through the DNS, the GSLB can forward the request of the user to a CDN server which is close to the user, and the user can directly pull static resources from the CDN server which is close to the user. The time between the client and each server is consistent before the reservation service is ensured by the time service. The real address of the reservation server is exposed only when the client and each server are time synchronized, so that the possibility of hacking is reduced, and the validity of the request access is verified by the returned URL address through the MD5 encryption algorithm. When the real reservation service starts, anti-brushing and current limiting are carried out in a mode of sliding the verification code; through the DDoS high-protection product, hacker attack can be effectively prevented, after malicious requests are filtered, user identity can be verified, and the behavior of the user is detected in a big data mode, so that cattle bill refreshing or other cheating behaviors are prevented. After passing through the security detection module, the reservation requests can be distributed to each reservation server for processing in a polling mode through independent LVS and Nginx load balancing. At this time, the whole business is limited according to the actual request of the deployed server, a token bucket algorithm is used to ensure that only tens of thousands of QPSs arrive at the back end per second, and then business limitation is carried out according to the actual reserved service number, and redundant reserved service requests are removed. After the actual request of the current limiter reaches the rear end, the locking of the residual stock number can be tried, the locking stock adopts a mode of matching the Lua script with the segmented stock in the Redis database, the Lua script ensures the atomicity, and the segmented stock ensures the load balance. And the problem of invalid request transmission caused by insufficient inventory of certain specific service numbers is solved through a blacklist mechanism, and the mechanism simultaneously solves the problems of inventory overstock and the like. After the reservation is successful, the reserved message is sent to the message middleware, the confirmation and payment service consumes the message from the message middleware, and the confirmation system sends a notification to the inventory system to ensure that the inventory is correctly deducted. During which time the producer retries, synchronously writes to disk and the client sends an ack to determine zero loss of the message. By means of the time limiting strategy of the front end, the time stamp comparison of the rear end and the quick failure strategy, the quick memory release based on Redis is guaranteed when message backlog occurs. And through the uniqueness of the reserved service number, the idempotent of the interface is ensured, and repeated consumption of the message is avoided.
The system has reasonable system architecture, integrally improves the high availability of the system, has strong system robustness and does not have single-point faults.
Claims (7)
1. A service reservation method, characterized in that: the method comprises the following steps:
(1) After the configuration of the reservation activity information is completed, the reservation activity information is pushed to a reservation server and cache servers in different areas, and reservation inventory information is stored through a Redis cluster;
(2) The client sends a reservation request to the reservation server after screening;
(3) The reservation request is received by the reservation server after global current limit and business current limit, and deduction is carried out from the reservation inventory when the reservation server processes the reservation request;
(4) After the client confirms the reservation information, completing service reservation;
the change information of the reservation activity information in the step (1) is sent to a message middleware, the reservation inventory server and the reservation page rendering server judge whether the reservation service change information exists or not through monitoring the message middleware, and when the reservation page rendering server monitors the reservation service message change, the dynamic reservation activity information is solidified to form static data and pushed to the Nginx server and CDN cache servers in different areas; after the reservation inventory server monitors the reservation configuration service, setting inventory information in a Redis cluster; the message middleware is used for decoupling the reservation service and the reservation confirmation service, the message middleware is deployed in a cluster deployment and multi-copy redundancy mode, if the message middleware crashes, the message is written into the local disk, and then the background thread tries to read the message from the local disk until the message of the local disk is sent out; if the reservation server crashes, the reservation server blocks the push thread, and after the set time is blocked, the reservation system is tried to be called;
in the step (3), the client, the reserved inventory server, the reserved page rendering server and the reserved server are communicated with the time service system to ensure that the system time is consistent; before the reservation service starts, the client receives a real reservation address, and the reservation address is encrypted; after the reservation service starts, the client side needs to verify the verification code and set a request sending interval when sending the reservation service request; and in the process of checking time, returning the real address of the reservation server to the user, and simultaneously adding an MD5 random encryption character string on the returned URL, wherein the MD5 encrypted random character string is stored in a Redis cluster, and Nginx uses a Lua script for checking.
2. A service reservation method according to claim 1, characterized in that: the reserved inventory formed in the Redis cluster in the step (1) comprises the inventory of reserved services, the locked inventory of the services to be confirmed and the determined inventory which is paid.
3. A service reservation method according to claim 2, characterized in that: when the reservation request of the client in the step (2) is sent to the DNS server, the whole flow of the service request is cleaned through DDos high security, the reservation request of the client is sent to the CDN cache server nearby, and static data in the CDN cache server is read.
4. A service reservation method according to claim 2, characterized in that: and (2) when the reservation dynamic data is required to be acquired, forwarding the reservation request sent by the client to the LVS server, forwarding the request to a designated Nginx server through the LVS server, and forwarding the reservation request which is determined to be a non-abnormal user to the reservation server by the Nginx server.
5. The service reservation method according to claim 4, wherein: the Nginx server in the step (3) limits the burst reservation request flow through a token bucket algorithm to complete global current limiting; when the service is limited, by using an atomic operation in the Redis, the service request is refused after the reservation request exceeds the actual reservation service number.
6. The service reservation method according to claim 4, wherein: and (3) distributing the inventory reservation service numbers in the step (3) in a plurality of servers, and adding the servers in the Redis cluster into a blacklist after inventory in any server is deducted, so as to avoid service reservation request access.
7. The service reservation method according to claim 4, wherein: in the step (4), after the client side successfully orders the reservation in the reservation server, the reservation message is sent to the confirmation module through the message middleware, the reservation can be ensured to be correctly processed through the retry mechanism and the ack mechanism, and after the client side confirms, the inventory service is called to reduce the locked inventory by 1, and the inventory plus 1 is determined.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111581983.9A CN114363264B (en) | 2021-12-22 | 2021-12-22 | Service reservation method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111581983.9A CN114363264B (en) | 2021-12-22 | 2021-12-22 | Service reservation method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114363264A CN114363264A (en) | 2022-04-15 |
| CN114363264B true CN114363264B (en) | 2024-03-15 |
Family
ID=81101797
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111581983.9A Active CN114363264B (en) | 2021-12-22 | 2021-12-22 | Service reservation method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114363264B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114819236A (en) * | 2022-06-06 | 2022-07-29 | 中国工商银行股份有限公司 | Data query method and device, computer equipment and storage medium |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102598771A (en) * | 2010-01-04 | 2012-07-18 | 上海贝尔股份有限公司 | Method and system for resource scheduling |
| AU2014100094A4 (en) * | 2013-06-26 | 2014-03-06 | Zazzle Inc. | Displaying Customization Options and Collecting Customization Specifications |
| CN106504061A (en) * | 2016-10-31 | 2017-03-15 | 沈思远 | A kind of extremely simple shopping website interactive system and method |
| CN110148034A (en) * | 2019-04-24 | 2019-08-20 | 珠海市珠澳跨境工业区好易通科技有限公司 | A kind of excellent device and method of online shopping system architecture |
| CN111062723A (en) * | 2019-10-25 | 2020-04-24 | 贝壳技术有限公司 | Virtual account transfer method, device, system and storage medium |
| WO2020186909A1 (en) * | 2019-03-18 | 2020-09-24 | 北京金山云网络技术有限公司 | Virtual network service processing method, apparatus and system, and controller and storage medium |
| CN112132662A (en) * | 2020-09-28 | 2020-12-25 | 广州立白企业集团有限公司 | Commodity second killing method and device, computer equipment and storage medium |
| CN112347222A (en) * | 2020-10-22 | 2021-02-09 | 中科曙光南京研究院有限公司 | Method and system for converting non-standard address into standard address based on knowledge base reasoning |
| CN112738252A (en) * | 2020-12-30 | 2021-04-30 | 昆山巨星行动电子商务有限公司 | E-commerce high-concurrency second-killing system |
-
2021
- 2021-12-22 CN CN202111581983.9A patent/CN114363264B/en active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102598771A (en) * | 2010-01-04 | 2012-07-18 | 上海贝尔股份有限公司 | Method and system for resource scheduling |
| AU2014100094A4 (en) * | 2013-06-26 | 2014-03-06 | Zazzle Inc. | Displaying Customization Options and Collecting Customization Specifications |
| CN106504061A (en) * | 2016-10-31 | 2017-03-15 | 沈思远 | A kind of extremely simple shopping website interactive system and method |
| WO2020186909A1 (en) * | 2019-03-18 | 2020-09-24 | 北京金山云网络技术有限公司 | Virtual network service processing method, apparatus and system, and controller and storage medium |
| CN110148034A (en) * | 2019-04-24 | 2019-08-20 | 珠海市珠澳跨境工业区好易通科技有限公司 | A kind of excellent device and method of online shopping system architecture |
| CN111062723A (en) * | 2019-10-25 | 2020-04-24 | 贝壳技术有限公司 | Virtual account transfer method, device, system and storage medium |
| CN112132662A (en) * | 2020-09-28 | 2020-12-25 | 广州立白企业集团有限公司 | Commodity second killing method and device, computer equipment and storage medium |
| CN112347222A (en) * | 2020-10-22 | 2021-02-09 | 中科曙光南京研究院有限公司 | Method and system for converting non-standard address into standard address based on knowledge base reasoning |
| CN112738252A (en) * | 2020-12-30 | 2021-04-30 | 昆山巨星行动电子商务有限公司 | E-commerce high-concurrency second-killing system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114363264A (en) | 2022-04-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1949774B (en) | Method and apparatus for managing web application program conversation | |
| CN109101341B (en) | Distribution method and equipment of distributed lock | |
| CN103329113B (en) | Configuration is accelerated and custom object and relevant method for proxy server and the Dynamic Website of hierarchical cache | |
| CN104168333B (en) | The working method of PROXZONE service platforms | |
| CN100586058C (en) | J2EE middleware criterion based tolerant inbreak application server and tolerant inbreak method | |
| EP3766203B1 (en) | Autonomous secrets renewal and distribution | |
| EP3765982B1 (en) | Autonomous cross-scope secrets management | |
| CN111338773A (en) | Distributed timed task scheduling method, scheduling system and server cluster | |
| CN109173270B (en) | Game service system and implementation method | |
| CN108985092A (en) | Submit filter method, device, electronic equipment and the storage medium of request | |
| CN110599144B (en) | Network access method and device for blockchain nodes | |
| US11544245B2 (en) | Transaction processing method, apparatus, and device and computer storage medium | |
| CN114363264B (en) | Service reservation method | |
| WO2014152076A1 (en) | Retry and snapshot enabled cross-platform synchronized communication queue | |
| US20070265976A1 (en) | License distribution in a packet data network | |
| CN114185558A (en) | Native application master selection method and device based on K8s and storage medium | |
| CN107819754B (en) | Anti-hijacking method, monitoring server, terminal and system | |
| US20150381516A1 (en) | Resource access driven distributed transaction coordination system | |
| CN111756784B (en) | Session method, session device, computer equipment and medium | |
| CN113923260B (en) | Method, device, terminal and storage medium for processing agent environment | |
| CN111190754A (en) | Block chain event notification method and block chain system | |
| CN111901366B (en) | Data pushing method, device, equipment and storage medium | |
| JP2004005377A (en) | Method for preventing recurrence of multiplex system outage | |
| CN111581613A (en) | Account login verification method and system | |
| CN109558205B (en) | Disk access method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |