System restarting method and device, equipment and storage medium

Abstract

The invention discloses a system restarting method and device, equipment and a storage medium, and the method comprises the steps: receiving a restarting instruction of a back-to-source service, building a shared storage unit, building a new first process for achieving the updated back-to-source service, closing a monitoring port of an old second process after a monitoring port of the first process is initialized, and starting the second process after the monitoring port of the second process is initialized. The new requests are collected to the first process to be processed, and updating of the back-to-source service is achieved in a hot restart mode; for a task which is not processed by a second process, a connection identification global mapping table is established in a shared storage unit, so that a first process can copy a to-be-processed data packet of the second process from the shared storage unit and put the to-be-processed data packet into a first thread of the first process for processing; in this way, the situation that request connection is interrupted or needed resources cannot be accessed can be reduced, and the success rate of obtaining the resources in the restarting period of the back-to-source service can be increased. The technical scheme of the invention can be widely applied to the technical field of networks.

Description

Technical Field

[0001] This application relates to the field of network technology, and in particular to a system restart method, apparatus, device, and storage medium. Background Technology

[0002] Currently, with the rapid development of information technology, related applications have gradually integrated into people's lives, providing a variety of services. Among them, a Content Delivery Network (CDN) is a distributed network architecture designed to provide efficient content transmission and delivery services. A CDN typically includes multiple nodes, which can cache resources on nodes closer to the requested object, thereby achieving fast content transmission and a low-latency access experience.

[0003] In existing technologies, in some cases, nodes in a content delivery network (CDN) may not have cached the resources required by a requested object. In such cases, the node will perform a back-to-origin operation through the origin service, querying the corresponding origin server to retrieve the resource based on the requested object's resource retrieval request. This type of back-to-origin operation can reduce the load on the origin server while satisfying the retrieval needs of various resources as much as possible. However, CDN nodes may undergo configuration updates, and the system's back-to-origin service may sometimes need to be restarted. During the restart process of the back-to-origin service, the requested object may encounter connection interruptions or be unable to access the required resources, reducing the success rate of resource retrieval and potentially leading to business losses.

[0004] In summary, the existing technologies have technical problems that need to be improved. Summary of the Invention

[0005] This application provides a system restart method, apparatus, device, and storage medium that achieves the update of the back-to-origin service through a hot restart, which can improve the success rate of obtaining resources during the back-to-origin service restart.

[0006] One aspect of this application provides a system restart method, including:

[0007] Receive the restart command from the origin service and establish a shared storage unit;

[0008] A first process is established according to the restart instruction, and the shared storage unit is mapped to the address space of the first process and the second process; wherein, the first process is the process that executes the return-to-origin service after restarting, and the second process is the process that executes the return-to-origin service before restarting. The first process includes a plurality of first threads, each first thread corresponding to a first queue, and the second process includes a plurality of second threads, each second thread corresponding to a second queue.

[0009] The listening port of the first process is initialized, and the listening port of the second process is closed after the initialization of the listening port of the first process is completed.

[0010] A global mapping table for connection identifiers is established and stored in the shared storage unit; wherein, the global mapping table for connection identifiers is used to store the relationships between various processes, threads and queues;

[0011] The first process is controlled to copy the data packets to be processed by the second process into the first queue according to the global mapping table of connection identifiers, and the first thread processes the data packets.

[0012] On the other hand, embodiments of this application provide a system restart device, including:

[0013] The receiving unit is used to receive restart commands from the origin service and establish a shared storage unit;

[0014] An establishment unit is used to establish a first process according to the restart instruction and map the shared storage unit to the address spaces of the first process and the second process; wherein, the first process is the process that executes the back-to-origin service after restarting, and the second process is the process that executes the back-to-origin service before restarting. The first process includes a plurality of first threads, each first thread corresponding to a first queue, and the second process includes a plurality of second threads, each second thread corresponding to a second queue.

[0015] An initialization unit is used to initialize the listening port of the first process and close the listening port of the second process after the initialization of the listening port of the first process is completed.

[0016] A mapping unit is used to establish a global mapping table for connection identifiers and store the global mapping table for connection identifiers in the shared storage unit; wherein, the global mapping table for connection identifiers is used to store the relationships between various processes, threads and queues;

[0017] The processing unit is configured to control the first process to copy the data packets to be processed by the second process into the first queue according to the global mapping table of connection identifiers, and to process the data packets through the first thread.

[0018] Optionally, in some embodiments, the system restart device further includes a generation unit, which is specifically used for:

[0019] In response to the interactive operation of the target object, obtain the target source address and target request parameters input by the target object;

[0020] The restart command is generated based on the target source address and the target request parameters.

[0021] Optionally, in some embodiments, the initialization unit is specifically used for:

[0022] The listening port of the first process is initialized, and the first start time of initialization is recorded;

[0023] Detect the first time interval between the current time node and the first starting time node;

[0024] If the first time interval is less than a preset first time threshold, return to the step of detecting the first time interval between the current time node and the first starting time node; or, if the first time interval is equal to the preset first time threshold, close the listening port of the second process.

[0025] Optionally, in some embodiments, the initialization unit is specifically used for:

[0026] Create the first socket and obtain the first file identifier corresponding to the first socket;

[0027] Based on the first file identifier, bind the first socket to the listening port of the first process;

[0028] The first socket is set to listening mode to complete the initialization of the listening port;

[0029] The first socket is used in the listening mode to receive external connection requests.

[0030] Optionally, in some embodiments, the establishing unit is specifically used for:

[0031] Obtain the first process identifier corresponding to the first process to be established, and the first thread identifier corresponding to each first thread in the first process;

[0032] Based on the first process identifier and the first thread identifier, the corresponding queue identifier is determined by random hashing;

[0033] Query whether the target queue corresponding to the queue identifier is in an available state. If the target queue is in an available state, determine the target queue as the first queue corresponding to the first thread.

[0034] Optionally, in some embodiments, the initialization unit is specifically used for:

[0035] Close the second socket and the second file identifier bound to the listening port of the second process;

[0036] After closing the listening port of the second process, the method further includes:

[0037] Detect whether a data packet being processed by the second thread exists;

[0038] If a data packet exists that is being processed by the second thread, a new third file identifier is created;

[0039] The third file identifier is used to send a prompt message to the requesting object corresponding to the data packet; wherein the prompt message is used to inform the requesting object that it is acquiring the target resource.

[0040] Optionally, in some embodiments, the mapping unit is specifically used for:

[0041] Obtain the first process identifier corresponding to the first process, the first thread identifier corresponding to the first thread, and the first queue identifier corresponding to the first queue;

[0042] Based on the first process identifier, the first thread identifier, and the first queue identifier, establish the first triplet information corresponding to each first queue;

[0043] Obtain the second process identifier corresponding to the second process, the second thread identifier corresponding to the second thread, and the second queue identifier corresponding to the second queue;

[0044] Based on the second process identifier, the second thread identifier, and the second queue identifier, establish the second triplet information corresponding to each second queue;

[0045] Based on the information of the first triplet and the information of the second triplet, a global mapping table for connection identifiers is established.

[0046] Optionally, in some embodiments, each thread locally stores a local connection identifier mapping table, which is periodically updated along with the global connection identifier mapping table; the processing unit is specifically used for:

[0047] The first thread queries the local connection identifier mapping table to check if there is a second queue of data packets that have not been copied.

[0048] If a second queue of uncopyable data packets exists in the local connection identifier mapping table, the data packets in the second queue are copied to the first queue corresponding to the first thread.

[0049] Optionally, in some embodiments, the processing unit is further configured to:

[0050] If the local connection identifier mapping table does not contain a second queue of uncopyable data packets, the first thread queries the global connection identifier mapping table to determine if a second queue of uncopyable data packets exists.

[0051] If a second queue of uncopyable data packets exists in the global mapping table of connection identifiers, the data packets in the second queue are copied to the first queue corresponding to the first thread.

[0052] Optionally, in some embodiments, the system restart device further includes a deletion unit, which is specifically used for:

[0053] Perform task status checks on each of the second threads in the second process;

[0054] If all the second threads of the second process are in an empty task state, delete the second process.

[0055] Optionally, in some embodiments, the deletion unit is further configured to:

[0056] Record the second start time node for establishing the first process;

[0057] Detect the second time interval between the current time node and the second starting time node;

[0058] If the second time interval equals a preset second time threshold, the second process is deleted.

[0059] The embodiments of this application include at least the following beneficial effects: This application provides a system restart method, apparatus, device, and storage medium. The method receives a restart instruction for a back-to-origin service, establishes a shared storage unit, and then establishes a new first process to implement the updated back-to-origin service. After the listening port of the first process is initialized, the listening port of the old second process is closed, so that all new requests are aggregated to the first process for processing. The update of the back-to-origin service is achieved through a hot restart. For tasks that the second process has not completed, a global mapping table of connection identifiers is established in the shared storage unit, so that the first process can copy the data packets to be processed by the second process from the shared storage unit and put them into its own first thread for processing. This can reduce the occurrence of interrupted request connections or inability to access required resources, and can improve the success rate of obtaining resources during the restart of the back-to-origin service. Attached Figure Description

[0060] The accompanying drawings are used to provide a further understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0061] Figure 1This is a schematic diagram illustrating the working principle of a content delivery network provided in the embodiments of this application;

[0062] Figure 2 This is a schematic diagram of a multi-level CDN architecture provided in the embodiments of this application;

