Virtual ornament cloud detection system and method for massive users
By adopting a distributed microservice architecture and a priority queue management mechanism, the problem of insufficient concurrency in the massive user virtual item detection system is solved, achieving efficient and rapid return of detection results and improved resource utilization, thus optimizing the user experience.
Patent Information
- Application Number
- CN202511654980.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-12
- Publication Date
- 2025-12-12
AI Technical Summary
Existing virtual item detection systems lack concurrency capabilities when dealing with massive numbers of users, and lack a unified cloud management and distribution mechanism, resulting in low inspection efficiency, low resource utilization, and a lack of efficient queue management and message scheduling, which can easily lead to request loss or disordered order.
Adopting a distributed microservice architecture, combined with a priority queue management mechanism and a low-latency communication protocol, it achieves distributed scheduling and processing of high-concurrency detection requests through long-connection real-time communication and message queue peak shaving and valley filling mechanisms, dynamic priority sorting and database sharding strategies, thereby improving resource utilization efficiency and the performance of detection data storage and retrieval.
It significantly improves system throughput and reduces detection result feedback latency, ensuring high-value jewelry is detected first, reducing waiting time, improving resource utilization and user experience, and supporting system scalability and user stickiness.
Smart Images
Figure CN121125806A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of inspection technology, specifically to a cloud-based inspection system and method for virtual accessories for a large number of users. Background Technology
[0002] With the increasing popularity of online games, especially first-person shooter games, virtual items (such as weapon skins and stickers) have gradually become important digital assets for players. The appearance information, float value, and rarity of these items have become important parameters affecting their value.
[0003] Currently available item detection systems mostly involve executing detection programs locally on the client side within the application layer, obtaining item information through game APIs or third-party interfaces. However, this type of solution has the following shortcomings: 1. Insufficient concurrency: Most existing systems are single-threaded or single-node viewing systems, which cannot support viewing requests initiated by a large number of users at the same time, and are prone to lag or timeout.
[0004] 2. The inspection process depends on the local environment: Users need to rely on the game client installed locally, which lacks a unified cloud management and distribution mechanism, resulting in low inspection efficiency.
[0005] 3. Lack of unified queuing and scheduling: During peak periods, when multiple users initiate inspection requests simultaneously, the lack of efficient queue management and message scheduling can easily lead to request loss or disordered order.
[0006] 4. Low resource utilization: It is common to see idle or overloaded machines (instances running game clients), and there is a lack of load balancing and health status monitoring mechanisms.
[0007] Based on this, the present invention designs a cloud-based detection system and method for virtual accessories for a large number of users to solve the above problems. Summary of the Invention
[0008] In view of the above-mentioned shortcomings of the existing technology, the present invention provides a cloud-based detection system and method for virtual accessories for a large number of users.
[0009] To achieve the above objectives, the present invention provides the following technical solution: A cloud-based virtual item verification system for a massive user base, including: It includes, from top to bottom, the application layer, access layer, business layer, service layer, storage layer, and environment layer; Application layer: Used to provide multi-terminal access for end users, allowing users to initiate virtual accessory detection requests through any terminal; Access layer: Used to uniformly receive virtual item detection requests from different terminals and forward the virtual item detection requests to the subsequent business layer; Business layer: Used for user management, queue management, community server management, event management, and exception monitoring management; Service layer: Provides specific service functions to support the business layer; The service functions include user services, event services, queue services, and machine management services; Storage layer: used to store structured data, cached data, message tasks, version code, and large-scale file resources respectively; Environment layer: Provides the hardware and cloud infrastructure support required for operation, allowing users to initiate virtual item detection requests through any terminal.
[0010] Furthermore, the application layer includes mobile applications (APPs), PC clients, and WeChat / Alipay mini-program clients.
[0011] Furthermore, the access layer acts as a gateway, uniformly receiving virtual item detection requests from different terminals, performing functions such as authentication, routing, load balancing, and protocol conversion, and forwarding the virtual item detection requests to the subsequent business layer for processing.
[0012] Furthermore, the business layer includes a user management module, a queue management module, a community server management module, an event management module, and an exception listening management module: The user management module is used to maintain user account information, permission levels, and usage records; The queue management module is used to control the queuing of detection requests to prevent resource overload; The community server management module is used to connect to and manage third-party community or server resources; The event management module is used to manage the triggered events in the detection process; The anomaly monitoring and management module is used to monitor abnormal situations during the detection process in real time and trigger alarms.
[0013] Furthermore, the service layer includes user service modules, event service modules, queue service modules, and machine management service modules: The user service module is used for authentication, signature, and login status determination. The event service module is used for event registration, event listening, and callback execution; The queue service module is used for scene management, instruction type identification, instruction strategy configuration, ranking query, total queue count statistics, and data caching. The machine management service module is used for functions such as machine initialization, status detection, command issuance, manual annotation, machine startup and release, and realizes dynamic scheduling of testing resources.
[0014] Furthermore, the storage layer includes a MySQL database, a Redis cache, a RocketMQ message queue, a GitLab code repository, and OSS object storage.
[0015] A detection method for a cloud-based virtual item detection system for a massive user base includes the following steps: Step 1: Start the application layer and determine whether the detection program in the application layer has been moved to the background. If the determination is yes, proceed to step 2; if the determination is no, proceed to step 3. Step 2: Next, determine if it is in the background queue. If yes, proceed to step 7; if no, proceed to step 3. Step 3: Open the detection program within the application layer and register the event; Registration events include client-side events such as "user login event", "queue number allocation event", and "check completion event"; The detection program within the application layer is a detection startup module that runs locally on the client side. It is mainly used to launch the detection logic and connect to the backend interface. Step 4: Determine if the user is logged in. If yes, proceed to step 5. If no, prompt the user to log in and proceed to step 5. Step 5: Determine if the check queue has reached its limit. If it is, display a message indicating that the queue is overcrowded, and the user can cancel the check or proceed to Step 6. If it is not, proceed to Step 6. Step 6: Determine if the queue is already open. If yes, proceed to step 8; otherwise, proceed to step 7. Step 7: Enter the queue management module, take a number and queue, then proceed to Step 8; Step 8: Determine if it can be viewed. If yes, proceed to step 9. If no, prompt the user "System busy, please try again later" and end the current process. Step 9: Allocate resources to the detection machine and determine whether a connection has been established with the monitoring program of the community server management module. If the determination is yes, proceed to step 10; if the determination is no, report the abnormal information. Step 10: Send detection information, then determine whether the number of times it is sent is greater than the set threshold. If the determination is yes, enter the waiting queue; if the determination is no, return to the detection screen.
[0016] Furthermore, the specific steps for step 7 are as follows: Step 71: Receive the queuing instruction "Queue Name + Instruction Type + Token" and encapsulate the upper limit text of the queuing instruction (QueueCommand Conet). Step 72: Enter the queuing system execution program in the queue management module, and then enter the checker responsibility chain; Step 73: The parameter validator determines whether the verification parameters are correct. If the determination is correct, proceed to step 74; if the determination is incorrect, the process ends. Step 74: The data validator checks if the queue exists. If it does, proceed to step 75; otherwise, end. Step 75: The rate limiting checker checks whether the interface limit threshold is triggered. If it is, proceed to step 76; if it is not, end. Step 76: The idempotency checker checks if the device is idempotent. If it is, proceed to step 77; otherwise, end the process. Step 77: Lock the queued object using tryLock; Step 78: Determine whether the locking was successful. If the determination is yes, proceed to step 710; if the determination is no, proceed to step 79. Step 79: Wait n seconds for the lock to complete step 78; Step 710: Query queue information, then execute step 714, and at the same time determine whether there is queue information. If the determination is yes, execute step 712; if the determination is no, execute step 711. Step 711: Add queuing information to MySQL, update queuing information to Redie, and then execute steps 712 and 713; Step 712: Return the result; The result returned is the queue status; Step 713: Determine whether the update was successful. If it is successful, proceed to step 713. If it is unsuccessful, proceed to step 714 after entering the compensation program in the queue management module. Step 714: Output and store the queue information; The output queue information includes the user's queue number, queue position, and estimated waiting time; Furthermore, the specific steps for step 9 are as follows: Step 91: Receive the machine inspection command, perform scheduling once every 1 second, then enter the scheduling management program in the community server management module, and then scan all the machines to be inspected; Step 92: Determine if the currently viewed machine field is idle. If yes, proceed to step 93; if no, proceed to step 94. Step 93: Register the registration information to the monitoring queue, update the currently viewed machine to the idle and allocable state, and proceed to step 99; Step 94: Determine if there is a queue. If yes, proceed to step 96; if no, proceed to step 95. Step 95: Determine if there is a dequeue situation. If yes, update the current viewing machine to the released / allocable state and proceed to step 99. If no, maintain the current state and do not perform any operation. Step 96: Enter the monitoring queue and determine if the waiting time has expired. If it has, query the queue information to be allocated and then execute steps 99 and 99. If it has not, execute step 97. Step 97: Continue to wait, then proceed to step 96; Step 99: Output the queue of machines to be assigned for inspection; Step 99: Update the machine status to be monitored, then determine whether the machine is powered on. If it is powered on, proceed to step 911; if it is not powered on, proceed to step 910. Step 910: Check the machine's power-on status and determine whether a connection has been established with the monitoring program of the community server management module. If the connection is established, proceed with steps 10 and 911. If the connection is not established, report the abnormal information. Step 911: Check the machine update status. The monitoring program of the community server management module establishes a webSocket dialogue between the user and the program, and then executes steps 912 and 913. Step 912: Send RocketMQ to the queue management module and determine if the sending was successful. If it is successful, update the queue management module's queuing system to the completed state. If it is not successful, retry the compensation program in the queue management module. After the compensation is completed, update the queue management module's queuing system to the completed state. Step 913: The heartbeat detection program sends a heartbeat packet to the inspection machine every 5 seconds, enters a session state, and then executes steps 914 and 915; Step 914: Determine whether the heartbeat response time exceeds the set threshold. If yes, mark the session as expired, update the heartbeat data, and proceed to step 915. If no, the session is in a renewed state, update the heartbeat data, and proceed to step 915. Step 915: Output heart rate data; Furthermore, the specific steps in step 710 are as follows: The specific steps for step 710 are as follows: Step 7101: Query queue information, execute step 714, exit the inspection program in the event management module, listen for exit events, and report exit events; Step 7102: Query and view session data; Step 7103: Determine whether the session data has expired. If yes, proceed to step 7104; if no, proceed to step 71010. Step 7104: Clear the token from the view session data; Step 7105: Clear the local session again; Step 7106: Clear the user view session data cache; Step 7107: Query user queue data; Step 7108: Determine if there is a queue. If yes, proceed to step 7109; if no, proceed to step 71010. Step 7109: Call the queue management module's queue system clear command to reset the number of people in the queue and reorder the queue counts, then execute step 712; Step 71010: End, then proceed to step 711.
[0017] Beneficial effects: This invention uses a distributed microservice architecture, a priority queue management mechanism, and a low-latency communication protocol as its core to support distributed scheduling and processing of high-concurrency detection requests; it achieves dynamic priority sorting based on the value of the jewelry and user attributes, improving resource utilization efficiency; it significantly reduces the latency of result return through long-connection real-time communication and message queue peak shaving and valley filling mechanisms; and it improves the storage and retrieval performance and stability of detection data by adopting database sharding and caching strategies. Attached Figure Description
[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.
[0019] Figure 1 This is a system architecture diagram of the present invention; Figure 2 This is the main flowchart of the present invention; Figure 3 This is a functional diagram of the queue management module of the present invention; Figure 4 This is the main flowchart of the queue management module of the present invention; Figure 5 This is the main flowchart of the community server management module of the present invention; Figure 6 This is a flowchart illustrating the data communication process of the event management module's operating environment in this invention. Figure 7 This is a view of the queue presentation diagram of the present invention; Figure 8 This is a normal viewing diagram of the present invention. Detailed Implementation
[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.
[0021] The present invention will be further described below with reference to embodiments.
[0022] Example 1: Please refer to Figure 1-3 A cloud-based virtual item verification system for a massive user base, including: It includes, from top to bottom, the application layer, access layer, business layer, service layer, storage layer, and environment layer; Application layer: Used to provide multi-terminal access for end users, allowing users to initiate virtual accessory detection requests through any terminal; Access layer: Used to uniformly receive virtual item detection requests from different terminals and forward the virtual item detection requests to the subsequent business layer; Business layer: Used for user management, queue management, community server management, event management, and exception monitoring management; Service layer: Provides specific service functions to support the business layer; The service functions include user services, event services, queue services, and machine management services; Storage layer: used to store structured data, cached data, message tasks, version code, and large-scale file resources respectively; Environment layer: Provides the hardware and cloud infrastructure support required for operation, allowing users to initiate virtual item detection requests through any terminal.
[0023] With a distributed microservice architecture, priority queue management mechanism, and low-latency communication protocol as its core, it supports distributed scheduling and processing of high-concurrency detection requests; it implements dynamic priority sorting based on the value of the jewelry and user attributes to improve resource utilization efficiency; it significantly reduces the latency of result return through long-connection real-time communication and message queue peak shaving and valley filling mechanism; and it adopts database sharding and caching strategies to improve the storage and retrieval performance and stability of detection data.
[0024] This invention significantly improves throughput: thanks to distributed queue scheduling and parallel execution of multiple inspection machines, the system can support millions of daily inspection requests.
[0025] This invention reduces latency: WebSocket real-time communication combined with asynchronous message queue distribution reduces the latency of detection result return by more than 50% compared to traditional HTTP polling.
[0026] This invention improves resource utilization: the priority queue ensures that high-value items are detected first, reducing the waiting time for high-value tasks.
[0027] The system of this invention has strong scalability: it supports dynamically adding inspection machine nodes and database shards without downtime maintenance.
[0028] This invention optimizes the user experience by making the detection process transparent and providing real-time feedback, significantly improving user engagement and satisfaction.
[0029] The application layer includes mobile applications (APP), PC clients, and WeChat / Alipay mini-program clients.
[0030] The access layer acts as a gateway, uniformly receiving virtual item detection requests from different terminals, performing functions such as authentication, routing, load balancing, and protocol conversion, and forwarding the virtual item detection requests to the subsequent business layer for processing.
[0031] The business layer includes a user management module, a queue management module, a community server management module, an event management module, and an exception listening management module. The user management module is used to maintain user account information, permission levels, and usage records; The queue management module is used to control the queuing of detection requests to prevent resource overload; The community server management module is used to connect to and manage third-party community or server resources; The event management module is used to manage the triggered events in the detection process; The anomaly monitoring and management module is used to monitor abnormal situations during the detection process in real time and trigger alarms.
[0032] The service layer includes a user service module, an event service module, a queue service module, and a machine management service module. The user service module is used for authentication, signature, and login status determination. The event service module is used for event registration, event listening, and callback execution; The queue service module is used for scene management, instruction type identification, instruction strategy configuration, ranking query, total queue count statistics, and data caching. The machine management service module is used for functions such as machine initialization, status detection, command issuance, manual annotation, machine startup and release, and realizes dynamic scheduling of testing resources.
[0033] The storage layer includes a MySQL database, a Redis cache, a RocketMQ message queue, a GitLab code repository, and OSS object storage.
[0034] It is used to store structured data, cached data, message tasks, version code, and large-scale file resources respectively.
[0035] The environment layer includes virtual machines, Alibaba Cloud servers, Huawei Cloud servers, and private cloud deployment solutions to support high availability and elastic scaling of the system.
[0036] A detection method for a cloud-based virtual item detection system for a massive user base includes the following steps: Step 1: Start the application layer and determine whether the detection program in the application layer has been moved to the background. If the determination is yes, proceed to step 2; if the determination is no, proceed to step 3. Step 2: Determine if the user is in a background queue. If yes, proceed to step 7. If no, it means the user is entering the detection program in the application layer for the first time and there is no queue information. Proceed to step 3. Step 3: Open the detection program within the application layer and register the event; Registration events include client-side events such as "user login event", "queue number allocation event", and "check completion event"; The detection program within the application layer is a detection startup module that runs locally on the client side. It is mainly used to launch the detection logic and connect to the backend interface. Step 4: Determine if the user is logged in. If yes, proceed to step 5. If no, prompt the user to log in and proceed to step 5. Step 5: Determine if the check queue has reached its limit. If it is, display a message indicating that the queue is overcrowded, and the user can cancel the check or proceed to Step 6. If it is not, proceed to Step 6. Step 6: Determine if the queue is already open. If yes, proceed to step 8; otherwise, proceed to step 7. Step 7: Enter the queue management module, take a number and queue, then proceed to Step 8; This section introduces a business verification mechanism for the number-taking process: it checks whether the user already exists in the queuing system of the queue management module. If the verification result is yes, the user is not re-queued, but is directly returned to the current position in the queue (i.e., the ZSet rank value and the remaining number of people waiting). If the verification result is no, it means that the user has not yet queued, the system generates a new queue number for him / her, and writes the user information into the Redis ZSet queue according to timestamp or priority to ensure orderly queuing.
[0037] Step 8: Determine if it can be viewed. If yes, proceed to step 9. If no, prompt the user "System busy, please try again later" and end the current process. Step 9: Allocate resources to the detection machine and determine whether a connection has been established with the monitoring program of the community server management module. If the determination is yes, proceed to step 10; if the determination is no, report the abnormal information. Step 10: Send detection information, then determine whether the number of times it is sent is greater than the set threshold. If the determination is yes, enter the waiting queue; if the determination is no, return to the detection screen.
[0038] Figure 4 The specific description is as follows: Step 71: Receive the queuing instruction "Queue Name + Instruction Type + Token" and encapsulate the upper limit text of the queuing instruction (QueueCommand Conet). Step 72: Enter the queuing system execution program in the queue management module, and then enter the checker responsibility chain; Step 73: The parameter validator determines whether the verification parameters are correct. If the determination is correct, proceed to step 74; if the determination is incorrect, the process ends. Step 74: The data validator checks if the queue exists. If it does, proceed to step 75; otherwise, end. Step 75: The rate limiting checker checks whether the interface limit threshold is triggered. If it is, proceed to step 76; if it is not, end. Step 76: The idempotency checker checks if the device is idempotent. If it is, proceed to step 77; otherwise, end the process. Step 77: Lock the queued object using tryLock; Step 78: Determine whether the locking was successful. If the determination is yes, proceed to step 710; if the determination is no, proceed to step 79. Step 79: Wait n seconds for the lock to complete step 78; n seconds is typically configured by the business logic; Step 710: Query queue information, then execute step 714, and at the same time determine whether there is queue information. If the determination is yes, execute step 712; if the determination is no, execute step 711. Step 711: Add queuing information to MySQL, update queuing information to Redie, and then execute steps 712 and 713; Step 712: Return the result; The result is a return of the queue status; The returned queue status includes the queue number, queue position, estimated waiting time, or a failure message, allowing the caller to decide whether to continue waiting or prompt the user for further action. Step 713: Determine whether the update was successful. If it is successful, proceed to step 713. If it is unsuccessful, proceed to step 714 after entering the compensation program in the queue management module. The compensation procedure within the queue management module specifically refers to situations where a Redis update fails, but the data has already been stored in MySQL, requiring data consistency repair; then retrying the Redis update, or triggering an asynchronous repair task via message notification to ensure data consistency between MySQL and Redis; Step 714: Output and store the queue information; The output queue information includes the user's queue number, queue position, and estimated waiting time; Figure 5 The specific description is as follows: Step 91: Receive the machine inspection command, perform scheduling once every 1 second, then enter the scheduling management program in the community server management module, and then scan all the machines to be inspected; Step 92: Determine if the currently viewed machine field is idle. If yes, proceed to step 93; if no, proceed to step 94. Step 93: Register the registration information to the monitoring queue, update the currently viewed machine to the idle and allocable state, and proceed to step 99; Step 94: Determine if there is a queue. If yes, proceed to step 96; if no, proceed to step 95. Step 95: Determine if there is a dequeue situation. If yes, update the current viewing machine to the released / allocable state and proceed to step 99. If no, maintain the current state and do not perform any operation. Step 96: Enter the monitoring queue and determine if the waiting time has expired. If it has, query the queue information to be allocated and then execute steps 99 and 99. If it has not, execute step 97. Step 97: Continue to wait, then proceed to step 96; Step 99: Output the queue of machines to be assigned for inspection; Step 99: Update the machine status to be monitored, then determine whether the machine is powered on. If it is powered on, proceed to step 911; if it is not powered on, proceed to step 910. Step 910: Check the machine's power-on status and determine whether a connection has been established with the monitoring program of the community server management module. If the connection is established, proceed with steps 10 and 911. If the connection is not established, report the abnormal information. Step 911: Check the machine update status. The monitoring program of the community server management module establishes a webSocket dialogue between the user and the program, and then executes steps 912 and 913. Step 912: Send RocketMQ to the queue management module and determine if the sending was successful. If it is successful, update the queue management module's queuing system to the completed state. If it is not successful, retry the compensation program in the queue management module. After the compensation is completed, update the queue management module's queuing system to the completed state. Update the queuing system in the queue management module to a completed state: mark the user's task as assigned to a machine, release the queue occupation, ensure the accuracy of the number of people in the queue, and avoid duplicate queuing.
[0039] Step 913: The heartbeat detection program sends a heartbeat packet to the inspection machine every 5 seconds, enters a session state, and then executes steps 914 and 915; Step 914: Determine whether the heartbeat response time exceeds the set threshold. If yes, mark the session as expired, update the heartbeat data, and proceed to step 915. If no, the session is in a renewed state, update the heartbeat data, and proceed to step 915. Step 915: Output heart rate data; The heartbeat detection program sends a heartbeat packet to the monitored machine every 5 seconds to maintain the session state. The heartbeat data is recorded in the monitoring system / log and used to determine the health of the machine and whether it needs to be removed or rescheduled.
[0040] The specific steps for step 710 are as follows: Step 7101: Query queue information, execute step 714, exit the inspection program in the event management module, listen for exit events, and report exit events; Exit events include user-initiated exit, task completion, abnormal exit, and heartbeat timeout; Step 7102: Query and view session data; Retrieve the user's current session information from Redis or MySQL, with Redis serving as a real-time cache and MySQL as persistent storage; Step 7103: Determine whether the session data has expired. If yes, proceed to step 7104; if no, proceed to step 71010. Step 7104: Clear the token from the view session data; Step 7105: Clear the local session again; Step 7106: Clear the user view session data cache; Step 7107: Query user queue data; Step 7108: Determine if there is a queue. If yes, proceed to step 7109; if no, proceed to step 71010. Step 7109: Call the queue management module's queue system clear command to reset the number of people in the queue and reorder the queue counts, then execute step 712; Because system anomalies or exit events may occur during a user's initial queuing, failing to synchronize with Redis and MySQL in a timely manner, the user may retain their previous queuing state upon re-entry. Executing the `Clear` command ensures that the system forcibly triggers a new queuing sequence upon re-entry, maintaining queue fairness and consistency. Specifically, this includes clearing residual data in the Redis queue; clearing stored data in the MySQL queue list; resetting the user's queuing count; resetting the user's queue position number; and releasing any remaining lock objects or resources.
[0041] Step 71010: End, then proceed to step 711.
[0042] Queue name + instruction type + specific definition in token Queue name: A unique identifier for the target queue (such as order_queue, message_queue), used to specify the queue to which the instruction should enter; Command type: The specific operation of the command (such as enqueue, dequeue, clear). token: An authentication token used to verify whether the entity sending the command has the authority to operate the queue.
[0043] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims
1. A cloud-based virtual accessory detection system for a massive user base, characterized in that: include: It includes, from top to bottom, the application layer, access layer, business layer, service layer, storage layer, and environment layer; Application layer: Used to provide multi-terminal access for end users, allowing users to initiate virtual accessory detection requests through any terminal; Access layer: Used to uniformly receive virtual item detection requests from different terminals and forward the virtual item detection requests to the subsequent business layer; Business layer: Used for user management, queue management, community server management, event management, and exception monitoring management; Service layer: Provides specific service functions to support the business layer; The service functions include user services, event services, queue services, and machine management services; Storage layer: used to store structured data, cached data, message tasks, version code, and large-scale file resources respectively; Environment layer: Provides the hardware and cloud infrastructure support required for operation, allowing users to initiate virtual item detection requests through any terminal.
2. The cloud-based virtual accessory detection system for a massive user base as described in claim 1, characterized in that, The application layer includes mobile applications (APP), PC clients, and WeChat / Alipay mini-program clients.
3. The cloud-based virtual accessory detection system for a massive user base as described in claim 2, characterized in that, The access layer acts as a gateway, uniformly receiving virtual item detection requests from different terminals, performing functions such as authentication, routing, load balancing, and protocol conversion, and forwarding the virtual item detection requests to the subsequent business layer for processing.
4. The cloud-based virtual accessory detection system for a massive user base as described in claim 3, characterized in that, The business layer includes a user management module, a queue management module, a community server management module, an event management module, and an exception listening management module. The user management module is used to maintain user account information, permission levels, and usage records; The queue management module is used to control the queuing of detection requests to prevent resource overload; The community server management module is used to connect to and manage third-party community or server resources; The event management module is used to manage the triggered events in the detection process; The anomaly monitoring and management module is used to monitor abnormal situations during the detection process in real time and trigger alarms.
5. The cloud-based virtual accessory detection system for a massive user base as described in claim 4, characterized in that, The service layer includes a user service module, an event service module, a queue service module, and a machine management service module. The user service module is used for authentication, signature, and login status determination. The event service module is used for event registration, event listening, and callback execution; The queue service module is used for scene management, instruction type identification, instruction strategy configuration, ranking query, total queue count statistics, and data caching. The machine management service module is used for functions such as machine initialization, status detection, command issuance, manual annotation, machine startup and release, and realizes dynamic scheduling of testing resources.
6. The cloud-based virtual accessory detection system for a massive user base as described in claim 5, characterized in that, The storage layer includes a MySQL database, a Redis cache, a RocketMQ message queue, a GitLab code repository, and OSS object storage.
7. A detection method for a cloud-based virtual accessory detection system for a massive user base as described in claim 6, characterized in that, Includes the following steps: Step 1: Start the application layer and determine whether the detection program in the application layer has been moved to the background. If the determination is yes, proceed to step 2; if the determination is no, proceed to step 3. Step 2: Next, determine if it is in the background queue. If yes, proceed to step 7; if no, proceed to step 3. Step 3: Open the detection program within the application layer and register the event; Step 4: Determine if the user is logged in. If yes, proceed to step 5. If no, prompt the user to log in and proceed to step 5. Step 5: Determine if the check queue has reached its limit. If it is, display a message indicating that the queue is overcrowded, and the user can cancel the check or proceed to Step 6. If it is not, proceed to Step 6. Step 6: Determine if the queue is already open. If yes, proceed to step 8; otherwise, proceed to step 7. Step 7: Enter the queue management module, take a number and queue, then proceed to Step 8; Step 8: Determine if it can be viewed. If yes, proceed to step 9. If no, prompt the user "System busy, please try again later" and end the current process. Step 9: Allocate resources to the detection machine and determine whether a connection has been established with the monitoring program of the community server management module. If the determination is yes, proceed to step 10; if the determination is no, report the abnormal information. Step 10: Send detection information, then determine whether the number of times it is sent is greater than the set threshold. If the determination is yes, enter the waiting queue; if the determination is no, return to the detection screen.
8. The detection method according to claim 7, characterized in that, The specific steps for step 7 are as follows: Step 71: Receive the queuing instruction "queue name + instruction type + token" and encapsulate the upper limit text of the queuing instruction; Step 72: Enter the queuing system execution program in the queue management module, and then enter the checker responsibility chain; Step 73: The parameter validator determines whether the verification parameters are correct. If the determination is correct, proceed to step 74; if the determination is incorrect, the process ends. Step 74: The data validator checks if the queue exists. If it does, proceed to step 75; otherwise, end. Step 75: The rate limiting checker checks whether the interface limit threshold is triggered. If it is, proceed to step 76; if it is not, end. Step 76: The idempotency checker checks if the device is idempotent. If it is, proceed to step 77; otherwise, end the process. Step 77: Lock the queued object using tryLock; Step 78: Determine whether the locking was successful. If the determination is yes, proceed to step 710; if the determination is no, proceed to step 79. Step 79: Wait n seconds for the lock to complete step 78; Step 710: Query queue information, then execute step 714, and at the same time determine whether there is queue information. If the determination is yes, execute step 712; if the determination is no, execute step 711. Step 711: Add queuing information to MySQL, update queuing information to Redie, and then execute steps 712 and 713; Step 712: Return the result; The result returned is the queue status; Step 713: Determine whether the update was successful. If it is successful, proceed to step 713. If it is unsuccessful, proceed to step 714 after entering the compensation program in the queue management module. Step 714: Output queue information and store it.
9. The detection method according to claim 8, characterized in that, The specific steps for step 9 are as follows: Step 91: Receive the machine inspection command, perform scheduling once every 1 second, then enter the scheduling management program in the community server management module, and then scan all the machines to be inspected; Step 92: Determine if the currently viewed machine field is idle. If yes, proceed to step 93; if no, proceed to step 94. Step 93: Register the registration information to the monitoring queue, update the currently viewed machine to the idle and allocable state, and proceed to step 99; Step 94: Determine if there is a queue. If yes, proceed to step 96; if no, proceed to step 95. Step 95: Determine if there is a dequeue situation. If yes, update the current viewing machine to the released / allocable state and proceed to step 99. If no, maintain the current state and do not perform any operation. Step 96: Enter the monitoring queue and determine if the waiting time has expired. If it has, query the queue information to be allocated and then execute steps 99 and 99. If it has not, execute step 97. Step 97: Continue to wait, then proceed to step 96; Step 99: Output the queue of machines to be assigned for inspection; Step 99: Update the machine status to be monitored, then determine whether the machine is powered on. If it is powered on, proceed to step 911; if it is not powered on, proceed to step 910. Step 910: Check the machine's power-on status and determine whether a connection has been established with the monitoring program of the community server management module. If the connection is established, proceed with steps 10 and 911. If the connection is not established, report the abnormal information. Step 911: Check the machine update status. The monitoring program of the community server management module establishes a webSocket dialogue between the user and the program, and then executes steps 912 and 913. Step 912: Send RocketMQ to the queue management module and determine if the sending was successful. If it is successful, update the queue management module's queuing system to the completed state. If it is not successful, retry the compensation program in the queue management module. After the compensation is completed, update the queue management module's queuing system to the completed state. Step 913: The heartbeat detection program sends a heartbeat packet to the inspection machine every 5 seconds, enters a session state, and then executes steps 914 and 915; Step 914: Determine whether the heartbeat response time exceeds the set threshold. If yes, mark the session as expired, update the heartbeat data, and proceed to step 915. If no, the session is in a renewed state, update the heartbeat data, and proceed to step 915. Step 915: Output heart rate data.
10. The detection method according to claim 9, characterized in that, The specific steps for step 710 are as follows: The specific steps for step 710 are as follows: Step 7101: Query queue information, execute step 714, exit the inspection program in the event management module, listen for exit events, and report exit events; Step 7102: Query and view session data; Step 7103: Determine whether the session data has expired. If yes, proceed to step 7104; if no, proceed to step 71010. Step 7104: Clear the token from the view session data; Step 7105: Clear the local session again; Step 7106: Clear the user view session data cache; Step 7107: Query user queue data; Step 7108: Determine if there is a queue. If yes, proceed to step 7109; if no, proceed to step 71010. Step 7109: Call the queue management module's queue system clear command to reset the number of people in the queue and reorder the queue counts, then execute step 712; Step 71010: End, then proceed to step 711.