Mail system based on large client load sharing mechanism and data processing method

Abstract

The invention discloses a mail system based on a large client load sharing mechanism and a data processing method. The system is constructed based on a three-layer load sharing network architecture of a terminal layer, an intelligent virtualization processing layer and a core server layer. The intelligent virtualization processing layer is deployed between the terminal cluster and the core server layer, and is provided with a plurality of functional modules; comprising an intelligent prefetching cache module, an intelligent attachment cache module, a centralized full-text retrieval preprocessing module, a contact synchronization module, a calendar data pre-calculation module, a mail rule preprocessing module, a batch operation processing optimization module and a mail behavior analysis preprocessing module. According to the scheme, the bearing capacity of the creative mailbox system in a high-concurrency scene is remarkably improved, through distributed caching and intelligent pre-calculation, the core service response time is shortened, the hardware input cost is reduced, and the use experience of large-scale enterprise users is effectively guaranteed.

Description

Technical Field

[0001] This invention relates to the field of high-concurrency processing technology for email systems, and in particular to an email system and data processing method based on a large client load balancing mechanism. Background Technology

[0002] Against the backdrop of deepening enterprise digitalization and the comprehensive promotion of the information technology innovation industry, domestically produced email systems are gradually taking on the important task of core office communication. With the expansion of user base and the increase in business complexity, the high-concurrency access pressure faced by email systems during peak office hours is becoming increasingly prominent. Issues such as system response delays and service instability directly affect user experience and office efficiency.

[0003] Currently, the industry generally adopts two technical approaches when handling high-concurrency scenarios in email systems: one is based on the traditional "thin client" architecture, which centralizes most of the computation and query logic on the server side; the other is to use technologies such as distributed caching or read / write separation to horizontally scale backend services. However, when facing large-scale concurrent access from users in the context of domestic IT innovation, existing technical solutions are gradually revealing obvious limitations.

[0004] First, in traditional "thin client" architectures, the client is only responsible for interface display and simple operations. All computational and data retrieval requests, such as email list loading, content rendering, search queries, and attachment previews, require real-time interaction with the server. During peak periods with thousands or even tens of thousands of users online simultaneously, the server experiences immense instantaneous request pressure, easily creating a performance bottleneck, leading to a significant increase in response latency and a sharp decline in user experience. Second, while relying solely on horizontal scaling of backend service clusters can improve processing capacity to some extent, it faces problems such as high hardware costs, a dramatic increase in system complexity, and limitations in scalability, and it is difficult to cope with sudden surges in traffic.

[0005] Furthermore, existing solutions generally lack in-depth utilization and intelligent predictive capabilities of user behavior data. For example, in high-frequency scenarios such as users opening their inbox, querying historical emails, and previewing attachments, the system often adopts a passive response mode, failing to preload data and cache it locally based on user habits. This results in a large number of duplicate requests consuming valuable bandwidth and server resources. In addition, for computationally intensive operations such as email body rendering, image compression, and attachment processing, existing architectures typically place all of these on the server side, which not only increases server load but also affects terminal response speed due to network transmission latency.

[0006] Finally, existing technologies do not adequately consider the unique characteristics of the domestic IT innovation environment. Domestic hardware platforms and software ecosystems differ in performance and compatibility, making it difficult to adapt a unified server-side optimization strategy to all terminals, which can easily lead to inconsistent experiences among different users.

[0007] The shortcomings of the aforementioned existing technologies mean that domestically developed email systems generally face challenges such as slow response during peak periods, insufficient system stability, low resource utilization efficiency, and inconsistent user experience when deployed on a large scale in enterprise environments. These issues severely restrict the usability and competitiveness of domestically developed email systems in high-concurrency scenarios. Therefore, there is an urgent need for a technical solution that can fundamentally alleviate traffic pressure at the architectural level, improve performance, and ensure a consistent user experience. Summary of the Invention

[0008] To address the aforementioned technical problems, this invention provides an email system and data processing method based on a large client load balancing mechanism. By constructing an intelligent virtualization processing layer located between the terminal and the server, the high concurrency problem is systematically solved.

[0009] This invention is achieved using the following technical solution: Firstly, the email system based on a large client load balancing mechanism is constructed using a three-layer load-sharing network architecture consisting of a terminal layer, an intelligent virtualization processing layer, and a core server layer. The intelligent virtualization processing layer is deployed between the terminal cluster and the core server layer and is configured with various functional modules, specifically including: Intelligent prefetch caching module: Based on user group access patterns and individual behavioral characteristics, it intelligently preloads and caches email metadata; Intelligent attachment caching module: Based on the frequency of attachment access and file characteristics, it performs hierarchical caching to reduce the direct access pressure on the backend storage system; Centralized full-text search preprocessing module: Builds a pre-indexing and retrieval engine in the intelligent virtualization processing layer, processes regular search requests locally, and only transmits complex queries to the core search service; Contact synchronization module: Establishes a mirror of contact data and a local cache to achieve near real-time query and synchronization; Calendar data pre-calculation module: Batch pre-generates user schedule views and caches them to avoid exposing the core database directly to terminal requests; Email rule preprocessing module: Performs real-time preprocessing of high-frequency rule operations, including email tagging, classification and filtering, in the intelligent virtualization processing layer, and only synchronizes the final state to the core email service; Batch operation processing optimization module: Processes batch requests from the terminal through an asynchronous queue, improving the ability to handle high-concurrency batch operations; Email Behavior Analysis Preprocessing Module: Processes user email behavior data in real time and generates pre-statistical results, supporting quick query and analysis reports.

