Method and apparatus for implementing synchronization network model asynchronization, and distributed system

Abstract

The application discloses a method and device for realizing synchronization network model asynchronization and a distributed system, the method comprising: initiating a service request by using a sending thread pool, and recording task context information associated with the request after sending the request; receiving a request result returned by a three-party server by using a receiving thread pool, performing reverse lookup in the task context information based on at least part of information carried in the request result, and matching a corresponding to-be-processed task; after successful matching, triggering a user-pre-registered asynchronous callback function to complete business processing logic; and based on a preset timing index structure, removing a timeout task, wherein the timing index structure at least comprises a plurality of task information sorted according to task deadlines. The application realizes asynchronization encapsulation of a synchronous interface without relying on underlying network control, and significantly improves system throughput and response timeliness.

Description

Technical Field

[0001] This application relates to the field of computer network technology, specifically to a method, apparatus, and distributed system for implementing asynchronous synchronous network models. Background Technology

[0002] In network interaction middleware, there are generally two approaches: one is the asynchronous I / O model, which is implemented through I / O multiplexing; the other is the synchronous I / O model, which is implemented through multithreading.

[0003] In general use cases, the two modes described above can run perfectly and efficiently in the system, suitable for most application scenarios. However, sometimes special scenarios arise, such as when using software libraries developed by third-party companies. These third-party companies provide synchronous network connections, and in order to obtain their services, it is necessary to accept the synchronous network model. Both synchronous and asynchronous models are implemented using the underlying network socket mechanism. However, relying on third-party network libraries may not provide sockets and only offer network API interfaces. When such API interfaces are blocking interfaces, this approach works fine, but the drawback is that the system throughput is low and a large number of threads are locked, resulting in low CPU utilization. Summary of the Invention

[0004] To address the aforementioned issues, embodiments of this application provide a method, apparatus, and distributed system for implementing asynchronous synchronous network models, aiming to provide the effect of asynchronous implementation of synchronous network models, significantly improve system throughput, and overcome or at least partially overcome the shortcomings of the prior art.

[0005] The embodiments of this application adopt the following technical solutions: Firstly, this application provides a method for implementing asynchronous operation of a synchronous network model. The method is applied to a distributed system comprising a business server and a third-party server, wherein the interfaces provided by the third-party server are synchronous and do not expose access to the underlying sockets; the business server is equipped with a sending thread pool and a receiving thread pool; the method is executed by the business server and includes: Initiate service requests using a thread pool and record the task context information associated with the request after it is sent. The request results returned by the third-party server are received using a receiving thread pool. Based on at least some of the information carried in the request results, a reverse lookup is performed in the task context information to match the corresponding task to be processed. Upon successful matching, the user-pre-registered asynchronous callback function is triggered to complete the business processing logic; Based on a preset timed index structure, timed-out tasks are cleared. The timed index structure includes at least multiple task information sorted by task deadline.

[0006] Secondly, this application also provides an apparatus for implementing asynchronous transformation of a synchronous network model, the apparatus comprising: The sending unit is used to initiate service requests using the sending thread pool and record the task context information associated with the request after the request is sent. The receiving unit is used to receive the request result returned by the third-party server using the receiving thread pool, and to perform a reverse lookup in the task context information based on at least some of the information carried in the request result to match the corresponding task to be processed. The function execution unit is used to trigger the asynchronous callback function pre-registered by the user to complete the business processing logic after a successful match; The timeout clearing unit is used to clear timeout tasks based on a preset timed index structure, wherein the timed index structure includes at least multiple task information sorted according to task deadlines.

[0007] Thirdly, this application also provides a distributed system, which includes at least one business server and a third-party server. The interfaces provided by the third-party services are synchronous and do not open access permissions to the underlying sockets. Each of the business servers is deployed with the above-mentioned asynchronous implementation device for the synchronous network model.

[0008] Fourthly, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method for asynchronousizing the synchronous network model.

[0009] Fifthly, this application also provides a computer-readable storage medium storing a computer program that, when instructed by a processor, implements the steps of the above-described method for asynchronousizing the synchronous network model.

