Batch case operation verification system based on Redis

Abstract

The invention provides a batch case operation verification system based on Redis, and relates to the technical field of data processing and storage, and the system comprises a Redis server used for storing verified case IDs and related information in a Redis database, an asynchronous task processing module used for obtaining a to-be-processed case ID list from Redis, constructing parameters required by batch operation, and sending the parameters to the Redis server. An asynchronous task is submitted; and the batch operation execution module is used for extracting tasks from the asynchronous task queue to execute batch operation, and processing the tasks according to a success or failure result after the operation. The problems of performance bottleneck, poor expansibility and complicated transaction management of the existing relational database in a high-concurrency environment are solved; according to the system, the high performance, high expandability and atomic operation characteristics of Redis are utilized, asynchronous task processing and priority queues are combined, an efficient batch case operation solution is provided, and the data processing efficiency and the expandability of the system are remarkably improved.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing and storage, and in particular to a verification system for batch case operations based on Redis. Background Art

[0002] In the existing judicial industry, batch case operations usually rely on relational databases for processing, such as MySQL and PostgreSQL. These operations include batch insertion, updating, and deletion of data. In order to ensure data consistency and atomicity of operations, existing solutions usually rely on the database's transaction mechanism. However, when faced with high concurrency and large amounts of data processing requirements, batch operation solutions based on relational databases have the following major disadvantages:

[0003] 1. As concurrent requests increase, the response time and throughput of relational databases will decrease significantly. This is mainly because the database connection pool and resource management become complicated, resulting in system performance degradation under high load. In a high-concurrency environment, multiple requests accessing the database at the same time may cause lock competition and resource contention, further affecting performance.

[0004] 2. Relational databases have limitations in scalability. It is difficult to cope with large-scale data processing needs through simple horizontal expansion. Horizontal expansion usually requires complex sharding and load balancing mechanisms, which increases system complexity and maintenance costs.

[0005] 3. Relational databases rely on complex transaction management mechanisms to ensure data consistency. Transaction management involves locking mechanisms, rollback logs, etc. These mechanisms will lead to performance degradation in high-concurrency environments and increase the complexity of the system. The transaction management mechanism itself will generate additional performance overhead, especially in high-concurrency environments. Frequent transaction management and locking operations will significantly reduce system performance.

[0006] Therefore, it is necessary to provide a new Redis-based batch case operation verification system to solve the above technical problems. Summary of the invention

[0007] In order to solve the above technical problems, the present invention provides a verification system for batch case operations based on Redis, aiming to solve the problems of performance bottlenecks, poor scalability and complex transaction management of batch case operations in the prior art, and provide a batch case operation verification solution based on Redis to improve data processing efficiency and system scalability.

[0008] The verification system for batch case operations based on Redis provided by the present invention includes:

[0009] The client is used to initiate batch case operation requests to the Web server and receive the operation results returned by the batch operation execution module;

[0010] Web server, used to receive and process client requests and perform user role and case status verification;

[0011] Redis server, used to store the verified case ID and related information in the Redis database;

[0012] The asynchronous task processing module is used to obtain the list of case IDs to be processed from Redis, build the parameters required for batch operations, and submit asynchronous tasks;

[0013] The batch operation execution module takes out tasks from the asynchronous task queue to execute batch operations and processes them according to the success or failure results after the operation.

[0014] Furthermore, the Redis server also includes setting up at least three servers with two adjacent nodes alternately built as master and slave, expanding the number of existing cluster nodes to an odd number, building Redis nodes and starting the management agent, verifying the existing cluster and the newly added nodes, adding the new master node to the current cluster, configuring the corresponding slave node for the newly added master node, and redistributing the slots of the entire Redis cluster so that the data is evenly distributed to all master nodes.

[0015] Furthermore, the Web server includes a user role verification module and a case status verification module. The user role verification module is used to verify the user role and execute corresponding verification logic according to different roles, and the case status verification module is used to verify the case status.

