Process update method and device

Abstract

The embodiments of the present specification provide a process update method and device, wherein the process update method is applied to a client, and the client includes: an initial process, a first target process, and a second target process updated based on the first target process; the first target process receives at least one user request forwarded by the initial process, and starts the second target process when it is determined that the update condition is met; the second target process receives the at least one user request sent by the initial process when initialization is completed, and processes the at least one user request.

Description

Technical Field

[0001] The embodiments of the present specification relate to the field of computer technology, and in particular to a process updating method. Background Art

[0002] With the development of network technology, the role of backend servers in the entire network environment is becoming increasingly important. At the same time, with the development of network technology, user needs are also constantly developing, and the requirements for backend servers are becoming higher and higher, which requires backend servers to be continuously upgraded to meet customer needs. In a distributed system, the client is usually embedded in the user process and runs. When the client needs to be upgraded, the user process must recompile and generate a new executable program, and then upgrade the online service nodes one by one. During the upgrade process, the client process needs to be restarted, which will incur a large upgrade cost and affect user usage. Summary of the invention

[0003] In view of this, the present specification provides a process update method. One or more embodiments of the present specification also relate to a process update device, a computing device, a computer-readable storage medium and a computer program to solve the technical defects existing in the prior art.

[0004] According to a first aspect of an embodiment of this specification, a process update method is provided, which is applied to a client, wherein the client includes: an initial process, a first target process, and a second target process updated based on the first target process;

[0005] The first target process receives at least one user request forwarded by the initial process, and starts the second target process when determining that an update condition is met;

[0006] When initialization is completed, the second target process receives the at least one user request sent by the initial process and processes the at least one user request.

[0007] According to a second aspect of the embodiments of this specification, a process updating device is provided, which is applied to a client, and the client includes: an initial process, a first target process, and a second target process updated based on the first target process;

[0008] The first target process is configured to receive at least one user request forwarded by the initial process, and start the second target process when it is determined that the update condition is met;

[0009] The second target process is configured to receive the at least one user request sent by the initial process and process the at least one user request when initialization is completed.

[0010] According to a third aspect of an embodiment of this specification, a computing device is provided, including:

[0011] Memory and processor;

[0012] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, wherein the processor implements the steps of the process updating method when executing the computer-executable instructions.

[0013] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided, which stores computer-executable instructions, and when the instructions are executed by a processor, the steps of any one of the process updating methods are implemented.

[0014] According to a fifth aspect of the embodiments of this specification, a computer program is provided, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the above-mentioned process updating method.

[0015] A process update method provided by an embodiment of the present specification is applied to a client, wherein the client includes: an initial process, a first target process, and a second target process updated based on the first target process; the first target process receives at least one user request forwarded by the initial process, and starts the second target process when it is determined that the update condition is met; the second target process receives the at least one user request sent by the initial process when initialization is completed, and processes the at least one user request.

[0016] Specifically, after the first target process receives the user request and determines that the update conditions are met, the second target process will be started. After the second target process completes initialization, it will re-receive at least one user request sent by the initial process and complete the processing of the user request, thereby realizing hot upgrade of the process, and thus being able to achieve no need for user process upgrade and restart, that is, no need for user operation or perception, and the hot upgrade is automatically completed by the client process, which not only reduces the process upgrade cost, but also has less impact on service delays in the user process and will not affect user usage. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a system architecture diagram of a process update method provided by an embodiment of this specification applied to a client;

[0018] Figure 2 is a flow chart of a process updating method provided by an embodiment of this specification;

[0019] Figure 3 is a processing flow chart of a process update method provided by an embodiment of this specification;

[0020] Figure 4 It is a structural diagram of a process updating device provided by an embodiment of this specification;

[0021] Figure 5 It is a structural block diagram of a computing device provided by an embodiment of this specification. DETAILED DESCRIPTION