[0010] Specifically, the implementation of the intelligent prefetch cache module includes: Behavioral feature analysis: Collect user email access data, build user group access models through collaborative filtering algorithms, and generate personalized prefetching strategies by combining individual historical behavior. Prefetching rule design: sorted by both popularity priority and time urgency, prioritize preloading metadata of high-frequency conversation emails from the first N pages of the inbox, where N is configurable; Cache cluster deployment: A two-level cache architecture combining local memory and distributed cache cluster is adopted. The terminal local memory caches the metadata of recently accessed emails, while the distributed cache cluster stores the metadata of emails frequently accessed by the user group. Cache update mechanism: By combining incremental synchronization with timed verification, when the core server email metadata changes, incremental updates are actively pushed to the cache cluster; the terminal local cache is verified with the cluster cache at preset time intervals, and incremental transmission is used in the synchronization process; The implementation of the intelligent attachment caching module specifically includes: Attachment classification strategy: Based on file size and access frequency, attachments are divided into high-frequency small attachments, medium-frequency attachments, and low-frequency large attachments; Tiered caching: High-frequency small attachments are stored in the memory of the distributed cache cluster; medium-frequency attachments are cached using a hybrid cache combining memory and disk; low-frequency large attachments are not cached directly, but are instead generated as intelligent redirect links. When a user requests an attachment, it is downloaded in segments from the backend storage system via the link, and the downloaded segments are cached locally. Subsequent accesses will directly reuse the cached segments. Cache eviction mechanism: The LRU (Least Recently Used) algorithm combined with access frequency weighting is adopted. When the cache space is insufficient, low-frequency and low-weight attachments are evicted first to ensure the cache priority of high-frequency attachments. Security controls: Attachment caches are stored using national cryptographic encryption, and cached links are marked with expiration dates and user identity verification information.

[0011] Specifically, the implementation of the centralized full-text search preprocessing module includes: Pre-index building: After a new email arrives at the core server layer, the email body and attachment text content are pushed to the preprocessing service simultaneously to build user-level and keyword-level secondary indexes in real time. The user-level index isolates data from different users, while the keyword-level index supports fuzzy matching and phrase matching for regular retrieval. Search request routing: When a user initiates a search request, the intelligent virtualization processing layer first parses the request complexity: regular queries are directly queried through the local pre-index, and the search status is marked synchronously after the results are returned; complex queries are optimized by the intelligent virtualization processing layer and then transmitted to the core search service, which updates the local index and feeds back to the user after receiving the results. Index optimization: Use an inverted index combined with a Bloom filter to reduce index storage usage; regularly defragment and optimize the index, and delete index data of deleted emails; The specific implementation of the contact synchronization module includes: Data mirroring: Regularly synchronize all contact data from the core server and build a distributed contact mirror library in the intelligent virtualization processing layer, supporting multi-dimensional indexing; Local caching strategy: The terminal layer client caches frequently used contact data, the intelligent virtualization processing layer caches all contact data, when a user queries a contact, the local cache is queried first, if no match is found, the processing layer image library is queried, and only if no match is found in either case is the core database queried and the cache updated. Intelligent routing and synchronization: When multiple terminals log in, routing is performed through the user's unique identifier; when contact data changes, a two-way synchronization mechanism combining terminal reporting and server push is adopted. Terminal changes are immediately reported to the intelligent virtualization processing layer, which then synchronizes to the core server layer and pushes the changes to all online terminals of the user. Concurrency control: A distributed lock mechanism is adopted, and conflicts are handled according to the rules of timestamp priority and terminal priority.

[0012] Specifically, the implementation of the calendar data pre-calculation module includes: Pre-calculation rules: Batch pre-generate view data based on user calendar data; for high-frequency scenarios, update the pre-calculation results in real time; Cache Management: The intelligent virtualization processing layer's distributed cache cluster stores pre-calculated calendar data for all users, and the terminal client caches the current view and the most recent calendar data; a cache expiration period is set, and recalculation is automatically triggered upon expiration; Conflict handling: When a user adds or modifies a schedule, a local pre-calculation is triggered, updating only the view data for the relevant time dimension; when a cross-user meeting schedule changes, the pre-calculated data for all participants is updated synchronously. High concurrency support: Employs a sharded storage strategy, distributing pre-computed data to different cache nodes based on user ID hash, and supports horizontal scaling of nodes; The specific implementation of the email rule preprocessing module includes: Rule synchronization and parsing: User-configured email rules are synchronized to the intelligent virtualization processing layer and parsed into executable rule scripts, supporting the combination of custom rules and system default rules; Real-time preprocessing: After a new email arrives at the intelligent virtualization processing layer, the rule engine is triggered to perform preprocessing, and classification, labeling and filtering operations are performed in sequence according to rule priority to generate the final state of the email; State synchronization: After preprocessing, only the final state of the email and the result of rule execution are synchronized to the core email service. The core server layer only needs to store the final state. Rule debugging and monitoring: Provides rule execution logs and debugging tools, monitors rule execution success rate and latency, and automatically degrades to core server-side processing when anomalies occur.

[0013] Specifically, the implementation of the batch operation processing optimization module includes: Request reception and response: The terminal layer initiates a batch operation request, and the intelligent virtualization processing layer receives it and immediately returns a unique operation identifier, while also prompting the user; Asynchronous queue processing: Batch requests are split into individual subtasks and added to a distributed asynchronous processing queue, which is sorted by operation type and priority; Background synchronization and status update: The intelligent virtualization processing layer consumes queue tasks in the background, performs specific operations, and synchronizes them to the core server layer. After successful synchronization, the operation status is updated. It also includes task breakpoint resume and automatic switching to a backup node when a queue node fails. Status query and callback: Users can query the processing progress through the operation identifier, and the user is notified through the client after the processing is completed; a retry button is provided when it fails, supporting batch retry or retry of a single subtask; The specific implementation of the email behavior analysis preprocessing module includes: Behavioral data collection: Real-time collection of user email behavior data; data transmission is compressed and encrypted. Pre-statistical calculation: In the intelligent virtualization processing layer, behavioral data is processed in real time through a stream computing engine to pre-generate statistical indicators or custom statistical dimensions; Report caching and querying: Pre-statistical results are cached in a distributed cache of the intelligent virtualization processing layer. When users query and analyze reports, they directly retrieve data from the cache to generate reports; the core analysis service is only responsible for complex statistical analysis. Data anonymization and storage: Anonymize statistical data, retain only the aggregated results, and periodically archive the pre-statistical results to low-cost storage.

[0014] Specifically, the terminal layer, the intelligent virtualization processing layer, and the core server layer include: Terminal layer: includes various domestically developed terminals and email clients, receives user operation requests and displays processing results, and interacts with the intelligent virtualization processing layer without directly accessing the core server; Intelligent virtualization processing layer: Through a storage mode that combines local memory clusters and distributed caching, it realizes localized and clustered management of user data. At the same time, based on user behavior analysis and business characteristics, it actively diverts regular requests and submits only complex queries and necessary operations for data final state synchronization to the core server layer. Core server layer: Includes various core components of traditional email systems, handles complex requests transmitted by the intelligent virtualization processing layer, maintains eventual data consistency, and provides underlying storage and security guarantees.