[0016] Furthermore, in the Redis server, a unique key is created for each verified case ID, and the case-related information is used as the value corresponding to the key and stored in Redis in the form of a hash table.

[0017] Furthermore, in the asynchronous task processing module, a corresponding batch operation parameter set is prepared according to the list of case IDs to be processed, and the constructed batch operation parameters are submitted to the batch operation execution module as an asynchronous task.

[0018] Furthermore, by setting priority queue support, tasks can be sorted and processed according to their importance and urgency.

[0019] Furthermore, the batch operation execution module takes out tasks from the asynchronous task queue through pipeline technology to execute batch operations, and ensures data consistency through Lua scripts.

[0020] Furthermore, in the batch operation execution module, when an error occurs, a rollback mechanism is triggered to restore to the state before the operation.

[0021] Compared with the related art, the verification system for batch case operations based on Redis provided by the present invention has the following beneficial effects:

[0022] The batch case operation verification system based on Redis solves the performance bottleneck, poor scalability and complex transaction management problems of existing relational databases in a high-concurrency environment by introducing the batch case operation verification system based on Redis. The system utilizes the high performance, high scalability and atomic operation characteristics of Redis, combines asynchronous task processing and priority queues, and provides an efficient batch case operation solution, which significantly improves data processing efficiency and system scalability. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 A system block diagram of a verification system for batch case operations based on Redis provided by the present invention;

[0024] Figure 2 A system block diagram of the extended cluster mode provided by the present invention;

[0025] Figure 3 This is a flowchart of the extended cluster mode provided by the present invention. DETAILED DESCRIPTION

[0026] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0027] Please refer to Figure 1 , Figure 2 as well as Figure 3 , Figure 1 A system block diagram of a verification system for batch case operations based on Redis provided by the present invention; Figure 2 A system block diagram of the extended cluster mode provided by the present invention; Figure 3 This is a flowchart of the extended cluster mode provided by the present invention.

[0028] In the specific implementation process, Figures 1 to 3 As shown, the verification system for batch case operations based on Redis provided by the present invention includes:

[0029] The client is used to initiate batch case operation requests to the Web server and receive the operation results returned by the batch operation execution module. The specific operations are as follows:

[0030] 1. Request preparation:

[0031] Authentication information: The client needs to prepare the user's authentication information, such as API key, JWT token, etc., which is passed to the server through the HTTP header or part of the request body;

[0032] Request body content: Construct a request body that contains all necessary information, including the operation type, case ID list, and other relevant data. The operation type may be update status, add notes, etc. The case ID list is the unique identifier of all cases to be batch operated. Other relevant data may also need to provide additional data, such as new case status, additional notes, etc., depending on the specific operation requirements.

[0033] 2. Send the request:

[0034] Select HTTP method: For batch operations, use the POST method to send data to the server. POST requests can carry a large amount of data and will not be cached;

[0035] Set URL: Determine the API endpoint address provided by the web server;

[0036] Set HTTP headers: Make sure the necessary information is included in the request header, such as Content-Type: application / json to specify that the request body format is JSON, and the Authorization field to contain authentication information;

[0037] Send request: Send the request to the server via HTTP / HTTPS protocol. This step can be completed through browser developer tools, Postman or any client tool that supports HTTP requests;

[0038] 3. Receive response:

[0039] Processing response codes: Receive HTTP response codes from the web server. The common successful response code is 200OK, indicating that the request has been successfully processed; other response codes may indicate different error conditions;

[0040] Parse the response body: Extract the information returned by the server from the response body, which is usually a JSON object containing the results and status update details of each case operation;

[0041] Display results: Based on the information returned by the server, the client can display corresponding messages to the user, such as "Operation successful", "Partial failure", etc., and list in detail which cases were successfully operated, which failed, and the reasons;

[0042] 4. Error handling:

[0043] If a non-200 response code is received, the client SHOULD check the error information in the response body and take appropriate action, which may include retrying the request, prompting the user to enter correct information, or contacting technical support;