[0022] Many specific details are described in the following description to facilitate a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the connotation of this specification, so this specification is not limited to the specific implementation disclosed below.

[0023] The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms of "a", "said" and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0024] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0025] First, the terms involved in one or more embodiments of this specification are explained.

[0026] Hot upgrade: During system operation, the system can be upgraded without interrupting service and without user operation or perception.

[0027] The client of a distributed system is usually embedded in the user process and runs. When the client needs to be upgraded, the user process must recompile itself to generate a new executable program, and then upgrade the online service nodes one by one. During the upgrade process, since the process needs to be restarted, the requests / traffic on the process to be upgraded also needs to be migrated in advance, and after the upgrade is completed, the requests / traffic will be migrated back. This process will not only affect the operation of the user process, but also the cost of the client upgrade. However, in some projects, the upgrade cost of the user process is very high, and it will be very difficult to fix the problem of the client program at this time. Based on this, a process update method provided in an embodiment of this specification realizes hot upgrade processing of the client process, without the need for user process upgrade and restart, and only needs to start a new client process to replace the old client process that needs to be updated, and then adopt a dual-process approach, which can not only avoid waiting for the client to initialize, but also reduce the cost of client upgrades.

[0028] It should be noted that when the client in the user process needs to be upgraded, the client program is split into two processes, one is a light client with relatively simple logic, which is only responsible for forwarding requests (forwarding to the heavy client); the other is a heavy client, which contains the main client logic. The light client is included in the user process, and the heavy client can be upgraded independently as an independent process.

[0029] Therefore, the process update method provided in the embodiments of this specification is mainly for upgrading the heavy client. Since the light client has simple logic, it is not necessary to upgrade it as much as possible. Only the heavy client is upgraded to reduce the upgrade cost of the client.

[0030] In this specification, a process update method is provided. This specification also relates to a process update device, a computing device, a computer-readable storage medium and a computer program, which are described in detail one by one in the following embodiments.

[0031] Figure 1 A system architecture diagram of a process updating method provided according to an embodiment of the present specification is shown, which is applied to a client.

[0032] It should be noted that the initial process in the client is only responsible for forwarding user requests, and the first target process and the second target process contain the main client logic and can be upgraded as an independent process.

[0033] Figure 1 It includes the initial process (light client), the first target process (old version heavy client), the second target process (new version client) and the backend service cluster.

[0034] In specific implementation, after receiving the user request sent by the user, the initial process forwards the user request to the first target process. When it is determined that the first target process meets the update conditions, the second target process is started, and after waiting for the second target process to complete all initializations, the initial process forwards the user request to the second target process. The second target process receives the internal handle associated with the user handle carried in the user request, which is determined by the initial process. The second target process accesses the backend service cluster based on the internal handle. At the same time, the second target process can force the first target process to stop receiving user requests, thereby implementing the upgrade process of the first target process.

[0035] The process update method provided in the embodiment of this specification divides the client process into an initial process, a first target process, and a second target process, and starts the second target process when it is determined that the first target process meets the update conditions. The initial process forwards the user request to the second target process, and the second target process can perform subsequent user request processing, thereby realizing automatic hot upgrade of the first target process. The hot upgrade processing of the first target process is completed without user operation or perception.

[0036] Figure 2 A flowchart of a process updating method provided according to an embodiment of the present specification is shown, which specifically includes the following steps.

[0037] Step 202: The first target process receives at least one user request forwarded by the initial process, and starts the second target process when it is determined that the update condition is met.

[0038] Among them, the initial process can be understood as a light client process with relatively simple logic and only responsible for request forwarding.

[0039] The first target process can be understood as a heavy client process that handles the main client logic, and the second target process can be understood as a new heavy client process that is started. Therefore, the first target process can be regarded as an old version of the heavy client process, and the second target process can be regarded as a new version of the heavy client process.