[0015] On the other hand, the email system data processing method based on the large client load balancing mechanism includes email reading, email searching, and batch operations. The email reading specifically includes the following steps: Step A1: The terminal client receives the user's operation request and parses the request parameters; Step A2: Send the request to the intelligent virtualization processing layer, and first check if the target email metadata exists in the local cache; Step A3: If the local cache is hit, the data is retrieved directly from the local cache and the email list and content are displayed, and the process ends; if the cache is not hit, the intelligent virtualization processing layer receives the request and queries the distributed cache cluster. Step A4: If the cache cluster is hit, the intelligent virtualization processing layer returns the email metadata to the terminal client, displays the email list and content, and updates the local cache at the same time; if it is not hit, the intelligent virtualization processing layer sends an incremental query request to the core server layer. Step A5: The core server layer returns the query results, the intelligent virtualization processing layer updates the distributed cache cluster, and at the same time returns the results to the terminal client. Step A6: The terminal client receives and displays the data, and updates the local cache; if the user clicks to preview or download the attachment, the smart attachment cache proxy layer process is triggered, and the attachment is processed according to the attachment classification strategy.

[0016] Specifically, the email search includes the following steps: Step B1: The terminal layer client receives the user's search request and parses the query conditions; Step B2: Send the query request to the intelligent virtualization processing layer, which determines the complexity of the request; Step B3: If it is a regular query, the intelligent virtualization processing layer calls the centralized full-text search preprocessing service to query the local pre-index; Step B4: When the pre-index is hit, return the search results to the terminal client, display the results, and the process ends; when no match is found, return a message indicating no matching results, and record the search log. Step B5: If it is a complex query, the processing layer optimizes the query parameters and then transmits them to the core search service; Step B6: The core search service returns the search results, the intelligent virtualization processing layer updates the local pre-index, and returns the results to the terminal client. Step B7: The terminal client receives and displays the search results, supporting result sorting and secondary filtering.

[0017] Specifically, the batch operation includes: Step C1: The terminal layer client receives the user's batch operation request and parses the operation type, target email ID list, and user ID; Step C2: Send the request to the batch operation processing optimization service of the intelligent virtualization processing layer; Step C3: The intelligent virtualization processing layer generates a unique operation identifier and immediately returns to the terminal client. The terminal displays a notification that the operation has been accepted and supports querying the progress by operation identifier. Step C4: The intelligent virtualization processing layer breaks down the batch requests into multiple individual deletion subtasks and adds them to a distributed asynchronous processing queue; Step C5: The background consumption queue task of the intelligent virtualization processing layer executes the email deletion operation in sequence, updates the cached data of the intelligent virtualization processing layer, and synchronizes it to the core email service; Step C6: The core email service receives the synchronization request, updates the email status, and returns the synchronization result; Step C7: The intelligent virtualization processing layer records the processing results of each subtask. After all tasks are completed, an operation result report is generated. Step C8: Notify the user that the operation is complete via the terminal client. The user can view the result report and retry failed tasks.

[0018] The beneficial effects of this invention are as follows: This invention proposes an email system and data processing method based on a large client load balancing mechanism. By constructing a three-layer architecture of "terminal-intelligent virtualization processing layer-server", it significantly improves the carrying capacity of the domestically developed email system in high-concurrency scenarios. Through distributed caching and intelligent pre-computation, it shortens the core service response time by more than 60% and reduces hardware investment costs by more than 30%, effectively ensuring the user experience for large-scale enterprise users. The advantages include the following: (1) Significant performance improvement: The core server request pressure is reduced by more than 80%, and the response time of routine operations such as email list loading, search, and contact query is controlled within 500ms, which is 6-8 times better than the traditional thin client architecture and 3-4 times better than the browser caching solution; (2) Significantly reduced costs: Hardware investment costs are reduced by more than 30% without relying on large-scale horizontal scaling of backend service clusters; Storage costs are reduced by 40%-50% through tiered caching and attachment deduplication (collaborative intelligent attachment caching proxy layer); (3) Enhanced stability and scalability: Supports user scale from 10,000 to more than 1 million. In high-concurrency scenarios (such as 100,000 users online at the same time during the morning peak), the system has no response delay and no service interruption, with availability reaching 99.99%. The intelligent virtualization processing layer supports elastic expansion, and adding new nodes does not require service interruption. (4) Consistent user experience: Adapts to different configurations of domestically developed terminals, with a difference of ≤20% in operation response speed between low-end and high-end devices and a data synchronization delay of ≤3 seconds, solving the problem of inconsistent user experience in existing solutions; (5) Security adaptation: Data transmission adopts TLS1.3 encryption, storage adopts national cryptographic algorithm, and cache links include time validity and identity verification, which meets the security requirements of government and enterprise customers for sensitive email data and is compatible with the security specifications of the information technology innovation environment. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of the email system architecture based on a large client load balancing mechanism in an embodiment of the present invention. Detailed Implementation

[0021] 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 embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0022] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0023] The following is in conjunction with the appendix Figure 1 The following describes some embodiments of the present invention in detail. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0024] This invention proposes an email system and data processing method based on a large client load balancing mechanism, aiming to solve problems such as excessive server load, response latency, inconsistent user experience, and low resource utilization efficiency faced by large-scale government and enterprise email systems during peak office periods under the domestic IT innovation environment. By constructing a three-layer architecture of "terminal-intelligent virtualization processing layer-server," integrating eight core modules including intelligent pre-fetch caching, hierarchical attachment caching, and full-text search preprocessing, over 80% of routine requests and computationally intensive operations are offloaded to the virtualization processing layer. Only complex requests and final states are synchronously transmitted to the core server. This fundamentally reduces pressure at the architectural level, improves response speed, and reduces hardware costs, while ensuring a consistent experience and data security across different terminals under the domestic IT innovation environment, meeting the core office communication needs of large-scale government and enterprise users.