[0063] Figure 3 This is a schematic diagram illustrating a CDN node restarting its origin service, as provided in an embodiment of this application.

[0064] Figure 4 This is a schematic diagram illustrating a process for restarting a back-to-origin service, provided in related technologies.

[0065] Figure 5 This is a system architecture diagram of the system restart method provided in the embodiments of this application;

[0066] Figure 6 This is a schematic diagram illustrating a method of providing streaming media services via CDN, as provided in an embodiment of this application.

[0067] Figure 7 This is a flowchart illustrating a system restart method provided in an embodiment of this application;

[0068] Figure 8 This is a schematic diagram of an application process for a back-to-origin service provided in an embodiment of this application;

[0069] Figure 9 This is a schematic diagram illustrating a process for executing a back-to-origin service restart task in both old and new processes, as provided in an embodiment of this application.

[0070] Figure 10 This is a structural block diagram of a system restart device provided in an embodiment of this application;

[0071] Figure 11 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0072] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0073] It is understood that the terms “first,” “second,” etc., used in this application may be used to describe various concepts herein, but unless otherwise stated, these concepts are not limited by these terms. These terms are used only to distinguish one concept from another.

[0074] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0075] Before providing a further detailed description of the embodiments of this application, the nouns and terms used in the embodiments of this application are explained, and the nouns and terms used in the embodiments of this application shall be interpreted as follows:

[0076] 1) A Content Delivery Network (CDN) is a distributed network architecture designed to provide efficient content delivery services. By deploying server nodes globally, a CDN caches content on nodes closer to the requesting user, achieving fast content delivery and a low-latency access experience. The working principle of a CDN is that when a user requests access to a website or application, the corresponding resources are replicated from the origin server to nodes closer to the user, based on the user's geographical location and network conditions. Thus, when a user initiates a request, the CDN delivers the content from the nearest node, reducing transmission distance and network congestion, thereby improving access speed and performance. The advantages of a CDN include accelerated content delivery, reduced bandwidth costs, improved reliability and stability, and support for global distribution. By optimizing content delivery, a CDN provides efficient, reliable, and stable network services, enhancing the user experience and website performance.

[0077] 2) The Domain Name System (DNS) is a distributed database used to translate readable domain names into computer-readable IP addresses. On the internet, when you enter a website's domain name, the DNS system looks up and returns the IP address corresponding to that domain name so that the device can find and connect to the correct server. This process is called DNS resolution. With DNS, you can easily access websites using easy-to-remember domain names instead of needing to remember complex IP addresses.

[0078] 3) Origin Fetch: CDN origin fetch refers to the process where a CDN node requests a resource from the origin server when it cannot directly obtain the required resource. When a user requests access to a website or application, the CDN node first checks if it has cached the required resource. If the resource exists in the cache, it is returned directly to the requesting user; otherwise, an origin fetch operation is required. The purpose of CDN origin fetch is to obtain the latest content or process dynamic requests to meet the needs of the requesting user. Origin fetch can reduce the load on the origin server and improve content transmission speed and response time.

[0079] 4) Process: A process is an abstraction of a program's execution in a computer, and it is the basic unit for system resource allocation and scheduling. Each process has its own independent memory space, including code, data, and a stack. Processes exchange information through various communication methods (such as pipes, sockets, and shared memory).

[0080] 5) Threads: A thread is an execution unit within a process and is the basic unit of scheduling by the operating system. Within the same process, threads share the process's memory space, including global and static variables, but each thread has its own stack for storing local variables and function call information. Communication between threads is mainly achieved through shared memory and semaphores. Compared to processes, thread creation and switching have lower overhead; therefore, in multi-core CPU environments, multithreading is often used to improve program execution efficiency.

[0081] 6) Queues: A queue is a data structure that follows the "first-in, first-out" principle. This means that the element inserted into the queue first will also be deleted first. Queues are commonly used in task scheduling, message passing, and other similar scenarios. Operating systems offer various types of queues, such as task queues (used to store tasks to be executed) and message queues (used for inter-process communication).

[0082] 7) Socket is a concept in computer networks. It is a network communication protocol interface that provides inter-process communication (IPC) or inter-process communication between different hosts. Sockets allow applications to send and receive data over the network and are the foundation for network communication.

[0083] 8) File Descriptor (FD): An integer value used in the operating system to identify and access files or other I / O resources. In Unix-like systems, each open file, device, or network connection is assigned a unique FD. The FD acts as a bridge between applications and the operating system, allowing applications to read, write, and close files or other I / O resources. Applications can manipulate FDs through system calls (such as open, read, write, close, etc.) to manage and control files or I / O resources. The advantage of using FDs is that they provide a unified way to handle different types of I / O resources. Whether it's a file, device, or network connection, applications can use the same operations for management, simplifying the programming process. By using FDs, applications can easily manage and manipulate I / O resources such as files, devices, and network connections, enabling data input / output and interaction. Simultaneously, the operating system can also use FDs to manage and control access to and sharing of these resources, ensuring system stability and security.

[0084] 9) UDS, short for Unix Domain Sockets, is an inter-process communication (IPC) mechanism in UNIX systems. It allows different processes on the same machine to exchange data efficiently, as if they were communicating within the same process. UDS is an abstraction layer based on the file system, providing an interface similar to network sockets (such as TCP or UDP) without involving the network protocol stack, thus offering lower overhead and higher efficiency.

[0085] 10) QUIC (Quick UDP Internet Connections) is a transport layer protocol based on UDP, designed to provide faster and more secure network connections. By integrating transport and application layer functions, QUIC reduces handshake latency and connection establishment time, thereby improving data transmission efficiency and performance. QUIC supports the simultaneous transmission of multiple data streams over a single connection, achieving multiplexing, which further improves concurrency and throughput. Simultaneously, QUIC incorporates encryption mechanisms, providing end-to-end data encryption and authentication to protect data security and privacy. QUIC's advantages lie in its fast connection establishment, multiplexing, and encrypted security.

[0086] Currently, with the rapid development of information technology, related applications have gradually integrated into people's lives, providing a variety of services. Among them, a Content Delivery Network (CDN) is a distributed network architecture designed to provide efficient content transmission and delivery services. A CDN typically includes multiple nodes, each a server device. A CDN can cache resources on nodes closer to the requested object, thereby achieving fast content transmission and a low-latency access experience.

[0087] For example, please refer to Figure 1 , Figure 1 A schematic diagram illustrating the working principle of a content delivery network provided in an embodiment of this application is shown. Figure 1 As shown, when requesting object 110 wants to obtain a specified network resource, it can initiate a resource acquisition request via a domain name. The resource acquisition request will be transmitted to the local DNS (LDNS) 120 for domain name resolution. The local DNS 120 checks its cache for an IP address record corresponding to the resource acquisition request. If found, it will be directly returned to the terminal device used by requesting object 110. If not, the local DNS 120 will further query the website's authoritative DNS 130. The website's authoritative DNS 130 can perform further domain name resolution on the resource acquisition request to obtain the IP address corresponding to the network resource; alternatively, the local DNS 120 can request the DNS scheduling system 140 to allocate a relevant IP address for the resource acquisition request, so that the local DNS 120 can return the IP address corresponding to the resource acquisition request to requesting object 110 after obtaining it.

[0088] Request object 110 can use the obtained IP address to initiate an access request to the specified resource. The access request will be transmitted to a node in CDN150, typically the node closest to request object 110, for example... Figure 1 The process involves several steps. First, the target node 151 retrieves the resource. If the resource is already cached on target node 151, it returns the resource to the requesting object, completing the resource retrieval request and response. Second, if the resource is not cached on target node 151, it sends a request for the resource to origin server 160. Once the resource is retrieved, CDN target node 151 caches the resource according to the configured caching strategy and returns it to the requesting object 110, completing the resource retrieval request and response.

[0089] Understandably, a CDN transmits content from the nearest node to the requested object, reducing transmission distance and network congestion, thereby improving access speed and performance. Figure 1As shown in the process, when a requesting object accesses relevant network resources via an IP address, if the CDN node does not have the cached resource, it will request the corresponding resource from the origin server. This process is called CDN origin pull. CDN nodes can satisfy the resource acquisition needs of the requesting object through origin pull services, while simultaneously supplementing and improving cached resources. Thus, when the requesting object accesses the resource again, the CDN node will have the corresponding resource cached, enabling faster resource delivery.

[0090] Currently, with the development of CDN technology, in order to reduce the origin server access operations for requested objects and alleviate the load pressure on the origin server, CDNs generally adopt a multi-level platform deployment strategy. For example, please refer to... Figure 2 , Figure 2 This illustration shows a schematic diagram of a multi-level CDN architecture provided in an embodiment of this application. Figure 2 The CDN shown is mainly divided into three layers: the OC (OuterCenter) layer, the middle layer, and the SOC (Super Outer Center) layer. This architecture can effectively optimize CDN services and improve the efficiency and reliability of content distribution. Specifically, the OC layer, as the outermost layer of the entire network, is responsible for establishing communication connections with the terminal devices of the requesting objects and aggregating relevant resource acquisition requests. The middle layer undertakes the task of further optimizing requests and distributing content. The SOC layer, as the innermost layer of the entire network, undertakes higher-level caching and distribution functions to further reduce origin pull operations and provide faster response speeds. Each layer can include one or more nodes. In this embodiment, nodes can be divided and named according to the layer they belong to. For example, the OC layer can include OC node 1, OC node 2, OC node 3... OC node N (N is a positive integer). Different layers can include the same number of nodes or different numbers of nodes; this application does not impose any restrictions on this.