[0044] 5. Safety considerations:

[0045] Throughout the process, ensure that all sensitive information is transmitted encrypted, use HTTPS instead of HTTP to ensure data security, and for authentication information, ensure that they are properly protected during transmission to avoid leakage.

[0046] In summary, this step describes the process of how the client interacts with the Web server to perform batch case operations.

[0047] The Web server is used to receive and process client requests and perform user role and case status verification. The Web server includes a user role verification module and a case status verification module:

[0048] The user role verification module is used to verify the user role and execute the corresponding verification logic according to different roles. It receives the request sent by the client, parses the identity information contained in the request, calls the authentication service or queries the database to verify the user's role, and decides whether to allow subsequent operations based on the user role.

[0049] The case status verification module is used to verify the case status, check all case IDs involved in the request, query the database or cache to obtain the current status of these cases, and verify whether the status meets expectations, such as the case must be in an open state to be modified. The verification result is returned to the client or passed to the next step of processing.

[0050] Detailed explanation of the web server processing flow

[0051] 1. Receive and parse client requests:

[0052] Receiving requests: The Web server receives batch case operation requests sent by the client through the HTTP / HTTPS protocol;

[0053] Parse the request: Extract necessary information from the request, including authentication information, operation type, case ID list, and other relevant data.

[0054] 2. User role verification module:

[0055] Identity information parsing: Extract and parse the authentication information in the request, such as JWT tokens or API keys. If a JWT token is used, its signature and expiration time need to be verified to ensure the validity of the token.

[0056] Call the authentication service or query the database: Use the identity information parsed by the OAuth service or directly query the local database to obtain the user's detailed information, especially the user's role information. The authentication service or database returns the user's permission level, such as administrator, ordinary user, read-only user, etc.

[0057] Role verification logic: According to the user's role information, the corresponding verification logic is executed. For example, administrators can perform all types of batch operations, ordinary users can only modify cases in a specific status, and read-only users are not allowed to perform any modification operations. If the user does not have sufficient permissions to perform the requested operation, an error response is immediately returned to the client and subsequent processing is terminated. If the user has the corresponding permissions, the next step of processing is continued.

[0058] 3. Case status verification module:

[0059] Check case ID list: extract all case IDs from the request;

[0060] Query the database or cache: query the database or Redis cache to obtain the current status information of these cases. If Redis cache is used, performance can be significantly improved, especially in high concurrency situations, to obtain the status of each case, such as "open", "closed", "processing", etc.;

[0061] Status verification: Verify whether the status of each case meets expectations based on the requested operation type. For example, if the request is to update the case status, only cases in the "open" status can be modified. If the request is to add a note, operations may be allowed in any status. For cases that do not meet the expected status, record the specific reasons and prepare to return them to the client.

[0062] Return verification results: If all cases meet the expected status, pass the verification results to the next step of processing. If there are cases that do not meet the expected status, return a response containing detailed error information to the client.

[0063] In summary, through this double-layer verification mechanism, the Web server can effectively protect the system from unauthorized access and illegal operations, while providing detailed feedback information so that the client can take appropriate measures.

[0064] The Redis server is used to store the verified case ID and related information in the Redis database. The specific operations are as follows:

[0065] 1. Store the verified case ID and related information:

[0066] Data preparation: After the user role and case status are verified, the Web server will prepare the case information that needs to be stored in Redis, which usually includes the case ID and related detailed information.

[0067] 2. Create a unique key:

[0068] Key design: To ensure the uniqueness of each case ID and facilitate subsequent queries and operations, the following format can be used to design the key: case:<case_id> , this naming convention helps to quickly locate and manage case-specific data in Redis.

[0069] 3.Store case information in hash table format:

[0070] Hash table structure: In Redis, the value corresponding to each case ID will be stored in the form of a hash table. The hash table is an efficient data structure that allows you to store multiple field and value pairs.