[0025] The following detailed description of the email system based on a large client load balancing mechanism according to the present invention is provided with reference to specific embodiments: The email system architecture based on the large client load balancing mechanism adopts a three-layer load balancing design concept of "terminal layer - intelligent virtualization processing layer - core server layer". The core lies in the construction and coordination of the intelligent virtualization processing layer. In this embodiment, the functions and coordination logic of each layer are as follows: Terminal layer: This includes various domestically developed terminals (domestic PCs, laptops, mobile devices, etc.) and email clients (domestic-developed adapted clients, browser clients), responsible for receiving user operation requests (email reading, searching, attachment previewing, batch operations, etc.), displaying processing results, and interacting with the intelligent virtualization processing layer, without needing to directly access the core server.

[0026] Intelligent Virtualization Processing Layer: As the core load-sharing carrier of this invention, it is deployed between the terminal cluster and the core server, and includes eight core functional modules (intelligent prefetch caching service, intelligent attachment caching proxy layer, etc.), possessing four core capabilities: data caching, preprocessing, asynchronous processing, and intelligent prediction. This layer achieves localized and clustered management of user data through a storage mode combining local memory clusters and distributed caching. Simultaneously, based on user behavior analysis and business characteristics, it proactively diverts regular requests, submitting only necessary operations such as complex queries and data final state synchronization to the core server.

[0027] The core server layer includes core components of traditional email systems such as email core services, database clusters, storage systems, and search services. It is responsible for handling complex requests passed through the intelligent virtualization processing layer, maintaining eventual data consistency, and providing underlying storage and security guarantees. It does not need to deal with the direct impact of large-scale regular requests, and the load pressure is significantly reduced.

[0028] The collaborative logic of the three-tier architecture is as follows: all requests initiated by the terminal layer are first routed to the intelligent virtualization processing layer. The processing layer performs traffic splitting based on the request type (regular request / complex request) and data status (cache hit / miss): regular requests with cache hits directly return results through the processing layer; regular requests with cache misses are pre-fetched and pre-processed by the processing layer before returning results and updating the cache; complex requests are initially processed by the processing layer (such as index building and parameter optimization) and then passed through to the core server layer. After receiving the returned results, the server layer synchronizes them to the cache and feeds them back to the terminal, achieving the collaborative effect of "reducing the burden on the terminal, splitting traffic in the processing layer, and reducing the pressure on the server".

[0029] The functional modules in the intelligent virtualization processing layer are described in detail below. (1) Intelligent prefetch cache module Core functionality: Based on user group access patterns and individual behavioral characteristics, it enables intelligent preloading and caching management of email metadata, reducing the query pressure on core email services.

[0030] Implementation mechanism: Behavioral feature analysis: Collect user email access data (such as high-frequency access time periods, frequently used folders, email reading order, and conversation association habits), build user group access models through collaborative filtering algorithms, and generate personalized prefetching strategies by combining individual historical behavior. Prefetching rule design: Sort by two dimensions: "popularity priority" and "time urgency", and prioritize preloading the metadata (including sender, subject, sending time, email status, body summary, etc.) of the first N pages of the inbox (N is configurable, default is 5 pages), unread emails, high-priority emails and high-frequency conversation emails in the last 3 months. Cache cluster deployment: It adopts a two-level cache architecture of "local memory + distributed cache cluster". The terminal local memory caches the metadata of the 100 most recently accessed emails, and the distributed cache cluster stores the metadata of emails frequently accessed by the user group. The cache cluster nodes are sharded by user ID hash and support elastic expansion. Cache update mechanism: Data consistency is ensured through "incremental synchronization + timed verification". When the core server email metadata changes (such as status update or new email), incremental updates are actively pushed to the cache cluster. The terminal local cache is verified with the cluster cache every 5 minutes to ensure data accuracy. The synchronization process uses incremental transmission to reduce bandwidth consumption.

[0031] Performance metrics: Mailing list loading response time ≤ 50ms, core email service query request volume reduced by more than 80%, cache hit rate ≥ 92%.

[0032] (2) Intelligent Attachment Cache Proxy Module Core functionality: Tiered caching based on attachment access frequency and file characteristics reduces direct access pressure on the backend storage system and improves attachment preview and download speeds.

[0033] Implementation mechanism: Attachment classification strategy: divided into three levels according to "file size + access frequency": high-frequency small attachments (≤1MB, accessed ≥5 times in 30 days), medium-frequency attachments (1MB-40MB, accessed 2-4 times in 30 days), and low-frequency large attachments (>40MB or accessed ≤1 time in 30 days). Tiered caching: High-frequency small attachments are stored in the memory of a distributed cache cluster, supporting millisecond-level preview and download; mid-frequency attachments are cached using a hybrid "memory + disk" approach, with metadata and the first 20% of the content cached in memory, and the remaining content cached on the local disk; low-frequency large attachments are not cached directly, but instead generate intelligent redirection links. When a user requests an attachment, it is downloaded in segments from the backend storage system via the link, and the downloaded segments are cached locally. Subsequent accesses can directly reuse the cached segments. Cache eviction mechanism: The "LRU (Least Recently Used) + access frequency weighted" algorithm is adopted. When the cache space is insufficient, low-frequency and low-weight attachments are evicted first to ensure the cache priority of high-frequency attachments. Security controls: Attachment caches are stored using national cryptographic encryption, and cached links are marked with an expiration date (valid for 24 hours) and user identity verification information to prevent unauthorized access.

[0034] Performance metrics: Direct access pressure to the backend storage system is reduced by 70%, high-frequency attachment preview response time is ≤200ms, and average attachment download speed is increased by 3 times.

[0035] (3) Centralized full-text search preprocessing module Core functionality: Build a pre-indexing and retrieval engine in the intelligent virtualization processing layer to enable local processing of regular search requests, while only passing complex queries to the core search service.

[0036] Implementation mechanism: Pre-index building: After a new email arrives at the core server, the email body and attachment text content are pushed to the preprocessing service simultaneously to build a "user-level + keyword-level" secondary index in real time. The user-level index isolates data from different users, while the keyword-level index supports conventional searches such as fuzzy matching and phrase matching. Search request routing: When a user initiates a search request, the processing layer first parses the complexity of the request: regular queries (simple combinations of conditions such as single keyword, time range + sender) are directly queried through the local pre-index, and the search status is marked synchronously after the results are returned; complex queries (logical combinations of multiple keywords, deep search across folders, full-text semantic matching) are optimized by the processing layer (such as splitting keywords and filtering invalid conditions) and then passed through to the core search service. After receiving the results, the local index is updated and feedback is given to the user; Index optimization: We use a combination of inverted index and Bloom filter to reduce index storage usage and improve retrieval speed; we regularly (every day at midnight) defragment and optimize the index, and delete index data of deleted emails to ensure retrieval accuracy.