[0010] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: The asynchronous implementation method of the synchronous network model provided in this application enables asynchronous processing of synchronous network calls even under the constraint that the third-party server only provides synchronous interfaces and does not expose access permissions to the underlying sockets. By setting up sending and receiving thread pools in the business server, the request sending and result receiving processes are separated, avoiding the problem of long-term thread blocking in the traditional synchronous mode, and effectively improving the system's concurrent processing capabilities and resource utilization. After the request is sent, the task context information is recorded, and when the receiving thread obtains the return result, a reverse lookup is performed based on the identification information in the result to accurately match the task to be processed, thereby achieving the correct association between the request and the response. After a successful match, a user-preset asynchronous callback function is triggered, allowing business logic to be executed in a non-blocking manner, enhancing the flexibility of the programming model. In addition, by introducing a timed index structure sorted by task deadline, the system can efficiently identify and clear timed-out tasks, preventing the accumulation of invalid tasks that lead to memory bloat, and improving the stability and robustness of the system. Overall, this application achieves asynchronous encapsulation of synchronous interfaces without relying on underlying network control, significantly improving system throughput and response timeliness. Attached Figure Description

[0011] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating an implementation method for asynchronousizing a synchronous network model according to an embodiment of this application is shown. Figure 2 A schematic diagram of multiple tasks on a timeline according to an embodiment of this application is shown; Figure 3 A schematic diagram illustrating an application scenario according to an embodiment of this application is shown; Figure 4 A schematic diagram of the structure of an apparatus for implementing asynchronous transformation of a synchronous network model according to an embodiment of this application is shown; Figure 5 A schematic diagram of the structure of an electronic device according to an embodiment of this application is shown. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] To enable those skilled in the art to more clearly understand the technical solutions provided in the various embodiments of this application, the technical concept of this application will first be described.

[0014] The main concept of this application is to realize the asynchronous nature of synchronous networks by adopting a mechanism of double caching and reverse lookup. Double caching refers to caching the sent request and the returned result respectively, and reverse lookup is to find the corresponding result based on the request or to find the corresponding request based on the result.

[0015] When using third-party network library APIs that are blocking, practical applications often prefer to use them asynchronously. This means specifying an asynchronous callback function when sending a request, and then directly invoking the callback function once the result is returned. The method provided in this application aims to solve this problem. A drawback of the synchronous model is that it blocks the current thread until the result is returned. While this approach is not inherently problematic, its disadvantages include low system throughput and low CPU utilization due to a large number of threads being locked.

[0016] In response, this application provides a method for implementing asynchronous synchronous network models. This method is mainly applied to distributed systems that include business servers and third-party servers. First, the overall access model of this application is explained. Figure 1 A schematic diagram of the structure of a distributed system according to an embodiment of this application is shown. Figure 1 As can be seen, a distributed system includes: a business server and a third-party server. The business server is, in practice, a transaction system, but it can also be other systems. The third-party server is the external service provider that provides the service.

[0017] Currently, the interfaces provided by the third-party services are synchronous and do not grant access to the underlying sockets. Network transmission is subject to congestion.

[0018] To address this, this application adds two thread pools to the business server: a send thread pool for sending requests and a recv thread pool for receiving results. The third-party server maintains two queues: a request queue (req) for receiving incoming requests, and an response queue (ans) for sending returned results.

[0019] Building upon this, the business server decouples the request sending and response processing flow, constructing an asynchronous call framework at the application layer. This allows synchronous API calls to third-party services to be used in an asynchronous callback manner. Specifically, Figure 1 This paper illustrates a flowchart of an implementation method for asynchronousizing a synchronous network model according to an embodiment of this application. Figure 1 As can be seen, this embodiment includes steps S110 to S140: Step S110: The business server initiates a service request using the sending thread pool and records the task context information associated with the request after the request is sent.

[0020] That is, the send thread of the business server sends a request, and then stores the corresponding task in the task queue of the business server, indicating that the request has been sent and the task is waiting for the return result.

[0021] To enable reverse lookup, the business server records the task context information associated with the request after the request is sent.