[0040] Among them, the update condition can be understood as the condition that needs to be updated when the first target process is running, that is, the trigger condition of hot upgrade. For example, the first target process may have a bug during operation, or it may need to be updated and upgraded to improve certain indicators, or it may be to add new functions.

[0041] In specific implementation, after receiving at least one user request, the initial process forwards at least one user request to the first target process. Then, after receiving at least one user request, the first target process triggers the start of the second target process when it is confirmed that the update condition is met. It should be noted that when the first target process needs to be repaired or upgraded after the update condition is triggered, if a cold upgrade is adopted for the first target process, a restart operation or other operations may generally be required, which may affect the user's usage process.

[0042] Based on this, in actual applications, in order to avoid the situation where the restart of the client process affects the normal use of the user when the client process is upgraded, when it is detected that the heavy client process meets the update conditions, a new version of the heavy client can be started to replace the old version of the heavy client that needs to be updated, so that the old version of the client automatically completes the hot upgrade without the user's perception, and the impact on service delay is very small. For example, in order to add new functions, the first target process needs to be upgraded, then it can be determined that the first target process meets the preset update conditions, thereby triggering the start of the second target process.

[0043] Furthermore, before the initial process forwards the received at least one user request to the first target process, the process further includes:

[0044] The initial process receives at least one user request and caches the at least one user request based on a user calling order.

[0045] The user request may be understood as a user processing request in a distributed system, such as a user storage request in a distributed storage system.

[0046] In actual applications, the initial process will receive at least one user request, and the system will cache the at least one received user request according to the calling order of different user requests, wherein the cached user request may be a user request for which a result has not yet been returned to the user.

[0047] In the process updating method provided in the embodiment of this specification, in order to ensure the order of processing user requests, the initial process caches at least one user request in the order of user calls, so that the subsequent initial process can forward at least one user to the second target process in the order of user calls.

[0048] Furthermore, the initial process forwards the user request to the first target process in two ways; specifically, the initial process forwards at least one received user request to the first target process, including:

[0049] The initial process forwards the received at least one user request to the first target process based on the local connection protocol; or

[0050] The initial process forwards the received at least one user request to the first target process based on a shared memory mechanism.

[0051] In actual applications, the initial process performs process communication through a local connection protocol, and forwards at least one received user request to the first target process, for example, performing process communication through a local socket; or the initial process performs process communication through shared memory, and forwards at least one received user request to the first target process, for example, performing process communication through shared memory.

[0052] It should be noted that the communication mechanism between various processes is described in this specification only by taking the above two methods as examples, but is not limited to the above methods, and this embodiment does not impose any limitation on this.

[0053] The process updating method provided in the embodiment of this specification enables the initial processes to communicate with each other through different communication methods, so as to forward the user request from the initial process to the first target process, thereby realizing real-time forwarding of the user request.

[0054] Step 204: When the initialization is completed, the second target process receives the at least one user request sent by the initial process and processes the at least one user request.

[0055] In specific implementation, after being started, the second target process may first complete all initialization work, and only after determining that the initialization work is completed, may it receive at least one user request sent by the initial process and process the at least one user request.

[0056] It should be noted that, in actual applications, the initialization of the second target process may also take a certain amount of time. During this process, the first target process can still receive user requests because the system has not forcibly stopped the running process of the first target process.

[0057] In order to accurately determine the time when the second target process is initialized, after the second target process completes all initializations, it is necessary to send a to-be-received instruction to the initial process to inform the initial process that the user request can be forwarded to the second target process to implement subsequent processing of the user request; specifically, after the second target process is initialized, it also includes:

[0058] The second target process sends a to-be-received instruction to the initial process;

[0059] The initial process sends the at least one user request to the second target process based on the user calling sequence in response to the instruction to be received.

[0060] In specific implementation, after the second target process sends the to-be-received instruction to the initial process, the initial process can determine that the second target process can receive the user request instead of the first target process, and then the initial process sends at least one user request to the second target process based on the cached user call order.