[0071] 4. Storage process:

[0072] Connect to Redis: The Web server or a dedicated service component establishes a connection with the Redis server;

[0073] Set key-value pairs: Use the HSET command to store case information in Redis;

[0074] Batch storage: If you need to store information of multiple cases in batches, you can loop through the above steps or use Redis batch operation commands, such as MULTI / EXEC, to improve efficiency.

[0075] 5. Data consistency:

[0076] Atomic operations: Ensure that all write operations are atomic to avoid concurrency issues. You can use Redis transaction mechanisms to ensure data consistency, such as WATCH, MULTI, and EXEC;

[0077] Expiration time: To prevent the cache data from growing indefinitely, you can set a reasonable expiration time for each case key, such as using the EXPIRE command, which helps to automatically clean up data that is no longer needed.

[0078] In summary, through the above methods, the Redis server can efficiently store and retrieve case information and support fast response in high-concurrency scenarios.

[0079] The three cluster modes of Redis include master-slave mode, sentinel mode and cluster mode. The cluster mode is a mode that groups multiple node Redis instances into a cluster and uses the consistent hashing principle to ensure the uniqueness of key values ​​and evenly distribute data to each master node. In this mode, the client can store and read data by interacting with any node in the cluster. In this mode, memory resources can be used to the maximum extent, and resources can be expanded online. In addition, the number of slave nodes can be set as needed to switch between master and slave nodes.

[0080] like Figure 2 as well as Figure 3 As shown in the figure, by developing a management agent, all nodes are managed on the management platform, and the agent interface is used to call the redis-cli command tool provided by Redis on the operating system to gradually expand the master and slave nodes, migrate and redistribute the data slots of the newly added nodes. The detailed process is as follows:

[0081] 1. Manage the Redis cluster:

[0082] Server management is to manage some users, permissions and resource information of application servers so as to centrally operate from a third-party platform. The agent developed in Go language performs command operations on remote servers through interface calls to achieve management. Since Redis clusters are widely used in enterprises, a large number of Redis clusters are running in production. Through server management, the information of hundreds or thousands of clusters can be managed on a unified third-party platform for centralized management, which greatly facilitates batch operations.

[0083] The agent can be compiled into a binary package and run directly on the Linux operating system, and provide interface services to the outside in the form of command parameters. It can operate the managed servers in the form of functional jobs in the Blue Whale and automated operation and maintenance systems. The third-party system uses the Blue Whale platform.

[0084] 2. Cluster environment preparation:

[0085] Dynamically expand horizontally in the existing Redis cluster by setting up three servers, 192.168.1.1, 192.168.1.2, and 192.168.1.3. Each server is configured with 8C 16G, and the master and slave nodes are interactively built;

[0086] Because each server has two nodes that are alternately built as master and slave, the maximum memory that each server can use is 16 / 2G=8G, and the total available memory of the cluster is 24G. As the business scale increases, when the memory usage value exceeds 24G, the existing cluster needs to be expanded. If the original resources do not have resource bottlenecks such as CPU, IO and memory, the CPU and memory resources can be vertically expanded, and the memory can be adjusted from 16G to 32G. When the existing cluster resources have exceeded the upper limit and cannot be vertically expanded, it is necessary to adopt the solution of horizontal expansion of Redis cluster to expand the memory;

[0087] To maximize the high availability of the Redis cluster, the number of cluster nodes must be an odd number when expanding horizontally. Redis nodes need to be built on the two newly allocated 8C 16G servers. The configuration and number of nodes on each server should be consistent with the original cluster. Four Redis nodes should be built on the two servers, and the management agent should be started at the same time so that all process orchestration operations can be implemented through interface calls on the Blue Whale platform.

[0088] 3. Expand the master node:

[0089] After building the Redis node on the new server, you need to verify the connectivity and availability of the existing cluster and the newly added node through commands such as ping and tel-net, verify the status of the cluster in advance through cluster info, and then add the new master node to the current cluster;