[0091] Of course, this is understandable. Figure 2 The CDN architecture shown is only for illustrative purposes to demonstrate a multi-tiered CDN architecture. In actual CDN deployment, the number of layers is not limited to this. Figure 2 The scenario shown may also involve one, two, or more than three layers; this application does not impose any restrictions on this.

[0092] exist Figure 2In the cascading multi-layered CDN application solution shown, origin pull services may be deployed at different layers. Origin pull services refer to the services within the CDN used to perform origin pull operations. During the application of a content delivery network, configuration updates may occur, and the related origin pull services may sometimes need to be restarted. In such cases, the requesting object may encounter connection interruptions or be unable to access the required resources, reducing the success rate of resource acquisition and potentially leading to business losses. For example, see reference... Figure 3 , Figure 3 This illustration shows a schematic diagram of a CDN node restarting its origin service, as provided in an embodiment of this application. Figure 3 In this scenario, assuming the current intermediate node's origin pull service needs to be updated and restarted, during the update, the intermediate node will create a new process to implement the corresponding origin pull service function. However, the old process corresponding to the origin pull service may still maintain a long connection with the previous level. For example... Figure 3 In CDN, persistent connections exist between the origin service processes of OC nodes and intermediate nodes. When subsequent requests access OC nodes, these persistent connections may be reused, causing the old processes to continue processing new requests. Particularly in Layer 4 acceleration scenarios, because multiple flows can be created simultaneously on a single connection, existing connections on the old processes may be used to forward traffic for more requests. This can significantly impact the success rate when the old processes time out and force exit, potentially causing many requests to encounter connection interruptions and fail to acquire network resources. In extreme cases, OC nodes may not even initiate new connections to the new origin service processes (because the connection pool has sufficient existing connections) until the old processes eventually exit, thus affecting the success rate of resource acquisition.

[0093] Reference Figure 4 , Figure 4This diagram illustrates a process for restarting a back-to-origin service, as provided in related technologies. When the back-to-origin service is updated, a new process is created based on the existing old process. After the new process completes initialization tasks such as configuration parsing, it attempts to acquire a file lock. Since an old process already holds the lock, the new process fails to acquire it; this step is a non-blocking operation. After failing to acquire the file lock, the new process reads the process ID of the old process from the file and sends a notification signal to the old process, instructing it to release the lock. Then, the new process re-acquires the file lock in a blocking manner, waiting for the old process to release it. The main thread of the old process can pre-register response events for this notification signal. Upon receiving the notification signal from the new process, it enters a paused state and notifies the worker threads. Because this is a restart operation, the worker threads of the old process do not immediately close their listening ports. After ensuring that all worker threads have received the pause message, the old process releases the file lock. At this point, the new process ends its blocking and begins its workflow.

[0094] Generally, to allow startup time for the new process, the main thread of the old process will pause and wait for 2 seconds before reclaiming resources. During these two seconds, both the old and new processes will listen for relevant requests simultaneously. After the old process's main thread pauses for 2 seconds, it will formally notify its worker threads to exit and perform cleanup actions. Of course, the duration of the old process's main thread's pause can be flexibly set according to actual needs and is not fixed at 2 seconds. Afterward, the worker threads check whether the event queue is empty or whether the maximum exit wait time has expired. If either condition is met, the worker threads terminate their work. The maximum exit wait time is configurable, with a minimum of 5 seconds and a default of 5 minutes.

[0095] exist Figure 4 In the illustrated origin server restart process, because the old and new processes receive requests simultaneously, their respective threads may receive non-QUIC messages, easily leading to errors in message processing and preventing proper request handling. During the period from the old process releasing the file lock to the new process completing startup, connection interruptions may occur because the old process has closed its listening port while the new process has not yet established one, causing connection establishment failure. While changing the fixed 2-second delay to a configurable option and increasing it, for example to 10 seconds, provides a longer and overlapping transition period for simultaneous listening between the old and new processes, thus optimizing the connection failure issue caused by the longer initialization time of the new process, the correspondingly longer period of simultaneous message listening by both processes still presents an opportunity for errors.

[0096] It should be noted that the above Figure 4The illustrated origin server restart process is only used to provide a more in-depth introduction to the origin server restart process and does not imply any... Figure 4 The content shown is publicly available prior art.

[0097] In view of this, this application provides a system restart method. The method receives a restart instruction for the origin service, establishes a shared storage unit, and then establishes a new first process to implement the updated origin service. After the listening port of the first process is initialized, the listening port of the old second process is closed, so that all new requests are aggregated to the first process for processing. The update of the origin service is achieved through a hot restart. For tasks that the second process has not completed, a global mapping table of connection identifiers is established in the shared storage unit, so that the first process can copy the data packets to be processed by the second process from the shared storage unit and put them into its own first thread for processing. This can reduce the occurrence of interrupted request connections or inability to access required resources, and can improve the success rate of obtaining resources during the restart of the origin service.

[0098] System architecture and scenario description used in the embodiments of this application

[0099] Figure 5 This is a system architecture diagram of a system restart method provided in this application embodiment, which includes a terminal device 540, an Internet 530, a gateway 520, a backend server 510, etc.

[0100] In this embodiment, the terminal device 540 can install and run related applications, such as video playback applications and browser applications. The requesting object can initiate a resource acquisition request for related resources based on the applications on the terminal device 540. The terminal device 540 can include various forms such as desktop computers, laptops, PDAs (personal digital assistants), mobile phones, in-vehicle terminals, home theater terminals, and dedicated terminals. Furthermore, it can be a single device or a collection of multiple devices. The terminal device 540 can communicate with the Internet 230 via wired or wireless means to exchange data.

[0101] A backend server 510 refers to a computer system that can provide certain services to terminal devices 540. Compared to ordinary terminal devices 540, backend servers 510 have higher requirements in terms of stability, security, and performance. A backend server 510 can be a single high-performance computer in a network platform, a cluster of multiple high-performance computers, a portion of a single high-performance computer (e.g., a virtual machine), or a combination of portions of multiple high-performance computers (e.g., virtual machines).

[0102] Gateway 520, also known as an internetwork connector or protocol converter, is a computer system or device that acts as a translator, enabling network interconnection at the transport layer. It bridges the gap between two systems using different communication protocols, data formats, languages, or even completely different architectures. Gateways can also provide filtering and security functions. Messages sent from terminal device 540 to backend server 510 are forwarded to the corresponding backend server 510 via gateway 520. Messages sent from backend server 510 to terminal device 540 are also forwarded to the corresponding terminal device 540 via gateway 520.

[0103] The system restart method provided in this application embodiment can be executed on a background server 510, which can be a server node in a CDN.

[0104] The system restart method provided in this application can be executed in various scenarios, and the following is an exemplary description of it.

[0105] (I) Streaming Media Scenarios

[0106] Currently, with the continuous development of information technology, numerous streaming media applications have emerged. Streaming media is a technology that continuously transmits audio and video content over a network, allowing terminal devices to begin playing media files before the data is fully downloaded. Streaming media scenarios typically involve real-time or near-real-time content delivery, which can include online video, live audio broadcasts, IPTV, distance learning courses, live game streaming, video conferencing, and more.

[0107] The system restart method provided in this embodiment can be applied in streaming media scenarios. Please refer to... Figure 6 , Figure 6 This illustration shows a schematic diagram of providing streaming media services via CDN according to an embodiment of this application, such as... Figure 6 As shown, streaming media content providers can use CDNs to distribute streaming media content, which involves caching relevant business data on various CDN nodes. When someone wants to access the relevant streaming media resources, the nearest CDN node will respond to the request and deliver the streaming media resources to the relevant terminal device for playback and display.

[0108] for Figure 6 In the scenario shown, when a CDN node needs to restart and update its origin service, the method provided in this application embodiment can be used to reduce the impact on resource transmission services during the restart process and improve the stability and transmission efficiency of streaming media resource acquisition.

[0109] (II) Online shopping scenarios

[0110] Online shopping is currently very popular. E-commerce websites typically contain a large number of product images, videos, and related files, which can be transmitted using a CDN. By caching these static resources at edge nodes around the world, CDNs allow shoppers to access content from the nearest node, significantly reducing page load times and improving the online shopping experience, which is especially important for international e-commerce platforms.

[0111] In online shopping scenarios, when CDN nodes need to restart and update their origin services, the methods provided in this application embodiment can be used to improve the performance and availability of online shopping websites, indirectly promoting sales growth and increasing customer satisfaction.

[0112] General Description of Embodiments in this Application

[0113] Please refer to Figure 7 , Figure 7 A flowchart illustrating a system restart method provided in an embodiment of this application is shown. Figure 7 As shown, a system restart method according to one embodiment of this application includes:

[0114] Step 710: Receive the restart command for the origin service and establish a shared storage unit;

[0115] Step 720: Establish a first process according to the restart instruction, and map the shared memory unit to the address space of the first process and the second process; wherein, the first process is the process that performs the return-to-origin service after restarting, and the second process is the process that performs the return-to-origin service before restarting. The first process includes several first threads, each first thread corresponding to a first queue, and the second process includes several second threads, each second thread corresponding to a second queue.

[0116] Step 730: Initialize the listening port of the first process, and close the listening port of the second process after the initialization of the listening port of the first process is completed;

[0117] Step 740: Establish a global mapping table for connection identifiers and store the global mapping table for connection identifiers in a shared storage unit; wherein, the global mapping table for connection identifiers is used to store the relationships between various processes, threads and queues;