[0061] In actual applications, after the second target process completes all initializations, it can send a to-be-received instruction to the initial process, that is, the second target process informs the initial process to forward all current user requests that have not yet returned results to the second target process in the order of user calls; the initial process forwards at least one user request to the second target process in response to the to-be-received instruction, and before the forwarding is completed, suspends forwarding subsequent new user requests to ensure the sending order of user requests, and after the forwarding is completed, forwards subsequent new user requests to the second target process.

[0062] The process updating method provided in the embodiment of this specification forwards the user request to the second target process after determining that the second target process has completed initialization to replace the first target process, thereby ensuring that the user request is processed without the user's perception.

[0063] After the newly started second target process receives the user request sent by the initial process, it can be understood that the second target process can replace the first target process to complete the processing of the user request, so the first target process can be forced to exit; specifically, after the second target process is initialized and receives the at least one user request sent by the initial process, it also includes:

[0064] The first target process stops receiving the at least one user request sent by the initial process.

[0065] In actual applications, after the initial process forwards at least one user request to the second target process, in order to enable the second target process to replace the first target process and complete the hot upgrade of the first target process, the first target process can then stop receiving at least one user request sent by the initial process, which can be understood as forcibly killing the old heavy client to be updated.

[0066] The process update method provided in the embodiment of this specification stops the first target process from receiving the user request sent by the initial process, thereby completing the process of replacing the first target process with the second target process, so that the heavy client to be updated does not participate in the user request processing and does not affect the entire user process.

[0067] Furthermore, the second target process processes the at least one user request, including:

[0068] The second target process receives the user handle carried in the at least one user request from the initial process, determines an internal handle associated with the user handle, and processes the at least one user request based on the internal handle.

[0069] In a distributed file system, after a user opens a file, he or she will get a handle, and then read and write the file through the handle. In the internal implementation of the file system, the corresponding internal resources are generally found through the handle to perform operations for user request processing. In the distributed file system provided in this embodiment, there are two types of handles: one is the handle returned to the user by the light client, called the user handle; the other is the handle returned to the heavy client by the backend service cluster, which the heavy client will bring back to the light client, and this handle is called the internal handle. There is a one-to-one correspondence between the two handles.

[0070] In actual applications, the second target process can receive an internal handle while receiving at least one user request sent by the initial process, wherein the internal handle is a handle associated with the user handle determined based on the user handle carried in each user request. The second target process can access the backend service cluster locally based on the determined internal handle to process the user request.

[0071] Furthermore, each user request carries a user handle. After the initial process converts the user handle into an internal handle, the initial process forwards the internal handle to the second target process. If the second target process finds that the internal handle does not exist locally, a new internal handle can be obtained based on the reopening operation to complete the processing of the user request. Specifically, after the second target process receives the user handle carried in the at least one user request by the initial process and determines the internal handle associated with the user handle, the process further includes:

[0072] The second target process, based on the internal handle associated with the user handle, obtains the target internal handle based on a reopening operation if a handle identical to the internal handle cannot be determined locally, and processes the at least one user request based on the target internal handle.

[0073] In actual applications, after the second target process receives the internal handle determined by the initial process to be associated with the user handle, if the handle identical to the internal handle cannot be determined locally, it can further perform a reopening operation (the old internal handle must be carried). In the reopening operation, the back-end server will return a new internal handle to the second target process. At the same time, the back-end server will delete the resources corresponding to the old internal handle and destroy the permissions, so that the old internal handle will also be unable to access the back-end server. After the second target process obtains a new internal handle, namely the target internal handle, it can further access the back-end server to process user requests based on the target internal handle. At the same time, the target internal handle is returned to the initial process to facilitate the subsequent initial process to update the correspondence between the user handle and the internal handle locally.

