Traffic control system based on message queue and message queue middleware under high concurrency conditions

Abstract

In view of the system performance problems caused by the sudden increase in traffic within a short period of time in high-concurrency scenarios, the present invention proposes a traffic control system and a message queue middleware based on a message queue under high-concurrency conditions. The system includes a presentation layer, a service unit layer, a cache layer, and a data layer, and the above-mentioned message queue middleware is applied to the above-mentioned system; asynchronous processing, application decoupling, and traffic peak shaving are realized by using the designed message queue; taking the commodity marketing flash sale activity as an example, experiments show that the present invention can effectively improve the system performance, the message queue can effectively relieve the server pressure, and under the impact of sudden traffic, the server message processing ability and response speed are significantly improved, reducing the risk of system TPS reduction.

Description

Technical Field

[0001] The present invention relates to the field of traffic control, and particularly to a traffic control system and a message queue middleware based on a message queue under high concurrency conditions. Background Art

[0002] With the rapid development of Internet technology, more and more e-commerce enterprises choose to release and sell new products online, and improve the brand awareness by holding promotional activities. In the scenario of commodity marketing activities, the user requests are too large in a short time, and the traffic surges, which easily leads to a sudden increase in the server pressure per unit time, unable to respond to user requests in time, resulting in system downtime, over-selling of commodities, and reduced system availability. Therefore, high concurrency and high availability have become essential requirements for e-commerce enterprise websites. Summary of the Invention

[0003] Aiming at the deficiencies in the prior art, the present invention provides a traffic control system and a message queue middleware based on a message queue under high concurrency conditions. On the basis of the ordinary system architecture, a message queue and data caching are added, and deployed in the form of microservices to improve the concurrency and availability of the system. Through the load balancing strategy of Nginx technology, the high availability of the website is achieved, and a message queue OPPLMQ is designed. Using the asynchronous processing mechanism of the message queue, the peak shaving is performed on the sudden traffic and the peak access period, enhancing the system message processing ability, reducing the response time and server pressure, and improving the high concurrency processing ability of the system.

[0004] To achieve the above object, the present invention adopts the following technical solutions:

[0005] A traffic control system based on a message queue under high concurrency conditions includes a presentation layer, a service unit layer, a caching layer, and a data layer;

[0006] The presentation layer is built through the Vue framework and is responsible for specific matters such as carrying user action requests, front-end and back-end data interaction, and page data rendering. The presentation layer connects users, data, and services. The presentation layer includes a front-end address, a back-end address, a route guard module, a route control module, a public status module, a service request module, and a data processing module. Users independently access the system front-end address and back-end address. Under the control of Vue routing, the page data of the URL index resource is guided and rendered; A route guard module is set up in the presentation layer, and a resource pre-processor is configured to intercept illegal and unauthenticated user requests; The presentation layer also includes a page control module. After the user obtains the resource, transaction processing is performed within the page. After the page receives the user action, a service request is made to the back-end through Axios, and the returned data is rendered within the page;

[0007] The service unit layer includes a public service unit, a mail service unit, and a message queue service unit. The service unit layer receives user requests from the presentation layer through the public service unit, parses and processes the request data, invokes the service unit corresponding to the request, decouples the service architecture, and returns a unified format response. The mail service unit undertakes the specific function of mail sending, and its object orientation is the internal unit of the service unit layer, and it is only allowed to be called within the service unit layer; the message queue service unit solves the data bearing and transmission processing of the public service unit, and provides a data transaction interface and a data monitoring address;

[0008] The cache layer is located between the data layer and the service unit layer, undertakes part of the I / O transactions, designs a three-level database cache based on Mybatis and Redis. When the user request hits the cached data, it directly returns, omitting steps such as parsing, optimization, and execution. A high-speed hot data cache service is built through Redis to bear the storage of high I / O data and temporary hot data of the service, and Mybatis provides a first-level cache to optimize queries;

[0009] The data layer persists data, stores service data, and provides business data. It realizes a relational data persistence model through MySQL. Under the call of the service unit layer and the cache layer, it provides data operations through transaction queries, and the query results are processed within the service unit layer and uniformly returned to the user.

[0010] To optimize the above technical solutions, the specific measures taken also include:

[0011] Further, the message queue service unit serves as the message center of the message queue model, responsible for the writing, storage, reading, confirmation, and retry of user requests. The message center includes at least one message queue; the message queue stores user requests according to the FIFO characteristic of the queue; the public service unit serves as the producer or consumer of the message queue model. When the public service unit receives a user request, it acts as a producer and writes the user request to the message queue service unit. When the public service unit receives the order processing business of the mall, it acts as a consumer and reads the user requests stored in the message queue service unit.