[0037] Performance metrics: Over 80% of regular search requests are completed at the processing layer, reducing the query pressure on the core search service by 85%, and the response time for regular searches is ≤300ms.

[0038] (4) Contact synchronization module Core functionality: Establish a mirror of contact data and a local cache to achieve near real-time querying and synchronization, reducing backend database query requests.

[0039] Implementation mechanism: Data mirroring: Periodically (default 15 minutes) synchronize all contact data (including name, email, phone number, department, remarks, etc.) from the core server, and build a distributed contact mirror library at the processing layer, supporting multi-dimensional indexing by user ID, email, name, etc. Local caching strategy: The terminal client caches frequently used contacts (accessed ≥3 times in the last 30 days), and the processing layer caches all contact data. When a user queries a contact, the local cache is queried first. If no match is found, the processing layer mirror database is queried. Only when no match is found in either local cache or processing layer mirror database is queried and the cache is updated. Intelligent routing and synchronization: When multiple terminals log in, routing is performed through the user's unique identifier to ensure that the contact data of each terminal is consistent; when the contact data changes (addition, modification, deletion), a two-way synchronization mechanism of "terminal reporting + server push" is adopted. The terminal change is immediately reported to the processing layer, the processing layer synchronizes to the core server and pushes to all online terminals of the user, with a synchronization delay of ≤3 seconds; Concurrency control: A distributed lock mechanism is adopted to avoid conflicts caused by multiple terminals modifying the same contact data at the same time. In case of conflict, the "timestamp priority + terminal priority" rule is used for handling.

[0040] Performance metrics: Backend database query requests are reduced by more than 85%, supporting tens of thousands of concurrent contact queries, query response time ≤100ms, and data synchronization latency ≤3 seconds.

[0041] (5) Calendar data pre-calculation module Core functionality: Batch pre-generate and cache user schedule views to avoid exposing the core database directly to terminal requests, thereby improving calendar service performance in high-concurrency scenarios.

[0042] Implementation mechanism: Pre-calculation rules: Based on user calendar data (schedules, meetings, reminders, etc.), view data is pre-generated in batches according to the "day / week / month" dimension, including schedule list, time conflict detection results, reminder trigger time, etc.; for high-frequency scenarios (such as today's schedule, tomorrow's reminder), the pre-calculation results are updated in real time. Cache management: The processing layer's distributed cache cluster stores pre-calculated calendar data for all users, while the terminal client caches the current view and calendar data for the most recent 3 months; it supports fast queries by user ID and time range, and the cache validity period is 24 hours by default, automatically triggering recalculation upon expiration; Conflict handling: When a user adds or modifies a schedule, a partial pre-calculation is triggered, updating only the view data for the relevant time dimension, without requiring a full recalculation; when a meeting schedule changes across users, the pre-calculated data for all participants is updated synchronously to ensure consistency; High concurrency support: It adopts a sharded storage strategy, distributes pre-computed data to different cache nodes by hashing user ID, supports horizontal scaling of nodes, and can cope with large-scale concurrent access by users.

[0043] Performance metrics: Core database calendar request volume reduced by 90%, calendar view loading response time ≤200ms, supports 100,000 concurrent users without pressure.

[0044] (6) Email rule preprocessing module Core functionality: Real-time preprocessing of high-frequency rule operations such as email tagging, classification, and filtering is performed at the processing layer, and only the final state is synchronized to the core email service, reducing rule processing latency.

[0045] Implementation mechanism: Rule synchronization and parsing: User-configured email rules (such as sender classification, keyword tagging, automatic reply, spam filtering, etc.) are synchronized to the processing layer and parsed into executable rule scripts, supporting the combination of custom rules and system default rules; Real-time preprocessing: When a new email arrives at the processing layer, the rule engine is triggered to perform preprocessing, which executes operations such as classification, tagging, and filtering according to rule priority, and generates the final status of the email (such as the folder it belongs to, read / unread status, and tags). The preprocessing process does not depend on the core server and is completed only at the processing layer. State synchronization: After preprocessing, only the final state of the email and the result of the rule execution are synchronized to the core email service. The core server does not need to repeat the rule processing, but only needs to store the final state. Rule debugging and monitoring: Provides rule execution logs and debugging tools, allowing users to view rule execution status; monitors rule execution success rate and latency, and automatically degrades to core server processing in case of anomalies (such as rule execution failure) to ensure business continuity.

[0046] Performance metrics: Email rule processing latency reduced by 90%, core email service rule processing pressure reduced by 95%, and rule execution success rate ≥99.9%.

[0047] (7) Batch operation processing optimization module Core functionality: Processing batch requests from terminals (such as batch deletion, batch marking as read, batch forwarding, etc.) through asynchronous queues to achieve a "zero-wait" user experience and improve the ability to handle high-concurrency batch operations.

[0048] Implementation mechanism: Request reception and response: When a terminal initiates a batch operation request (such as deleting 100 emails in batches), the processing layer immediately returns a unique operation identifier (in the format of "OpID_UserID_Timestamp") to inform the user that "the operation has been accepted" without waiting for the processing to be completed. Asynchronous queue processing: Batch requests are split into individual subtasks and added to a distributed asynchronous processing queue. The queue is sorted by "operation type + priority". Lightweight operations such as batch deletion and marking are processed first, while heavyweight operations such as batch forwarding and batch downloading of attachments are processed later. Background synchronization and status update: The processing layer consumes queue tasks in the background, executes specific operations and synchronizes them to the core server. After successful synchronization, the operation status (success / failure) is updated. It supports task breakpoint resumption and automatically switches to a backup node when a queue node fails to ensure that no tasks are lost. Status query and callback: Users can query the processing progress through the operation icon. After the processing is completed, the user will be notified via client notification (such as pop-up window, message prompt); a retry button is provided in case of failure, supporting batch retry or retry of a single subtask.