[0074] The process updating method provided in the embodiment of this specification can, after the second target process fails to find a matching internal handle locally, regain a new internal handle based on a reopening operation, and access the backend server to process user requests based on the new internal handle, thereby completing the processing of user requests through the second target process.

[0075] Further, obtaining a target internal handle based on the reopening operation, and processing the at least one user request based on the target internal handle, includes:

[0076] The second target process sends a reopen instruction carrying an internal handle associated with a user handle to the back-end server, receives the target internal handle returned by the back-end server in response to the reopen instruction, and processes the at least one user request based on the target internal handle.

[0077] In specific implementation, after the second target process is unable to locally determine the internal handle that is consistent with the internal handle associated with the user handle, it sends a reopen instruction to the back-end server. After receiving the reopen instruction, the back-end server determines the target internal handle based on the reopen instruction and returns the target internal handle to the second target process. After the second target process receives the target internal handle, it can access the back-end server based on the target internal handle to process the user request.

[0078] The process update method provided in the embodiment of this specification sends a reopen instruction to the backend server, thereby obtaining a new target internal handle, which facilitates the subsequent processing of user requests based on the target internal handle.

[0079] After returning the new target internal handle to the second target process, the back-end server also needs to delete the resources corresponding to the old internal handle and destroy its permissions, so that the back-end server cannot be accessed according to the old internal handle; specifically, after processing the at least one user request based on the target internal handle, it also includes:

[0080] The second target process receives a handle update completion message returned by the backend server.

[0081] In actual applications, the back-end server deletes the resources corresponding to the old internal handle and destroys its permissions, so that the back-end server process cannot be accessed based on the old internal handle. After the back-end server updates the handle, it can return a message to the second target process indicating that the handle update is complete. In addition, the back-end server can also return the new internal handle to the second target process and store it locally, so that the second target process can subsequently determine the internal handle that is associated with the user handle locally.

[0082] The process update method provided in the embodiment of this specification returns a handle update completion message to the second target process after the back-end server updates the internal handle process, so that the second target process can subsequently return the target internal handle to the initial process to update the one-to-one correspondence between the user handle and the target internal handle.

[0083] In order to facilitate the subsequent second target process to determine the internal handle corresponding to the user handle locally, it is also necessary to cache the association relationship between the user handle and the new target internal handle in the initial process to ensure that the second target process can accurately determine the corresponding internal handle, and then access the backend server to obtain processing resources; specifically, after processing the at least one user request based on the target internal handle, it also includes:

[0084] The initial process obtains the target internal handle from the second target process, and caches the association relationship between the user handle carried in the at least one user request and the target internal handle.

[0085] In actual applications, after the second target process processes the user request based on the target internal handle, the initial process can obtain the target internal handle from the second target process, determine the association relationship between the target internal handle and the user handle carried in the user request, and cache the determined association relationship to update the association relationship list, so that the internal handle corresponding to the user handle can be found based on the updated association relationship.

[0086] The process update method provided in the embodiment of this specification is that the initial process caches the association relationship between the target internal handle and the user handle to achieve the update of the one-to-one correspondence between the handles, thereby ensuring that the internal handle determined based on the correspondence can access the backend server in a timely manner to obtain the corresponding usage resources.

[0087] In summary, the process update method provided in the embodiments of the present specification divides the client process into two categories. Client processes with simple logic do not need to be upgraded, and only clients with mainly complex logic are upgraded. When it is determined that the first target process meets the update conditions, a new heavy client process is started to replace the first target process to access the back-end server, thereby realizing the upgrade and update of the heavy client. In addition, while waiting for the second target process to be initialized, the first target process can still receive user requests and does not affect the operation of the user process. By adopting this dual-process approach, it is possible to avoid the time of waiting for the client to initialize affecting the user process. Furthermore, for user requests that have not been completed on the first target process, when the internal handle corresponding to the user handle cannot be determined, only one more step of reopening operation is required to obtain a new internal handle, thereby completing the processing of the user request, thereby reducing the processing overhead cost.