[0118] Step 750: Control the first process to copy the data packets to be processed by the second process into the first queue according to the global mapping table of connection identifiers, and process the data packets through the first thread.

[0119] The system restart method in this application embodiment can be applied to CDN nodes that provide origin recovery services. When performing a system restart, it can be performed on the origin recovery service alone, or it can be performed on the origin recovery service together with other services. This application does not impose any restrictions on this.

[0120] In step 710, when the origin service configured on the CDN node needs to be restarted, an instruction can be sent to the CDN node. In this embodiment, this instruction is referred to as a restart instruction. In this embodiment, there can be multiple triggering methods for the origin service restart instruction, such as automatic or manual triggering. Specifically, in some embodiments, a timed update strategy can be set. For example, a timed refresh interval for the origin service can be configured for each CDN node. When the time since the last restart reaches the set timed refresh interval, a restart instruction can be automatically triggered to achieve automated updates to the origin service. In some embodiments, CDN administrators or developers can interact through a relevant management interface to trigger the restart instruction, such as clearing the cache of specific content or iteratively updating the business functions of the origin service. In some embodiments, when encountering security issues, misconfigurations, or other emergencies, it may be necessary to immediately restart the origin service to apply remedial measures as quickly as possible. In this case, conditions corresponding to various specific situations can be pre-defined. When one or more conditions corresponding to specific situations are met, a restart instruction can be automatically triggered.

[0121] Of course, the above are some exemplary descriptions of restarting the origin service in the embodiments of this application, and are not intended to limit the triggering of the restart command for the origin service in this application. In actual execution, the restart command can be generated according to specific needs, which will not be elaborated here.

[0122] It should be noted that there are generally multiple nodes in a CDN, and each node can be configured with a corresponding origin service. When restarting the origin service, the origin service of one or more nodes can be restarted. That is, the restart command can be issued to one or more CDN nodes. For each node, it can execute the above steps 710 to 750 to realize the update and restart of the local origin service.

[0123] In step 710, when a restart instruction for the origin service is received, a shared storage unit can be established. Here, a shared storage unit refers to a data storage area that can be accessed and shared by multiple processes. In this embodiment, when updating and restarting the origin service, there will be both new and old processes corresponding to the origin service, i.e., a multi-process environment exists. The established shared storage unit allows different processes to share data in this multi-process environment. In this embodiment, the specific form of the shared storage unit is not limited; it can be part of physical memory or a logical storage space simulated by software. Shared storage enables multiple processes to directly access the same data, facilitating subsequent processing of data packets from older processes by newer processes. For example, in this embodiment, when establishing a shared storage unit, it can be created using APIs (Application Programming Interfaces) or library functions provided by the operating system. For instance, in a Unix-like system, the `shmget` function can be used to create a shared memory segment, which can then serve as a shared storage unit.

[0124] As mentioned earlier, when updating and restarting the origin service, there are both new and old processes corresponding to the origin service. The old process is the process that executed the origin service before the restart, referred to as the second process in this embodiment. The new process is the process that executes the origin service after the restart, referred to as the first process in this embodiment. Specifically, the first process may include several threads, referred to as the first thread, and each first thread corresponds to a queue, referred to as the first queue. The first queue can be used to transmit the data packets processed by the first thread. Similarly, the second process may also include several threads, referred to as the second thread, and each second thread corresponds to a queue, referred to as the second queue. The second queue can be used to transmit the data packets processed by the second thread. In this embodiment, the number of first threads in the first process and the number of second threads in the second process are not limited; they can both be one or more, and the number of first threads and second threads can be the same or different.

[0125] In step 720, upon receiving a restart command, a first process can be established based on the restart command. Specifically, in this embodiment, when establishing the first process, a starting point for the first process can be defined, typically the main function or entry point of the program. Then, relevant resources, such as memory space, file descriptors, and system resource handles, can be allocated to the first process, allowing it to run independently of other processes. In this embodiment, the restart command can also be used to specify the specific requirements for updating and restarting the origin service. When establishing the first process based on the restart command, some context data, such as the program counter, register state, and stack, can be copied from the original second process and modified based on relevant requirements, thereby quickly completing the establishment of the first process.

[0126] In step 720, after the new first process is established, the shared memory unit can be mapped to the address spaces of both the first and second processes. Mapping the created shared memory unit to the address spaces of related processes enables inter-process sharing of the shared memory unit. Subsequently, each process can read and write data within the mapped address space, thereby achieving data sharing and transmission. For example, in a Unix-like system, the `shmat` function can be used to map the shared memory unit, allowing both the first and second processes to directly access it.

[0127] It should be noted that, in the embodiments of this application, related locks (such as mutexes, semaphores) or other synchronization mechanisms can also be configured for the shared storage unit to prevent data contention and maintain the consistency of data within the shared storage unit.

[0128] In step 730, after the first process is established, its listening port can be initialized. Initializing the listening port enables it to receive client requests from the network. Here, the listening port is a specific network port number used to identify which port the process is waiting to connect on. Thus, once the first process's listening port is established, any client attempting to connect to that port can communicate with the first process. In the application of this embodiment, the first process's listening port can be used to receive and process resource acquisition requests initiated by a requesting object. For example, in a Unix-like system, functions such as `socket()`, `bind()`, `listen()`, and `accept()` can be used to initialize the listening port. Of course, in other programming languages, related operations can also be encapsulated as other library functions, and this application does not impose any limitations on this.

[0129] In this embodiment, after the initialization of the listening port of the first process is completed, the listening port of the second process can be closed. Here, the listening port of the second process is the port used by the origin service to receive resource acquisition requests initiated by request objects before restarting. After the listening port of the first process is initialized, it can be used normally to acquire and process resource acquisition requests initiated by request objects. Since the second process is the old process, to prevent the old process from also receiving and processing resource acquisition requests initiated by request objects, the listening port of the second process can be closed synchronously when the listening port of the first process is put into use. In this way, resource acquisition requests initiated by request objects will no longer be transmitted to the second process, allowing subsequent requests to be processed by the updated second process, thereby achieving the restart and update of the origin service.

[0130] Specifically, in this embodiment, when closing the listening port of the second process, it is possible to detect whether the listening port of the first process has been initialized. If the listening port of the first process has not yet been initialized, the listening port of the second process is temporarily retained to reduce the probability of requests from the requested object failing to connect normally. When the listening port of the first process has been initialized, a notification signal can be sent to the second process to inform it that the initialization of the listening port of the first process has been completed, thereby triggering the second process to close its corresponding listening port.

[0131] In step 730, when closing the listening port of the second process, the relevant function can be called first to prevent the second process from processing further new client requests. Next, the socket used for listening can be closed. In most systems, the corresponding system call or function can be used to close the listening socket. For example, in Unix-like systems, the `close()` function is typically used to close the listening socket; in C++, the `close()` or `shutdown()` functions can be used; in Python, the `socket.close()` method can be used to close the listening socket. Closing the listening socket will release the bound port and related resources.

[0132] It should be noted that, in this embodiment, closing the listening port of the second process does not immediately prevent connected clients from continuing to communicate. Connections established by the second process can continue for a period of time until either the client or the second process actively closes the connection. Therefore, even after closing the listening port of the second process, the second process may still have requests that need to be processed.

[0133] In step 740, a global connection ID (CID) mapping table can be established. This global connection ID mapping table is a data file used to track and manage different processes, threads, queues, and their connection and communication states within the system. This global mapping table helps the system effectively manage and coordinate multiple concurrent operations, especially in network services or multithreaded applications. Specifically, in this embodiment, the global connection ID mapping table stores the relationships between various processes, threads, and queues. For example, each process, thread, and queue can be assigned corresponding identification information, and then the relationships between these identification information can be stored, such as which process includes which threads, and which queue corresponds to each thread. Whenever a new process, thread, or queue is created, a corresponding entry can be added to the global mapping table. It should be noted that each process, thread, and queue needs to be assigned a unique identifier for accurate recording and differentiation. When a process, thread, or queue terminates, the corresponding entry can be removed from the global mapping table.

[0134] In step 740, the established global mapping table of connection identifiers can be stored in a shared storage unit so that the first process and the second process can use the data of each entry stored therein.

[0135] In step 750, the first process is the newly established and updated origin service process, and it is currently expected that all data packets related to the origin service will be processed by the first process. While the second process closed its listening port in step 730, it may still maintain long-lived connections with some clients, and there are still some data packets that need to be processed. In this embodiment, since the origin service is currently in an update and restart process, having the second process process the related data packets may cause the origin service to fail to achieve the expected results or even fail. Discarding or ignoring the data packets to be processed in the second process would result in some request objects' resource acquisition needs not being met. Therefore, in this embodiment, the first process is controlled to obtain the data packets to be processed by the second process based on the shared storage unit, and the first thread in the first process processes the data packets, thereby achieving a hot restart of the origin service and reducing the impact on real-time requests.

[0136] Specifically, in this embodiment, a relevant instruction can be sent to the first process. This instruction can control the first process to query the second queues based on the global mapping table of connection identifiers to determine which second queues still contain data packets awaiting processing by the second process. If a relevant queue is found, the first process can copy the data packets from these second queues from the shared storage unit to its own first queue, and process these data packets using the first thread corresponding to the first queue. This reduces the likelihood of interrupted connection requests or inability to access required resources, and improves the success rate of resource acquisition during origin service restarts.

