Data processing method and related equipment

Abstract

The embodiment of the invention provides a data processing method and related equipment, the method is applied to a data processing system, the data processing system comprises a content distribution network and a server side, the server side comprises a main service cluster and a playback service cluster, and the main service cluster and the playback service cluster correspond to different cluster information respectively. The method comprises the following steps: if a target service cluster indicated by target cluster information included in task information of an updating task is obtained as a main service cluster, sending a task pulling request to the main service cluster, so that the main service cluster obtains updating data of the updating task based on task identification information in the task pulling request; if the target service cluster is a playback service cluster, sending a task pulling request to the playback service cluster, so that the playback service cluster obtains update data of the update task based on task identification information in the task pulling request; and updating the cache data in the node equipment according to the update data returned by the target service cluster, so that the task pulling efficiency can be improved.

Description

Technical Field

[0001] This application relates to the field of Internet technology, specifically to a data processing method and related equipment. Background Technology

[0002] With the development of internet technology, each node in a content delivery network is equipped with a corresponding refresh client and caching service before going live. The refresh client continuously requests refresh tasks from the server for that node and smoothly submits them to the node's caching service to delete old caches from the existing network.

[0003] Currently, each time a refresh client requests a task from the server, it fetches a maximum of 10,000 tasks (if the number of refresh tasks is less than 10,000, it fetches all existing refresh tasks). These tasks are then smoothly submitted to the local caching service. When there are network anomalies such as poor network quality, the task fetching speed of the refresh client will significantly slow down or even fail to fetch tasks. As a result, once the network recovers, a large number of refresh clients will be fetching tasks from the server through a single channel, causing some refresh clients to be unable to fetch tasks in a timely manner, leading to low task fetching efficiency. Summary of the Invention

[0004] This application provides a data processing method and related equipment that can improve task retrieval efficiency.

[0005] On one hand, embodiments of this application provide a data processing method applied to a data processing system. The data processing system includes a content delivery network and a server. The content delivery network includes node devices, and the server includes a main service cluster and a playback service cluster, each corresponding to different cluster information. The method includes:

[0006] Obtain the task information for the update task, which includes: target cluster information and task identifier information for the update task;

[0007] If the target cluster information indicates that the target service cluster is the main service cluster, then a task retrieval request is sent to the main service cluster so that the main service cluster can obtain the update data of the update task based on the task identifier information in the task retrieval request.

[0008] If the target service cluster indicated by the target cluster information is the playback service cluster, a task retrieval request is sent to the playback service cluster so that the playback service cluster can obtain the update data of the update task based on the task identifier information in the task retrieval request.

[0009] Receive update data from the update task returned by the target service cluster, and update the cached data in the node device according to the update data.

[0010] On one hand, embodiments of this application provide a data processing method applied to a data processing system. The data processing system includes a content delivery network and a server. The content delivery network includes node devices, and the server includes at least two service clusters, each corresponding to different cluster information. The target service cluster among the at least two service clusters includes a target access object and a target data proxy object. The method includes:

[0011] Through the target access object, receive task pull requests sent by node devices based on target cluster information; the task pull request includes task identifier information for updating tasks;

[0012] The task retrieval requests are merged using the server instance corresponding to the target access object, and the merged requests are sent to the target data proxy object through the target access object; the merged requests include task identification information.

[0013] By using the server instance corresponding to the target data proxy object, the update data of the update task is obtained based on the task identification information in the merged request, and the update data of the update task is returned to the target access object.

[0014] The update data for the update task is returned to the node device through the target access object.

[0015] On one hand, embodiments of this application provide a data processing method applied to a data processing system. The data processing system includes a content delivery network and a server. The content delivery network includes node devices, and the server includes at least two service clusters, each service cluster corresponding to different cluster information. The method includes:

[0016] Obtain node association information for node devices;

[0017] Based on the node association information, determine the target cluster information of the target service cluster used to obtain the update task from the cluster information corresponding to at least two service clusters.

[0018] Send the target cluster information to the central control module on the server so that the central control module can associate the target cluster information with the node devices.

[0019] On one hand, embodiments of this application provide a data processing method applied to a data processing system. The data processing system includes a content delivery network and a server. The content delivery network includes node devices, and the server includes at least two service clusters, each corresponding to different cluster information. The method includes:

[0020] Receive the task retrieval request sent by the receiving node device based on the target domain name information;

[0021] Determine the target service cluster indicated by the target domain name information;

[0022] Forward the task fetch request to the target service cluster. The task fetch request is used to request the target service cluster to obtain the update data of the update task based on the task identifier information in the task fetch request and return the update data of the update task. The target service cluster can be any one of at least two service clusters.

[0023] Return the updated data of the update task to the node device.

[0024] On one hand, embodiments of this application provide a data processing apparatus applied to a data processing system. The data processing system includes a content delivery network and a server. The content delivery network includes node devices, and the server includes a main service cluster and a playback service cluster, each corresponding to different cluster information. The apparatus includes:

[0025] The processing unit is used to obtain the task information of the update task, which includes: target cluster information and task identifier information of the update task.

[0026] The processing unit is also configured to send a task retrieval request to the main service cluster if the target service cluster indicated by the target cluster information is the main service cluster, so that the main service cluster can obtain the update data of the update task based on the task identifier information in the task retrieval request.

[0027] The processing unit is also configured to send a task retrieval request to the replay service cluster if the target service cluster indicated by the target cluster information is the replay service cluster, so that the replay service cluster can obtain the update data of the update task based on the task identification information in the task retrieval request.

[0028] The receiving unit is used to receive update data from the update task returned by the target service cluster, and update the cached data in the node device according to the update data.

[0029] On one hand, embodiments of this application provide a data processing apparatus applied to a data processing system. The data processing system includes a content delivery network and a server. The content delivery network includes node devices, and the server includes at least two service clusters, each corresponding to different cluster information. The target service cluster among the at least two service clusters includes a target access object and a target data proxy object. The apparatus includes:

[0030] The receiving unit is used to receive a task retrieval request sent by a node device based on target cluster information through the target access object; the task retrieval request includes the task identifier information of the update task;

[0031] The processing unit is used to merge task retrieval requests through the server instance corresponding to the target access object, and send the merged request to the target data proxy object through the target access object; the merged request includes task identification information;

[0032] The processing unit is also used to obtain the update data of the update task based on the task identification information in the merged request through the server instance corresponding to the target data proxy object, and return the update data of the update task to the target access object.

[0033] The processing unit is also used to return update data of the update task to the node device through the target access object.

[0034] On one hand, embodiments of this application provide a data processing apparatus applied to a data processing system. The data processing system includes a content delivery network and a server. The content delivery network includes node devices, and the server includes at least two service clusters, each corresponding to different cluster information. The apparatus includes:

[0035] The acquisition unit is used to acquire node association information of node devices;

[0036] The processing unit is used to determine the target cluster information of the target service cluster used to obtain the update task from the cluster information corresponding to at least two service clusters, based on the node association information.

[0037] The processing unit is also used to send target cluster information to the central control module on the server side, so that the central control module can associate the target cluster information with the node devices.

[0038] On one hand, embodiments of this application provide a data processing apparatus applied to a data processing system. The data processing system includes a content delivery network and a server. The content delivery network includes node devices, and the server includes at least two service clusters, each corresponding to different cluster information. The apparatus includes:

[0039] The receiving unit is used to receive task retrieval requests sent by node devices based on target domain name information;

[0040] The processing unit is used to determine the target service cluster indicated by the target domain name information;

[0041] The processing unit is also used to forward task retrieval requests to the target service cluster. The task retrieval request is used to request the target service cluster to obtain the update data of the update task based on the task identifier information in the task retrieval request and return the update data of the update task. The target service cluster can be any one of at least two service clusters.

[0042] The processing unit is also used to return update data for the update task to the node device.

[0043] On one hand, embodiments of this application provide a computer device, the computer device comprising:

[0044] A processor is used to execute computer programs;

[0045] A computer-readable storage medium storing a computer program, which, when executed by a processor, implements the data processing method described above.

[0046] On one hand, embodiments of this application provide a computer-readable storage medium storing a computer program that is loaded by a processor and executed as described above in the data processing method.

[0047] On one hand, embodiments of this application provide a computer program product, which includes a computer program or computer instructions, and the computer program or computer instructions implement the above-described data processing method when executed by a processor.

[0048] In this embodiment, a data processing system is provided. This system may include a content distribution network and a server. The content distribution network includes node devices, and the server may include a main service cluster and a replay service cluster. The main service cluster and the replay service cluster correspond to different cluster information. The node devices acquire task information for update tasks, including target cluster information and task identifier information for the update task. If the target cluster information indicates that the target service cluster is a main service cluster, a task retrieval request is sent to the main service cluster so that the main service cluster can obtain the update data of the update task based on the task identifier information in the task retrieval request. If the target cluster information indicates that the target service cluster is a replay service cluster, a task retrieval request is sent to the replay service cluster so that the replay service cluster can obtain the update data of the update task based on the task identifier information in the task retrieval request. The system receives the update data of the update task returned by the target service cluster and updates the cached data in the node devices according to the update data. As can be seen, by dividing the server into a main service cluster and a playback service cluster, and using different cluster information for differentiation, the node device can select to initiate a task retrieval request to the corresponding service cluster based on the obtained target domain name information, and thus obtain the update task through the corresponding service cluster. This effectively prevents the problem of low task retrieval speed caused by the node device in the content delivery network retrieving update tasks through only one service cluster (i.e., a single channel), and improves the efficiency of task retrieval. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of this application 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0050] Figure 1a An architecture diagram of a data processing system provided in this application embodiment;

[0051] Figure 1b An architecture diagram of another data processing system provided in this application embodiment;

[0052] Figure 2 A schematic diagram of a merged back-to-source architecture provided in an embodiment of this application;

[0053] Figure 3 A flowchart illustrating a data processing method provided in an embodiment of this application;

[0054] Figure 4 A flowchart illustrating a data processing method provided in an embodiment of this application;

[0055] Figure 5 A flowchart illustrating a data processing method provided in an embodiment of this application;

[0056] Figure 6 A flowchart illustrating a data processing method provided in an embodiment of this application;

[0057] Figure 7 This is a schematic diagram illustrating a process from querying heartbeat information to task distribution, provided as an embodiment of this application.

[0058] Figure 8 A flowchart illustrating a data processing method provided in an embodiment of this application;

[0059] Figure 9 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application;

[0060] Figure 10 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application;

[0061] Figure 11 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application;

[0062] Figure 12 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0063] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0064] First, the relevant technical terms provided in the embodiments of this application will be explained.

[0065] I. CDN (Content Delivery Network)

[0066] A CDN (Content Delivery Network) is a distributed network architecture designed to improve the speed and reliability of content delivery by distributing content to multiple geographically dispersed servers. The primary goal of a CDN is to reduce latency when users access websites or applications, improving content availability and performance. CDNs replicate and store content on multiple cache servers (also known as edge servers) deployed globally. When a user requests content from a website or application, the CDN routes the request to the nearest edge server based on the user's geographical location. This significantly reduces data transmission distance and time, thereby improving access speed.

[0067] II. Caching Service

[0068] Caching is a technology used for temporary data storage, designed to accelerate data access, reduce latency, and improve system performance. By storing frequently accessed data in memory, caching avoids requiring access to slower backend storage (such as databases or file systems) for every request, significantly improving data read speed and system response time. Caching services typically sit between the client and backend storage, acting as an intermediary layer. When a client requests data, the caching service first checks if the data exists in its cache. If the data exists (a cache hit), it is returned directly from the cache; if the data does not exist (a cache miss), it is retrieved from the backend storage and stored in the cache so that subsequent requests can access it more quickly.

[0069] III. Cache refresh

[0070] Cache refresh refers to the process of updating data in the cache to ensure consistency between the cached data and the source data. Cache refresh is a critical operation in cache management, designed to address the issue of expired or inconsistent cached data, thereby improving system reliability and data accuracy. While the primary purpose of caching is to improve data access speed and system performance, cached data may become outdated or inaccurate over time. To ensure users receive the latest and most accurate data, a cache refresh mechanism is essential. Cache refresh prevents users from accessing stale data, ensuring the system maintains data consistency while achieving high performance.

[0071] IV. Returning to the Source