[0088] The following combination Figure 3 , taking the application of the process update method provided in this specification in a distributed file system as an example, the process update method is further described. Figure 3 A process flow chart of a process update method provided by an embodiment of the present specification is shown, which specifically includes the following steps.

[0089] It should be noted that Figure 3 The processing procedure of a process update method provided in this embodiment, step 302 is the user request processing process of dividing the client process into a light client and an old version heavy client; step 304 is the processing process of repairing or updating when it is determined that the old version heavy client meets the update conditions; step 306 is the process of starting a new version heavy client to replace the old version heavy client to process user requests.

[0090] Step 302: After receiving the user request, the light client forwards the user request to the old version heavy client, which then accesses the backend service cluster to complete the processing of the user request.

[0091] Step 304: When the old version re-client determines that the update condition is met, the new version re-client may be started and wait for the new version re-client to complete all initialization processes.

[0092] It should be noted that while waiting for the new version of the re-client to complete initialization, the initial process will still forward the received user requests to the old version of the re-client to ensure that the user process is not affected.

[0093] Step 306: After the new version re-client completes initialization, the initial process forwards the received user request to the new version re-client, and at the same time, forces the old version re-client to stop receiving user requests. The new version re-client receives the user request and receives the internal handle corresponding to the user handle carried in the user request. Based on the internal handle, the backend service cluster is accessed to obtain resources for processing the user request, thereby implementing the processing of the user request.

[0094] It should be noted that the process update method provided in this embodiment ensures that only the heavy client is upgraded, so that the light client is upgraded as little as possible. When the heavy client is upgraded, a dual-process method is adopted to avoid waiting for the client to initialize. User requests that are not completed on the old client can also be processed by reopening the operation later to obtain a new internal handle, so that the cost of the upgrade is relatively low.

[0095] The process update method provided in the embodiments of this specification starts the new version of the re-client process when the old version of the re-client meets the update conditions, thereby avoiding affecting the use of the user process and reducing the cost of the process upgrade. Based on this hot upgrade method, there is no need for the user process to be restarted for the upgrade. The client program can automatically complete the hot upgrade, and the impact on service delays is very small, and the user is almost unaware.

[0096] Corresponding to the above method embodiment, this specification also provides an object processing device embodiment, Figure 4 FIG. 1 shows a schematic diagram of a process updating device provided by an embodiment of the present specification. Figure 4 As shown, the device is applied to a client, and the client includes: an initial process 402, a first target process 404, and a second target process 406 updated based on the first target process;

[0097] The first target process 404 is configured to receive at least one user request forwarded by the initial process, and start the second target process when it is determined that the update condition is met;

[0098] The second target process 406 is configured to receive the at least one user request sent by the initial process when initialization is completed, and process the at least one user request.

[0099] Optionally, the second target process 406 is further configured to receive the user handle carried in the at least one user request by the initial process, determine an internal handle associated with the user handle, and process the at least one user request based on the internal handle.

[0100] Optionally, the second target process 406 is further configured to obtain the target internal handle based on a reopening operation based on the internal handle associated with the user handle, if a handle identical to the internal handle cannot be determined locally, and process the at least one user request based on the target internal handle.

[0101] Optionally, the second target process 406 is further configured to send a reopen instruction to the back-end server carrying an internal handle associated with the user handle, receive the target internal handle returned by the back-end server in response to the reopen instruction, and process the at least one user request based on the target internal handle.

[0102] Optionally, the second target process 406 is further configured to receive a handle update completion message returned by the backend server.

[0103] Optionally, the initial process 402 is configured to obtain the target internal handle from the second target process, and cache the association relationship between the user handle carried in the at least one user request and the target internal handle.

[0104] Optionally, the initial process 402 is further configured to forward the received at least one user request to the first target process based on a local connection protocol; or

[0105] Optionally, the initial process 402 is further configured to forward the received at least one user request to the first target process based on a local connection protocol; or