[0137] It is understood that the system restart method provided in this application embodiment receives the restart instruction of the origin service, establishes a shared storage unit, and then establishes a new first process to implement the updated origin service. After the listening port of the first process is initialized, the listening port of the old second process is closed, so that all new requests are gathered to be processed by the first process. The update of the origin service is realized through hot restart. For tasks that the second process has not completed, a global mapping table of connection identifiers is established in the shared storage unit, so that the first process can copy the data packets to be processed by the second process from the shared storage unit and put them into its own first thread for processing. This can reduce the situation of encountering interrupted request connections or inability to access the required resources, and can improve the success rate of obtaining resources during the restart of the origin service.

[0138] Specifically, in some embodiments, the restart command is generated in the following manner:

[0139] In response to the interactive operation of the target object, obtain the target origin address and target request parameters input by the target object;

[0140] Generate a restart command based on the target source address and the target request parameters.

[0141] In this embodiment, when restarting a CDN node for origin server access, the restart command may be triggered by CDN maintenance personnel updating the origin server access policy. For example, a CDN node may be configured with a specific origin server address and request parameters. The origin server address indicates which server the CDN node requests resources from, and the request parameters are used to modify resource acquisition requests initiated by the requesting object. For instance, if the request parameters carried in the original resource acquisition request are inconsistent with the request parameters to be sent to the origin server, the request parameters configured on the CDN node can be used to replace the request parameters carried in the resource acquisition request, thereby achieving resource acquisition.

[0142] In this embodiment, updating the origin server service may involve updating the origin server address and request parameters. In this case, CDN maintenance personnel can configure the new origin server address and request parameters through interactive operations. In this embodiment, the maintenance personnel are designated as the target object, and the configured new origin server address and request parameters are designated as the target origin server address and target request parameters. Based on the target origin server address and target request parameters, a restart command can be generated to update and restart the configuration of the origin server service, thereby facilitating CDN nodes to obtain resources from the specified origin server.

[0143] Of course, it is understood that in the embodiments of this application, the target object is not limited to CDN maintenance personnel, but can be any object with management authority over CDN, and this application does not impose any restrictions on this.

[0144] Specifically, in some embodiments, the listening port of the first process is initialized, and the listening port of the second process is closed after the initialization of the listening port of the first process is completed, including:

[0145] Initialize the listening port of the first process and record the first start time of initialization;

[0146] Detect the first time interval between the current time node and the first starting time node;

[0147] If the first time interval is less than the preset first time threshold, return to the step of detecting the first time interval between the current time node and the first starting time node; or, if the first time interval is equal to the preset first time threshold, close the listening port of the second process.

[0148] In this embodiment, when closing the listening port of the second process, in some scenarios, the estimated initialization time of the listening port of the first process can be combined to achieve the closure of the listening port of the second process. Specifically, in this embodiment, the time required for initializing the listening port of a process in a CDN node can be pre-calculated, and an average value can be calculated. This average value is used as a preset time threshold, which is recorded as the first time threshold in this embodiment. Then, when initializing the listening port of the first process, the time node at which initialization begins is recorded, which is recorded as the first start time node in this embodiment. Next, the time interval between the current time node and the first start time node can be detected in real time, and this time interval is recorded as the first time interval. If the first time interval reaches the set first time threshold, it means that the first process has likely completed the initialization of the listening port, so the listening port of the second process can be closed at this time. Conversely, if the first time interval does not reach the set first time threshold, it means that the first process has likely not yet completed the initialization of the listening port, so the listening port of the second process can continue to be maintained, and the first time interval can be detected again.

[0149] Of course, it should be noted that the setting of the first time threshold in the above embodiments is not limited to the example of calculating the average initialization time of the listening port. In some embodiments, the first time threshold can also be set manually according to needs, for example, it can be set to 2 seconds, and this application does not limit its size.

[0150] It is understood that, in this embodiment of the application, by setting a first time threshold, the monitoring port of the second process can be automatically controlled. Once the monitoring port of the first process has completed initialization, there is no need to send a notification signal to the second process, which can reduce the communication overhead between processes and achieve the restart operation of the back-to-origin service more efficiently.

[0151] Specifically, in some embodiments, the listening port of the first process is initialized, including:

[0152] Create the first socket and obtain the first file identifier corresponding to the first socket;

[0153] Bind the first socket to the listening port of the first process based on the first file identifier;

[0154] Set the first socket to listening mode and complete the initialization of the listening port;

[0155] The first socket is used in listening mode to receive external connection requests.

[0156] In this embodiment, when initializing the listening port of the first process, in some embodiments, the port number of the listening port corresponding to the first process can be selected first. Generally, within a CDN node, each service will have a corresponding port preset as the listening port (such as port 80 for HTTP and port 443 for HTTPS). In this embodiment, there is no restriction on the port number of the listening port corresponding to the first process. Next, a network socket can be created in the first process. A socket is the basic unit of network communication, used to connect the client and the server. In this embodiment, it is denoted as the first socket, and the file identifier corresponding to the first socket can be obtained and denoted as the first file identifier. Through the first file identifier, the first socket and the listening port of the first process can be bound, so that the first socket will listen on the port selected by the first process. In this embodiment, the first socket can be set to listening mode so that it can accept new connection requests. When the requesting object sends a resource acquisition request, it can connect with the first process.

[0157] In this embodiment, the initialization of the listening port of the first process is achieved through the above-described method, which improves the flexibility of listening port usage and allows for customization of network communication details, such as selecting the transport protocol (TCP or UDP), setting the port number, specifying the buffer size, and handling concurrent connections. Furthermore, the socket mode can be used on various operating systems, such as Unix / Linux, Windows, and Mac OS, thereby expanding the applicability of CDN nodes.

[0158] Specifically, in some embodiments, establishing a first process based on a restart instruction includes:

[0159] Obtain the first process identifier corresponding to the first process to be established, and the first thread identifier corresponding to each first thread in the first process;

[0160] Based on the first process identifier and the first thread identifier, the corresponding queue identifier is determined by random hashing.

[0161] Check if the target queue corresponding to the queue identifier is in an available state. If the target queue is in an available state, determine the target queue as the first queue corresponding to the first thread.

[0162] In this embodiment of the application, during the process of establishing the first process, it is necessary to configure an available queue for the first process. Considering the load balancing and resource scheduling rationality between queues, this embodiment of the application provides an implementation strategy for randomly allocating a first queue to the first process.

[0163] Specifically, in this embodiment, each process and thread has a unique identifier. When allocating a first queue to a first process, the process identifier corresponding to the first process to be established can be obtained first; in this embodiment, this is recorded as the first process identifier. The thread identifiers corresponding to each first thread in the first process can also be obtained; in this embodiment, these are recorded as the first thread identifiers. For each first thread, a corresponding first queue needs to be allocated. In this embodiment, the corresponding queue identifier can be determined based on the first process identifier and the first thread identifier using a random hashing strategy. Here, random hashing refers to using a hash function combined with a certain degree of randomness to determine the queue identifier.

[0164] For example, in this embodiment, a hash function (such as MD5 or SHA-1) can be used to convert the string combining the first process identifier and the first thread identifier into a fixed-length hash value, and then a portion of this hash value (such as the first few characters) can be used as the queue identifier. Due to the characteristics of hash functions, different inputs may produce very different outputs, thus ensuring the randomness of the queue identifier to a certain extent. In this embodiment, after obtaining the queue identifier, it is possible to query whether the queue corresponding to the queue identifier (denoted as the target queue) is in an available state. If it is in an available state, the target queue can be determined as the first queue corresponding to the first thread. Conversely, if the target queue is not in an available state, another random queue can be re-determined as the first queue corresponding to the first thread. For example, the available queue closest to the target queue can be determined as the first queue corresponding to the first thread, and this application does not impose any restrictions on this.

[0165] It is understood that, in this embodiment of the application, determining the first queue corresponding to each first thread in the first process in a random manner can more evenly distribute the first threads of the first process across various queues, avoiding situations where some queues are overloaded while others are idle, thereby improving the overall processing capacity of the system. Furthermore, if a problem occurs in one or more queues, the random allocation method can reduce its impact on the entire first process, as other threads may continue to work normally in different first queues. Thus, the operational stability of the first process can be improved, the probability of its abnormal crash can be reduced, and consequently, the reliability of the origin service can be improved.

[0166] Specifically, in some embodiments, closing the listening port of the second process includes:

[0167] Close the second socket and the second file identifier bound to the listening port of the second process;

[0168] After closing the listening port of the second process, the method also includes:

[0169] Detect whether there are data packets being processed by a second thread;

[0170] If a data packet is being processed by a second thread, a new third file identifier is created;

[0171] A third file identifier is used to send a prompt message to the requesting object corresponding to the data packet; the prompt message is used to inform the requesting object that it is acquiring the target resource.

[0172] In this embodiment, the listening port of the second process can be established by referring to the establishment process of the listening port of the first process described above. It also has a corresponding bound socket and file identifier. In this embodiment, the socket used by the second process before restarting is denoted as the second socket, and the corresponding file identifier is denoted as the second file identifier. When the listening port of the second process is closed, the second socket and the second file identifier bound to the listening port of the second process can be closed.