[0072] Origin pull refers to the process of forwarding a user's request back to the origin server (i.e., the original data storage server) to retrieve the required data when the caching server (such as a CDN edge server or proxy server) cannot fulfill the request. Origin pull mechanisms are widely used in Content Delivery Networks (CDNs), caching systems, and proxy servers to ensure users can access the latest, uncached data. When a user requests a resource, the caching server first checks if the resource exists in its cache. If it exists in the cache and has not expired, the cached data is returned directly; if it does not exist in the cache or has expired, an origin pull operation is triggered, forwarding the request to the origin server. The origin server processes the request and returns the latest data, which the caching server then caches and returns to the user.

[0073] Currently, when CDN nodes go live, they deploy refresh clients and refresh services. The refresh clients on the nodes asynchronously request refresh tasks from the server. Each time a refresh client makes a request, it fetches a maximum of 10,000 tasks (if the number of tasks is less than 10,000, it fetches all existing refresh tasks) and then smoothly submits these tasks to the local caching service. After the caching service returns the corresponding execution results, the refresh client continues to fetch the next batch of refresh tasks from the server. Each refresh client request hits the server's access module, which then fetches refresh tasks from the storage layer. This current asynchronous request for refresh tasks from the server by the refresh client has the following problems:

[0074] 1. Network quality issues cause task backlog, preventing refresh clients from retrieving refresh tasks in a timely manner. Each refresh client needs to asynchronously request refresh tasks from the server. However, when network quality is poor, the task retrieval speed of refresh clients slows down significantly. In this case, tasks that cannot be retrieved in time will accumulate on the server, causing task backlog. This not only affects the timeliness of tasks but may also lead to task expiration and invalidation, thus impacting user experience. After the network recovers, lagging clients will make a large number of requests to the server, further increasing the pressure on the server, which may lead to system performance degradation or even crashes, and will also prevent refresh clients from retrieving refresh tasks in a timely manner.

[0075] 2. This leads to excessive server load. Each refresh client's request hits the server's access module, which then retrieves the corresponding task from the storage module. This means all requests use the same channel to fetch tasks from the storage layer. This single-channel design exhibits significant disadvantages during fault recovery, resulting in slow recovery speeds. As the number of refresh clients and the workload increase, the server's access module and storage layer face immense pressure. This centralized request processing method easily leads to server bottlenecks, impacting the overall system performance and stability. During peak periods, the server may be unable to respond to all refresh client requests in a timely manner, causing task processing delays and a degraded user experience.

[0076] 3. High risk of secondary failures. Since each refresh client independently requests and processes tasks, when the network recovers, lagging refresh clients will simultaneously send a large number of requests to the server, placing immense pressure on it. In this situation, the server may experience performance degradation or even crash, leading to secondary failures. Secondary failures not only affect system stability but may also result in task loss and a degraded user experience. Existing solutions lack effective mechanisms to prevent and respond to secondary failures.

[0077] 4. Lack of task priority management. In the current solution, the refresh client retrieves a fixed number of refresh tasks, lacking task priority management. This approach cannot prioritize tasks based on their importance and urgency, potentially causing some high-priority tasks to be delayed, impacting user experience. With a large workload, low-priority tasks may consume significant system resources, affecting the processing efficiency of high-priority tasks. The lack of task priority management makes it difficult for the system to efficiently process tasks while maintaining a good user experience.

[0078] To address the aforementioned issues, this application provides a data processing scheme applicable to a data processing system, which includes a CDN and a server. This application can divide the server's distribution layer into at least two service clusters, each using different cluster information (such as domain name information or URL (uniform resource locator)) to process and retrieve corresponding refresh tasks. For ease of description, taking at least two service clusters including a main service cluster and a replay service cluster as an example, in one implementation, different service clusters can handle refresh tasks of different task types; that is, the main service cluster can be used to obtain real-time refresh tasks, and the replay service cluster can be used to obtain historical refresh tasks. In another implementation, different service clusters can obtain refresh tasks for node devices of different device types; that is, the main service cluster can obtain refresh tasks for node devices with normal progress, and the replay service cluster can obtain refresh tasks for node devices with abnormal progress.

[0079] In some embodiments, the data processing scheme provided in this application can access a load balancer VIP (i.e., virtual service address) and process task retrieval requests corresponding to different cluster information according to the configured load balancing rules. This can distribute the network traffic of task retrieval requests to multiple server instances in the corresponding service cluster, thereby achieving load balancing. Furthermore, the scheme provided in this application adds a second-level caching logic. Specifically, in this application, the distribution layer is transformed into a merged origin-back architecture where the service cluster includes access objects (such as the access module) and the service cluster includes data proxy objects (such as the data-proxy module). For each service cluster, there are access objects and data proxy objects. When a node device obtains a refresh task through the service cluster, the access object and data proxy object can merge the task retrieval requests sent by the node device according to the merged origin-back scope mechanism. The data proxy object then retrieves the refresh task required by the node device from the storage layer. The server instances corresponding to the access object and the data proxy object can cache some refresh tasks. Thus, when the server instances corresponding to the access object and the data proxy object receive a task retrieval request, they can search for the corresponding refresh task in their own memory. The load balancer intelligently distributes the traffic of task pull requests to the corresponding server instances, and the two-level caching mechanism ensures that client requests can be effectively merged and processed after the network recovers, reducing the direct pressure on Redis.

[0080] The data processing solution provided in this application has the following beneficial effects:

[0081] (1) Improve system performance and stability. The multi-cluster task fetching and second-level caching logic provided in this application embodiment significantly slows down the task fetching speed of the client when network quality is poor. In this case, tasks that fail to be fetched in time will accumulate on the server side, leading to task backlog. This not only affects the timeliness of tasks but may also cause tasks to expire and become invalid, thus affecting user experience. The mechanism of merging the origin request range can combine multiple small-range requests into a large-range request, further reducing the number of processing operations and resource consumption on the server side. This optimization measure can significantly improve the performance and stability of the system and avoid server bottlenecks caused by high-concurrency requests.

[0082] (2) Reduced server-side pressure and optimized network traffic and bandwidth utilization. This application's embodiments employ a service cluster approach, with each service cluster including access objects and data proxy objects. This effectively avoids the problem of excessive pressure on the access and storage modules caused by all node devices acquiring refresh tasks through a single channel (i.e., only through the access module). This reduces server-side pressure and prevents potential performance degradation or even server crashes, thus avoiding secondary failures. The second-level caching logic allows for local storage of some task data on the client, reducing the amount of data transmitted between the client and server. The mechanism for merging origin requests can combine multiple small-scale requests into a large-scale request, reducing the frequency and amount of network transmission. This optimization effectively reduces network traffic and bandwidth consumption, improves network resource utilization, and significantly enhances system response speed and user experience, especially under poor network conditions.

[0083] (3) Improve task processing efficiency. By introducing a two-level caching logic and a multi-cluster fetching mechanism, node devices can fetch and refresh tasks according to the task type or device type through the corresponding cluster. This avoids the slow task fetching speed caused by all requests being fetched through a single cluster, thus improving the task processing efficiency of node devices. In addition, the two-level caching logic can store some task data locally at the lower layer, reducing the number of times the client frequently requests the server, thereby reducing the server load and improving the task processing efficiency of refreshing the client to a certain extent. Furthermore, by fetching tasks through multiple clusters, task priority management can be implemented, prioritizing tasks based on their importance and urgency, ensuring timely processing of high-priority tasks. Moreover, the load balancing mechanism of the VIP can dynamically adjust the allocation and processing of tasks according to the client's processing capacity and network conditions, thus avoiding task backlog and delays. These optimization measures can significantly improve task processing efficiency, ensure the timeliness and accuracy of tasks, and improve the overall system performance and user experience.

[0084] (4) Enhanced User Experience. By optimizing task processing workflows and improving system performance, the user experience has been significantly improved. Second-level caching logic reduces task processing latency and network transmission frequency, increasing system response speed. Task priority management and intelligent scheduling mechanisms ensure timely processing of high-priority tasks, avoiding task backlog and delays. These optimization measures significantly improve task processing efficiency and accuracy, ensuring timely response and satisfaction of user needs, and enhancing user satisfaction and experience.

[0085] The data processing system provided in the embodiments of this application will be described in detail below.

[0086] Please see Figure 1a This is an architectural diagram of a data processing system provided in an embodiment of this application. The data processing system may include a CDN and a server. The CDN may include at least one node device, and the server includes at least two service clusters, each corresponding to different cluster information, which may be domain name information or URL information. (Illustrative example, as shown below) Figure 1a In this context, at least two service clusters can include a primary service cluster and a replay service cluster. Specifically:

[0087] Before going online, node devices can install a corresponding refresh client (i.e., refresh agent) and caching service. The refresh client can request an update task (i.e., the refresh task) from the server and smoothly submit the updated data of the requested update task to the node device's caching service. The caching service is used to update the cached data in the node device based on the update task and delete the old cache in the node device. In this embodiment, node devices can be divided into node devices of a first device type and node devices of a second device type. The first device type can be a node device with normal progress, and the second device type can be a node device with abnormal progress (such as progress lag). A node device with normal progress refers to a node device that requests an update task from the server within a certain period of time; a node device with abnormal progress refers to a node device that does not request an update task from the server within a certain period of time.

[0088] A service cluster can include multiple server instances. The service cluster is used to process update tasks. In one implementation, different service clusters can be used to handle different update tasks. For example, the main service cluster handles real-time update tasks, and the replay service cluster handles historical update tasks. Historical update tasks are defined as those where the difference between the creation time and the current time is greater than or equal to a threshold. Conversely, real-time update tasks are those where the difference between the creation time and the current time is less than a threshold. In another implementation, different service clusters can be used to process update tasks for node devices of different device types. For example, the main service cluster processes update tasks for node devices of the first device type (e.g., devices with normal progress), and the replay service cluster processes update tasks for node devices of the second device type (e.g., devices with abnormal progress).

[0089] Among them, node devices can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0090] In some implementations, for security reasons, the server is deployed in an intranet environment. To enable CDN nodes to access server data, requests must be forwarded through the corresponding forwarding layer devices. Please refer to [link to relevant documentation]. Figure 1b This application provides an architecture diagram of another data processing system. This data processing system includes a refresh client, a forwarding layer, and a server; wherein:

[0091] ① The refresh client runs on the node device. The refresh client can initiate a task pull request using cluster information. This cluster information can be domain name information or URL information, such as... Figure 1b In the process, the refresh client can initiate a task fetching request using the domain name information. This task fetching request can be an HTTP (Hypertext Transfer Protocol) request.

[0092] ② The forwarding layer corresponds to a forwarding device. The forwarding device can receive task fetch requests from refresh clients and forward the received task fetch requests to the server. Specifically, the forwarding device is equipped with Nginx (a high-performance HTTP and reverse proxy web server). When a refresh client sends a task fetch request, the forwarding device can use the Nginx service to receive the task fetch request from the physical external network interface eth0, and then use the Nginx service to forward it to the server through the physical internal network interface eth1.

[0093] ③ The server-side can include a distribution layer and a storage layer; the distribution layer distinguishes different service clusters, and update tasks are pulled through different service clusters. In one implementation, such as... Figure 1b In this approach, the deployment layer can differentiate between primary service clusters and replay service clusters, using different cluster information for each. For example, cluster information includes `get_task_data` to indicate the primary service cluster, and `get_delay_task_data` to indicate the replay service cluster. By deploying primary and replay service clusters, the throughput of the storage layer can be smoothly pulled.

[0094] Furthermore, a two-tier access architecture is adopted on the server side. This access architecture includes access objects and data proxy objects. The distribution layer is transformed into a merged origin-to-origin architecture, where access objects return to the origin and data proxy objects return to the origin, thus implementing two-level caching logic. For example... Figure 2 The diagram shown is a schematic representation of a merge-to-source architecture provided in an embodiment of this application. Wherein:

[0095] A. The access object is used to refresh the client service and send the request back to the data proxy object. More specifically, the access object can receive task fetch requests forwarded by the forwarding device, process the task fetch requests (such as merging them), and then send the merged requests back to the data proxy object.

[0096] B. The data proxy object is responsible for merging the requests sent by the access object and pulling data from Redis, which is included in the storage layer (the data here may include update tasks).