[0090] In the BlueWhale platform, call the agent interface of any managed server in the cluster and pass in command parameters;

[0091] After the above results are returned successfully, pass the cluster nodes command parameters in the same way to check whether new server nodes have been added to the cluster nodes. Since no slots are allocated on the newly added master nodes, there will be no data distribution, but it will not affect the normal use of the original cluster.

[0092] 4. Expand the slave nodes corresponding to the master node:

[0093] To ensure high availability of the cluster and avoid the entire cluster becoming unavailable due to a single node exception, you need to configure the corresponding slave nodes for the newly added master node. The detailed operations are as follows:

[0094] In the BlueWhale platform, call the agent interface of any managed server in the cluster and pass in the command parameters:

[0095] After the interface returns successfully, it is preliminarily proved that the newly added slave node has been mounted on the newly added master node. At the same time, the cluster nodes command parameters are passed in the same way to confirm again whether the newly added slave node has been mounted on the newly added master node.

[0096] 5. The master node redistributes slots:

[0097] Through the above two steps, the newly added master and slave nodes have been added to the Redis cluster, but these two nodes have no slots allocated, and no business data will flow in. In order to ensure the even distribution of the entire cluster data, the slots of the entire Redis cluster need to be redistributed. This can ensure that the newly added nodes have data entering, and can also reduce the amount of data in the original cluster memory and ease IO. In the Blue Whale platform, call the agent interface of any managed server in the cluster and pass in the command parameters:

[0098] Through the above operations, the 16,838 slots in the entire cluster can be redistributed, and the data can be evenly distributed to all master nodes, alleviating the original node memory pressure and achieving the effect of horizontally expanding the cluster.

[0099] Repeat the above three steps to perform the same operations on the 192.168.1.5 server. Finally, the cluster can be horizontally expanded online on the two servers 192.168.1.4 and 192.168.1.5, and the entire memory can be expanded from 24G to 40G.

[0100] In summary, the online horizontal expansion method of Redis cluster based on management has many advantages such as convenience, efficiency, and security. Enterprises can complete online expansion at a lower cost, avoid resource and IO bottlenecks caused by vertical expansion, reduce misjudgments and misoperations caused by manual intervention, and improve the operation and maintenance service level.

[0101] The asynchronous task processing module is used to obtain the list of case IDs to be processed from Redis, build the parameters required for batch operations, and submit asynchronous tasks;

[0102] In the asynchronous task processing module, a corresponding batch operation parameter set is prepared according to the list of case IDs to be processed, and the constructed batch operation parameters are submitted to the batch operation execution module as an asynchronous task;

[0103] By setting the priority queue support, the constructed parameters are put into the priority queue as tasks, and the tasks are automatically sorted and processed according to their importance and urgency;

[0104] 1. Get the list of pending case IDs from Redis:

[0105] Connecting to Redis: The asynchronous task processing module first establishes a connection with the Redis server;

[0106] Get a list of case IDs: Use the Redis SMEMBERS or LRANGE command to get the pending case IDs from a specific collection or list. These case IDs are usually previously verified and stored in Redis.

[0107] Filtering and batching: Based on actual needs, the acquired case IDs can be filtered and processed in batches. For example, cases can be filtered based on their status, type, or other attributes, or a large number of case IDs can be divided into multiple small batches to improve processing efficiency.

[0108] 2. Build a batch operation parameter set:

[0109] Prepare parameters: For each case ID to be processed, build a corresponding parameter set based on specific operation requirements. The parameter set includes: case ID, operation type (such as updating status, adding notes, etc.), other related data (such as new status value, notes content, etc.), user information (such as user ID) and timestamp;

[0110] Parameter format: The parameter set should be an object in JSON format for easy subsequent processing.

[0111] 3. Submit asynchronous tasks:

[0112] Priority queue setting: The asynchronous task processing module requires a task queue system that supports priority. Common implementation methods include message queue systems such as RabbitMQ and Celery.