[0022] Specifically, in some embodiments of this application, the task context information includes at least: original request parameters, user-registered callback function, request sending timestamp, preset timeout threshold, and a unique message ID (msgid) used to identify this request, and a task mapping relationship with msgid as the key is established in local memory for quickly locating the corresponding task when the response arrives.

[0023] Furthermore, in some embodiments, the task context information may also include: a current task status flag; the status flag is used to indicate that the task is in a stage such as "sent but not responded", "responded but not called back", "completed" or "timed out". Furthermore, a complete task state machine control can be realized by combining a dual-buffer and timed index structure, supporting fine-grained task scheduling and exception handling.

[0024] Each process contains two threads: a sending thread responsible for sending data and a receiving thread responsible for receiving data. After sending data, the sending thread returns an msgid to uniquely identify the request. It then stores the msgid and the task data (original request parameters, user-registered callback functions, request timestamps, etc.) as key-value pairs in the task queue to record task context information. The third-party server's request queue (req) receives the service request, passes it to the response queue (ans) for response, and returns the request result.

[0025] Step S120: Receive the request result returned by the third-party server using the receiving thread pool, and perform a reverse lookup in the task context information based on at least some of the information carried in the request result to match the corresponding task to be processed.

[0026] The receiving thread (recv thread) is responsible for receiving the request results returned by the third-party server. The request results retain at least the msgid information from the task context information. Based on this msgid information, a reverse lookup can be performed to match the request with the task to be processed.

[0027] Specifically, the reverse lookup process relies on a third-party server returning a unique identifier msgid in the response that is the same as the request. The business server uses this identifier to retrieve tasks that have been issued but not yet completed (tasks to be processed) in the local storage structure, thus realizing the semantic association between the request and the response.

[0028] The application server uses the msgid in the returned request result to find the corresponding task in the key-value pair that was just inserted, thus matching the request with the result.

[0029] Step S130: After a successful match, the user-pre-registered asynchronous callback function is triggered to complete the business processing logic.

[0030] After a successful match, the callback continues to be executed, that is, the asynchronous callback function pre-registered by the user is triggered to complete the subsequent business logic.

[0031] In some embodiments of this application, there exists an extreme special scenario. As described above, each process has two threads: a sending thread responsible for sending data and a receiving thread responsible for receiving data. After sending data, the sending thread returns an msgid to identify this unique request, and then stores the msgid and the task as a key-value pair in the task list. The receiving thread is responsible for receiving the result, which retains the msgid information. It then uses the returned msgid to find the corresponding task in the previously inserted key-value pair, thus linking the request and the result.

[0032] However, in extremely rare scenarios, after the business server's sending thread sends a request and receives the request result from the third-party server, even though the request result contains the msgid, due to the existence of two threads, the receiving thread may have already received the request result, but the sending thread may not have had time to insert the msgid and task into the key-value pair. In this case, the receiving thread cannot find the task corresponding to the msgid in the key-value pair, and the system will mistakenly assume that the task has timed out, when in fact it is because the sending thread has not yet had time to insert the data.

[0033] To address this issue, this application provides a "dual-buffering mechanism" to meet this extreme and special scenario. A send buffer (send_buff) and a receive buffer (recv_buff) are set up on the business server, both using a map function. <msgid, The data is stored in key-value pairs; where msgid is the unique message ID of the request. This refers to a task object containing the original request parameters and the user registration callback function. When the sending thread receives the unique message ID returned by the third-party server, it first searches for the corresponding request result in the receive cache recv_buff. If it exists, the callback function is executed immediately; if it does not exist, the request indicated by the unique message ID is written into the sending cache send_buff. When the receiving thread receives the request result, it searches for the corresponding request in the sending cache send_buff based on the unique message ID carried by the request result. If it exists, the callback function is executed immediately; if it does not exist, the request is written into the sending cache send_buff.

[0034] The dual-buffering mechanism comprises two independently operating but cooperative hash mapping structures—the send buffer `send_buff` and the receive buffer `recv_buff`, both of which employ a map mechanism. <msgid, The data is stored in key-value pairs; where msgid is a unique message identifier returned by a third-party server. This points to the task object containing the original request parameters and the user registration callback function. If the receiving thread has already obtained the response result before the sending thread has written the task to send_buff, the result is temporarily stored in recv_buff. Subsequently, after obtaining the msgid of the request, the sending thread first checks whether there is a corresponding request result in recv_buff. If there is, the callback function is executed immediately and both sides of the cache are cleared, thereby solving the race condition problem of "result being inserted earlier than request" caused by asynchronous thread execution.