[0097] It should be understood that the lower-level layer is divided into at least two service clusters, each including its own access object (i.e., the access module) and data proxy object (i.e., the data-proxy module). For example... Figure 1b In this context, the main service cluster includes access objects and data proxy objects, and the replay service cluster also includes access objects and data proxy objects.

[0098] As can be seen, this application embodiment, by differentiating service clusters at the lower layer and adopting a two-level deployment access architecture, can distinguish between node devices with normal progress and node devices with abnormal progress, and pull tasks in different service clusters respectively. This does not affect the task pulling of node devices with normal refresh progress, and also facilitates task pulling of node devices with abnormal progress, significantly improving the CDN refresh task processing efficiency and overall performance. Secondly, by replaying the service cluster to pull update tasks, the rate of replaying the update tasks can be determined without placing an excessive burden on Redis in the storage layer.

[0099] Furthermore, the distribution layer involved in this application embodiment may also include a central control module (i.e., a master module). The central control module is used to write the update tasks submitted by the user and the update data of the update tasks into the storage layer, and to return the task information of the update tasks to the node devices that need to pull the update tasks. The task information may include the task identifier information of the update task, the creation time of the update task, the cluster information of the service cluster that needs to pull the update task, etc.

[0100] Ensuring that node devices do not lag behind and that they correctly belong to the service cluster is crucial. To achieve this, a robust decision-making module is designed at the lower layer, which can be deployed on the server instance. This module can effectively handle device cluster issues in the event of system failure, preventing further problems. The decision-making module is used to determine the progress of the refresh client to identify the device type of the node device to which the refresh client resides, and synchronizes this information with the central control module to determine the client's behavior. Through this mechanism, the server can accurately determine whether a node device is experiencing abnormal progress and send the task information of the update task that the node device needs to fetch to the refresh client, guiding its task fetching behavior. Introducing a decision-making module in this embodiment can optimize the performance and stability of the data processing system.

[0101] ④ The storage layer can include MySQL and Redis. The MySQL storage layer can write user-submitted update tasks. Redis caches the update tasks written to MySQL, as well as the updated data from those tasks. Redis acts as a "caching layer" to reduce the load on MySQL (this caching is unrelated to CDN caching). In other words, the data broker will only request data from MySQL when it cannot retrieve it from Redis, thus reducing the number of requests to MySQL and protecting its performance.

[0102] It is evident that the dramatic increase in request volume placed enormous pressure on Redis. While Redis, as a high-performance in-memory database, excels in handling high concurrency requests, its performance and stability are still severely tested when faced with massive requests. Especially in CDN architectures, Redis is often used as a core component for caching and task queues. When the request volume exceeds its processing capacity, it may lead to increased response latency or even service unavailability. This embodiment of the application addresses this by introducing service cluster partitioning at the lower layer and incorporating second-level caching logic. This effectively merges and processes client requests, significantly reducing the direct pressure on the storage layer, improving system availability and reliability, and preventing secondary failures.

[0103] Secondly, the embodiments of this application enable effective differentiation and management of the service cluster. This ensures that when a network failure occurs, all task retrieval requests will no longer retrieve tasks from Redis through the same channel (i.e., only through the access module). This effectively avoids a sudden increase in Redis load, which could even lead to the collapse of the Redis service. To a certain extent, this ensures the normal execution of update tasks and improves the stability and reliability of the entire system.

[0104] The data processing method provided in the embodiments of this application will be described in detail below.

[0105] Based on the above data processing system, please refer to Figure 3 This is a flowchart illustrating a data processing method provided in an embodiment of this application. In this embodiment, the access object included in the main service cluster is called the main access object, and the data proxy object included in the main service cluster is called the main data proxy object. The main access object and the main data proxy object respectively correspond to one or more server instances in the main service cluster; the access object included in the replay service cluster is called the replay access object, and the data proxy object included in the replay service cluster is called the replay data proxy object. The replay access object and the replay data proxy object respectively correspond to one or more server instances in the replay service cluster; the data processing method may include the following steps S301-S321:

[0106] S301. The node device sends a task information retrieval request to the server instance corresponding to the main access object. The task information retrieval request is used to request the update of the task information.

[0107] Specifically, a refresh client is deployed on the node device. This refresh client can send a task information retrieval request to the server instance corresponding to the main access object through the main access object. The update task is used to update the cached data in the node device. Task information may include, but is not limited to: the task identifier information (such as ID) of the update task, the target cluster information of the target service cluster to be retrieved, the creation time of the update task, etc. The target cluster information can be domain name information or URL information; this embodiment does not impose any limitations.

[0108] S302. The server instance corresponding to the main access object forwards a task information retrieval request to the central control module. Correspondingly, the central control module can receive the task information retrieval request forwarded by the server instance corresponding to the main access object.

[0109] S303. In response to the task information acquisition request, the central control module returns the task information for the updated task to the server instance corresponding to the main access object.

[0110] In one implementation, the task information retrieval request includes the address information (such as IP address) of the node device. The central control module can determine the task identifier information of the update task and the target cluster information of the target service cluster to be retrieved based on the address information in the task information retrieval request. It then uses the task identifier information and target cluster information of the update task to be retrieved as the task information for the update task and returns it to the server instance corresponding to the main access object. For example, if the central control module stores user-submitted update tasks, and determines that the task identifier information of the update task to be retrieved by the node device is ID1 based on the address information in the task information retrieval request, then the central control module uses ID1 and the target cluster information as the task information for the update task and returns it to the server instance corresponding to the main access object. Optionally, the creation time of the update task can also be obtained from the central control module.

[0111] In one implementation, the central control module may obtain target cluster information in the following ways:

[0112] Method 1: The decision module can synchronize the progress information of the node devices with the central control module. The central control module can obtain the target cluster information by determining the target cluster information of the target service cluster used to pull the update task from at least two service clusters based on the progress information of the node devices or the node association information.

[0113] The process of determining the target service cluster for pulling the update task from at least two service clusters based on the node device's progress information may include: determining the device type of the node device based on its progress information; specifically, if the node device's progress information indicates that the node device has obtained an update task within the target time period, then the node device's device type is determined to be a first device type; if the node device's progress information indicates that the node device has not obtained an update task within the target time period, then the node device's device type is determined to be a second device type. Then, based on the node device's device type, the target service cluster information for pulling the update task is determined from at least two service clusters.

[0114] In this embodiment, at least two service clusters include a main service cluster and a replay service cluster. The main service cluster is used to obtain update tasks for node devices of a first device type, and the replay service cluster is used to obtain update tasks for node devices of a second device type. The target cluster information for the target service cluster used to pull update tasks can be determined from the at least two service clusters according to the type of the node device: if the device type of the node device is the first device type, then the target service cluster used to pull update tasks is determined to be the main service cluster, and the cluster information of the main service cluster is determined to be the target cluster information; if the device type of the node device is the second device type, then the target service cluster used to pull update tasks is determined to be the replay service cluster, and the cluster information of the replay service cluster is determined to be the target cluster information.

[0115] Method 2: The decision module can determine the target cluster information for the service cluster used to pull the update task from at least two service clusters based on the node association information of the node device. Then, the decision module sends the target cluster information to the central control module. The central control module can associate the target cluster information with the node device, so that when the node device sends a task information retrieval request, the central control module can directly obtain the target cluster information stored in its own memory.

[0116] The node association information may include, but is not limited to: the time when the task information acquisition request was initiated; the target address information; the heartbeat information reported by the node device in the historical time period; the priority of the update tasks that the node device needs to pull; the processing capacity of the node device; and the network status, etc.

[0117] ① Node association information includes the initiation time of the task information request. The server records the creation time of the update task. Based on the node association information of the node device, the target cluster information for pulling the update task is determined from the cluster information corresponding to at least two service clusters. This can include steps A-C: Step A: Determine the device type of the node device based on the creation time and initiation time of the update task. Specifically, if the difference between the creation time and initiation time of the update task is less than a time threshold, the device type of the node device is determined to be the first device type, and step B is executed; if the difference between the creation time and initiation time of the target update task is greater than or equal to the time threshold, the device type of the node device is determined to be the second device type, and step C is executed; in one implementation, the first device type can be a device type with normal progress, and the second device type can be a device type with abnormal progress (progress lag). Step B: If the device type of the node device is the first device type, the main service cluster is determined as the target service cluster for pulling the update task, and the cluster information of the main service cluster is determined as the target cluster information. Step C: If the device type of the node device is the second device type, then the replay service cluster is determined as the target service cluster for pulling update tasks, and the cluster information of the replay service cluster is determined as the target cluster information.

[0118] ② Node association information includes target address information. The server sets a whitelist; more specifically, the decision module has an entry point for setting a whitelist or blacklist. This entry point allows for the design of whitelists or blacklists for the address information of certain node devices. A whitelist can include multiple address information entries, each corresponding to one device. Devices on the whitelist can obtain update tasks using the main service cluster. Similarly, a blacklist can also include multiple address information entries, with each address corresponding to one device. Devices on the blacklist can obtain update tasks using the replay service cluster. Based on node association information, the target cluster information for obtaining the update task is determined from the cluster information corresponding to at least two service clusters. This includes: if the target address information of the node device is within the whitelist, the primary service cluster is determined as the target service cluster for obtaining the update task, and its cluster information is determined as the target cluster information; if the target address information of the node device is not within the whitelist, the replay service cluster is determined as the target service cluster for obtaining the update task, and its cluster information is determined as the target cluster information; or, if the target address information of the node device is not within the whitelist but is within the blacklist, the replay service cluster is determined as the target service cluster for obtaining the update task, and its cluster information is determined as the target cluster information. The flexibility and controllability of the system are further enhanced by flexibly setting whitelists and blacklists in the decision module.

[0119] ③ Node association information includes heartbeat information reported by the node device within a historical time period (e.g., the previous 1 hour, the previous 2 hours). Within this historical time period, the node device may report heartbeat information multiple times. In one implementation, when a node device pulls an update task from the server, the server records the heartbeat information once. Therefore, the decision module can query the heartbeat information reported by the node device within a historical time period in batches from the server. Heartbeat information is periodic communication between the node device and the server, used to confirm the node device's online status and health condition. By periodically querying heartbeat information (e.g., every two hours, every day), the decision module can obtain the latest device status, ensuring that the node device's progress does not lag behind.

[0120] The heartbeat information may include the address information of the node device and the time of the last reported heartbeat. Based on the node association information, the target cluster information for obtaining the update task is determined from the cluster information corresponding to at least two service clusters. This includes: Step 1, determining the device type of the node device based on the heartbeat information reported by the node device within a historical time period. In one implementation, when the heartbeat information reported by the node device within a historical time period only includes address information, this means that the node device has no task progress information, and the device type of the node device can be determined to be the second device type. Alternatively, if the node device has no progress information and still has not obtained heartbeat information after adding a preset time lag, the device type of the node device can be determined to be the second device type. When the heartbeat information reported by the node device within a historical time period includes address information and the time of the last reported heartbeat, if the difference between the time of the last reported heartbeat and the system time is less than or equal to a preset difference, the device type of the node device is determined to be the first device type; if the difference between the time of the last reported heartbeat and the system time is greater than a preset difference, the device type of the node device is determined to be the second device type. Step 2: If the node device is of the first device type, then the target service cluster for obtaining the update task is determined to be the main service cluster, and the cluster information of the main service cluster is determined to be the target cluster information. Step 3: If the node device is of the second device type, then the target service cluster for obtaining the update task is determined to be the replay service cluster, and the cluster information of the replay service cluster is determined to be the target cluster information.

[0121] In this embodiment, node devices of the second device type can also be processed. That is, node devices of the second device type can be set as devices that have lost progress. The decision module can mark the node device and mark it as a task-lost device. The decision module needs to perform special processing (such as marking) on ​​these devices to a certain extent to avoid these devices affecting the progress of the overall update task.

[0122] In some implementations, the decision-making module can update the address information (such as IP addresses) of node devices. During the heartbeat information query process, the decision-making module continuously updates the address information of all node devices in the CDN to prevent address information omissions. The main purpose of this step is to monitor the health status of node devices and update their status information in a timely manner. By regularly updating the address information of all node devices in the CDN, the decision-making module can ensure that the status information of all devices is up-to-date, avoiding erroneous decisions due to information lag.