[0012] Further, the service unit layer also includes a traffic controller, and the traffic controller controls the traffic of user requests, specifically:

[0013] The traffic controller generates tokens at a certain rate and puts them into the token bucket. Before processing a user request, it judges whether there are still tokens in the token bucket. If there are tokens, it applies to obtain the tokens and then processes the user request. If there are no tokens, it selects an immediate return policy or a blocking waiting policy according to the actual scenario.

[0014] Furthermore, the communication methods between the message center, producers, and consumers include point-to-point communication and publish-subscribe communication;

[0015] In the point-to-point communication method, the producer sends messages to the message queue, and the consumer retrieves messages from the message queue. The message queue is a buffer for storing messages, and the identities of the producer and consumer can be interchanged. In the publish-subscribe communication method, the messages produced by the producer are distributed to all message queues, and all consumers bound to the message queues will subscribe to this message;

[0016] In the flash sale activity, the point-to-point communication method of the message queue is used for traffic peak shaving, while in the product spike kill activity, the publish-subscribe communication method is used for the spread of single-point data in transaction passing; the user requests and business operations are executed asynchronously. When the user sends a spike kill request and the system processes it successfully, it immediately responds and at the same time sends the spike kill request to an independently named message queue. The message consumer subscribes to or listens to this message queue, obtains the spike kill request and performs subsequent business processing. The consumer does not need to make a synchronous response to the publisher, and the entire connection is processed and forwarded by the message center.

[0017] The present invention also proposes a message queue middleware, which is applied to the traffic control system based on the message queue under the above-mentioned high concurrency conditions, and includes a message queue server, a message queue client, and a communication manager;

[0018] The message queue server bears the running logic and storage process of data in the message queue. The message queue client is the access end of the message queue. The communication manager is a set of data exchange protocols agreed upon by the message queue server and the message queue client, and will encapsulate and transmit data through internal specified logic, so as to achieve data communication between the message queue server and the message queue client;

[0019] The communication manager includes a container unit, a queue unit, queue information, an authentication label, and a queue key; the container unit is used to carry information transmission tasks, and the queue unit specifically uses a non-blocking queue in Java.

[0020] To optimize the above technical solutions, the specific measures taken also include:

[0021] Furthermore, the message queue server is implemented using the Jooby Web framework. The message queue server includes an OpplMessageQueue startup class, an autoconfig package, a content package, an entity package, an exception package, a request package, a tools package, and an Initializer class;

[0022] The OpplMessageQueue startup class is used to build service components, set up around-log printing, set up global exception control, set up resource paths, set up external components, and mount routers and configure authorization and authentication modules;

[0023] The autoconfig package is responsible for the automatic configuration of the service, including the AutoBanner class, the AutoConfig class, and the AutoSaveDisk class; the AutoBanner class implements the output of the program identifier; the AutoConfig class implements automatic configuration, including the startup reading of users and passwords in the user.oldb file; the AutoSaveDisk class realizes data persistence for JSON-format data through the Netty Channel channel;

[0024] The content package is responsible for the implementation of specific queues, including the Queu class, the QueueType class, the AdminMq class, the DirectQueue class, the TopicQueue class, the DirectController class, and the TopicController class. The Queu class is the smallest queue unit, and automatically fills the specific type of the container unit through the getGenericSuperclass() reflection method. The QueueType class internally declares that it can create enumerated queue types. The AdminMq class is mainly responsible for managing the queue content created by the service, namely the DirectQueue class and the TopicQueue class. The DirectController class and the TopicController class are queue transaction request implementation classes. All internal requests are protected resources of the service. Each request will perform username and password verification in the pre-guard. If the verification passes, transaction operations can be performed; otherwise, it is determined to be an illegal request and intercepted.

[0025] The entity package includes the response return body Result, the request body FromClientEntity, and the common fields GlobalFields;

[0026] The exception package is responsible for managing internal exception information classes;

[0027] The request package internally implements the RPC communication module;

[0028] The Initializer class is the internal service interface of the queue monitoring page, complementing the ThymeleafModule. The interface " / initauth" implements the login and resource management of the service data monitoring page, obtains the username and password of the user in the service data monitoring page, verifies the login request, encapsulates the data model if the verification passes, and returns the data resources; otherwise, it intercepts.