[0106] Forwarding the at least one received user request to the first target process based on a shared memory mechanism.

[0107] Optionally, the initial process 402 is further configured to receive at least one user request and cache the at least one user request based on a user calling order.

[0108] Optionally, the second target process 406 is further configured to send a to-be-received instruction to the initial process;

[0109] Optionally, the initial process 402 is further configured to send the at least one user request to the second target process based on the user calling sequence in response to the instruction to be received.

[0110] Optionally, the first target process 404 is further configured to stop receiving the at least one user request sent by the initial process.

[0111] The process update device provided in the present specification will start the second target process after the first target process receives the user request and determines that the update conditions are met, and forward the user request to the second target process for processing. After the second target process is initialized, the second target process completes the processing of the user request based on the determined internal handle, thereby realizing hot upgrade of the process, and thus being able to achieve process upgrade and restart without the need for user operation or perception, that is, the upgrade is automatically completed by the client process without the need for user operation or perception, which not only reduces the process upgrade cost, but also has less impact on service delays in the user process and will not affect user usage.

[0112] The above is a schematic scheme of a process update device of this embodiment. It should be noted that the technical scheme of the process update device and the technical scheme of the process update method described above are of the same concept, and the details not described in detail in the technical scheme of the process update device can be found in the description of the technical scheme of the process update method described above.

[0113] Figure 5 The structure block diagram of a computing device 500 provided according to an embodiment of the present specification is shown. The components of the computing device 500 include but are not limited to a memory 510 and a processor 520. The processor 520 is connected to the memory 510 via a bus 530, and the database 550 is used to store data.

[0114] The computing device 500 also includes an access device 540 that enables the computing device 500 to communicate via one or more networks 560. Examples of these networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or a combination of communication networks such as the Internet. The access device 540 may include one or more of any type of network interface (e.g., a network interface card (NIC)) whether wired or wireless, such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a World Wide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a universal serial bus (USB) interface, a cellular network interface, a Bluetooth interface, a near field communication (NFC) interface, and the like.

[0115] In one embodiment of the present specification, the above components of the computing device 500 and Figure 5 Other components not shown in the figure may also be connected to each other, for example, via a bus. It should be understood that Figure 5The computing device structure block diagram shown is only for the purpose of illustration, and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0116] The computing device 500 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook, etc.), a mobile phone (e.g., a smart phone), a wearable computing device (e.g., a smart watch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or PC. The computing device 500 may also be a mobile or stationary server.

[0117] The processor 520 is used to execute the following computer executable instructions, which implement the steps of the above-mentioned process updating method when executed by the processor.

[0118] The above is a schematic scheme of a computing device of this embodiment. It should be noted that the technical scheme of the computing device and the technical scheme of the object processing method described above are of the same concept, and the details not described in detail in the technical scheme of the computing device can be found in the description of the technical scheme of the process update method described above.

[0119] An embodiment of the present specification further provides a computer-readable storage medium storing computer-executable instructions, which can implement the steps of the above-mentioned process updating method when executed by a processor.

[0120] The above is a schematic scheme of a computer-readable storage medium of this embodiment. It should be noted that the technical scheme of the storage medium and the technical scheme of the process update method described above are of the same concept, and the details not described in detail in the technical scheme of the storage medium can be found in the description of the technical scheme of the process update method described above.

[0121] An embodiment of the present specification further provides a computer program, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the above-mentioned process updating method.

[0122] The above is an illustrative solution of a computer program of this embodiment. It should be noted that the technical solution of the computer program and the technical solution of the process update method described above are of the same concept, and the details not described in detail in the technical solution of the computer program can be found in the description of the technical solution of the process update method described above.

[0123] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0124] The computer instructions include computer program codes, which may be in source code form, object code form, executable files or some intermediate forms, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content contained in the computer-readable medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0125] It should be noted that, for the above-mentioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of this specification are not limited by the order of the actions described, because according to the embodiments of this specification, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the embodiments of this specification.