[0123] ④ Node association information includes the task priority of the update task. The task priority can be determined according to the urgency of the update task. For example, if an update task is more urgent, its priority can be set to a higher priority. In one implementation, at least two service clusters include a main service cluster and a replay service cluster. The main service cluster can be used to handle update tasks with lower priority, and the replay service cluster is also used to handle update tasks with lower priority. Based on the node association information, the target cluster information for obtaining the update task is determined from the cluster information corresponding to the at least two service clusters. This includes: if the priority of the update task is lower than a preset priority, the main service cluster is determined as the target service cluster for obtaining the update task, and the cluster information of the main service cluster is determined as the target service cluster; if the priority of the update task is higher than the preset priority, the replay service cluster is determined as the target service cluster for obtaining the update task, and the cluster information of the replay service cluster is determined as the target cluster information. Therefore, this embodiment of the application, by implementing task priority management, that is, by allocating corresponding service clusters for priority processing according to the importance and urgency of the task, ensures the timely processing of high-priority tasks and effectively avoids task backlog and delays.

[0124] ⑤ Node association information includes the processing capacity and network status of the node device. Taking network status as an example, based on the node association information, the target cluster information for obtaining the update task is determined from the cluster information corresponding to at least two service clusters. This includes: if the network status of the node device is in state one (e.g., poor network quality), the replay service cluster is determined as the target service cluster for obtaining the update task, and its cluster information is determined as the target cluster information; if the network status of the node device is in state two (e.g., good network quality), the primary service cluster is determined as the target service cluster for obtaining the update task, and its cluster information is determined as the target cluster information. By using network status or processing capacity, the replay service cluster or the primary service cluster can be intelligently scheduled, dynamically adjusting the task allocation and processing methods, avoiding task backlog and delays, and improving task processing efficiency.

[0125] Method 3: After determining the target cluster information of the target service cluster for the pull update task, the decision module can associate the target cluster information with the node device. Then, after receiving the cluster information retrieval request sent by the central control module, the decision module can return the target cluster information associated with the node device to the central control module.

[0126] S304. The server instance corresponding to the main access object will return the task information of the update task to the node device.

[0127] In one implementation, the server instance corresponding to the primary access object can return the update task information to the node device through the primary access object. The node device can then receive the update task information returned by the server instance corresponding to the primary access object.

[0128] S305. The node device sends a task retrieval request to the load balancer based on the target domain name information in the task information. The task retrieval request includes task identification information.

[0129] The load balancer can be deployed based on Layer 7 Load Balancing (CLB). Node devices can send task fetch requests to the load balancer based on the target domain name information. The load balancer then routes the task fetch requests to the corresponding service cluster, enabling server instances in the service cluster to obtain the corresponding update tasks based on the task fetch request. In one implementation, the load balancer provides a Virtual Service Address (VIP) for the node devices, which can then send task fetch requests to the load balancer based on this VIP.

[0130] S306. The load balancer determines the target service cluster indicated by the target domain name information.

[0131] The target service cluster can be any one of at least two service clusters. When the at least two service clusters include the main service cluster and the replay service cluster, if the target service cluster is the main service cluster, then steps S307-S313 are executed; if the target service cluster is the replay service cluster, then steps S314-S321 are executed.

[0132] S307. If the target service cluster is a primary service cluster, the load balancer sends the task retrieval request to the server instance corresponding to the primary access object through the primary access object.

[0133] In this embodiment, the load balancer can process task pull requests from different service clusters according to pre-configured load balancing rules, thereby allocating task pull requests to one or more server instances in the corresponding service clusters to improve the availability and reliability of the data processing system. In one implementation, step S307 may include: determining the server instance to which the task pull request should be forwarded from one or more server instances corresponding to the main access object, based on pre-configured load balancing rules and the load information of each server instance in the main service cluster; and then sending the task pull request to the determined server instance through the main access object included in the main service cluster.

[0134] As an implementation, the load balancing rule could be, for example, to select the server instance with the lowest load indicated by the load information. In this case, the server instance with the lowest load among one or more server instances corresponding to the main access object can be determined as the server instance to which the task pull request should be forwarded.

[0135] S308. The server instance corresponding to the main access object merges the task retrieval requests to obtain the merged request.

[0136] In one implementation, the server instance corresponding to the main access object can store some update tasks. The server instance of the main access object can respond to a task retrieval request by querying its own memory for the update task identified by the task identifier information in the task retrieval request. If the update task identified by the task identifier information in the task retrieval request is found, the update data of that update task is directly retrieved from memory and returned directly to the node device (i.e., the task body). If the update task identified by the task identifier information in the query task retrieval request is not found, step S308 can be executed.

[0137] In this embodiment, the server instance corresponding to the main access object receives task pull requests from various node devices. Therefore, this application provides a mechanism for merging the origin pull scope, which can merge small-scale requests into large-scale requests. The specific implementation of step S308 may include: the server instance corresponding to the main access object performs merge processing on multiple task pull requests according to the merge origin pull scope mechanism to obtain the merged request.

[0138] As one implementation, the merged origin scope mechanism defines the direct merging of multiple task pull requests. For example, multiple task pull requests include task pull request 1 and task pull request 2. Task pull request 1 is used to pull the update task with task identifier information 1, and task pull request 2 is used to pull the update task with task identifier information 2. Then, task pull request 1 and task pull request 2 can be merged to obtain a merged request. The merged request includes task identifier information 1 and task identifier information 2.

[0139] As another implementation, the merge origin scope mechanism defines the merging of requests for update tasks that retrieve the same task identifier information. This means that from multiple task retrieval requests, the request for the update task with the same task identifier information can be identified and merged to obtain the merged request. For example, the server instance corresponding to the main access object receives task retrieval requests 1, 2, and 3; task retrieval request 1 requests the update task with task identifier information 1, task retrieval request 2 requests the update task with task identifier information 2, and task retrieval request 3 requests the update task with task identifier information 1. In this case, task retrieval request 1 and task retrieval request 3 can be merged to obtain the merged request, and task retrieval request 3 can be merged separately to obtain the merged request.

[0140] S309. The server instance corresponding to the main access object forwards the merged request to the server instance corresponding to the main data proxy object through the main data proxy object.

[0141] Correspondingly, the server instance corresponding to the master data proxy object can receive the merged request forwarded by the server instance corresponding to the master access object.

[0142] S310. The server instance corresponding to the master data proxy object processes the merged request, obtains the merge request, and sends the merge request to the storage layer through the master data proxy object.

[0143] Specifically, the server instance corresponding to the master data proxy object merges the merged requests to obtain a merge request. The storage layer includes Redis and MySQL. The server instance corresponding to the master data proxy object smoothly sends the merge request to Redis in the storage layer through the master data proxy object to obtain the updated data for the update task.

[0144] In one implementation, the server instance corresponding to the master data proxy object can store some update tasks. The server instance of the master data proxy object can respond to the merged request by querying the corresponding update task from its own memory based on the task identifier information in the merged request. If the corresponding update task is found, the update data for that update task is directly retrieved from memory and returned directly to the node device. If no update task is found, step S310 can be executed.

[0145] In this embodiment, the server instance corresponding to the master data proxy object receives task fetch requests from different server instances corresponding to the master access object. Therefore, this embodiment also employs a merge origin scope mechanism on the server instance corresponding to the master data proxy to merge requests from a smaller range. The specific implementation of step S310 may include: the server instance corresponding to the master data proxy object merges the received requests after different merge processing according to the merge origin scope mechanism to obtain a merged request. For details on how the server instance corresponding to the master data proxy object merges the received requests after different merge processing according to the merge origin scope mechanism, please refer to the specific implementation of merging multiple task fetch requests according to the merge origin scope mechanism described above, which will not be repeated here.

[0146] As can be seen, this application embodiment adds a two-level caching logic, that is, storing the update data of some update tasks in the server instances corresponding to the proxy objects and the data proxy objects in each service cluster. This allows some update tasks to be retrieved directly from the server instances without requesting from the server's storage layer. This not only improves task processing efficiency but also reduces the amount of data transmitted between the client and the server, lowering the server load. Furthermore, this application embodiment can merge multiple small-scale requests into a large-scale request through a merged origin scope mechanism, reducing the frequency and amount of network transmission. This optimization effectively reduces network traffic and bandwidth consumption, improves network resource utilization, and significantly enhances system response speed and user experience, especially under poor network quality conditions.

[0147] S311. Based on the task identification information in the merge request, the storage layer returns the updated data of the update task to the server instance corresponding to the master data broker object.

[0148] S312. The server instance corresponding to the master data proxy object returns the update data of the update task to the server instance corresponding to the master access object through the master access object.

[0149] There are multiple update tasks. The server instance corresponding to the master data proxy object can aggregate the update data of multiple update tasks in memory and return the aggregated update data of the update tasks to the server instance corresponding to the master access object through the master access object.

[0150] S313. The server instance corresponding to the main access object returns the update data of the update task to the load balancer and executes S321.

[0151] S314. If the target service cluster is a replay service cluster, the load balancer sends the task retrieval request to the server instance corresponding to the replay access object through the replay access object.

[0152] In this embodiment, the load balancer can process task pull requests from different clusters according to pre-configured load balancing rules, thereby allocating the task pull requests to one or more server instances in the corresponding service cluster to improve the availability and reliability of the data processing system. In one implementation, step S314 may include: determining the server instance to which the task pull request should be forwarded from one or more server instances corresponding to the replay access object, based on pre-configured load balancing rules and the load information of each server instance in the replay service cluster; and then sending the task pull request to the determined server instance through the replay access objects included in the replay service cluster.

[0153] As an implementation, the load balancing rule could be, for example, to select the server instance with the lowest load indicated by the load information. In this case, the server instance with the lowest load among one or more server instances corresponding to the replay access object can be determined as the server instance to which the task pull request should be forwarded.

[0154] S315. The server instance corresponding to the replay access object merges the task retrieval requests to obtain the merged request.

[0155] In one implementation, the server instance corresponding to the replay access object can store some update tasks. The server instance of the replay access object can respond to a task retrieval request by querying its own memory for the update task identified by the task identifier information in the task retrieval request. If the update task identified by the task identifier information in the task retrieval request is found, the update data of that update task is directly retrieved from memory and returned directly to the node device. If the update task identified by the task identifier information in the query task retrieval request is not found, step S315 can be executed.

[0156] In this embodiment, the server instance corresponding to the replay access object receives task pull requests from various node devices. Therefore, this application provides a mechanism for merging the origin pull scope, which can merge small-scale requests into large-scale requests. The specific implementation of step S315 may include: the server instance corresponding to the replay access object performs merge processing on multiple task pull requests according to the merge origin pull scope mechanism to obtain the merged request.

[0157] One implementation is the merge origin scope mechanism, which directly merges multiple task fetch requests to obtain a merged request. Another implementation is the merge origin scope mechanism, which merges requests for tasks that fetch update tasks with the same task identifier. This involves identifying the requests for tasks that fetch update tasks with the same task identifier among multiple task fetch requests and merging them to obtain a merged request.

[0158] S316. The server instance corresponding to the replay access object forwards the merged request to the server instance corresponding to the replay data proxy object through the replay data proxy object.

[0159] Correspondingly, the server instance corresponding to the replay data proxy object can receive the merged request forwarded by the server instance corresponding to the replay access object.

[0160] S317. The server instance corresponding to the replay data proxy object processes the merged request, obtains the merge request, and sends the merge request to the storage layer through the replay data proxy object.

[0161] Specifically, the server instance corresponding to the replay data proxy object merges the merged requests to obtain a merge request. The storage layer includes Redis and MySQL; the merge request can be sent to Redis in the storage layer via the replay data proxy object to retrieve the updated data for the update task.

[0162] In one implementation, the server instance corresponding to the replay data proxy object can store some update tasks. The server instance of the replay data proxy object can respond to the merged request by querying the corresponding update task from its own memory based on the task identifier information in the merged request. If the corresponding update task is found, the update data for that update task is directly retrieved from memory and returned directly to the node device. If no update task is found, step S310 can be executed.

[0163] In this embodiment, the server instance corresponding to the replay data proxy object receives task fetch requests from different server instances corresponding to the replay access object. Therefore, this embodiment also employs a merge origin scope mechanism on the server instance corresponding to the replay data proxy to merge requests from a smaller range. The specific implementation of step S317 may include: the server instance corresponding to the replay data proxy object merges the received requests after different merging processes according to the merge origin scope mechanism to obtain a merged request. For details on how the server instance corresponding to the replay data proxy object merges the received requests after different merging processes according to the merge origin scope mechanism, please refer to the specific implementation of merging multiple task fetch requests according to the merge origin scope mechanism described above, which will not be repeated here.