[0113] Task construction: put the constructed batch operation parameter set into the priority queue as a task. The task usually includes:

[0114] Task ID: uniquely identifies the task;

[0115] Task type: indicates the specific operation type of the task;

[0116] Parameter set: contains all necessary parameters;

[0117] Priority: Set priorities based on the importance and urgency of tasks;

[0118] Priority sorting: The priority queue will automatically sort tasks according to their priority. High-priority tasks will be processed first.

[0119] 4. Automatic sorting and processing:

[0120] Automatic sorting: When a new task is submitted to the queue, the queue will automatically sort it according to the priority of the task. High-priority tasks will be placed in front, and low-priority tasks will be placed at the back.

[0121] Task processing: The asynchronous task processing module will periodically take tasks from the priority queue and pass them to the batch operation execution module for processing. The processing order follows the priority order in the queue. The specific process example is as follows:

[0122] 1. Get the case ID list from Redis: Use the Redis command to get the case ID list to be processed;

[0123] 2. Build a batch operation parameter set: For each case ID, build a parameter set;

[0124] 3. Submit asynchronous tasks: Submit the constructed parameter set as a task to the priority queue

[0125] 4. Automatic sorting and processing: The priority queue automatically sorts tasks according to their priorities. High-priority tasks are processed first. The asynchronous task processing module periodically takes tasks out of the queue and passes them to the batch operation execution module for processing.

[0126] In summary, through the above methods, the asynchronous task processing module can efficiently manage and process a large number of batch operation tasks, ensuring that important and urgent tasks are given priority.

[0127] The batch operation execution module takes out tasks from the asynchronous task queue to execute batch operations, and processes them according to the success or failure results after the operation. The specific operations are as follows:

[0128] 1. Take the task out of the asynchronous task queue:

[0129] Connecting to message queues: The batch operation execution module establishes connections with asynchronous task queue systems, such as RabbitMQ, Celery, etc.

[0130] Get tasks: Regularly take out pending tasks from the priority queue. According to the queue settings, high-priority tasks will be taken out first;

[0131] Parse tasks: Extract necessary information from tasks, including task ID, task type, parameter set, etc.

[0132] 2. Perform batch operations:

[0133] Prepare data: Prepare the data required for batch operation according to the parameter set in the task. This may include multiple case IDs and their related operation parameters;

[0134] Use pipeline technology: Use Redis's pipeline technology to package multiple commands together and send them to the Redis server. This can significantly reduce network latency and improve performance. For example, if you need to update the status of multiple cases, you can send all HSET or HMSET commands to Redis at once through the pipeline.

[0135] Execute Lua scripts: To ensure data consistency, use Lua scripts to perform complex atomic operations. Lua scripts run inside Redis to ensure that all operations are either successful or failed. Lua scripts can contain logical judgments, conditional branches, loops, etc., to handle complex business logic. For example, a Lua script can check the status of each case and update the status based on the conditions.

[0136] 3. Processing operation results:

[0137] Successful processing: If all operations are completed successfully, the success log is recorded, and the status in the relevant database or cache is updated. A success notification can be sent to the client or the UI interface can be updated;

[0138] Failure handling: If any error occurs during the operation, the rollback mechanism is triggered to restore to the state before the operation;

[0139] The specific steps of the rollback mechanism include:

[0140] Undo changes: For actions that have been performed, undo these changes. For example, if the status of some cases has been updated, restore it to its original status;

[0141] Mark transaction failure: Mark the transaction as failed in the database or cache for subsequent retries or other processing;

[0142] Record error logs: Record detailed error logs, including the time when the error occurred, specific error information, case ID involved, etc., to facilitate subsequent troubleshooting;

[0143] Notification mechanism: As needed, relevant personnel or system administrators can be notified via email, text message, etc.

[0144] 4. Specific process:

[0145] 1. Take a task out of the queue: Suppose a task is taken out of the queue;