[0035] Specifically, as mentioned earlier, the data is defined in the following format: map <msgid, >send_buff; map <msgid, >recv_buff.

[0036] Because there are two threads, the sending thread sends the request and the receiving thread receives the result quickly, but the sending thread may not have inserted the request into the queue in time. To address this, some embodiments of this application use two caches: a sending thread cache (send_buff) to cache request data and a receiving thread cache (recv_buff) to cache result data. Since both requests and results belong to tasks, task pointers are used in the data structure. The synchronization method for the two threads is as follows: For the sending thread, firstly, it sends the request; secondly, the sending thread finds the corresponding result in the `recv_buff` cache and executes the callback function to continue the subsequent process. This situation requires special explanation because the sending thread and the receiving thread are two different threads. Therefore, there's a scenario where, after sending the request, the receiving thread receives the returned result first and then caches it in advance. Thus, when the sending thread receives the `msgid`, it first checks if a corresponding result exists. If a result for the request already exists, it directly executes the callback. Thirdly, if the sending thread doesn't find a corresponding result in the `recv_buff` cache, it inserts the request into the `send_buff` cache. This situation indicates that a request has been sent but no result has been received.

[0037] For the receiving thread, firstly, it receives the result; secondly, if the receiving thread finds the corresponding request in the `send_buff` cache, the callback continues the subsequent process. Thirdly, if the receiving thread does not find the corresponding request in the `send_buff` cache, it inserts the result into the `recv_buff` cache. This situation indicates that the result has been received but the request has not been found, which is the trigger for the second step of the sending thread above. The result has returned, but the sender has not yet had time to insert the request into the `send_buff` sending cache.

[0038] Step S140: Based on a preset timed index structure, timed-out tasks are cleared, wherein the timed index structure includes at least multiple task information sorted according to task deadlines.

[0039] The business server records a large number of requests and results. If the third-party server does not return results for a long time, a large number of tasks will accumulate, leading to memory bloat and affecting system performance. Therefore, this application embodiment designs a timeout removal mechanism, aiming to remove timed-out tasks from the system while ensuring that the removal is as efficient as possible and does not consume too much CPU resources.

[0040] In some embodiments of this application, the timeout removal mechanism constructs a timed index structure map organized in chronological order. <time_t, set <msgid>> This manages the lifecycle of pending tasks; where the key is the expected latest response timestamp of the task, and the value is the set of all msgids that time out at the same time point; this ordered structure supports batch timeout detection with an approximate O(1) time complexity, quickly locates all timeout msgids in periodic scanning, and then deletes the corresponding task entries from send_buff based on these identifiers, and optionally triggers timeout callbacks to prevent memory backlog and improve system robustness.

[0041] When a third-party server fails to return a result for an extended period, an efficient mechanism is needed to remove timed-out tasks. For example... Figure 2 As shown, Figure 2 A schematic diagram of multiple tasks on a timeline according to an embodiment of this application is shown. Figure 2 The middle horizontal axis represents time, recording which tasks timed out at different points in time. (The above...) Figure 2 As illustrated, sorting tasks by their deadlines allows for an approximate O(1) time complexity to determine which tasks have timed out at the current time. Therefore, some embodiments of this application design the following data structure: map <msgid, >; map <time_t, set <msgid>>

[0042] Among them, map <msgid, This is primarily used to locate the corresponding task based on the msgid. For the sending thread, after sending the request, it will return the msgid. As mentioned above, the sending thread will insert the requested msgid into a key-value pair, where the key is the msgid and the value is the task pointer. .