[0164] S318. Based on the task identification information in the merge request, the storage layer returns the updated data of the update task to the server instance corresponding to the replay data proxy object.

[0165] S319. The server instance corresponding to the replay data proxy object returns the updated data of the update task to the server instance corresponding to the replay access object through the replay access object.

[0166] There are multiple update tasks. The server instance corresponding to the replay data proxy object can aggregate the update data of multiple update tasks in memory and return the aggregated update data of the update tasks to the server instance corresponding to the replay access object through the replay access object.

[0167] S320: Replay the server instance corresponding to the access object to return the update data of the update task to the load balancer, and execute S321.

[0168] S321. The load balancer returns the update data of the update task to the node device.

[0169] Correspondingly, the node device can receive update data from the update task returned by the load balancer and update the cached data in the node device based on the update data. Specifically, the refresh client in the node device can submit the update data of the update task to the refresh service, which updates the cached data based on the update data and returns the update result to the refresh client.

[0170] In this embodiment, the server includes at least two service clusters (such as a main service cluster and a replay service cluster). The central control module of the server can return task information for update tasks to the node devices. This task information includes target domain name information. The node devices can send task retrieval requests to the corresponding service clusters based on the target domain name information. Retrieving tasks through different service clusters avoids the slow task retrieval problem caused by retrieving update tasks from the same cluster, thus improving task processing efficiency. Secondly, each service cluster includes access objects and data proxy objects. Based on the access objects and data proxy objects, a two-level caching logic and a merge origin scope mechanism are provided, which can merge requests, reduce the frequency and amount of network transmission, effectively reduce network traffic and bandwidth consumption, improve network resource utilization, and significantly improve system performance and stability, avoiding server bottlenecks caused by high concurrency requests. In addition, this application can load balance requests sent to the service clusters through a load balancing mechanism, enabling dynamic adjustment and allocation of tasks, which can also improve task processing efficiency to a certain extent. Furthermore, the introduction of a decision module can significantly improve the refresh task processing efficiency and overall performance of the CDN system. In summary, by implementing service cluster partitioning, load balancing mechanisms, secondary caching logic, and decision-making modules, the CDN system's refresh task processing efficiency and overall performance have been significantly improved, enhancing the system's flexibility and controllability, and ensuring efficient operation under high concurrency and network fluctuation conditions.

[0171] Please see Figure 4 This is a flowchart illustrating a data processing method provided in an embodiment of this application. The data processing method can be applied to a data processing system, which includes a content delivery network and a server. The content delivery network includes node devices, and the server includes a main service cluster and a playback service cluster, each corresponding to different cluster information. The data processing method can be executed by the node devices in the system; more specifically, it can be executed by a refresh client running on the node devices. The data processing method may include the following steps S401-404:

[0172] S401. Obtain the task information for the update task. The task information includes: target cluster information and task identifier information for the update task.

[0173] In one implementation, step S401 may include: (1) sending a task information retrieval request to the main service cluster, which triggers the main service cluster to retrieve task information for the update task from the central control module of the server. Specifically, the main service cluster includes a main access object, which is deployed on one or more server instances in the main service node device. The node device can send a task information retrieval request to the server instance corresponding to the main access object through the main access object, and the server instance corresponding to the access object retrieves the task information for the update task from the central control module. (2) receiving the task information for the update task returned by the main service cluster. Specifically, receiving the task information for the update task returned by the server instance corresponding to the main access object through the main access object.

[0174] The target cluster information in the task information is determined by the decision module in the server based on the node association information of the node devices. Alternatively, it can be determined by the central control module in the server based on the node association information of the node devices.

[0175] S402. If the target cluster information indicates that the target service cluster is the main service cluster, then a task retrieval request is sent to the main service cluster so that the main service cluster can obtain the update data of the update task based on the task identifier information in the task retrieval request.

[0176] In one implementation, the node device can determine the target service cluster indicated by the target domain name information. If the target service cluster is a primary service cluster, a task retrieval request is sent to the primary service cluster based on the target domain name information. If the target service cluster is a replay service cluster, step S403 is executed, i.e., a task retrieval request is sent directly to the replay service cluster. In another implementation, the server sets up a load balancer. The node device sends a task retrieval request to the load balancer based on the target domain name information. This task retrieval request triggers the load balancer to forward the task retrieval request to the server instances in the primary service cluster according to the load information of each server instance after determining that the target service cluster indicated by the target domain name information is a primary service cluster.

[0177] The main service cluster includes a main access object and a main data proxy object. The main access object and the main data proxy object are deployed on one or more server instances in the main service cluster. Sending a task retrieval request to the main service cluster can include: sending a task retrieval request through the main access object, and the server instance corresponding to the main access object sending the merged request to the main data proxy object after merging the task retrieval request. The server instance corresponding to the main data proxy object then obtains the update data of the update task based on the task identification information included in the merged request.

[0178] S403. If the target service cluster indicated by the target cluster information is the playback service cluster, then a task retrieval request is sent to the playback service cluster so that the playback service cluster can obtain the update data of the update task based on the task identifier information in the task retrieval request.

[0179] In one implementation, if the node device determines that the target service cluster indicated by the target service cluster is a replay service cluster, the node device can send a task pull request to the replay service cluster. In another implementation, the node device sends a task pull request to the load balancer based on the target domain name information. This task pull request triggers the load balancer, after determining that the target service cluster indicated by the target domain name information is a replay service cluster, to forward the task pull request to the server instances in the replay service cluster according to the load information of each server instance.

[0180] The replay service cluster includes a replay access object and a replay data proxy object. The replay access object and the replay data proxy object are deployed on one or more server instances in the replay service cluster. Sending a task retrieval request to the replay service cluster can include: the server instance corresponding to the replay access object sends a task retrieval request through the replay access object. The task retrieval request is used to trigger the server instance corresponding to the replay access object to merge the task retrieval request and then send the merged request to the replay data proxy object through the replay access object. The server instance corresponding to the replay data proxy object obtains the update data of the update task based on the task identification information included in the merged request.

[0181] S404. Receive update data from the update task returned by the target service cluster, and update the cached data in the node device according to the update data.

[0182] In one implementation, when the target service cluster is the master service cluster, receiving the update data of the update task returned by the target service cluster may include: receiving the update data of the update task returned by the master access object, wherein the update data returned by the master access object is obtained by the master access object from the server instance corresponding to the master data proxy object.

[0183] In another implementation, when the target service cluster is a playback service cluster, receiving the update data of the update task returned by the target service cluster may include: receiving the update data of the update task returned by the playback access object, wherein the update data returned by the playback access object is obtained by the playback access object from the server instance corresponding to the playback data proxy object.

[0184] In this embodiment, task information for the update task is obtained, including target cluster information and task identifier information for the update task. If the target cluster information indicates a primary service cluster, a task fetch request is sent to the primary service cluster so that the primary service cluster can obtain the update data of the update task based on the task identifier information in the task fetch request. If the target cluster information indicates a replay service cluster, a task fetch request is sent to the replay service cluster so that the replay service cluster can obtain the update data of the update task based on the task identifier information in the task fetch request. The update data of the update task returned by the target service cluster is received, and the cached data in the node device is updated according to the update data. It can be seen that by dividing the primary service cluster and the replay service cluster, and distinguishing them by different cluster information, the node device can select to initiate a task fetch request to the corresponding service cluster based on the obtained target domain name information, thereby obtaining the update task through the corresponding service cluster. This effectively prevents the problem of low task fetching speed caused by node devices in the content delivery network fetching update tasks through only one service cluster, thus improving the efficiency of task fetching.

[0185] Please see Figure 5 This is a flowchart illustrating a data processing method provided in an embodiment of this application. The data processing method is applied to a data processing system, which includes a content delivery network and a server. The content delivery network includes node devices, and the server includes at least two service clusters, each corresponding to different cluster information. The target service cluster in the at least two service clusters includes a target access object and a target data proxy object, which are deployed on one or more server instances within the target service cluster. In one implementation, the at least two service clusters include a main service cluster and a replay service cluster. When the target service cluster is the main service cluster, the target access object is the main access object, and the target data proxy object is the main data proxy object. When the target service cluster is the replay service cluster, the target access object is the replay access object, and the target data proxy object is the replay data proxy object. The data processing method may include the following steps S501-S504:

[0186] S501. Receive a task retrieval request sent by a node device based on the target cluster information through the target access object; the task retrieval request includes the task identifier information for updating the task.

[0187] In one implementation, the server sets up a load balancer, which provides a virtual service address for the node devices; S501 can be: receiving a task retrieval request forwarded by the load balancer based on the target cluster information through the target access object; the task retrieval request is sent by the node device to the load balancer based on the virtual service address.

[0188] S502. Merge the task retrieval requests through the server instance corresponding to the target access object, and send the merged request to the target data proxy object through the target access object; the merged request includes task identification information.

[0189] It should be understood that the server instance corresponding to the target access object can receive task pull requests from multiple node devices in the CDN. At this time, the server instance corresponding to the target access object can merge these task pull requests according to the merge origin scope mechanism. That is, step S502 may include: merging multiple task pull requests according to the merge origin scope mechanism through the server instance corresponding to the target access object to obtain the merged request.

[0190] Optionally, the server instance corresponding to the target access object stores update data for some update tasks. Using the server instance corresponding to the target access object, the update data for the update task identified by the task identifier information can be retrieved from the stored update data. If the update data for the update task identified by the task identifier information is found, the update data for the corresponding update task is directly returned to the node device through the target access object. If the update data for the update task identified by the task identifier information is not found, then S502 is executed.

[0191] S503. Using the server instance corresponding to the target data proxy object, obtain the update data of the update task based on the task identification information in the merged request, and return the update data of the update task to the target access object.

[0192] In one implementation, the server instance corresponding to the target data proxy object may also receive merged requests from one or more server instances corresponding to the autonomous access object. Therefore, the specific implementation of step S503 may include: merging multiple merged requests according to the merge-back-to-origin rules through the server instance corresponding to the target data proxy object to obtain a merge request; the merge request includes task identification information; sending the merge request to the storage layer through the target data proxy object, which triggers the storage layer to return update data for the update task based on the task identification information; and obtaining the update data for the update task returned by the storage layer through the target data proxy object.

[0193] In another implementation, the server instance corresponding to the target data proxy object stores the update data of some update tasks. Obtaining the update data of the update tasks based on the task identification information in the merged request through the server instance corresponding to the target data proxy object can include: searching for the update data of the update task identified by the task identification information from the stored update data of the partial update tasks through the server instance corresponding to the target data proxy object; if the update data of the update task identified by the task identification information is found, then retrieving the update data of the update task identified by the task identification information from its own memory through the server instance corresponding to the target data proxy object; if the update data of the corresponding update task is not found, then retrieving the update data of the corresponding update task from the storage layer through the server instance corresponding to the target data proxy object based on the task identification information in the merged request.

[0194] As can be seen, a two-level caching logic can be formed by the target access object and the target data proxy object. Part of the task data can be stored in the server instance corresponding to the target access object and the server instance corresponding to the target data proxy object, which reduces the number of frequent requests to the storage layer in the server and thus reduces the load on the server.

[0195] S504. Return the update data of the update task to the node device through the target access object.

[0196] In one implementation, the target access object returns the update data of the update task to the load balancer, and the load balancer then returns the update data of the update task to the node device.

[0197] In some optional embodiments, after obtaining the update data of the update task identified by the task identification information from the storage layer, the server instance corresponding to the target access object and the server instance corresponding to the target data proxy object can cache the update data of the update task identified by the task identification information. In this way, if a node device needs to obtain the update data of the update task next time, it can directly retrieve the update data of the update task from its own memory and return it, which improves the task processing efficiency and avoids the storage layer from crashing due to a large number of requests being sent to the storage layer, thereby improving the stability of the data processing system.