[0126] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0127] The preferred embodiments of this specification disclosed above are only used to help explain this specification. The optional embodiments do not describe all the details in detail, nor do they limit the invention to only the specific implementation methods described. Obviously, many modifications and changes can be made according to the content of the embodiments of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the embodiments of this specification, so that technicians in the relevant technical field can well understand and use this specification. This specification is only limited by the claims and their full scope and equivalents.

Claims

1. A process update method, applied to a client, the client comprising: An initial process, a first target process, and a second target process, wherein the initial process is a process responsible for forwarding user requests, the first target process is a process for processing the main client logic, and the second target process is a new process started by processing the main client logic; The first target process receives at least one user request forwarded by the initial process, and starts the second target process when determining that an update condition is met; When initialization is completed, the second target process receives the at least one user request sent by the initial process and processes the at least one user request.

2. The process updating method according to claim 1, wherein the second target process processes the at least one user request, comprising: The second target process receives the user handle carried in the at least one user request from the initial process, determines an internal handle associated with the user handle, and processes the at least one user request based on the internal handle.

3. The process updating method according to claim 2, after the second target process receives the user handle carried in the at least one user request by the initial process and determines the internal handle associated with the user handle, further comprising: The second target process, based on an internal handle associated with the user handle, obtains the target internal handle based on a reopening operation if a handle identical to the internal handle cannot be determined locally, and processes the at least one user request based on the target internal handle.

4. The process update method according to claim 3, wherein obtaining a target internal handle based on a reopen operation and processing the at least one user request based on the target internal handle comprises: The second target process sends a reopen instruction carrying an internal handle associated with a user handle to the back-end server, receives the target internal handle returned by the back-end server in response to the reopen instruction, and processes the at least one user request based on the target internal handle.

5. The process updating method according to claim 3 or 4, after processing the at least one user request based on the target internal handle, further comprising: The second target process receives a handle update completion message returned by the backend server.

6. The process updating method according to claim 5, after processing the at least one user request based on the target internal handle, further comprising: The initial process obtains the target internal handle from the second target process, and caches the association relationship between the user handle carried in the at least one user request and the target internal handle.

7. The process updating method according to claim 1, wherein the initial process forwards the received at least one user request to the first target process, comprising: The initial process forwards the received at least one user request to the first target process based on the local connection protocol; or The initial process forwards the received at least one user request to the first target process based on a shared memory mechanism.

8. The process updating method according to claim 7, before the initial process forwards the received at least one user request to the first target process, further comprising: The initial process receives at least one user request and caches the at least one user request based on a user calling order.

9. The process updating method according to claim 8, after the second target process is initialized, further comprising: The second target process sends a to-be-received instruction to the initial process; The initial process sends the at least one user request to the second target process based on the user calling sequence in response to the instruction to be received.

10. The process updating method according to claim 7, wherein after the second target process is initialized and receives the at least one user request sent by the initial process, the method further comprises: The first target process stops receiving the at least one user request sent by the initial process.

11. A process updating device, applied to a client, the client comprising: An initial process, a first target process, and a second target process, wherein the initial process is a process responsible for forwarding user requests, the first target process is a process for processing the main client logic, and the second target process is a new process started by processing the main client logic; The first target process is configured to receive at least one user request forwarded by the initial process, and start the second target process when it is determined that the update condition is met; The second target process is configured to receive the at least one user request sent by the initial process and process the at least one user request when initialization is completed.

12. A computing device comprising: Memory and processor; The memory is used to store computer executable instructions, and the processor is used to execute the computer executable instructions. When the computer executable instructions are executed by the processor, the steps of the process updating method according to any one of claims 1 to 10 are implemented.

13. A computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, implement the steps of the process updating method according to any one of claims 1 to 10.

Images