[0043] map <time_t, set <msgid>This is primarily used to sort tasks by deadline. It can be understood as a timed index structure, where the key is the task's deadline timestamp, i.e., `time_t`. According to the C++ specification, maps are sorted by time from smallest to largest, naturally satisfying the requirement of sorting by deadline. Since multiple tasks may exist for the same deadline, they are stored in a set. If a request is never received, timed-out tasks are periodically cleared. Using a binary search, the msgid to be deleted can be quickly found in approximately O(1) complexity. Then, based on the msgid, the task is found, thus determining which tasks have timed out at that point in time, allowing the timed-out tasks to be deleted.

[0044] In real-world scenarios, there are often multiple processes, such as... Figure 3 As shown, Figure 3 A schematic diagram illustrating an application scenario according to an embodiment of this application is shown. Figure 3 As can be seen, one third-party server corresponds to four business servers. Each business server has five processes, each process has five threads, and each thread corresponds to a task. The task is a concrete representation of the business logic, containing requests and results. The question is how the server finds the corresponding task when it receives the returned result.

[0045] When the application server sends a request, it receives an msgid from the third-party server. The msgid is a unique identifier for that request. The application server needs to establish a key-value pair, where the key is the msgid and the value is a pointer to the task. This allows it to find the corresponding task based on the msgid. However, this relies on the assumption that the process sending the request receives the result, and not that other processes receive the result. In real-world scenarios, multiple processes typically exist concurrently, as shown above. Figure 3 As shown, each third-party server corresponds to 4 business servers, and each business server has 5 processes. It is necessary to ensure that for each process of a business server to send out a request, that process can receive the result and not other processes receive the result.

[0046] In some embodiments of this application, the message routing of the request and response relies on the groupid grouping mechanism. When the business server sends a request, it carries a globally unique identifier groupid = ip + pid, which is generated by combining the local IP address and the current process PID. The third-party server redirects the response back to the specific process space of the specified business server based on the globally unique identifier, ensuring that a request issued by the same process can only be received and processed by that process. This avoids the result mismatch problem in multi-machine and multi-process deployment scenarios and ensures the accuracy of reverse lookup.

[0047] This situation can be resolved using the concept of a third-party server group ID. Requests received by the third-party server are grouped according to their group IDs. When sending a request, the sender must specify which group the request belongs to. The sender can specify that only the group ID data needs to be provided.

[0048] Another issue is how groupid is assigned. For a trading system, the assignment method is groupid = ip + pid, where ip is the IP address and pid is the process ID. The ip identifies the server, and the pid identifies the process ID, thus ensuring the uniqueness of this process identifier. In other words, only this process can receive the result of a sent request. This solves the problem of multiple processes.

[0049] Depend on Figure 1 As can be seen, the asynchronous implementation method of the synchronous network model provided in this application can achieve asynchronous processing of synchronous network calls under the restriction that the third-party server only provides synchronous interfaces and does not open the underlying socket access permissions. By setting up a sending thread pool and a receiving thread pool in the business server, the request sending and result receiving processes are separated, avoiding the problem of long-term thread blocking in the traditional synchronous mode, and effectively improving the system's concurrent processing capability and resource utilization. After the request is sent, the task context information is recorded, and when the receiving thread obtains the return result, a reverse lookup is performed based on the identification information in the result to accurately match the task to be processed, thereby realizing the correct association between the request and the response. After a successful match, the user-preset asynchronous callback function is triggered, allowing the business logic to be executed in a non-blocking manner, enhancing the flexibility of the programming model. In addition, by introducing a timed index structure sorted by task deadline, the system can efficiently identify and clear timed-out tasks, preventing the accumulation of invalid tasks and memory bloat, and improving the stability and robustness of the system. Overall, this application achieves asynchronous encapsulation of synchronous interfaces without relying on the underlying network control, significantly improving system throughput and response timeliness.

[0050] Figure 4 This diagram illustrates a structural schematic of an implementation apparatus for asynchronousizing a synchronous network model according to an embodiment of this application. Figure 4 It can be seen that the asynchronous implementation device 400 of the synchronous network model includes: Sending unit 410 is used to initiate a service request using the sending thread pool and record the task context information associated with the request after the request is sent. The receiving unit 420 is used to receive the request result returned by the third-party server using the receiving thread pool, and to perform a reverse lookup in the task context information based on at least some of the information carried in the request result to match the corresponding task to be processed. Function execution unit 430 is used to trigger the asynchronous callback function pre-registered by the user to complete the business processing logic after a successful match; The timeout clearing unit 440 is used to clear timeout tasks based on a preset timed index structure, wherein the timed index structure includes at least multiple task information sorted according to task deadlines.