[0029] The tools package is responsible for providing common tool methods for the service and encapsulating a collection of common tool classes.

[0030] Furthermore, the message queue client establishes communication based on Apache Http Client to implement the transaction interaction between the message queue server and the message queue client; the message queue client includes the ManagerQueue management class, the autoconfig package, the entity package, and the request package, which are imported and used through external dependencies. Before the user accesses the queue, the message queue server needs to be started and authenticated and bound. After successfully connecting to the service, the user can operate on queue transactions, such as queue creation and deletion, data pushing and retrieval, and message subscription and removal.

[0031] The ManagerQueue management class is set with static directQueue transaction implementation classes and topicQueue transaction implementation classes, including methods such as queue creation, queue data pushing, queue data consumption, queue deletion, calculating the queue data capacity, and queue information.

[0032] The autoconfig package implements the parameter configuration reading of application.yml. The parameters include the local host localhost, port, username, and password. The autoconfig package also includes the AutoBanner package and the AutoConnect package. The AutoBanner package implements the output of the program identifier and reads the banner in the resource folder. The AutoConnect package implements the automatic connection to the message queue server and verifies the login through the read username and password.

[0033] The entity package includes the response return body Result, the request body FromClientEntity, and the common fields GlobalFields.

[0034] The HttpTemplate class inside the request package encapsulates the remote request method post(), adds the request headers "Content-Type: application / json" and "Connection: Keep-Alive", converts the data body to JSON, and adds the request data body to establish communication with the message queue server.

[0035] Further, to ensure message consistency, the message queue client requests services synchronously. After the request is sent, it will wait for the {code: <response code>} field and the {msg: <request address>} field of the message queue server. The meaning of the {code: <response code>} field is that if it ends with "00", the request is processed successfully; if it ends with "99", the request is processed failed.

[0036] The beneficial effects of the present invention are:

[0037] Adding a message queue and data cache, deploying in the form of microservices to improve the concurrency and availability of the system. Through the load balancing strategy of Nginx technology, the high availability of the website is achieved. Using the asynchronous processing mechanism of the message queue to perform peak shaving for sudden traffic and peak access periods, enhancing the system's message processing ability, reducing response time and server pressure, improving the system's high-concurrency processing ability, effectively reducing service pressure, increasing response speed, and reducing the risk of system TPS reduction. Description of the Drawings

[0038] Figure 1 Is the overall system architecture diagram;

[0039] Figure 2 Is the operating principle diagram of the traffic controller;

[0040] Figure 3 Is the message queue logical model;

[0041] Figure 4 Is the message queue communication model;

[0042] Figure 5 Is the component business model;

[0043] Figure 6 Is the operating logic diagram of the message queue middleware;

[0044] Figure 7 Is the startup diagram of the message queue server;

[0045] Figure 8 Is the data monitoring page;

[0046] Figure 9 Is the total successful response time unit proportion diagram;

[0047] Figure 10 It is a percentage chart of response time;

[0048] Figure 11 It is a graph of the relationship between time and threads. Specific implementation manners

[0049] Now, the present invention will be further described in detail with reference to the accompanying drawings.

[0050] In one embodiment, the present invention provides a traffic control system based on a message queue under high concurrency conditions. The overall architecture diagram of the system is as Figure 1 shown. The system includes a presentation layer, a service unit layer, a cache layer, and a data layer;

[0051] The presentation layer is built through the Vue framework and is responsible for carrying specific tasks such as user action requests, front-end and back-end data interaction, and page data rendering. The presentation layer connects users, data, and services. The presentation layer includes a front-end address, a back-end address, a route guard module, a route control module, a public status module, a service request module, and a data processing module. Users independently access the front-end and back-end addresses of the system. Under the control of Vue routing, the page data of the URL-indexed resources is guided and rendered; a route guard module is set up in the presentation layer to configure a resource pre-processor to intercept illegal and unauthenticated user requests; the presentation layer also includes a page control module. After the user obtains the resources, transaction processing is performed within the page. After the page receives the user action, a service request is sent to the back-end through Axios, and the returned data is rendered within the page;