[0049] Performance metrics: Batch operation response latency ≤100ms (only operation identifier is returned), background processing throughput up to 1000 messages / second, task success rate ≥99.9%, supports batch operations of more than 10,000 messages at a time.

[0050] (8) Email Behavior Analysis Preprocessing Module Core functionality: Processes user email behavior data in real time and generates pre-statistical results, supports quick query and analysis reports, and reduces the pressure on core analysis services.

[0051] Implementation mechanism: Behavioral data collection: Real-time collection of user email behavior data (such as the number of emails sent / received, reading time, number of attachment downloads, frequency of interaction with frequently used contacts, etc.). Data transmission adopts compression and encryption methods to ensure security and transmission efficiency. Pre-statistical calculation: In the processing layer, behavioral data is processed in real time through a stream computing engine (such as Flink), and statistical indicators (such as the number of emails sent per day, the number of high-frequency contacts this week, the total number of attachments downloaded per month, etc.) are pre-generated according to the "daily / weekly / monthly" dimensions, and custom statistical dimensions are supported; Report caching and querying: Pre-statistical results are cached in a distributed cache at the processing layer. When users query analysis reports, data is directly extracted from the cache to generate reports (supporting table and chart display), without calling the core analysis service. The core analysis service is only responsible for complex statistical analysis (such as cross-departmental email correspondence analysis and annual email trend analysis). Data anonymization and storage: Statistical data is anonymized, retaining only the aggregated results and not storing the original behavioral details; pre-statistical results are periodically archived to low-cost storage, retaining 6 months of historical data and supporting historical report queries.

[0052] Performance metrics: Core analytics service pressure reduced by 90%, analytics report query response time ≤500ms, behavioral data processing latency ≤5 seconds, and support for 100,000 concurrent users querying reports.

[0053] Based on the aforementioned email system with a large client load balancing mechanism, the core data processing flow includes three typical scenarios: email reading, email searching, and batch operation. Specifically, the email reading process includes: S1: The terminal client receives the user's "open inbox" or "read specified email" operation request and parses the request parameters (user ID, folder type, email ID (if specified)). S2: The terminal client sends the request to the intelligent virtualization processing layer, which first checks whether the target email metadata (inbox list / specified email metadata) exists in the local cache. S3: If the local cache is hit, retrieve the data directly from the local cache and display the email list / content, and the process ends; if the cache is not hit, the processing layer receives the request and queries the distributed cache cluster. S4: If the cache cluster is hit, the processing layer returns the email metadata (including the body summary and attachment information) to the terminal client, and the terminal displays the email list / content, while updating the local cache; if it is not hit, the processing layer sends an incremental query request to the core server (only querying the uncached email metadata). S5: The core server returns the query results, the processing layer updates the distributed cache cluster, and at the same time returns the results to the terminal client; S6: The terminal client receives and displays data, and updates the local cache; if the user clicks on the attachment preview / download, the smart attachment cache proxy layer process is triggered, and the attachments are processed according to the attachment classification strategy (high-frequency small attachments are directly cached and read, and low-frequency large attachments are downloaded and cached in segments).

[0054] In this embodiment, the email search process specifically includes: S1: The terminal client receives the user's search request and parses the search keywords, time range, folder and other query conditions; S2: The terminal client sends the query request to the intelligent virtualization processing layer, and the processing layer determines the complexity of the request (normal query / complex query). S3: For regular queries, the processing layer calls the centralized full-text search preprocessing service to query the local pre-index; S4: When the pre-index is hit, return the search results (including the email list and highlighted matching keywords) to the terminal client, the terminal displays the results, and the process ends; when no match is found, return the "No matching results" message and record the search log at the same time; S5: For complex queries, the processing layer optimizes the query parameters (splitting keywords and filtering invalid conditions) and then passes them through to the core search service; S6: The core search service returns search results, the processing layer updates the local pre-index, and returns the results to the terminal client. S7: The terminal client receives and displays search results, supporting result sorting (time / relevance) and secondary filtering.

[0055] The batch operation process specifically includes: S1: The terminal client receives a user's batch operation request (such as deleting 100 emails in batches), and parses the operation type, target email ID list, and user ID; S2: The terminal client sends the request to the batch operation processing optimization service of the intelligent virtualization processing layer; S3: The processing layer generates a unique operation identifier and immediately returns it to the terminal client. The terminal displays a "Operation accepted" message and supports querying the progress by operation identifier; S4: The processing layer breaks down batch requests into 100 individual deletion subtasks and adds them to a distributed asynchronous processing queue; S5: Processing layer background consumption queue tasks, sequentially execute email deletion operations, update processing layer cache data, and synchronize to the core email service; S6: The core email service receives the synchronization request, updates the email status (marks it as deleted), and returns the synchronization result; S7: The processing layer records the processing result (success / failure) of each subtask. After all tasks are completed, an operation result report is generated. S8: The processing layer notifies the user that the operation is complete through a pop-up window or message prompt in the terminal client. The user can view the result report (such as "98 emails were successfully deleted, 2 failed to be deleted because they were in use"), and supports retrying failed tasks.

[0056] The email system and data processing method based on a large client load-sharing mechanism proposed in this invention have the following characteristics in terms of technical principles: (1) Innovative architecture for load balancing on large clients: Breaking through the limitations of traditional “thin client + server extension” or “browser caching + API optimization”, an independent intelligent virtualization processing layer is constructed to divert regular requests and computationally intensive operations from the server to the processing layer, achieving “architecture-level load balancing” rather than “local optimization”, fundamentally reducing the server load; (2) Multi-dimensional intelligent prediction and preprocessing mechanism: Integrating user group access patterns and individual behavioral characteristics, it realizes email metadata pre-fetching, calendar data pre-calculation, and retrieval index pre-construction, changing "passive response" to "active prediction", greatly improving response speed and cache hit rate; (3) Tiered caching and asynchronous processing co-optimization: Differentiated tiered caching strategies are designed for different data types such as attachments, contacts, and calendars. Combined with batch operation asynchronous queues, data consistency is guaranteed while achieving a "zero-wait" user experience and adapting to the performance differences of different terminals in the information technology innovation environment. (4) Adaptability design for the information technology innovation environment: Through distributed architecture, multi-terminal compatibility, encrypted data storage, and conflict handling mechanism, the differences in hardware of information technology innovation terminals, browser compatibility, and data security are resolved, ensuring a consistent experience for different users and the security of sensitive data.