[0173] As mentioned earlier, closing the listening port of the second process does not immediately prevent connected clients from continuing to communicate. Connections established by the second process can continue for a period of time until the client or the second process actively closes the connection. Therefore, although step 750 allows the first process to replace some data packets within the second process, since the second process itself is still running, some data packets may still be processed by it. For these data packets, since the second process itself is an expired process, the actual processing result may not meet expectations. Therefore, in this embodiment, it is possible to detect whether there are data packets being processed by the second thread of the second process. If so, within the CDN node, the result processed by the second process can be discarded, and the corresponding data packet can be sent to the upper-level CDN node for processing. For the requesting object, to reduce the adverse effects, in this embodiment, the connection between the second process and the requesting object is not interrupted. Instead, a new file identifier is established in the second process, referred to as the third file identifier in this embodiment. The third file identifier can be used to send a prompt message to the requesting object corresponding to the data packet, informing the requesting object that the CDN node is acquiring the target resource. In this way, the impact of disconnection on the requesting object can be reduced, while reminding the requesting object to wait appropriately for the target resource, thus improving the experience of the requesting object in obtaining resources as much as possible.

[0174] In this embodiment, the second process creates a new third file identifier to provide feedback information to the requesting object. This can achieve the response to some requests without interfering with the logic of the first process in processing other requests normally, thereby improving the continuity and stability of the origin service.

[0175] Specifically, in some embodiments, a global mapping table for connection identifiers is established, including:

[0176] Get the first process identifier corresponding to the first process, the first thread identifier corresponding to the first thread, and the first queue identifier corresponding to the first queue;

[0177] Based on the first process identifier, the first thread identifier, and the first queue identifier, establish the first triplet information corresponding to each first queue;

[0178] Get the second process identifier corresponding to the second process, the second thread identifier corresponding to the second thread, and the second queue identifier corresponding to the second queue;

[0179] Based on the second process identifier, the second thread identifier, and the second queue identifier, establish the second triplet information corresponding to each second queue;

[0180] Based on the information of the first triplet and the information of the second triplet, establish a global mapping table for connection identifiers.

[0181] In this embodiment of the application, when establishing the global identifier mapping table, the first process identifier corresponding to the first process, the first thread identifier corresponding to the first thread, and the first queue identifier corresponding to the first queue can be obtained; similarly, the identifiers corresponding to the second process, the second thread, and the second queue are also obtained. In this embodiment of the application, they are recorded as the second process identifier, the second thread identifier, and the second queue identifier.

[0182] Next, for each thread (or queue), the identifiers corresponding to its process, thread, and queue can be integrated to obtain a triplet, which can be represented as <process ID, thread ID, queue ID>. For example, for each first thread, a triplet can be constructed from the first process identifier, the first thread identifier, and the first queue identifier; in this embodiment, this is referred to as the first triplet. For each second thread, another triplet can be constructed from the second process identifier, the second thread identifier, and the second queue identifier; in this embodiment, this is referred to as the second triplet. A global mapping table for connection identifiers can be established using the first triplets for each first thread and the second triplets for each second thread.

[0183] Specifically, in some embodiments, each thread locally stores a local connection identifier mapping table, which is periodically updated along with the global connection identifier mapping table; controlling the first process to copy data packets to be processed by the second process into the first queue according to the global connection identifier mapping table includes:

[0184] The first thread checks the local connection identifier mapping table to see if there is a second queue of data packets that have not been copied.

[0185] If a second queue of data packets that have not been copied exists in the local connection identifier mapping table, copy the data packets in the second queue to the first queue corresponding to the first thread.

[0186] In this embodiment, each thread can also store a connection identifier mapping table locally, referred to as the local connection identifier mapping table. This local connection identifier mapping table can be updated periodically along with the global connection identifier mapping table. For example, each thread can periodically copy a copy of the global connection identifier mapping table from the shared storage unit and store it in its corresponding storage space. This application does not limit the period at which each thread updates its local connection identifier mapping table.

[0187] In this embodiment, when the first process copies the data packet to be processed by the second process into the first queue, it can first query the local connection identifier mapping table through the first thread to see if there is a second queue of uncopyable data packets. If it finds one, it can directly use the first queue corresponding to the first thread to copy the data packet and process the copied data packet. If it finds that there is no uncopyable data packet in the local connection identifier mapping table, the first process can further query the connection identifier global mapping table through the first thread to determine if there is a second queue of uncopyable data packets in the connection identifier global mapping table. If it finds one, it can use the first queue corresponding to the first thread to copy the data packet and process the copied data packet. If it does not find one in the connection identifier global mapping table either, it can process other newly arrived requests normally, or query the local connection identifier mapping table and the connection identifier global mapping table again after a period of time.

[0188] It is understood that in this embodiment of the application, the local connection identifier mapping table is stored locally in the first thread. When the first thread copies and obtains data packets from the second queue, it does not need to look up the connection identifier global mapping table every time. It can directly query the local connection identifier mapping table first, which can reduce the time spent by the first thread in obtaining relevant data packets and improve the processing efficiency of the back-to-origin service.

[0189] Specifically, in some embodiments, the method further includes:

[0190] Perform task status checks on each second thread of the second process;

[0191] If all second threads in the second process are in an empty task state, delete the second process.

[0192] In this embodiment of the application, during the restart process of the origin service, once the first process has been successfully put into use and is running smoothly, the second process can be terminated. Specifically, in some embodiments, the task status of each second thread in the second process can be detected. If the second thread is still processing related tasks, the second process can be retained for a period of time; conversely, if the task status of all second threads in the second process is empty, it indicates that the second process has no more tasks to process and can be deleted.

[0193] Of course, it should be noted that the embodiments of this application are not limited to the methods given in the above embodiments for exiting the second process. In other embodiments, a time threshold can be set, denoted as the second time threshold, which can be used to set how long after the first process is established before closing the second process. Specifically, in the embodiments of this application, the time node at which the first process is established can be detected and recorded as the second start time node. Then, the time interval between the current time node and the second start time node can be detected and recorded as the second time interval. If the second time interval is less than the second time threshold, the second process can continue to be retained; if the second time interval is equal to the second time threshold, the second process can be deleted.

[0194] It is understood that in this embodiment of the application, timely termination of the second process during the restart of the origin service can free up relevant storage and computing resources for other services of the CDN node, which is beneficial to improving the resource utilization efficiency of the CDN node.

[0195] The following describes and explains a system restart method provided in this application embodiment, with reference to specific application examples.

[0196] Please refer to Figure 8 , Figure 8 This illustration shows an application flow diagram of a back-to-origin service provided in an embodiment of this application. The back-to-origin service in this embodiment can respond to a resource acquisition request from a requesting object, obtain the corresponding network resources from the origin server, and return them to the requesting object. Specifically, as shown... Figure 8As shown, without a restart or update of the origin service, the process corresponding to the origin service is the old process (i.e., the second process). Resource acquisition requests from the requested object can be processed by threads within the old process. After processing, the five-tuple data corresponding to the network resource can be sent to the requesting object. This five-tuple data can include the source IP address, source port number, destination IP address, destination port number, and protocol type. The source IP address refers to the IP address of the node processing the resource acquisition request and preparing to return the result (i.e., the node where the origin service resides). The source port number is the port number used by the origin service responsible for processing the request and returning the result. The destination IP address is the IP address of the requesting object, and the destination port number can be used to identify the port number used by the application or service receiving the response from the requesting object. The protocol type can be used to identify the type of transport layer protocol used between the origin service and the requesting object. When a link migration is detected, the old process can use another thread to handle the resource acquisition request from the requesting object. Within a process (such as the old process), multiple threads (i.e., the second thread) can exist, each corresponding to a different file identifier.

[0197] When the origin service restarts for updates, a shared storage unit and a new process will be established. Figure 8 In a new process (the first process), both the new and old processes can contain multiple threads. Within the shared memory unit, a global mapping table of connection identifiers is stored for both processes, indicating the correspondence between each thread and queue. Each thread can also maintain its own local connection identifier mapping table, which can be copied from the global connection identifier mapping table stored in the shared memory unit. New and old processes can transfer data through the shared memory unit. Data packets can also be transmitted between threads and processes using UDS (Unix Domain Sockets).

[0198] Reference Figure 9 , Figure 9 This illustration shows a flowchart illustrating the process of old and new processes executing a service restart task from the source server, as provided in an embodiment of this application. In this embodiment, the old process can perform the following steps:

[0199] Step 911: Receive the restart command;

[0200] Step 912: Wait 2 seconds to allow the new process to complete the initialization of the listening port;

[0201] Step 913: Obtain the data packet;

[0202] Step 914: Close the socket;

[0203] Step 915: Process the data packets obtained from the shared storage unit;

[0204] Step 916: Reply to the client with a prompt message using the new file identifier;

[0205] Step 917: Determine if the waiting task is empty, or if the maximum exit time has been exceeded after receiving the restart command. If neither of these conditions is met, return to step 915; if either condition is met, proceed to step 918.

[0206] Step 918: Disconnect the shared storage unit;

[0207] Step 919: End the old process.

[0208] In this embodiment, after receiving the restart command, the old process can wait for a period of time (e.g., 2 seconds) to allow the new process to complete the initialization of the listening port. Then, it can retrieve data packets from the shared storage unit. Both the old and new processes can store their corresponding data packets in the shared storage unit. To facilitate a unified execution flow between the old and new processes, both can execute the following data packet retrieval process:

[0209] Step 901: Search for the relevant packet queue in the local connection identifier mapping table and determine if it is found. If found, proceed to step 904; if not found, proceed to step 902.

[0210] Step 902: Search the global connection mapping table for the relevant packet queue and determine if it is found. If not found, proceed to step 904; if found, proceed to step 903.