[0052] The service unit layer includes a public service unit, an email service unit, and a message queue service unit. The service unit layer receives user requests from the presentation layer through the public service unit, parses and processes the request data, calls the service unit corresponding to the request, decouples the service architecture, and returns a unified format response. The email service unit undertakes the specific function of email sending, and the object-oriented is the internal unit of the service unit layer, and it is only allowed to be called within the service unit layer; the message queue service unit solves the data bearing and transmission processing of the public service unit, and provides a data transaction interface and a data monitoring address; the message queue service unit serves as the message center of the message queue model and is responsible for the writing, storage, reading, confirmation, and retry of user requests. The message center includes at least one message queue; the message queue stores user requests according to the FIFO characteristics of the queue; the public service unit serves as the producer or consumer of the message queue model. When the public service unit receives a user request, it acts as a producer and writes the user request to the message queue service unit. When the public service unit receives the order processing service of the mall, it acts as a consumer and reads the user requests stored in the message queue service unit.

[0053] The message queue is a component for data communication between processes and threads. It is a loosely coupled, reliable asynchronous communication service in a transaction mode, responsible for decoupling business modules, and plays an important role in enhancing the system's scalability and concurrency. The queue service needs to ensure asynchrony, peak shaving, and decoupling, and maintain the connection of service units. Regarding its middleware characteristics, the queue adopts a configuration file access method to reduce redundant code and lower the configuration constraints of unnecessary class methods. At the same time, considering issues such as duplicate consumption, dirty reads and phantom reads, message loss, weak network reading and writing, and data order, a message confirmation mechanism is designed to reduce risks and enhance the robustness of the service. The logical model of the message queue is as Figure 3 shown. The message producer generates message data and writes it into the message center, and the consumer reads the message data from the message center.

[0054] The cache layer is located between the data layer and the service unit layer, undertaking part of the I / O transactions. Based on Mybatis and Redis, a three-level database cache is designed. When the user request hits the cached data, it is directly returned, omitting steps such as parsing, optimization, and execution. A high-speed hot data cache service is built through Redis to carry the storage of high I / O data and temporary hot data of the service, and Mybatis provides a first-level cache to optimize queries;

[0055] The service unit layer also includes a traffic controller. The traffic controller controls the traffic of user requests. The operating principle of the traffic controller is as Figure 2 shown. Specifically: the traffic controller generates tokens at a certain rate and puts them into the token bucket. Before processing a user request, it judges whether there are still tokens in the token bucket. If there are tokens, it applies to obtain the tokens and then processes the user request. If there are no tokens, it selects an immediate return policy or a blocking wait policy according to the actual scenario. TPS (Transactions Per Second) is the number of request transactions that the server can process per second. The system performance is evaluated by the number of request processing completed per second. To solve the problem of high-traffic requests impacting the server under high concurrency conditions, the system uses AOP technology to cut into the service unit layer (that is, the operations of user requests entering the service unit layer from the presentation layer and data returning from the service unit layer to the presentation layer. The purpose is to ensure the around control of business entering and leaving the service unit layer and improve the controllability of requests), and adds a RateLimiter traffic controller. The traffic controller is located on the side of authorized requests and data requests in the service unit layer, aiming to effectively control user requests and achieve traffic limiting.

[0056] The data layer persists data, stores service data, and provides business data. It realizes a relational data persistence model through MySQL. Under the call of the service unit layer and the cache layer, it provides data operations through transaction queries, and the query results are processed within the service unit layer and uniformly returned to the user.

[0057] The communication methods between the message center, producers, and consumers include point-to-point communication and publish-subscribe communication; the point-to-point communication and publish-subscribe communication are as Figure 4 shown. In the point-to-point communication method, the producer sends messages to the message queue, and the consumer retrieves messages from the message queue. The message queue is a buffer for storing messages, and the identities of the producer and consumer can be interchanged; in the publish-subscribe communication method, the messages produced by the producer are distributed to all message queues, and all consumers bound to the message queues will subscribe to this message.

[0058] In a flash sale event, users generate orders when they snap up products. The user order information is transmitted as a data element in the message queue, and the user's snap-up action, i.e., the snap-up request, can be used as a message producer to publish messages. The order processing service module of the service module will retrieve from the queue, that is, the message consumer will receive and subscribe to the messages.

[0059] In a flash sale event, the data transfer presents a point-to-point relationship, that is, the user's order placement action and the single-product inventory deduction action are single-piece data transfers, and the point-to-point communication method of the message queue is used for traffic peak shaving. In the product flash sale event, the notification presents a point-to-many relationship. An event can be subscribed to by an unlimited number of users. When the event starts, the publish-subscribe communication method is used for the diffusive transaction transfer of single-point data; the user request and the business operation are executed asynchronously. When the user sends a snap-up request and the system processes it successfully, it will respond immediately, and at the same time, the snap-up request will be sent to an independently named message queue. The message consumer subscribes to or listens to this message queue, obtains the snap-up request, and performs subsequent business processing. The consumer does not need to make a synchronous response to the publisher, and the entire connection is processed and forwarded by the message center.