[0057] For the foregoing embodiments, in order to simplify the description, they are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to this application.

[0058] The above embodiments describe the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Modifications and variations made by those skilled in the art without departing from the spirit and scope of the invention should be within the protection scope of the appended claims.

Claims

1. An email system based on a large client load balancing mechanism, characterized in that: The network architecture is built on a three-layer load-sharing structure consisting of the terminal layer, the intelligent virtualization processing layer, and the core server layer. The intelligent virtualization processing layer is deployed between the terminal cluster and the core server layer, and is configured with various functional modules, including: Intelligent prefetch caching module: Based on user group access patterns and individual behavioral characteristics, it intelligently preloads and caches email metadata; Intelligent attachment caching module: Based on the frequency of attachment access and file characteristics, it performs hierarchical caching to reduce the direct access pressure on the backend storage system; Centralized full-text search preprocessing module: Builds a pre-indexing and retrieval engine in the intelligent virtualization processing layer, processes regular search requests locally, and only transmits complex queries to the core search service; Contact synchronization module: Establishes a mirror of contact data and a local cache to achieve near real-time query and synchronization; Calendar data pre-calculation module: Batch pre-generates user schedule views and caches them to avoid exposing the core database directly to terminal requests; Email rule preprocessing module: Performs real-time preprocessing of high-frequency rule operations, including email tagging, classification and filtering, in the intelligent virtualization processing layer, and only synchronizes the final state to the core email service; Batch operation processing optimization module: Processes batch requests from the terminal through an asynchronous queue, improving the ability to handle high-concurrency batch operations; Email Behavior Analysis Preprocessing Module: Processes user email behavior data in real time and generates pre-statistical results, supporting quick query and analysis reports.

2. The email system based on a large client load balancing mechanism as described in claim 1, characterized in that, The implementation details of the intelligent prefetch cache module include: Behavioral feature analysis: Collect user email access data, build user group access models through collaborative filtering algorithms, and generate personalized prefetching strategies by combining individual historical behavior. Prefetching rule design: sorted by both popularity priority and time urgency, prioritize preloading metadata of high-frequency conversation emails from the first N pages of the inbox, where N is configurable; Cache cluster deployment: A two-level cache architecture combining local memory and distributed cache cluster is adopted. The terminal local memory caches the metadata of recently accessed emails, while the distributed cache cluster stores the metadata of emails frequently accessed by the user group. Cache update mechanism: By combining incremental synchronization with timed verification, when the core server's email metadata changes, incremental updates are proactively pushed to the cache cluster; The terminal's local cache is checked against the cluster cache at a preset time interval, and incremental transmission is used during the synchronization process. The implementation of the intelligent attachment caching module specifically includes: Attachment classification strategy: Based on file size and access frequency, attachments are divided into high-frequency small attachments, medium-frequency attachments, and low-frequency large attachments; Tiered caching: High-frequency small attachments are stored in the memory of the distributed cache cluster; medium-frequency attachments are cached using a hybrid cache combining memory and disk; low-frequency large attachments are not cached directly, but are instead generated as intelligent redirect links. When a user requests an attachment, it is downloaded in segments from the backend storage system via the link, and the downloaded segments are cached locally. Subsequent accesses will directly reuse the cached segments. Cache eviction mechanism: The LRU (Least Recently Used) algorithm combined with access frequency weighting is adopted. When the cache space is insufficient, low-frequency and low-weight attachments are evicted first to ensure the cache priority of high-frequency attachments. Security controls: Attachment caches are stored using national cryptographic encryption, and cached links are marked with expiration dates and user identity verification information.

3. The email system based on a large client load balancing mechanism as described in claim 1, characterized in that, The specific implementation of the centralized full-text search preprocessing module includes: Pre-index building: After a new email arrives at the core server layer, the email body and attachment text content are pushed to the preprocessing service simultaneously to build user-level and keyword-level secondary indexes in real time. The user-level index isolates data from different users, while the keyword-level index supports fuzzy matching and phrase matching for regular retrieval. Search request routing: When a user initiates a search request, the intelligent virtualization processing layer first parses the request complexity: regular queries are directly queried through the local pre-index, and the search status is marked synchronously after the results are returned; complex queries are optimized by the intelligent virtualization processing layer and then transmitted to the core search service, which updates the local index and feeds back to the user after receiving the results. Index optimization: Use an inverted index combined with a Bloom filter to reduce index storage usage; regularly defragment and optimize the index, and delete index data of deleted emails; The specific implementation of the contact synchronization module includes: Data mirroring: Regularly synchronize all contact data from the core server and build a distributed contact mirror library in the intelligent virtualization processing layer, supporting multi-dimensional indexing; Local caching strategy: The terminal layer client caches frequently used contact data, the intelligent virtualization processing layer caches all contact data, when a user queries a contact, the local cache is queried first, if no match is found, the processing layer image library is queried, and only if no match is found in either case is the core database queried and the cache updated. Intelligent routing and synchronization: When multiple terminals log in, routing is performed through the user's unique identifier; when contact data changes, a two-way synchronization mechanism combining terminal reporting and server push is adopted. Terminal changes are immediately reported to the intelligent virtualization processing layer, which then synchronizes to the core server layer and pushes the changes to all online terminals of the user. Concurrency control: A distributed lock mechanism is adopted, and conflicts are handled according to the rules of timestamp priority and terminal priority.

4. The email system based on a large client load balancing mechanism as described in claim 1, characterized in that, The specific implementation of the calendar data pre-calculation module includes: Pre-calculation rules: Batch pre-generate view data based on user calendar data; for high-frequency scenarios, update the pre-calculation results in real time; Cache Management: The intelligent virtualization processing layer's distributed cache cluster stores pre-calculated calendar data for all users, and the terminal client caches the current view and the most recent calendar data; a cache expiration period is set, and recalculation is automatically triggered upon expiration; Conflict handling: When a user adds or modifies a schedule, a local pre-calculation is triggered, updating only the view data for the relevant time dimension; when a cross-user meeting schedule changes, the pre-calculated data for all participants is updated synchronously. High concurrency support: Employs a sharded storage strategy, distributing pre-computed data to different cache nodes based on user ID hash, and supports horizontal scaling of nodes; The specific implementation of the email rule preprocessing module includes: Rule synchronization and parsing: User-configured email rules are synchronized to the intelligent virtualization processing layer and parsed into executable rule scripts, supporting the combination of custom rules and system default rules; Real-time preprocessing: After a new email arrives at the intelligent virtualization processing layer, the rule engine is triggered to perform preprocessing, and classification, labeling and filtering operations are performed in sequence according to rule priority to generate the final state of the email; State synchronization: After preprocessing, only the final state of the email and the result of rule execution are synchronized to the core email service. The core server layer only needs to store the final state. Rule debugging and monitoring: Provides rule execution logs and debugging tools, monitors rule execution success rate and latency, and automatically degrades to core server-side processing when anomalies occur.