[0198] Optionally, when the target service cluster is the primary service cluster, a task information retrieval request sent by the node device can be received through the target access object. In response to the task information retrieval request, the task identifier information and target cluster information of the update task to be pulled by the node device are obtained; the target cluster information and task identifier information are identified as the task information of the update task, and the task information of the update task is returned to the node device. The central control module stores the update tasks submitted by the user and the update data of the update tasks. Retrieving the task identifier information and target cluster information of the update task to be pulled by the node device can include: obtaining the task identifier information and target cluster information of the update task to be pulled by the node device from the control module on the server side through the target access object.

[0199] In this embodiment, the data processing system includes a content delivery network and a server. The content delivery network includes node devices, and the server includes at least two service clusters, each corresponding to different cluster information. The target service cluster among the at least two service clusters includes a target access object and a target data proxy object. The target access object receives task retrieval requests sent by the node devices based on the target cluster information. The task retrieval request includes task identifier information for the update task. The task retrieval requests are merged through the server instance corresponding to the target access object, and the merged request is sent to the target data proxy object through the target access object. The merged request includes task identifier information. The update data for the update task is obtained based on the task identifier information in the merged request through the server instance corresponding to the target data proxy object, and the update data for the update task is returned to the target access object. The update data for the update task is returned to the node devices through the target access object. As can be seen, the target service cluster in this embodiment includes a target access object and a target data proxy object. The task retrieval requests can be merged through the server instance corresponding to the target access object and the server instance corresponding to the target data proxy object. In this way, multiple task retrieval requests can be merged into one request, which can reduce the number of times the node device frequently requests the server, thereby reducing the server load, further reducing the number of processing operations and resource consumption on the server, optimizing the task processing flow and improving system performance, significantly improving the user experience, and ensuring that the user's needs are responded to and met in a timely manner.

[0200] Please see Figure 6This is a flowchart illustrating a data processing method provided in an embodiment of this application. The data processing system includes a content delivery network and a server. The content delivery network includes node devices, and the server includes at least two service clusters, each corresponding to different cluster information. The server may also deploy a robust decision module, which can effectively handle device cluster problems in the event of system failure, preventing other issues from arising. The data processing method can be executed by a target server instance with the decision module deployed in the server, or it can be executed by the decision module itself. The data processing method may include the following steps S601-S603:

[0201] S601. Obtain node association information of node devices.

[0202] S602. Based on the node association information, determine the target cluster information of the target service cluster used to obtain the update task from the cluster information corresponding to at least two service clusters.

[0203] The specific implementation of step S602 may include, but is not limited to, the following implementation methods:

[0204] Method 1: The server records the creation time of the object creation and update task, and the node association information includes the initiation time of the task information retrieval request; there are at least two service clusters, including a main service cluster and a replay service cluster; based on the node association information, the target cluster information for retrieving the update task is determined from the cluster information corresponding to the at least two service clusters, including: determining the device type of the node device based on the creation time and initiation time of the update task; if the device type of the node device is the first device type, then the target service cluster for retrieving the update task is determined to be the main service cluster, and the cluster information of the main service cluster is determined to be the target cluster information; if the device type of the node device is the second device type, then the target service cluster for retrieving the update task is determined to be the replay service cluster, and the cluster information of the replay service cluster is determined to be the target cluster information.

[0205] Method 2: The server has a whitelist containing multiple address information entries, each corresponding to a device; node association information includes target address information; at least two service clusters, including a primary service cluster and a replay service cluster; based on the node association information, the target cluster information for obtaining the update task is determined from the cluster information corresponding to the at least two service clusters, including: if the target address information is in the whitelist, the target service cluster for obtaining the update task is determined to be the primary service cluster, and the cluster information of the primary service cluster is determined as the target cluster information; if the target address information is not in the whitelist, the target service cluster for obtaining the update task is determined to be the replay service cluster, and the cluster information of the replay service cluster is determined as the target cluster information.

[0206] Method 3: The node association information includes heartbeat information reported by the node device within a historical time period, and at least two service clusters including a primary service cluster and a replay service cluster. Based on the node association information, the target cluster information for obtaining the update task is determined from the cluster information corresponding to the at least two service clusters, including: determining the device type of the node device based on the heartbeat information reported by the node device within a historical time period; if the device type of the node device is a first device type, then the target service cluster for obtaining the update task is determined to be a primary service cluster, and the cluster information of the primary service cluster is determined as the target cluster information; if the device type of the node device is a second device type, then the target service cluster for obtaining the update task is determined to be a replay service cluster, and the cluster information of the replay service cluster is determined as the target cluster information.

[0207] S603. Send the target cluster information to the central control module on the server so that the central control module can associate the target cluster information with the node devices.

[0208] In some alternative implementations, such as Figure 7 The diagram shown is a flowchart illustrating the process from querying heartbeat information to task distribution, as provided in an embodiment of this application. Figure 7 In the first step, the decision-making module performs the following steps: 1) Batch query heartbeat information: First, it needs to batch query the node information that reported heartbeat information within a historical time period to obtain the address information (such as IP address) of all node devices in the CDN. This information is recorded by the server after the refresh client pulls the update task. Heartbeat information is a periodic communication between the device and the server to confirm the device's online status and health status. Heartbeat information includes two parts: address information and the time of the last reported heartbeat. By periodically querying heartbeat information, the decision-making module can obtain the latest device status, ensuring that the progress of node devices is not lagging behind. 2) Update the address information of all node devices: During the heartbeat information query process, the decision-making module will continuously update the address information of all node devices in the current network to prevent address information from being missed. The main purpose of this step is to monitor the health status of node devices and update the device status information in a timely manner. By periodically updating the CDN's address information, the decision-making module can ensure that the status information of all node devices is up-to-date, avoiding incorrect decisions due to information lag. 3) Handling Nodes with Lost Task Progress: When an address with no progress is found, a preset time (e.g., 1 hour) is added to the progress. If the node still does not report a heartbeat, it is marked as a "task-lost device," classifying it as a second-type device (e.g., abnormal task progress). A "task-lost device" refers to a device that has not reported heartbeat or progress information within a historical time period. To prevent these nodes from affecting the overall task progress, the decision-making module needs to handle them specially.

[0209] Furthermore, embodiments of this application provide a distribution timer and asynchronous coroutines. The distribution timer is used to periodically trigger task distribution operations to determine whether the updated data of the corresponding update task can be distributed to each node device in a timely manner. The asynchronous coroutine is used to execute task distribution operations concurrently, improving the system's concurrency performance and response speed. Figure 7In this process, update tasks are stored in the storage layer. The server side includes multiple server instances that deploy the decision module. For example, server instance 1 can deploy the decision module, server instance 2 can deploy the decision module, and for ease of description, the target server instance is used as an example. The task distribution process includes the following steps: 4) When multiple node devices need to obtain the update data of the update task, the decision module in the target server instance starts a distribution timer. 5) When the timer expires, an asynchronous coroutine is started. 6) The decision module in the target server instance needs to acquire a distributed lock to ensure the synchronization of the distribution process. The distributed lock can prevent multiple server instances deploying the decision module from distributing tasks simultaneously, avoiding duplicate task distribution or conflicts. Specifically, the decision module in the target server instance looks up the distributed lock in the storage layer according to the lock name. 7) The decision module in the target server instance generates a unique identifier (UUID) for each node device based on the address information of each node device and the task identifier information of the update task. 8) During the distributed lock search process, it is determined whether the distributed lock name exists in the storage layer. If it exists, the distributed lock is updated, and the unique identifier corresponding to each node device is stored in the storage layer as the value of the distributed lock, thus successfully acquiring the distributed lock. 9) If the distributed lock name does not exist in the storage layer, the decision module in the target server instance inserts the distributed lock name into the storage layer, and stores the unique identifier corresponding to each node device as the value of the distributed lock, thus successfully acquiring the distributed lock. 10) After successfully acquiring the distributed lock, the decision module in the target server instance performs task distribution; that is, it can use asynchronous coroutines to distribute the update data of the update task obtained by the target service cluster to multiple node devices. Specifically, asynchronous coroutines can be used to distribute the update data of the update task obtained by the target service cluster to node devices through the access objects included in the target service cluster. 11) If the update data of the update task is successfully distributed, the decision module in the target server instance deletes the distributed lock. Optionally, after deleting the distributed lock, it is possible to continue querying the node information that reported heartbeat information within the historical time period. 12) If task distribution fails, check if the distribution timer has timed out. 13) If the distribution timer timed out, query the node information that reported heartbeat information in the historical time period to determine if the node device is the one that lost task progress. If it is, process the node device that lost task progress, i.e., execute step 3) above. 14) If the distribution timer did not time out, but the decision module in the target server instance failed to acquire the distributed lock, a retry mechanism can be implemented, i.e., continuously try to acquire the distributed lock within a certain time (e.g., 1 minute, 30 seconds, etc.).Specifically, the system can continue searching for the distributed lock in the storage layer based on its lock name within a certain time period. If the distributed lock is found in the storage layer based on its lock name within the time period, steps 10) to 13) can be executed. If the distributed lock is still not found in the storage layer based on its lock name within the time period, a prompt message can be output to indicate that the distributed lock acquisition failed.

[0210] It should be understood that when there are multiple node devices, a unique identifier is generated based on the address information of each node device. Subsequently, after the decision module in the target server instance acquires the distributed lock, it can store each node device's unique identifier as the value of the distributed lock in the storage layer. This ensures that only the server instance holding the distributed lock can distribute the update data of the update task obtained by the target service cluster to multiple node devices. After distributing the update data of the update task obtained by the target service cluster to multiple node devices, the decision module in the target server instance needs to delete the distributed lock to release the lock resource, allowing other server instances with decision modules deployed to perform task distribution operations. The process of deleting the distributed lock must ensure that only the server instance holding the distributed lock can delete it to avoid accidental deletion of the distributed lock.

[0211] In this embodiment, node association information of the node device is obtained; based on the node association information, target cluster information for obtaining the target service cluster for the update task is determined from the cluster information corresponding to at least two service clusters; the target cluster information is sent to the central control module of the server so that the central control module associates the target cluster information with the node device. It is evident that this embodiment can accurately determine the target cluster information for obtaining the update task for the node device based on the node association information, thereby improving the efficiency of task processing.

[0212] Please see Figure 8 This is a flowchart illustrating a data processing method provided in an embodiment of this application. The method is applied to a data processing system, which includes a content delivery network and a server. The content delivery network includes node devices, and the server includes at least two service clusters, each corresponding to different cluster information. The data processing method can be executed by a load balancer on the server and may include the following steps S801-S804:

[0213] S801, Receive node device sends task retrieval request based on target domain name information, the task retrieval request includes task identification information.

[0214] S802. Determine the target service cluster indicated by the target domain name information.

[0215] The target service cluster can be any one of at least two service clusters. Specifically, when the at least two service clusters include the main service cluster and the replay service cluster, if the target domain name information matches the domain name information corresponding to the main service cluster, then the target service cluster is determined to be the main service cluster; if the target domain name information matches the domain name information of the replay service cluster, then the target service cluster is determined to be the replay service cluster.

[0216] S803. Forward the task retrieval request to the target service cluster. The task retrieval request is used to request the target service cluster to obtain the update data of the update task based on the task identifier information in the task retrieval request and return the update data of the update task.

[0217] In one implementation, a task retrieval request is forwarded to the target service cluster. The task retrieval request is used to request the target service cluster to retrieve the update data of the update task from the storage layer based on the task identifier information in the task retrieval request and return the update data of the update task.

[0218] In another implementation, the target service cluster includes a target access object and a target data proxy object. The target access object and the target data proxy object are deployed in one or more server instances. The load balancer can forward task pull requests to the corresponding server instances through the target access object, so that the corresponding server instances can obtain the update data of the corresponding update task based on the task identification information in the task pull request.

[0219] In this embodiment, the load balancer includes load balancing rules. Based on these rules and the load information of each server instance corresponding to the target access object, the load balancer determines the server instance from among the server instances corresponding to the target access object to which the task fetch request should be forwarded. The target access object then forwards the task fetch request to the determined server instance. This allows the server instance corresponding to the target access object to merge the task fetch request and forward the merged request to the target data proxy object. The target data proxy object then retrieves the update data of the corresponding update task based on the task identifier information in the merged request. The determination of the server instance from among the server instances corresponding to the target access object based on the load balancing rules and the load information of the server instances corresponding to the target access object is described above. Figure 3 The relevant descriptions will not be repeated here.

[0220] S804: Receive the update data of the update task returned by the target service cluster, and return the update data of the update task to the node device.