[0060] In the message queue communication method, message data is the key to transactions, and message consistency and the internal logical relationship of components need to be considered.

[0061] In the message queue, message consistency refers to the consistency between message generation and message sending transactions. If the business operation is successful, the message must be sent; otherwise, the message is determined to be lost. If the business does not occur or fails, the message is not sent. Therefore, if there are business operations, data persistence, service calls, message publishing, etc. in the message, in a distributed application scenario, the failure and exception of a certain operation are likely to result in message ambiguity. To ensure data consistency, the service process of the message queue client request is designed to be synchronous. After the transaction request is sent, it will wait for the {code: <response code>} field and the {msg: <request address>} field of the message queue server. The meaning of the code field ends with "00", such as "x00" indicating that the request is processed successfully, and if it ends with "99", such as "x99", it indicates that the request fails.

[0062] The message queue model consists of three parts: the producer, the consumer, and the message center. The producer is the data generator, which can be request instructions from users, systems, processes, or even threads, and is responsible for message generation and queue writing transactions. The producer in this system is the spike request of the public service unit; the consumer is the data user, which obtains messages in the data center for processing. The consumer in this system is the order processing service of the public service unit; the data center is the data storage unit, responsible for data writing and reading. The data center in this system is the message queue service unit. The business model among the three is as Figure 5 shown.

[0063] In another embodiment, the present invention proposes a message queue middleware, which is applied to the traffic control system based on the message queue under high concurrency conditions as described above, and is characterized in that it includes a message queue server, a message queue client, and a communication manager;

[0064] The message queue server bears the running logic and storage process of data in the message queue. The message queue client is the access end of the message queue. The communication manager is a set of data communication protocols agreed upon by the message queue server and the message queue client, and will encapsulate and transmit data through internal specified logic, so as to achieve data communication between the message queue server and the message queue client;

[0065] The communication manager includes a container unit, a queue unit, queue information, an authentication label, and a queue key; the container unit is used to carry information transmission tasks, and the queue unit specifically uses a non-blocking queue in Java.

[0066] In view of the high concurrency scenario in the spike activity, when selecting a large-capacity, high-density, and structured data container, the first considerations are data uniqueness, reliability, stability, and security. Secondly, consider data reading and writing efficiency, data transmission rate, and data storage structure. In the distributed scenario of asynchronous multi-threading and microservices, this system uses the CAS algorithm model for locking and uses the ConcurrentLinkedQueue (non-blocking queue) in Java as the basic queue unit. The non-blocking queue is a safe queue sorted in FIFO order and is friendly to multi-threaded scenarios. In addition, a high-performance cache container based on Redis also has good benefits. The running logic of the message queue middleware is as Figure 6 shown.

[0067] The message queue server is the entire message queue service, which is the content of the entire queue architecture. It bears the running logic and storage process of data in the queue and is an independent service entity. The message queue client is the queue access end, also an independent service entity. In this architecture, it is the mall system. The roles of products and users in the mall system in the message queue are producers and consumers respectively, thus meeting the queue running conditions. The communication manager is a set of data communication protocols agreed upon by the message queue server and the message queue client. It will encapsulate and transmit data through the internally specified logic to achieve data communication between the two service entities. In a Web application, the message queue can enter as a middleware, establish connections with the message producers and message consumers, form an entity relationship chain, buffer and store data, improve system performance, and highlight the high scalability and robustness of the system.

[0068] Since a large amount of I / O is generated during queue communication and high service performance is required, the message queue server is implemented using the Jooby Web framework, which consists of the OpplMessageQueue startup class, as well as the autoconfig, content, entity, exception, request, tools packages and the Initializer class. The startup of the message queue service is as Figure 7 shown.

[0069] The OpplMessageQueue startup class is used to build service components, set the surrounding log printing AccessLogHandler, set the global exception control globalException(), set the resource path assets(), set external components install(), and mount routes and configure authorization and authentication modules.

[0070] The autoconfig package is responsible for the automatic configuration of the service and consists of the AutoBanner class, the AutoConfig class, and the AutoSaveDisk class. The AutoBanner class outputs the program identifier; the AutoConfig class implements automatic configuration, mainly including the startup reading of users and passwords in the user.oldb file. The AutoSaveDisk class implements the data persistence logic. The main persistence solution is that the AutoSaveDisk class performs file persistence on JSON format data through the Netty Channel.