[0211] Step 903: Copy the data packet to the thread queue used by this process;

[0212] Step 904: Process the data packets that have been found in the local connection identifier mapping table.

[0213] For the old process, it can look up the data packets it needs to process in the local connection identifier mapping table. If found, it can copy them to its own queue for processing (this process is the same as the normal processing flow, meaning the old process does not need to adjust its own business execution logic during restart). If not found in the local connection identifier mapping table, it can look up the connection identifier global mapping table. After the new process's listening port is initialized, the old process can close its own listening port. At this time, for data packets still being processed within the old process, it can directly use the new file identifier (i.e., the third file identifier) ​​to send a prompt message to the requesting object, informing it that the target resource is still being acquired. When all threads of the old process have no waiting tasks, or when the old process exceeds the maximum exit time (i.e., the second time threshold), the old process can be terminated, its connection to the shared memory unit disconnected, and the old process deleted.

[0214] In this embodiment of the application, the following steps can be performed for a new process:

[0215] Step 921: Start a new process;

[0216] Step 922: Obtain the address of the shared memory unit;

[0217] Step 923: Randomly select a queue identifier based on the process identifier and thread identifier;

[0218] Step 924: Determine if there is an available queue. If so, proceed to step 925; otherwise, confirm that the startup has failed (it can be restarted).

[0219] Step 925: Start listening on the port and obtain data packets;

[0220] Step 926: Process the acquired data packets;

[0221] Step 927: Respond.

[0222] In this embodiment, after starting a new process, the address of the shared memory unit can be obtained, and the queue corresponding to the new process (i.e., the first queue) can be determined. If no queue is available, the new process creation fails and needs to be recreated. Once the first queue corresponding to the new process is determined and the listening port is initialized, requests from requesting objects can be received. In addition to new requests, the new process in this embodiment will also query the local connection identifier mapping table and the global connection identifier mapping table to check if a second queue of uncopyable data packets exists. If it exists, the corresponding data packets will be copied using the first queue, and the new process's thread will handle these data packets. After processing the data packets, the new process can reply with the corresponding processing result to the requesting object.

[0223] It is understood that the system restart method provided in this application embodiment has at least the following advantages:

[0224] 1. Reduced Request Failure Rate. This application embodiment utilizes a lossless hot restart to ensure that related requests can be processed normally during the origin service restart period, avoiding an increase in the request failure rate and enabling requesting objects to successfully obtain the required resources. With the lossless hot restart solution, requesting objects will not encounter problems such as request failures or slow page loading when accessing websites or services. Even during the origin service restart period, the requesting object's requests can still receive timely responses, ensuring that the requesting object can smoothly browse web pages, conduct transactions, or use online services. This seamless switching mechanism can effectively reduce the request failure rate and improve the satisfaction and experience of requesting objects.

[0225] 2. Reduced data transmission time. This embodiment of the application effectively reduces data transmission latency during the restart of the origin service by maintaining data synchronization and transmission continuity, thereby shortening the waiting time of the requesting object and improving response speed. This means that the requesting object's request can continue to be processed, data can continue to be transmitted, and the waiting time of the requesting object will not increase due to restart. The requesting object can obtain the required resources faster, reducing waiting time and improving response speed. This is particularly important for businesses and application scenarios with high requirements for response speed, such as online games and real-time video streaming.

[0226] 3. Improved Configuration Update Time. This embodiment improves configuration update efficiency by restarting and updating the origin service without interrupting traffic, avoiding issues such as configuration failures or misconfigurations during restart. Through a lossless hot restart solution, the origin service restart and configuration updates can be performed without interrupting traffic. This means configuration updates take effect faster, preventing accessibility or misconfiguration issues during restart, ensuring the system can adapt to changes in business needs promptly, and reducing the risk of system malfunctions or instability.

[0227] 4. Ensuring Data Integrity. This application's embodiments effectively reduce the risk of data loss or corruption during the restart of the origin service by maintaining data synchronization and transmission continuity, thereby protecting the stability of business operations and the integrity of data. Through a lossless hot restart solution, the restart process of the origin service can be performed without interrupting data transmission. This means that data can be continuously transmitted without being lost or corrupted due to the restart. Continuous data transmission and synchronization ensure the normal operation of the business system and avoid the potential losses and risks caused by data loss.

[0228] Reference Figure 10 In this embodiment of the application, a system restart device is also provided, which includes:

[0229] The receiving unit is used to receive restart commands from the origin service and establish a shared storage unit;

[0230] The establishment unit is used to establish a first process according to the restart instruction and map the shared memory unit to the address space of the first process and the second process. The first process is the process that performs the return-to-origin service after restarting, and the second process is the process that performs the return-to-origin service before restarting. The first process includes several first threads, each of which corresponds to a first queue. The second process includes several second threads, each of which corresponds to a second queue.

[0231] An initialization unit is used to initialize the listening port of the first process and close the listening port of the second process after the initialization of the listening port of the first process is completed.

[0232] The mapping unit is used to establish a global mapping table of connection identifiers and store the global mapping table of connection identifiers in the shared storage unit; wherein, the global mapping table of connection identifiers is used to store the relationships between various processes, threads and queues;

[0233] The processing unit is used to control the first process to copy the data packets to be processed by the second process into the first queue according to the global mapping table of connection identifiers, and to process the data packets through the first thread.

[0234] Optionally, in some embodiments, the system restart apparatus further includes a generation unit, which is specifically used for:

[0235] In response to the interactive operation of the target object, obtain the target origin address and target request parameters input by the target object;

[0236] Generate a restart command based on the target source address and the target request parameters.

[0237] Optionally, in some embodiments, the initialization unit is specifically used for:

[0238] Initialize the listening port of the first process and record the first start time of initialization;

[0239] Detect the first time interval between the current time node and the first starting time node;

[0240] If the first time interval is less than the preset first time threshold, return to the step of detecting the first time interval between the current time node and the first starting time node; or, if the first time interval is equal to the preset first time threshold, close the listening port of the second process.

[0241] Optionally, in some embodiments, the initialization unit is specifically used for:

[0242] Create the first socket and obtain the first file identifier corresponding to the first socket;

[0243] Bind the first socket to the listening port of the first process based on the first file identifier;

[0244] Set the first socket to listening mode and complete the initialization of the listening port;

[0245] The first socket is used in listening mode to receive external connection requests.

[0246] Optionally, in some embodiments, the establishing unit is specifically used for:

[0247] Obtain the first process identifier corresponding to the first process to be established, and the first thread identifier corresponding to each first thread in the first process;

[0248] Based on the first process identifier and the first thread identifier, the corresponding queue identifier is determined by random hashing.

[0249] Check if the target queue corresponding to the queue identifier is in an available state. If the target queue is in an available state, determine the target queue as the first queue corresponding to the first thread.

[0250] Optionally, in some embodiments, the initialization unit is specifically used for:

[0251] Close the second socket and the second file identifier bound to the listening port of the second process;

[0252] After closing the listening port of the second process, the method also includes:

[0253] Detect whether there are data packets being processed by a second thread;

[0254] If a data packet is being processed by a second thread, a new third file identifier is created;

[0255] A third file identifier is used to send a prompt message to the requesting object corresponding to the data packet; the prompt message is used to inform the requesting object that it is acquiring the target resource.

[0256] Optionally, in some embodiments, the mapping unit is specifically used for:

[0257] Get the first process identifier corresponding to the first process, the first thread identifier corresponding to the first thread, and the first queue identifier corresponding to the first queue;

[0258] Based on the first process identifier, the first thread identifier, and the first queue identifier, establish the first triplet information corresponding to each first queue;

[0259] Get the second process identifier corresponding to the second process, the second thread identifier corresponding to the second thread, and the second queue identifier corresponding to the second queue;

[0260] Based on the second process identifier, the second thread identifier, and the second queue identifier, establish the second triplet information corresponding to each second queue;

[0261] Based on the information of the first triplet and the information of the second triplet, establish a global mapping table for connection identifiers.

[0262] Optionally, in some embodiments, each thread locally stores a local connection identifier mapping table, which is periodically updated along with the global connection identifier mapping table; the processing unit is specifically used for:

[0263] The first thread checks the local connection identifier mapping table to see if there is a second queue of data packets that have not been copied.

[0264] If a second queue of data packets that have not been copied exists in the local connection identifier mapping table, copy the data packets in the second queue to the first queue corresponding to the first thread.

[0265] Optionally, in some embodiments, the processing unit is further configured to:

[0266] If the local connection identifier mapping table does not contain a second queue of uncopyable data packets, the first thread queries the global connection identifier mapping table to see if a second queue of uncopyable data packets exists.

[0267] If a second queue of uncopyable data packets exists in the connection identifier global mapping table, copy the data packets in the second queue to the first queue corresponding to the first thread.

[0268] Optionally, in some embodiments, the system restart apparatus further includes a deletion unit, which is specifically used for:

[0269] Perform task status checks on each second thread of the second process;

[0270] If all second threads in the second process are in an empty task state, delete the second process.

[0271] Optionally, in some embodiments, the deletion unit is further used for:

[0272] Record the second start time node for establishing the first process;

[0273] Detect the second time interval between the current time node and the second starting time node;

[0274] If the second time interval equals the preset second time threshold, delete the second process.

[0275] It is understandable that, such as Figure 7 The content of the system restart method embodiments shown is applicable to the system restart device embodiments. The specific functions implemented by the system restart device embodiments are the same as those shown in the examples. Figure 7 The system restart method shown in the embodiment is the same, and the beneficial effects achieved are the same as those described above. Figure 7 The beneficial effects achieved by the system restart method embodiment shown are also the same.