[0051] In some embodiments of this application, in the above-described apparatus, the task context information includes at least: original request parameters, user-registered callback function, request sending timestamp, preset timeout threshold, and a unique message ID used to identify this request, and a task mapping relationship is established in local memory with the unique message ID as the key, for quickly locating the corresponding task when the response arrives.

[0052] In some embodiments of this application, in the above-described apparatus, the format of the timing index structure is: map <time_t, set <msgid>>, where time_t is the task's deadline timestamp, set <msgid>It is a set of unique message IDs for at least one task corresponding to the deadline timestamp of the task.

[0053] In some embodiments of this application, in the above-described apparatus, the receiving unit 420 is used to perform a reverse lookup based on the unique message ID that is the same as the request returned by the third-party server in the returned request result. The business server uses the unique message ID to retrieve the issued but not yet completed task from the task context information in the local storage structure.

[0054] In some embodiments of this application, the above-mentioned apparatus further includes: a dual-buffer unit, used to set a send buffer (send_buff) and a receive buffer (recv_buff) on the service server, wherein both the send buffer (send_buff) and the receive buffer (recv_buff) use a map. <msgid, The data is stored in key-value pairs; where msgid is the unique message ID of the request. This refers to a task object containing the original request parameters and the user registration callback function. When the sending thread receives the unique message ID returned by the third-party server, it first searches for the corresponding request result in the receive cache recv_buff. If it exists, the callback function is executed immediately; if it does not exist, the request indicated by the unique message ID is written into the sending cache send_buff. When the receiving thread receives the request result, it searches for the corresponding request in the sending cache send_buff based on the unique message ID carried by the request result. If it exists, the callback function is executed immediately; if it does not exist, the request is written into the sending cache send_buff.

[0055] In some embodiments of this application, there are multiple business servers, which are communicatively connected to one third-party server. Each business server contains multiple processes, and each process contains multiple threads. The routing of requests and request results depends on the groupid grouping mechanism. When sending a request, the business server carries a globally unique identifier generated by combining the local IP address and the current process PID. The third-party server redirects the returned request result to a specific process of the specified business server based on the globally unique identifier.

[0056] It should be noted that the above-mentioned implementation device for asynchronousizing the synchronous network model can implement the aforementioned implementation method for asynchronousizing the synchronous network model, and will not be elaborated further.

[0057] Figure 5 This invention illustrates a schematic diagram of the structure of an electronic device according to an embodiment of the present application. Figure 5 As shown, the electronic device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used for communication with external devices via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a method for asynchronousizing a synchronous network model.

[0058] In one embodiment, the electronic device provided in this application includes a memory and a processor. The memory stores a database and a computer program that can run on the processor. When the processor executes the computer program, it implements the steps of the aforementioned method for implementing the asynchronous transformation of the synchronous network model.

[0059] The above is as stated in this application. Figure 4 The method for implementing asynchronous transformation of a synchronous network model disclosed in the illustrated embodiments can be applied to a processor or implemented by a processor. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The steps of the method disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0060] In one embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the aforementioned method for implementing the asynchronous transformation of the synchronous network model.

[0061] It should be noted that the functions or steps that the above-mentioned electronic devices or computer-readable storage media can achieve can be referred to the relevant descriptions in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0062] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0063] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0064] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.< / msgid> < / msgid> < / msgid> < / msgid> < / msgid>

Claims