[0071] The core code of this part is as follows:

[0072] The content package is responsible for the implementation logic of specific queues and consists of the Queu class, QueueType class, AdminMq class, DirectQueue class, TopicQueue class, DirectController class, and TopicController class. The Queu class is the smallest queue unit and automatically fills the specific type of the container through the getGenericSuperclass() reflection method. The QueueType class declares the enumeration queue types that can be created internally. The AdminMq class is mainly responsible for managing the queue content models of the DirectQueue class and TopicQueue class created by the service.

[0073] The entity package contains entities such as the response return body Result, the request body FromClientEntity, and the common fields GlobalFields.

[0074] The exception package is responsible for managing internal exception information classes.

[0075] The request package internally implements the RPC communication module, which is the key to forming the service.

[0076] The Initializer class is the internal interface of the service for the queue monitoring page and complements the ThymeleafModule. The interface " / initauth" implements the login and resource management of the service data monitoring page, such as Figure 8 shown. It obtains the username and pwd values of the user on the page, validates the login request, encapsulates the data model if the validation passes, and returns the data resources; otherwise, it intercepts. The DirectController class and TopicController class are the implementation classes for queue transaction requests. All internal requests are protected resources of the service. Each request will perform username and password validation in the pre-guards. If the validation passes, transaction operations can be performed; otherwise, it is determined as an illegal request and intercepted.

[0077] The tools package is responsible for providing common tool methods for the service and encapsulating a collection of common tool classes.

[0078] The message queue client consists of the ManagerQueue management class and the autoconfig, entity, and request packages, and is imported and used through external dependencies. When a user accesses the queue, they need to start the message queue server and authenticate and bind. After successfully connecting to the service, they can operate on queue transactions, such as creating and deleting queues, pushing and retrieving data, subscribing to and removing messages, etc. Adhering to the concept of rapid development, the message queue client reduces redundant configurations and provides a comprehensive set of general transaction interfaces, which are invoked and started through object methods, maximizing the decoupling concept.

[0079] The ManagerQueue management class is set with static implementation classes for directQueue transactions and topicQueue transactions. It internally includes methods such as queue creation create(), queue data pushing push(), queue data consumption pop(), queue deletion remove(), queue data capacity size(), and queue information info().

[0080] The autoconfig package implements the reading of parameters in application.yml. The parameters include properties such as local host localhost, port port, username username, and password password. The autoconfig package also includes the AutoBanner package and the AutoConnect package. The AutoBanner package implements the output of the program identifier, reads the banner in the resource folder, and realizes the startup output. The AutoConnect package realizes the automatic connection to the message queue server and verifies and logs in through the read username usernmae and password password.

[0081] The entity package is consistent with the content of the message queue server and is responsible for implementing entity classes.

[0082] The HttpTemplate class inside the request package encapsulates the remote request method post(), adds the request headers "Content-Type:application / json" and "Connection: Keep-Alive", converts the data body to JSON, and adds the request data body to establish communication with the message queue server.

[0083] To verify the effectiveness of the system architecture and the performance of the message queue under high concurrency conditions, a real marketing activity scenario was simulated, and a spike activity with a high concurrency volume was selected for testing and analysis. The Apache Jmter test tool was used for performance testing, and the performance metrics tested included system response time, concurrent connection count, and throughput. The system simulated Http requests, sent requests to the server, the test object received and processed the data, and Jmter collected the response data to form the test results.

[0084] The test method started from 1000 threads per second and increased in increments of 1000 until the concurrent count reached 10000. Ten sets of experimental data results were obtained at the end of the test and analyzed based on the system performance metrics. The ten experimental data are shown in Table 1. It can be seen that the response time of 95% is good in the concurrent environment.

[0085] Table 1 Test experimental data

[0086] Concurrency Response Time (ms) Throughput (req / sec) 95% Line (ms) 1000 1 973.4 2 2000 1 948.3 2 3000 171 1298.7 1032 4000 514 1135.1 1583 5000 680 1347.3 2062 6000 721 1439.9 2088 7000 732 1677.1 2219 8000 829 1790.9 2034 9000 921 1671.9 2307 10000 7774 1883.6 2110

[0087] The proportion of the total successful response time unit is as Figure 9 shown. The oval is the minimum response time, the octagon is the 90% response time, the pentagon is the 95% response time, and the circle is the maximum response time. The experimental results show that the system performance is good.