[0276] This application also discloses an electronic device, including:

[0277] At least one processor;

[0278] At least one memory for storing at least one program;

[0279] When at least one program is executed by at least one processor, such that at least one processor implements as Figure 7 The system restart method shown is an example.

[0280] It is understandable that, such as Figure 7 The content of the system restart method embodiments shown is applicable to the embodiments of this electronic device, and the specific functions implemented by the embodiments of this electronic device are the same as those shown. Figure 7 The system restart method shown in the embodiment is the same, and the beneficial effects achieved are the same as those described above. Figure 7 The beneficial effects achieved by the system restart method embodiment shown are also the same.

[0281] The electronic device in the embodiments of this application may be a terminal device, a computer device, or a server device.

[0282] For example, taking a server device as an example, refer to Figure 11 The server device 1100 can vary significantly due to differences in configuration or performance. It may include one or more central processing units (CPUs) and memory 1160, and one or more storage media 1130 (e.g., one or more mass storage devices) for storing application programs 1133 or data 1132. The memory 1160 and storage media 1130 may be temporary or persistent storage. The program stored in the storage media 1130 may include one or more units or modules, each unit or module may include a series of operation instructions on the server device 1100. Furthermore, the CPU 1110 may be configured to communicate with the storage media 1130 and execute the series of operation instructions stored in the storage media 1130 on the server device 1100.

[0283] Server device 1100 may also include one or more power supplies 1120, one or more wired or wireless network interfaces 1140, one or more input / output interfaces 1150, and one or more operating systems 1131.

[0284] The central processing unit 1110 in server device 1100 can be used to perform tasks such as Figure 7 The system restart method shown is an example.

[0285] This application also discloses a computer-readable storage medium storing a processor-executable program, which, when executed by a processor, is used to implement, for example... Figure 7 The system restart method shown is an example.

[0286] Understandable, Figure 7 The content of the system restart method embodiments shown is applicable to the embodiments of this computer-readable storage medium. The specific functions implemented by the embodiments of this computer-readable storage medium are the same as those shown in the embodiments. Figure 7 The system restart method shown in the embodiment is the same, and the beneficial effects achieved are the same. Figure 7 The beneficial effects achieved by the system restart method embodiment shown are also the same.

[0287] This application also discloses a computer program product or computer program, which includes computer instructions stored in the aforementioned computer-readable storage medium. Figure 11 The processor of the illustrated electronic device can read the computer instructions from the aforementioned computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform... Figure 7 The system restart method shown is an example.

[0288] Understandable, Figure 7 The content of the system restart method embodiments shown is applicable to this computer program product or computer program embodiment, and the specific functions implemented by this computer program product or computer program embodiment are the same as those shown. Figure 7 The system restart method shown in the embodiment is the same, and the beneficial effects achieved are the same. Figure 7 The beneficial effects achieved by the system restart method embodiment shown are also the same.

[0289] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0290] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated to the contrary, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of conventional technology for an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0291] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0292] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable storage medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable storage medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0293] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0294] In the foregoing description of this specification, the references to terms such as "one embodiment," "another embodiment," or "some embodiments," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0295] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

[0296] The above is a detailed description of the preferred embodiments of this application, but this application is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application, and these equivalent modifications or substitutions are all included within the scope defined by the claims of this application.

Claims

1. A system restart method, characterized in that, The method includes: Receive the restart command from the origin service and establish a shared storage unit; A first process is established according to the restart instruction, and the shared storage unit is mapped to the address space of the first process and the second process; wherein, the first process is the process that executes the return-to-origin service after restarting, and the second process is the process that executes the return-to-origin service before restarting. The first process includes a plurality of first threads, each first thread corresponding to a first queue, and the second process includes a plurality of second threads, each second thread corresponding to a second queue. The listening port of the first process is initialized, and the listening port of the second process is closed after the initialization of the listening port of the first process is completed. A global mapping table for connection identifiers is established and stored in the shared storage unit; wherein, the global mapping table for connection identifiers is used to store the relationships between various processes, threads and queues; The first process is controlled to copy the data packets to be processed by the second process into the first queue according to the global mapping table of connection identifiers, and the first thread processes the data packets.

2. The system restart method according to claim 1, characterized in that, The restart command is generated in the following way: In response to the interactive operation of the target object, obtain the target source address and target request parameters input by the target object; The restart command is generated based on the target source address and the target request parameters.

3. The system restart method according to claim 1, characterized in that, The initialization of the listening port of the first process, and the closing of the listening port of the second process after the initialization of the listening port of the first process is completed, includes: The listening port of the first process is initialized, and the first start time of initialization is recorded; Detect the first time interval between the current time node and the first starting time node; If the first time interval is less than a preset first time threshold, return to the step of detecting the first time interval between the current time node and the first starting time node; or, if the first time interval is equal to the preset first time threshold, close the listening port of the second process.

4. The system restart method according to claim 1 or 3, characterized in that, The initialization of the listening port of the first process includes: Create the first socket and obtain the first file identifier corresponding to the first socket; Based on the first file identifier, bind the first socket to the listening port of the first process; The first socket is set to listening mode to complete the initialization of the listening port; The first socket is used in the listening mode to receive external connection requests.

5. The system restart method according to claim 1, characterized in that, The step of establishing the first process according to the restart command includes: Obtain the first process identifier corresponding to the first process to be established, and the first thread identifier corresponding to each first thread in the first process; Based on the first process identifier and the first thread identifier, the corresponding queue identifier is determined by random hashing; Query whether the target queue corresponding to the queue identifier is in an available state. If the target queue is in an available state, determine the target queue as the first queue corresponding to the first thread.

6. The system restart method according to claim 1, characterized in that, Closing the listening port of the second process includes: Close the second socket and the second file identifier bound to the listening port of the second process; After closing the listening port of the second process, the method further includes: Detect whether a data packet being processed by the second thread exists; If a data packet exists that is being processed by the second thread, a new third file identifier is created; The third file identifier is used to send a prompt message to the requesting object corresponding to the data packet; wherein the prompt message is used to inform the requesting object that it is acquiring the target resource.

7. The system restart method according to claim 1, characterized in that, The establishment of the global mapping table for connection identifiers includes: Obtain the first process identifier corresponding to the first process, the first thread identifier corresponding to the first thread, and the first queue identifier corresponding to the first queue; Based on the first process identifier, the first thread identifier, and the first queue identifier, establish the first triplet information corresponding to each first queue; Obtain the second process identifier corresponding to the second process, the second thread identifier corresponding to the second thread, and the second queue identifier corresponding to the second queue; Based on the second process identifier, the second thread identifier, and the second queue identifier, establish the second triplet information corresponding to each second queue; Based on the information of the first triplet and the information of the second triplet, a global mapping table for connection identifiers is established.

8. The system restart method according to claim 1, characterized in that, Each thread has a local connection identifier mapping table stored locally, and the local connection identifier mapping table is updated periodically along with the global connection identifier mapping table. The step of controlling the first process to copy the data packets to be processed by the second process into the first queue according to the connection identifier global mapping table includes: The first thread queries the local connection identifier mapping table to check if there is a second queue of data packets that have not been copied. If a second queue of uncopyable data packets exists in the local connection identifier mapping table, the data packets in the second queue are copied to the first queue corresponding to the first thread.

9. The system restart method according to claim 8, characterized in that, The step of controlling the first process to copy the data packets to be processed by the second process into the first queue according to the connection identifier global mapping table also includes: If the local connection identifier mapping table does not contain a second queue of uncopyable data packets, the first thread queries the global connection identifier mapping table to determine if a second queue of uncopyable data packets exists. If a second queue of uncopyable data packets exists in the global mapping table of connection identifiers, the data packets in the second queue are copied to the first queue corresponding to the first thread.

10. The system restart method according to claim 1, characterized in that, The method further includes: Perform task status checks on each of the second threads in the second process; If all the second threads of the second process are in an empty task state, delete the second process.

11. The system restart method according to claim 1, characterized in that, The method further includes: Record the second start time node for establishing the first process; Detect the second time interval between the current time node and the second starting time node; If the second time interval equals a preset second time threshold, the second process is deleted.

12. A system restart device, characterized in that, The system restart device includes: The receiving unit is used to receive restart commands from the origin service and establish a shared storage unit; An establishment unit is used to establish a first process according to the restart instruction and map the shared storage unit to the address spaces of the first process and the second process; wherein, the first process is the process that executes the back-to-origin service after restarting, and the second process is the process that executes the back-to-origin service before restarting. The first process includes a plurality of first threads, each first thread corresponding to a first queue, and the second process includes a plurality of second threads, each second thread corresponding to a second queue. An initialization unit is used to initialize the listening port of the first process and close the listening port of the second process after the initialization of the listening port of the first process is completed. A mapping unit is used to establish a global mapping table for connection identifiers and store the global mapping table for connection identifiers in the shared storage unit; wherein, the global mapping table for connection identifiers is used to store the relationships between various processes, threads and queues; The processing unit is configured to control the first process to copy the data packets to be processed by the second process into the first queue according to the global mapping table of connection identifiers, and to process the data packets through the first thread.

13. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the system restart method according to any one of claims 1 to 11.

14. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the system restart method according to any one of claims 1 to 11.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the system restart method according to any one of claims 1 to 11.

Images