[0146] 2. Perform batch operations: prepare data and construct Redis commands; use pipeline technology to send these commands together to Redis; use Lua scripts to perform the above operations to ensure consistency;

[0147] 3. Processing operation results:

[0148] Successful processing: update the status in the database or cache, record the success log, and send a success notification (optional);

[0149] Failure handling: Assuming that update 12345 succeeds but 67890 fails, roll back the status of 12345, mark task-001 as failed in the database or cache, record detailed error logs, and send error notifications to relevant personnel.

[0150] In summary, through the above methods, the batch operation execution module can efficiently process a large number of tasks and automatically recover to a consistent state when encountering errors, ensuring the stability and reliability of the system.

[0151] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a general hardware platform, and of course, by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0152] The above shows and describes the basic principles and main features of the present invention and the advantages of the present invention. For those skilled in the art, it is obvious that the present invention is not limited to the details of the above exemplary embodiments, and the present invention can be implemented in other specific forms without departing from the spirit or basic features of the present invention. Therefore, no matter from which point of view, the embodiments should be regarded as exemplary and non-restrictive. The scope of the present invention is defined by the attached claims rather than the above description, and it is intended that all changes falling within the meaning and scope of the equivalent elements of the claims are included in the present invention, and any figure mark in the claims should not be regarded as limiting the claims involved.

[0153] In addition, it should be understood that although the present specification is described according to implementation modes, not every implementation mode contains only one independent technical solution. This description of the specification is only for the sake of clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment may also be appropriately combined to form other implementation modes that can be understood by those skilled in the art.

Claims

1. A verification system for batch case operations based on Redis, characterized in that: include: The client is used to initiate batch case operation requests to the Web server and receive the operation results returned by the batch operation execution module; Web server, used to receive and process client requests and perform user role and case status verification; Redis server, used to store the verified case ID and related information in the Redis database; The asynchronous task processing module is used to obtain the list of case IDs to be processed from Redis, build the parameters required for batch operations, and submit asynchronous tasks; The batch operation execution module takes out tasks from the asynchronous task queue to execute batch operations and processes them according to the success or failure results after the operation.

2. The verification system for batch case operations based on Redis according to claim 1 is characterized in that: The Redis server also includes setting up at least three servers with two adjacent nodes alternately built as master and slave, expanding the number of existing cluster nodes to an odd number, building Redis nodes and starting the management agent, verifying the existing cluster and the newly added nodes, adding the new master node to the current cluster, configuring the corresponding slave node for the newly added master node, and redistributing the slots of the entire Redis cluster so that the data is evenly distributed to all master nodes.

3. The verification system for batch case operations based on Redis according to claim 2 is characterized in that: The Web server includes a user role verification module and a case status verification module. The user role verification module is used to verify the user role and execute corresponding verification logic according to different roles, and the case status verification module is used to verify the case status.

4. The verification system for batch case operations based on Redis according to claim 3 is characterized in that: In the Redis server, a unique key is created for each verified case ID, and the case-related information is used as the value corresponding to the key and stored in Redis in the form of a hash table.

5. The verification system for batch case operations based on Redis according to claim 4 is characterized in that: In the asynchronous task processing module, a corresponding batch operation parameter set is prepared according to the list of case IDs to be processed, and the constructed batch operation parameters are submitted to the batch operation execution module as an asynchronous task.

6. The verification system for batch case operations based on Redis according to claim 5 is characterized in that: By setting priority queue support, tasks can be sorted and processed according to their importance and urgency.

7. The verification system for batch case operations based on Redis according to claim 6 is characterized in that: The batch operation execution module uses pipeline technology to take tasks from the asynchronous task queue to execute batch operations, and ensures data consistency through Lua scripts.

8. The verification system for batch case operations based on Redis according to claim 7 is characterized in that: In the batch operation execution module, when an error occurs, the rollback mechanism is triggered to restore to the state before the operation.

Images