[0088] Set the number of threads to 1000, the ramp-up period value to 1s, and loop ten times. The response time percentage is as Figure 10 shown. The relationship between time and threads is as Figure 11 shown. Through aggregation analysis, it can be seen that the average response is 19.77ms when the thread is at 318.69.

[0089] The above is only the preferred implementation mode of the present invention. The protection scope of the present invention is not limited to the above embodiments. Any technical solutions falling within the idea of the present invention belong to the protection scope of the present invention. It should be noted that for those of ordinary skill in the art, several improvements and refinements made without departing from the principle of the present invention should be regarded as within the protection scope of the present invention.

Claims

1. A traffic control system based on a message queue under high concurrency conditions, characterized in that It includes a presentation layer, a service unit layer, a cache layer, and a data layer; The presentation layer is built with the Vue framework and is responsible for carrying user action requests, front-end and back-end data interaction, and page data rendering. The presentation layer connects users, data, and services. The presentation layer includes a front-end address, a back-end address, a route guard module, a route control module, a common status module, a service request module, and a data processing module. Users independently access the system's front-end and back-end addresses. Under the control of Vue routing, it guides the page data of the URL-indexed resources and renders them. A route guard module is set up in the presentation layer to configure a resource pre-processor to intercept illegal and unauthenticated user requests. The presentation layer also includes a page control module. After the user obtains the resources, transaction processing is carried out within the page. After the page receives the user action, it makes a service request to the back-end through Axios and renders the returned data within the page; The service unit layer includes a common service unit, an email service unit, and a message queue service unit. The service unit layer receives user requests from the presentation layer through the common service unit, parses and processes the request data, calls the service unit corresponding to the request, decouples the service architecture, and returns a unified format response. The email service unit undertakes the specific function of email sending, with the object-oriented being the internal units of the service unit layer and only allowing internal calls within the service unit layer; The message queue service unit solves the data bearing and transmission processing of the common service unit, and provides a data transaction interface and a data monitoring address; The cache layer is located between the data layer and the service unit layer, undertaking part of the I / O transactions. It designs a three-level database cache based on Mybatis and Redis. When the user request hits the cached data, it directly returns, omitting the parsing, optimization, and execution steps. It builds a high-speed hot data cache service through Redis to carry the storage of high I / O data and temporary hot data of the service, and Mybatis provides a first-level cache to optimize queries; The data layer persists data, stores service data, and provides business data. It realizes a relational data persistence model through MySQL. Under the call of the service unit layer and the cache layer, it provides data operations through transaction queries, and the query results are processed within the service unit layer and uniformly returned to the user.

2. The traffic control system based on a message queue under high concurrency conditions according to claim 1, wherein The message queue service unit serves as the message center of the message queue model and is responsible for the writing, storage, reading, confirmation, and retry of user requests. The message center contains at least one message queue; The message queue stores user requests according to the FIFO characteristics of the queue; The common service unit acts as a producer or consumer of the message queue model. When the common service unit receives a user request, it acts as a producer and writes the user request to the message queue service unit. When the common service unit receives the order processing business of the mall, it acts as a consumer and reads the user requests stored in the message queue service unit.

3. The traffic control system based on a message queue under high concurrency conditions according to claim 1, characterized in that, The service unit layer also includes a traffic controller, and the traffic controller controls the traffic of user requests, specifically: The traffic controller generates tokens at a certain rate and puts them into the token bucket. Before processing a user request, it checks whether there are still tokens in the token bucket. If there are tokens, it applies to obtain the tokens and then processes the user request. If there are no tokens, it selects an immediate return policy or a blocking wait policy according to the actual scenario.

4. The traffic control system based on a message queue under high concurrency conditions according to claim 2, wherein The communication methods between the message center, producers, and consumers include point-to-point communication and publish-subscribe communication. In the point-to-point communication method, the producer sends messages to the message queue, and the consumer retrieves messages from the message queue. The message queue is a buffer for storing messages, and the identities of the producer and consumer can be interchanged. In the publish-subscribe communication method, the messages produced by the producer are distributed to all message queues, and all consumers bound to the message queues will subscribe to this message. In a flash sale event, the point-to-point communication method of the message queue is used for traffic peak shaving, while in a product instant kill event, the publish-subscribe communication method is used for the diffusion transaction transfer of single-point data. The user request and business operation are executed asynchronously. When the user sends a flash sale request and the system processes it successfully, it immediately responds. At the same time, the flash sale request is sent to an independently named message queue. The message consumer subscribes to or listens to this message queue, obtains the flash sale request, and performs subsequent business processing. The consumer does not need to make a synchronous response to the publisher, and the entire connection is processed and forwarded by the message center.