[0221] The update data received from the target service cluster can include: the load balancer can receive the update data of the update task obtained by the server instance corresponding to the target data proxy through the target access object.

[0222] In this embodiment, the load balancer can determine the target cluster information indicated by the target domain name information and send the task fetch request sent by the node device to the corresponding target cluster information. This allows the target service cluster to obtain the update data of the update task based on the task identifier information in the task fetch request and return the update data. Furthermore, according to load balancing rules, the task fetch request can be forwarded to server instances in the target service cluster. This enables the server instances to respond to the task fetch request promptly, improving the efficiency of task fetching and enhancing the availability and reliability of the data processing system.

[0223] The data processing apparatus provided in the embodiments of this application will be described in detail below.

[0224] Please see Figure 9 , Figure 9 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application. The data processing device can be a computer program within a computer device, such as application software within the computer device; the data processing device can be used to execute... Figure 3 and Figure 4 Some or all of the steps in the method embodiments shown. Please refer to [link / reference]. Figure 9 The data processing device includes the following units:

[0225] Processing unit 901 is used to obtain task information of update task, including: target cluster information and task identifier information of update task;

[0226] The processing unit 901 is further configured to send a task retrieval request to the main service cluster if the target service cluster indicated by the target cluster information is the main service cluster, so that the main service cluster can obtain the update data of the update task based on the task identifier information in the task retrieval request.

[0227] The processing unit 901 is further configured to send a task retrieval request to the replay service cluster if the target service cluster indicated by the target cluster information is the replay service cluster, so that the replay service cluster can obtain the update data of the update task based on the task identifier information in the task retrieval request.

[0228] The receiving unit 902 is used to receive update data of the update task returned by the target service cluster, and update the cached data in the node device according to the update data.

[0229] The main service cluster includes the main access object and the main data proxy object, which are deployed on one or more server instances in the main service cluster.

[0230] When processing unit 901 sends a task retrieval request to the main service cluster so that the main service cluster can obtain the update data of the update task based on the task identifier information in the task retrieval request, it can be specifically used for:

[0231] Through the main access object, a task retrieval request is sent to the server instance corresponding to the main access object. The task retrieval request is used to trigger the server instance corresponding to the main access object to merge the task retrieval request and then send the merged request to the main data proxy object through the main access object. The server instance corresponding to the main data proxy object then obtains the update data of the update task based on the task identification information included in the merged request.

[0232] Receive update data from the target service cluster for the update task, including:

[0233] Receive update data from the update task returned by the main access object; the update data returned by the main access object is obtained by the main access object from the server instance corresponding to the main data proxy object.

[0234] Specifically, when processing unit 901 obtains task information for the update task, it can be used for:

[0235] Send a task information retrieval request to the main service cluster. The task information retrieval request is used to trigger the main service cluster to retrieve the task information for the updated task from the central control module on the server side.

[0236] Receive task information for update tasks returned by the main service cluster;

[0237] Among them, the target cluster information in the task information is determined by the decision module in the server based on the node association information of the node devices.

[0238] The server-side configuration includes a load balancer, which provides virtual service addresses for the node devices; the target cluster information indicates that the target service cluster includes multiple server instances.

[0239] When processing unit 901 sends a task retrieval request to the main service cluster if the target cluster information indicates that the target service cluster is the main service cluster, it can be specifically used for:

[0240] Based on the virtual service address, a task pull request is sent to the load balancer, so that after the load balancer determines that the target service cluster indicated by the target cluster information is the main service cluster, it forwards the task pull request to the server instances in the main service cluster according to the load information of each server instance.

[0241] In this embodiment, a data processing system is provided. This system may include a content distribution network and a server. The content distribution network includes node devices, and the server may include a main service cluster and a replay service cluster. The main service cluster and the replay service cluster correspond to different cluster information. The node devices acquire task information for update tasks, including target cluster information and task identifier information for the update task. If the target cluster information indicates that the target service cluster is a main service cluster, a task retrieval request is sent to the main service cluster so that the main service cluster can obtain the update data of the update task based on the task identifier information in the task retrieval request. If the target cluster information indicates that the target service cluster is a replay service cluster, a task retrieval request is sent to the replay service cluster so that the replay service cluster can obtain the update data of the update task based on the task identifier information in the task retrieval request. The system receives the update data of the update task returned by the target service cluster and updates the cached data in the node devices according to the update data. As can be seen, by dividing the server into a main service cluster and a playback service cluster, and using different cluster information for differentiation, the node device can select to initiate a task retrieval request to the corresponding service cluster based on the obtained target domain name information, and thus obtain the update task through the corresponding service cluster. This effectively prevents the problem of low task retrieval speed caused by the node device in the content delivery network retrieving update tasks through only one service cluster (i.e., a single channel), and improves the efficiency of task retrieval.

[0242] Please see Figure 10 , Figure 10 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application. The data processing device can be a computer program within a computer device, such as application software within the computer device; the data processing device can be used to execute... Figure 3 and Figure 5 Some or all of the steps in the method embodiments shown. Please refer to [link / reference]. Figure 10 The data processing device includes the following units:

[0243] The receiving unit 1001 is used to receive a task retrieval request sent by a node device based on target cluster information through a target access object; the task retrieval request includes task identifier information for updating tasks;

[0244] Processing unit 1002 is used to merge task retrieval requests through the server instance corresponding to the target access object, and send the merged request to the target data proxy object through the target access object; the merged request includes task identification information;

[0245] The processing unit 1002 is also used to obtain the update data of the update task based on the task identification information in the merged request through the server instance corresponding to the target data proxy object, and return the update data of the update task to the target access object.

[0246] The processing unit 1002 is also used to return update data of the update task to the node device through the target access object.

[0247] The number of merged requests is multiple. When processing unit 1002 obtains the update data of the update task based on the task identifier information in the merged requests through the server instance corresponding to the target data proxy object, it can be specifically used for:

[0248] The merged request is obtained by merging multiple merged requests using the server instance corresponding to the target data proxy object; the merged request includes task identification information.

[0249] A merge request is sent to the storage layer through the target data proxy object. The merge request is used to trigger the storage layer to return the updated data of the update task based on the task identification information.

[0250] The update data of the update task returned by the storage layer is obtained through the target data proxy object.

[0251] Among them, at least two service clusters include a primary service cluster, the target service cluster is the primary service cluster, and processing unit 1002 is also used for:

[0252] The target access object receives a task information retrieval request sent by the node device.

[0253] In response to a task information retrieval request, the task identifier information and target cluster information of the update task to be pulled by the node device are obtained.

[0254] The target cluster information and task identifier information are identified as the task information for the update task, and the task information for the update task is returned to the node device.

[0255] Specifically, when the processing unit 1002 obtains the task identifier information and target cluster information of the update task to be pulled by the node device, it can be used for:

[0256] By using the target access object, the task identifier information and target cluster information of the update task to be pulled by the node device are obtained from the central control module of the server.

[0257] Among them, the target cluster information in the task information is determined by the decision module in the server based on the node association information of the node devices.

[0258] The server-side configuration includes a load balancer, which provides virtual service addresses for the node devices. When the processing unit 1002 receives a task retrieval request from the node device based on the target cluster information via the target access object, it can specifically be used for:

[0259] Through the target access object, the task pull request is received by the load balancer based on the target cluster information; the task pull request is sent by the node device to the load balancer based on the virtual service address.

[0260] In this embodiment, the data processing system includes a content delivery network and a server. The content delivery network includes node devices, and the server includes at least two service clusters, each corresponding to different cluster information. The target service cluster among the at least two service clusters includes a target access object and a target data proxy object. The target access object receives task retrieval requests sent by the node devices based on the target cluster information. The task retrieval request includes task identifier information for the update task. The task retrieval requests are merged through the server instance corresponding to the target access object, and the merged request is sent to the target data proxy object through the target access object. The merged request includes task identifier information. The update data for the update task is obtained based on the task identifier information in the merged request through the server instance corresponding to the target data proxy object, and the update data for the update task is returned to the access object. The update data for the update task is returned to the node devices through the target access object. As can be seen, the target service cluster in this embodiment includes a target access object and a target data proxy object. The task retrieval requests can be merged through the server instance corresponding to the target access object and the server instance corresponding to the target data proxy object. In this way, multiple task retrieval requests can be merged into one request, which can reduce the number of times the node device frequently requests the server, thereby reducing the server load, further reducing the number of processing operations and resource consumption on the server, optimizing the task processing flow and improving system performance, significantly improving the user experience, and ensuring that the user's needs are responded to and met in a timely manner.

[0261] Please see Figure 11 , Figure 11 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application. The data processing device can be a computer program within a computer device, such as application software within the computer device; the data processing device can be used to execute... Figure 3 and Figure 6 Some or all of the steps in the method embodiments shown. Please refer to [link / reference]. Figure 11 The data processing device includes the following units:

[0262] The acquisition unit 1101 is used to acquire node association information of the node device;

[0263] Processing unit 1102 is used to determine the target cluster information of the target service cluster used to obtain the update task from the cluster information corresponding to at least two service clusters based on the node association information.

[0264] The processing unit 1102 is also used to send target cluster information to the central control module on the server side, so that the central control module can associate the target cluster information with the node devices.

[0265] The server records the creation time of the object creation and update task, and the node association information includes the initiation time of the task information retrieval request; there are at least two service clusters, including a main service cluster and a replay service cluster.

[0266] When processing unit 1102 determines the target cluster information for obtaining the target service cluster for the update task from the cluster information corresponding to at least two service clusters based on node association information, it can specifically be used for:

[0267] Determine the device type of the node device based on the creation time and initiation time of the update task;

[0268] If the device type of the node device is the first device type, then the target service cluster used to obtain the update task is determined to be the main service cluster, and the cluster information of the main service cluster is determined as the target cluster information.

[0269] If the device type of the node device is the second device type, then the target service cluster used to obtain the update task is determined to be the replay service cluster, and the cluster information of the replay service cluster is determined as the target cluster information.

[0270] The server has a whitelist, which includes multiple address information, each address corresponding to a device; the node association information includes the target address information; and there are at least two service clusters, including a main service cluster and a replay service cluster.

[0271] When processing unit 1102 determines the target cluster information for obtaining the target service cluster for the update task from the cluster information corresponding to at least two service clusters based on node association information, it can specifically be used for:

[0272] If the target address information is in the whitelist, the target service cluster used to obtain the update task is determined to be the main service cluster, and the cluster information of the main service cluster is determined as the target cluster information.

[0273] If the target address information is not in the whitelist, the target service cluster used to obtain the update task is determined to be the replay service cluster, and the cluster information of the replay service cluster is determined as the target cluster information.

[0274] Among them, the node association information includes the heartbeat information reported by the node device within a historical time period, and at least two service clusters include the main service cluster and the replay service cluster;

[0275] When processing unit 1102 determines the target cluster information for obtaining the target service cluster for the update task from the cluster information corresponding to at least two service clusters based on node association information, it can specifically be used for:

[0276] The device type of the node device is determined based on the heartbeat information reported by the node device within a historical time period;

[0277] If the device type of the node device is the first device type, then the target service cluster used to obtain the update task is determined to be the main service cluster, and the cluster information of the main service cluster is determined as the target cluster information.

[0278] If the device type of the node device is the second device type, then the target service cluster used to obtain the update task is determined to be the replay service cluster, and the cluster information of the replay service cluster is determined as the target cluster information.

[0279] The number of node devices is one or more, the update task is stored in the storage layer, and the processing unit 1102 is also used for:

[0280] When each node device needs to obtain the update data of the update task, it searches for the distributed lock in the storage layer according to the lock name of the distributed lock;

[0281] If a distributed lock is found, a unique identifier for each node device is generated based on the address information of each node device and the task identifier information of the update task.

[0282] The unique identifier corresponding to each node device is stored as the value of the distributed lock in the storage layer; and,

[0283] After obtaining the update data of the update task from the target service cluster, asynchronous coroutines are used to distribute the update data of the update task obtained from the target service cluster to multiple node devices.

[0284] Once the updated data distribution for the update task is complete, delete the distributed lock.

[0285] In this embodiment, node association information of the node device is obtained; based on the node association information, target cluster information for obtaining the target service cluster for the update task is determined from the cluster information corresponding to at least two service clusters; the target cluster information is sent to the central control module of the server so that the central control module associates the target cluster information with the node device. It is evident that this embodiment can accurately determine the target cluster information for obtaining the update task for the node device based on the node association information, thereby improving the efficiency of task processing.