5. The email system based on a large client load balancing mechanism as described in claim 1, characterized in that, The specific implementation of the batch operation processing optimization module includes: Request reception and response: The terminal layer initiates a batch operation request, and the intelligent virtualization processing layer receives it and immediately returns a unique operation identifier, while also prompting the user; Asynchronous queue processing: Batch requests are split into individual subtasks and added to a distributed asynchronous processing queue, which is sorted by operation type and priority; Background synchronization and status update: The intelligent virtualization processing layer consumes queue tasks in the background, executes specific operations and synchronizes them to the core server layer. After successful synchronization, the operation status is updated. It also includes task breakpoint resume and automatic switch to backup node when queue node fails. Status query and callback: Users can query the processing progress through the operation identifier, and the client will notify the user after the processing is completed; a retry button is provided when it fails, supporting batch retry or retry of a single subtask; The specific implementation of the email behavior analysis preprocessing module includes: Behavioral data collection: Real-time collection of user email behavior data; data transmission is compressed and encrypted. Pre-statistical calculation: In the intelligent virtualization processing layer, behavioral data is processed in real time through a stream computing engine to pre-generate statistical indicators or custom statistical dimensions; Report caching and querying: Pre-statistical results are cached in a distributed cache of the intelligent virtualization processing layer. When users query and analyze reports, they directly retrieve data from the cache to generate reports; the core analysis service is only responsible for complex statistical analysis. Data anonymization and storage: Anonymize statistical data, retain only the aggregated results, and periodically archive the pre-statistical results to low-cost storage.

6. The email system based on a large client load-sharing mechanism as described in claim 1, characterized in that, The terminal layer, intelligent virtualization processing layer, and core server layer specifically include: Terminal layer: includes various domestically developed terminals and email clients, receives user operation requests and displays processing results, and interacts with the intelligent virtualization processing layer without directly accessing the core server; Intelligent virtualization processing layer: Through a storage mode that combines local memory clusters and distributed caching, it realizes localized and clustered management of user data. At the same time, based on user behavior analysis and business characteristics, it actively diverts regular requests and submits only complex queries and necessary operations for data final state synchronization to the core server layer. Core server layer: Includes various core components of traditional email systems, handles complex requests transmitted by the intelligent virtualization processing layer, maintains eventual data consistency, and provides underlying storage and security guarantees.

7. A data processing method for an email system based on a large client load balancing mechanism, implemented based on the email system based on the large client load balancing mechanism described in any one of claims 1 to 6, characterized in that, This includes email reading, email searching, and batch operations. Specifically, email reading includes the following steps: Step A1: The terminal client receives the user's operation request and parses the request parameters; Step A2: Send the request to the intelligent virtualization processing layer, and first check if the target email metadata exists in the local cache; Step A3: If the local cache is hit, the data is retrieved directly from the local cache and the email list and content are displayed, and the process ends; if the cache is not hit, the intelligent virtualization processing layer receives the request and queries the distributed cache cluster. Step A4: If the cache cluster is hit, the intelligent virtualization processing layer returns the email metadata to the terminal client, displays the email list and content, and updates the local cache at the same time; if it is not hit, the intelligent virtualization processing layer sends an incremental query request to the core server layer. Step A5: The core server layer returns the query results, the intelligent virtualization processing layer updates the distributed cache cluster, and at the same time returns the results to the terminal client. Step A6: The terminal client receives and displays the data, and updates the local cache; if the user clicks to preview or download the attachment, the smart attachment cache proxy layer process is triggered, and the attachment is processed according to the attachment classification strategy.

8. The email system data processing method based on a large client load balancing mechanism as described in claim 7, characterized in that, The email search specifically includes the following steps: Step B1: The terminal layer client receives the user's search request and parses the query conditions; Step B2: Send the query request to the intelligent virtualization processing layer, which determines the complexity of the request; Step B3: If it is a regular query, the intelligent virtualization processing layer calls the centralized full-text search preprocessing service to query the local pre-index; Step B4: When the pre-index is hit, return the search results to the terminal client, display the results, and the process ends; when no match is found, return a message indicating no matching results, and record the search log. Step B5: If it is a complex query, the processing layer optimizes the query parameters and then transmits them to the core search service; Step B6: The core search service returns the search results, the intelligent virtualization processing layer updates the local pre-index, and returns the results to the terminal client. Step B7: The terminal client receives and displays the search results, supporting result sorting and secondary filtering.

9. The email system data processing method based on a large client load balancing mechanism as described in claim 7, characterized in that, The batch operations specifically include: Step C1: The terminal layer client receives the user's batch operation request and parses the operation type, target email ID list, and user ID; Step C2: Send the request to the batch operation processing optimization service of the intelligent virtualization processing layer; Step C3: The intelligent virtualization processing layer generates a unique operation identifier and immediately returns to the terminal client. The terminal displays a notification that the operation has been accepted and supports querying the progress by operation identifier. Step C4: The intelligent virtualization processing layer breaks down the batch requests into multiple individual deletion subtasks and adds them to a distributed asynchronous processing queue; Step C5: The background consumption queue task of the intelligent virtualization processing layer executes the email deletion operation in sequence, updates the cached data of the intelligent virtualization processing layer, and synchronizes it to the core email service; Step C6: The core email service receives the synchronization request, updates the email status, and returns the synchronization result; Step C7: The intelligent virtualization processing layer records the processing results of each subtask. After all tasks are completed, an operation result report is generated. Step C8: Notify the user that the operation is complete via the terminal client. The user can view the result report and retry failed tasks.

Images