5. A message queue middleware for a traffic control system based on message queues under high concurrency conditions as described in claim 1, characterized in that, It includes a message queue server, a message queue client, and a communication manager. The message queue server bears the running logic and storage process of data in the message queue. The message queue client is the access end of the message queue. The communication manager is a set of data exchange protocols agreed upon by the message queue server and the message queue client, which will encapsulate and transmit data through internal specified logic to achieve data communication between the message queue server and the message queue client. The communication manager includes a container unit, a queue unit, queue information, an authentication label, and a queue key. The container unit is used to carry information transmission tasks, and the queue unit specifically uses a non-blocking queue in Java.

6. The message queue middleware according to claim 5, wherein The message queue server is implemented using the Jooby Web framework. The message queue server includes the OpplMessageQueue startup class, the autoconfig package, the content package, the entity package, the exception package, the request package, the tools package, and the Initializer class. The OpplMessageQueue startup class is used to build service components, set around-log printing, set global exception control, set resource paths, set external components, and mount routes and configure authorization and authentication modules. The autoconfig package is responsible for the automatic configuration of services, including the AutoBanner class, the AutoConfig class, and the AutoSaveDisk class; the AutoBanner class implements the output of the program identifier; the AutoConfig class implements automatic configuration, including the startup reading of users and passwords in the user.oldb file; the AutoSaveDisk class realizes data persistence for JSON-format data through the Netty Channel channel; The content package is responsible for the implementation of specific queues, including the Queu class, the QueueType class, the AdminMq class, the DirectQueue class, the TopicQueue class, the DirectController class, and the TopicController class. The Queu class is the smallest queue unit, and the specific type of the container unit is automatically filled through the getGenericSuperclass() reflection method. The QueueType class internally declares that it can create enumerated queue types. The AdminMq class is mainly responsible for managing the queue content created by the service, the DirectQueue class and the TopicQueue class; the DirectController class and the TopicController class are the queue transaction request implementation classes. All internal requests are protected resources of the service. Each request will perform username and password verification in the pre-guards. If the verification passes, transaction operations can be performed; otherwise, it is determined as an illegal request and intercepted; The entity package includes the response return body Result, the request body FromClientEntity, and the common fields GlobalFields; The exception package is responsible for managing internal exception information classes; The request package internally implements the RPC communication module; The Initializer class is the internal interface of the service for the queue monitoring page and complements the ThymeleafModule. The interface " / initauth" implements the login and resource management of the service data monitoring page, obtains the username and password of the user in the service data monitoring page, verifies the login request, encapsulates the data model if the verification passes, and returns the data resources; otherwise, it is intercepted; The tools package is responsible for providing common tool methods for the service and encapsulating a collection of common tool classes.

7. The message queue middleware according to claim 6, characterized in that, The message queue client establishes communication based on Apache Http Client to achieve transaction interaction between the message queue server and the message queue client; the message queue client includes a ManagerQueue management class, an autoconfig package, an entity package, and a request package, which are imported and used through external dependencies. Before a user accesses the queue, the message queue server needs to be started and authenticated and bound. After successfully connecting to the service, the user can operate on queue transactions, including queue creation and deletion, data pushing and retrieval, and message subscription and removal. The ManagerQueue management class is set with static directQueue and topicQueue transaction implementation classes, including queue creation, queue data pushing, queue data consumption, queue deletion, calculation of queue data capacity, and queue information. The autoconfig package implements the reading of parameter configurations in application.yml. The parameters include the local host localhost, port port, username username, and password password. The autoconfig package also includes an AutoBanner package and an AutoConnect package. The AutoBanner package implements the output of the program identifier and reads the banner in the resource folder. The AutoConnect package implements the automatic connection to the message queue server and verifies and logs in through the read username usernmae and password password. The entity package includes a response return body Result, a request body FromClientEntity, and common fields GlobalFields. The HttpTemplate class inside the request package encapsulates the remote request method post(), adds the request headers "Content-Type: application / json" and "Connection: Keep-Alive", converts the data body to JSON, and adds the request data body to establish communication with the message queue server.

8. The message queue middleware according to claim 5, wherein To ensure message consistency, the message queue client requests the service synchronously. After the request is sent, it will wait for the {code: <response code>} field and the {msg: <request address>} field of the message queue server. The meaning of the {code: <response code>} field is that if it ends with "00", the request is processed successfully; if it ends with "99", the request is processed failed.

Images