[0286] The computer device provided in the embodiments of this application will be described in detail below.

[0287] Furthermore, this application also provides a schematic diagram of the structure of a computer device, which can be found in [reference needed]. Figure 12 The computer device may include a processor 1201, an input device 1202, an output device 1203, and a memory 1204. The processor 1201, input device 1202, output device 1203, and memory 1204 are connected via a bus. The memory 1204 stores a computer program, which includes program instructions. The processor 1201 executes the program instructions stored in the memory 1204. By running the program instructions stored in the memory 1204, the processor 1201 causes the computer device to perform the method steps in the foregoing embodiments of this application. Furthermore, the effects achieved after the computer device executes the method steps in the various embodiments via the processor can be referred to the description of the foregoing embodiments, and will not be repeated here.

[0288] In this application, the term "unit" refers to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more units. Furthermore, each unit can be part of an overall unit that includes the functionality of that unit.

[0289] Furthermore, it should be noted that this application also provides a computer-readable storage medium storing a computer program, which includes program instructions. When a processor executes these program instructions, it can execute the aforementioned... Figure 3-6 or Figure 8The methods described in the corresponding embodiments are therefore not repeated here. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application. As an example, program instructions may be deployed on a computer device, executed on multiple computer devices located in one location, or executed on multiple computer devices distributed in multiple locations and interconnected through a communication network.

[0290] According to one aspect of this application, a computer program product is provided, comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, enabling the computer device to perform the aforementioned... Figure 3-6 or Figure 8 The methods described in the corresponding embodiments will not be repeated here.

[0291] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0292] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method, characterized in that, The method is applied to a data processing system, which includes a content delivery network and a server. The content delivery network includes node devices, and the server includes a main service cluster and a playback service cluster, each corresponding to different cluster information. The method includes: Obtain the task information for the update task, the task information including: target cluster information and task identifier information of the update task; If the target service cluster indicated by the target cluster information is the main service cluster, then a task retrieval request is sent to the main service cluster so that the main service cluster can obtain the update data of the update task based on the task identifier information in the task retrieval request. If the target service cluster indicated by the target cluster information is the playback service cluster, then a task retrieval request is sent to the playback service cluster so that the playback service cluster can obtain the update data of the update task based on the task identifier information in the task retrieval request. The system receives update data from the target service cluster for the update task and updates the cached data in the node device based on the update data.

2. The method as described in claim 1, characterized in that, The main service cluster includes a main access object and a main data proxy object, and the main access object and the main data proxy object are respectively deployed in one or more server instances in the main service cluster; Sending a task fetch request to the main service cluster, so that the main service cluster can obtain the update data of the update task based on the task identifier information in the task fetch request, includes: Through the main access object, a task retrieval request is sent to the server instance corresponding to the main access object. The task retrieval request is used to trigger the server instance corresponding to the main access object to send the merged request to the main data proxy object through the main access object after merging the task retrieval request. The server instance corresponding to the main data proxy object obtains the update data of the update task based on the task identification information included in the merged request. The step of receiving the update data of the update task returned by the target service cluster includes: Receive the update data of the update task returned by the main access object; the update data returned by the main access object is obtained by the main access object from the server instance corresponding to the main data proxy object.

3. The method as described in claim 1, characterized in that, The task information for obtaining the update task includes: Send a task information retrieval request to the main service cluster. The task information retrieval request is used to trigger the main service cluster to retrieve the task information of the update task from the central control module of the server. Receive the task information of the update task returned by the main service cluster; The target cluster information in the task information is determined by the decision module in the server based on the node association information of the node device.

4. The method as described in claim 1, characterized in that, The server is configured with a load balancer, which provides a virtual service address for the node devices; the target service cluster indicated by the target cluster information includes multiple server instances. If the target service cluster indicated by the target cluster information is the primary service cluster, then a task retrieval request is sent to the primary service cluster, including: Based on the virtual service address, a task retrieval request is sent to the load balancer, so that after the load balancer determines that the target service cluster indicated by the target cluster information is the main service cluster, it forwards the task retrieval request to the server instances in the main service cluster according to the load information of each server instance.

5. A data processing method, characterized in that, The method is applied to a data processing system, which includes a content delivery network and a server. The content delivery network includes node devices, and the server includes at least two service clusters, each corresponding to different cluster information. The target service cluster in the at least two service clusters includes: a target access object and a target data proxy object, and the method includes: The target access object receives a task retrieval request sent by the node device based on the target cluster information; the task retrieval request includes task identifier information for updating the task. The task retrieval request is merged using the server instance corresponding to the target access object, and the merged request is sent to the target data proxy object through the target access object; the merged request includes the task identification information. Using the server instance corresponding to the target data proxy object, the update data of the update task is obtained based on the task identification information in the merged request, and the update data of the update task is returned to the target access object. The update data of the update task is returned to the node device through the target access object.

6. The method as described in claim 5, characterized in that, The number of merged requests is multiple. The step of obtaining update data for the update task based on the task identifier information in the merged requests, through the server instance corresponding to the target data proxy object, includes: The server instance corresponding to the target data proxy object is used to merge multiple merged requests to obtain a merge request; the merge request includes the task identification information. The target data proxy object sends the merge request to the storage layer, and the merge request is used to trigger the storage layer to return the updated data of the update task based on the task identification information; The update data of the update task returned by the storage layer is obtained through the target data proxy object.

7. The method as described in claim 5, characterized in that, The at least two service clusters include a primary service cluster, the target service cluster is the primary service cluster, and the method further includes: The target access object receives the task information acquisition request sent by the node device. In response to the task information acquisition request, the task identifier information and target cluster information of the update task to be pulled by the node device are obtained; The target cluster information and the task identifier information are used to determine the task information of the update task, and the task information of the update task is returned to the node device.

8. The method as described in claim 7, characterized in that, The step of obtaining the task identifier information and target cluster information of the update task to be pulled by the node device includes: The task identifier information and target cluster information of the update task to be pulled by the node device are obtained from the central control module of the server through the target access object. The target cluster information in the task information is determined by the decision module in the server based on the node association information of the node device.

9. The method as described in claim 5, characterized in that, The server is configured with a load balancer, and the load balancer provides virtual service addresses for the node devices. The step of receiving a task pull request from the node device based on the target cluster information through the target access object includes: Through the target access object, receive the task pull request forwarded by the load balancer based on the target cluster information; The task retrieval request is sent by the node device to the load balancer based on the virtual service address.

10. A data processing method, characterized in that, The method is applied to a data processing system, which includes a content delivery network and a server. The content delivery network includes node devices, and the server includes at least two service clusters, each corresponding to different cluster information. The method includes: Obtain the node association information of the node device; Based on the node association information, the target cluster information of the target service cluster used to obtain the update task is determined from the cluster information corresponding to the at least two service clusters. The target cluster information is sent to the central control module of the server so that the central control module can associate the target cluster information with the node device.

11. The method as described in claim 10, characterized in that, The server records the creation time of the object creation and update task, and the node association information includes the initiation time of the task information acquisition request; the at least two service clusters include a main service cluster and a replay service cluster. The step of determining the target cluster information for obtaining the update task from the cluster information corresponding to the at least two service clusters based on the node association information includes: The device type of the node device is determined based on the creation time and initiation time of the update task; If the device type of the node device is the first device type, then the target service cluster used to obtain the update task is determined to be the main service cluster, and the cluster information of the main service cluster is determined to be the target cluster information; If the device type of the node device is the second device type, then the target service cluster for obtaining the update task is determined to be the replay service cluster, and the cluster information of the replay service cluster is determined to be the target cluster information.

12. The method as described in claim 10, characterized in that, The server has a whitelist, which includes multiple address information, each address information corresponding to a device; the node association information includes target address information; the at least two service clusters include a main service cluster and a replay service cluster. The step of determining the target cluster information for obtaining the update task from the cluster information corresponding to the at least two service clusters based on the node association information includes: If the target address information is within the whitelist, then the target service cluster used to obtain the update task is determined to be the main service cluster, and the cluster information of the main service cluster is determined to be the target cluster information; If the target address information is not in the whitelist, then the target service cluster used to obtain the update task is determined to be the replay service cluster, and the cluster information of the replay service cluster is determined to be the target cluster information.

13. The method as described in claim 10, characterized in that, The node association information includes the heartbeat information reported by the node device within a historical time period, and the at least two service clusters include a main service cluster and a replay service cluster. The step of determining the target cluster information for obtaining the update task from the cluster information corresponding to the at least two service clusters based on the node association information includes: The device type of the node device is determined based on the heartbeat information reported by the node device within a historical time period. If the device type of the node device is the first device type, then the target service cluster used to obtain the update task is determined to be the main service cluster, and the cluster information of the main service cluster is determined to be the target cluster information; If the device type of the node device is the second device type, then the target service cluster for obtaining the update task is determined to be the replay service cluster, and the cluster information of the replay service cluster is determined to be the target cluster information.

14. The method as described in claim 10, characterized in that, The number of node devices is one or more, the update task is stored in the storage layer, and the method further includes: When each node device needs to obtain the update data of the update task, it searches for the distributed lock in the storage layer according to the lock name of the distributed lock; If the distributed lock is found, a unique identifier corresponding to each node device is generated based on the address information of each node device and the task identifier information of the update task. The unique identifier corresponding to each node device is stored as the value of the distributed lock in the storage layer; and... After the target service cluster obtains the update data of the update task, it uses asynchronous coroutines to distribute the update data of the update task obtained by the target service cluster to multiple node devices. Once the update data distribution for the update task is complete, the distributed lock is deleted.

15. A data processing apparatus, characterized in that, The device is applied to a data processing system, which includes a content delivery network and a server. The content delivery network includes node devices, and the server includes a main service cluster and a playback service cluster, each corresponding to different cluster information. The device includes: The processing unit is used to obtain task information for the update task, the task information including: target cluster information and task identifier information of the update task; The processing unit is further configured to send a task retrieval request to the main service cluster if the target service cluster indicated by the target cluster information is the main service cluster, so that the main service cluster can obtain the update data of the update task based on the task identifier information in the task retrieval request. The processing unit is further configured to send a task retrieval request to the playback service cluster if the target service cluster indicated by the target cluster information is the playback service cluster, so that the playback service cluster can obtain the update data of the update task based on the task identifier information in the task retrieval request. The receiving unit is used to receive the update data of the update task returned by the target service cluster, and update the cached data in the node device according to the update data.

16. A data processing apparatus, characterized in that, The device is applied to a data processing system, which includes a content distribution network and a server. The content distribution network includes node devices, and the server includes at least two service clusters, each corresponding to different cluster information. The target service cluster in the at least two service clusters includes: a target access object and a target data proxy object, and the device includes: The receiving unit is configured to receive a task retrieval request sent by the node device based on the target cluster information through the target access object; the task retrieval request includes task identifier information for updating the task; The processing unit is configured to merge the task retrieval request through the server instance corresponding to the target access object, and send the merged request to the target data proxy object through the target access object; the merged request includes the task identification information; The processing unit is further configured to obtain the update data of the update task based on the task identification information in the merged request through the server instance corresponding to the target data proxy object, and return the update data of the update task to the target access object; The processing unit is further configured to return the update data of the update task to the node device through the target access object.

17. A data processing apparatus, characterized in that, The device is applied to a data processing system, which includes a content delivery network and a server. The content delivery network includes node devices, and the server includes at least two service clusters, each corresponding to different cluster information. The device includes: The acquisition unit is used to acquire the node association information of the node device; The processing unit is configured to determine the target cluster information of the target service cluster for obtaining the update task from the cluster information corresponding to the at least two service clusters based on the node association information. The processing unit is further configured to send the target cluster information to the central control module of the server, so that the central control module can associate the target cluster information with the node device.

18. A computer device, characterized in that, include: A processor is used to execute computer programs; A computer-readable storage medium storing a computer program, which, when executed by the processor, performs the data processing method according to any one of claims 1-14.

19. A computer-readable storage medium, characterized in that, The computer storage medium stores a computer program, which, when executed by a processor, performs the data processing method according to any one of claims 1-14.

20. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the data processing method according to any one of claims 1-14.

Images