1. A method for implementing asynchronous operation of a synchronous network model, wherein the method is applied to a distributed system comprising a business server and a third-party server, wherein, The interfaces provided by the third-party servers are synchronous and do not grant access to the underlying sockets; the business server is equipped with a send thread pool and a receive thread pool. The method is executed by the business server and includes: Initiate service requests using a thread pool and record the task context information associated with the request after it is sent. The request results returned by the third-party server are received using a receiving thread pool. Based on at least some of the information carried in the request results, a reverse lookup is performed in the task context information to match the corresponding task to be processed. Upon successful matching, the user-pre-registered asynchronous callback function is triggered to complete the business processing logic; Based on a preset timed index structure, timed-out tasks are cleared, wherein the timed index structure includes at least multiple task information sorted by task deadline; Configure a send buffer (send_buff) and a receive buffer (recv_buff) on the business server. Both the send buffer (send_buff) and the receive buffer (recv_buff) use a map. <msgid, The data is stored in key-value pairs; where msgid is the unique message ID of the request. Points to the task object containing the original request parameters and the user registration callback function; when the sending thread receives the unique message ID returned by the third-party server, it first searches for the corresponding request result in the receive cache recv_buff. If it exists, the callback function is executed immediately; if it does not exist, the request indicated by the unique message ID is written into the send cache send_buff. When the receiving thread receives the request result, it searches for the corresponding request in the send_buff according to the unique message ID carried in the request result. If it exists, the callback function is executed immediately; if it does not exist, the request is written into the send_buff.

2. The method according to claim 1, characterized in that, The task context information includes at least: original request parameters, user-registered callback function, request sending timestamp, preset timeout threshold, and a unique message ID used to identify this request. A task mapping relationship is established in local memory with the unique message ID as the key, which is used to quickly locate the corresponding task when the response arrives.

3. The method according to claim 1, characterized in that, The format of the timed index structure is: map <time_t,set <msgid>>, where time_t is the task's deadline timestamp, set <msgid> It is a set of unique message IDs for at least one task corresponding to the deadline timestamp of the task.< / msgid> < / msgid> 4. The method according to claim 1, characterized in that, The reverse lookup process relies on the unique message ID that the third-party server returns in the requested result, which is the same as the request. The business server uses the unique message ID to retrieve the issued but not yet completed tasks in the task context information in the local storage structure.

5. The method according to claim 1, characterized in that, The method further includes: multiple service servers, each communicating with a third-party server; each service server containing multiple processes; and each process containing multiple threads. The routing of the request and the request result depends on the groupid grouping mechanism. When the business server sends the request, it carries a globally unique identifier generated by combining the local IP address and the current process PID. The third-party server redirects the returned request result to a specific process of the specified business server based on the globally unique identifier.

6. An apparatus for implementing asynchronous transformation of a synchronous network model, characterized in that, The device includes: The sending unit is used to initiate service requests using the sending thread pool and record the task context information associated with the request after the request is sent. The receiving unit is used to receive the request results returned by the third-party server using the receiving thread pool, and to perform a reverse lookup in the task context information based on at least some of the information carried in the request results to match the corresponding task to be processed. The function execution unit is used to trigger the asynchronous callback function pre-registered by the user to complete the business processing logic after a successful match; The timeout clearing unit is used to clear timeout tasks based on a preset timed index structure, wherein the timed index structure includes at least multiple task information sorted according to task deadline time. The device further includes: setting a send buffer (send_buff) and a receive buffer (recv_buff), wherein both the send buffer (send_buff) and the receive buffer (recv_buff) use a map. <msgid, The data is stored in key-value pairs; where msgid is the unique message ID of the request. Points to the task object containing the original request parameters and the user registration callback function; when the sending thread receives the unique message ID returned by the third-party server, it first searches for the corresponding request result in the receive cache recv_buff. If it exists, the callback function is executed immediately; if it does not exist, the request indicated by the unique message ID is written into the send cache send_buff. When the receiving thread receives the request result, it searches for the corresponding request in the send_buff according to the unique message ID carried in the request result. If it exists, the callback function is executed immediately; if it does not exist, the request is written into the send_buff.

7. A distributed system, characterized in that, The distributed system includes at least one business server and a third-party server. The interfaces provided by the third-party services are synchronous and do not open access permissions to the underlying sockets. Each business server is equipped with the asynchronous implementation device of the synchronous network model as described in claim 6.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method for implementing asynchronous transformation of the synchronous network model as described in any one of claims 1 to 5.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is instructed by the processor, it implements the steps of the method for implementing asynchronous transformation of the synchronous network model as described in any one of claims 1 to 5.

Images