Data interaction method and device, storage medium and electronic equipment

Abstract

The invention discloses a data interaction method and device, a storage medium and electronic equipment, and relates to the technical field of computer storage, the data interaction method comprises the steps that a user mode thread group is created, and the user mode thread group comprises an equipment interaction thread and M request processing threads, the device interaction thread is a unique thread allowing interaction with the storage device by calling the user mode execution thread; in response to a received first service instruction, converting the first service instruction into a first data interaction request, and allocating the first data interaction request to a first request processing thread in the M request processing threads; submitting the first data interaction request to an equipment interaction thread through a first request processing thread; the user mode execution thread is called through the device interaction thread, and the first data interaction request is sent to the first storage device, so that the first storage device executes the corresponding first data interaction operation, and the technical problems of low efficiency and performance waste existing in a data interaction method in related technologies are solved.

Description

Technical Field

[0001] The present application relates to the field of computer storage technology, and in particular to a data interaction method and device, a storage medium, and an electronic device. Background Art

[0002] In a traditional Ceph distributed storage cluster, when the storage engine uses the traditional multi-threaded asynchronous I / O (Input / Output) method to process business and perform I / O operations, it needs to submit I / O requests through the operating system kernel. There are thread context switches and the context switches caused by switching to kernel state, which lead to time-consuming and performance-wasting. When user-state drivers are introduced, although the data interaction process can be completed in user state, the I / O model supported by the user-state driver is incompatible with the I / O model of the storage engine itself, resulting in low efficiency in processing data interaction requests and executing interaction operations, and wasted performance.

[0003] It can be seen that the data interaction methods in related technologies have problems of low efficiency and performance waste. Summary of the Invention

[0004] The present application provides a data interaction method and device, a storage medium, and an electronic device to at least solve the problems of low efficiency and performance waste in data interaction methods in related technologies.

[0005] The present application provides a data interaction method, comprising: creating a user-state thread group, wherein the user-state thread group includes a device interaction thread and M request processing threads, the device interaction thread is the only thread in the user-state thread group that is allowed to interact with a storage device by calling a user-state execution thread, and M is a positive integer greater than or equal to 2; in response to a received first business instruction, converting the first business instruction into a first data interaction request, and assigning the first data interaction request to a first request processing thread among the M request processing threads; submitting the first data interaction request to the device interaction thread through the first request processing thread; calling the user-state execution thread through the device interaction thread, and sending the first data interaction request to a storage device, so that the storage device performs a first data interaction operation corresponding to the first data interaction request.

[0006] The present application also provides a data interaction device, including: a creation unit, used to create a user-state thread group, wherein the user-state thread group includes a device interaction thread and M request processing threads, the device interaction thread is the only thread in the user-state thread group that is allowed to interact with the storage device by calling the user-state execution thread, and M is a positive integer greater than or equal to 2; a first execution unit, used to convert the first business instruction into a first data interaction request in response to a received first business instruction, and assign the first data interaction request to the first request processing thread among the M request processing threads; a submission unit, used to submit the first data interaction request to the device interaction thread through the first request processing thread; a first sending unit, used to call the user-state execution thread through the device interaction thread, and send the first data interaction request to the storage device, so that the storage device executes the first data interaction operation corresponding to the first data interaction request.

[0007] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned data interaction methods when executing the computer program.

[0008] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned data interaction methods are implemented.

[0009] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned data interaction methods when executed by a processor.

[0010] Through the present application, a user-mode thread group is created, wherein the user-mode thread group includes a device interaction thread and M request processing threads, the device interaction thread is the only thread in the user-mode thread group that is allowed to interact with the storage device by calling the user-mode execution thread, and M is a positive integer greater than or equal to 2; in response to a received first business instruction, the first business instruction is converted into a first data interaction request, and the first data interaction request is assigned to the first request processing thread among the M request processing threads; the first data interaction request is submitted to the device interaction thread through the first request processing thread; the user-mode execution thread is called through the device interaction thread, and the first data interaction request is sent to the first storage device, so that the first storage device executes the first data interaction operation corresponding to the first data interaction request. As a result, multiple request processing threads in each user-mode thread group can share a device interaction thread to call a user-mode execution thread to process the data interaction request, avoiding the situation where each thread requires an independent queue, thereby utilizing the queue depth and high concurrency of the storage device and reducing the context switching overhead. Therefore, the problems of low efficiency and performance waste in the data interaction method in the related art can be solved, and the technical effect of improving data interaction efficiency and improving thread processing performance can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0012] Figure 1 This is a schematic diagram of an application scenario of a data interaction method according to an embodiment of the present application.

[0013] Figure 2 This is a flow chart of an optional data interaction method according to an embodiment of the present application.

[0014] Figure 3 This is a schematic diagram of an optional data interaction method according to an embodiment of the present application.

[0015] Figure 4 It is a schematic diagram of another optional data interaction method according to an embodiment of the present application.

[0016] Figure 5 This is a schematic diagram of another optional data interaction method according to an embodiment of the present application.

[0017] Figure 6 This is a schematic diagram of another optional data interaction method according to an embodiment of the present application.

[0018] Figure 7 This is a flowchart of another optional data interaction method according to an embodiment of the present application.

[0019] Figure 8 This is a schematic diagram of another optional data interaction method according to an embodiment of the present application.

[0020] Figure 9 This is a schematic diagram of another optional data interaction method according to an embodiment of the present application.

[0021] Figure 10 This is a structural block diagram of an optional data interaction device according to an embodiment of the present application. DETAILED DESCRIPTION

[0022] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0023] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0024] According to one aspect of the embodiment of the present application, a data interaction method is provided. Optionally, in this embodiment, the above data interaction method can be applied to Figure 1 In the hardware environment shown in FIG. 1 , which is composed of a terminal device 102 and a server 104. Figure 1 As shown, the server 104 is connected to the terminal device 102 via a network, and can be used to provide services (such as application services, etc.) for the terminal or the client installed on the terminal. A database can be set on the server or independently of the server to provide data storage services for the server 104.

[0025] The aforementioned network may include, but is not limited to, at least one of the following: a wired network and a wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: a wide area network, a metropolitan area network, and a local area network. The aforementioned wireless network may include, but is not limited to, at least one of the following: Wi-Fi (Wireless Fidelity) and Bluetooth.

[0026] The data interaction method of the embodiment of the present application can be executed by the server 104, or by the terminal device 102, or by both the server 104 and the terminal device 102. The data interaction method of the embodiment of the present application can also be executed by the client installed on the terminal device 102.

[0027] Taking the data interaction method in this embodiment executed by the server 104 as an example, Figure 2 is a flow chart of an optional data interaction method according to an embodiment of the present application, such as Figure 2 As shown, the process of this method includes the following steps:

[0028] Step S202: Create a user-mode thread group, where the user-mode thread group includes one device interaction thread and M request processing threads. The device interaction thread is the only thread in the user-mode thread group that is allowed to interact with the storage device by calling the user-mode execution thread. M is a positive integer greater than or equal to 2.

[0029] Step S204: In response to the received first business instruction, convert the first business instruction into a first data interaction request, and assign the first data interaction request to a first request processing thread among the M request processing threads;

[0030] Step S206: submitting the first data interaction request to the device interaction thread through the first request processing thread;

[0031] Step S208 : calling the user-mode execution thread through the device interaction thread and sending the first data interaction request to the storage device, so that the storage device executes the first data interaction operation corresponding to the first data interaction request.

[0032] The method of this embodiment can be applied to the field of computer storage technology, and can be applied to scenarios where data interaction and storage are performed using a Ceph distributed storage cluster. Here, the Ceph distributed storage cluster is a highly scalable distributed storage system that supports object storage, block storage, and file storage. Among them, Ceph OSD (Object Storage Device, object storage daemon) is one of the components of the Ceph distributed storage cluster and is used to perform data read and write operations on storage nodes.

[0033] In a traditional Ceph distributed storage cluster, the storage engine OSD uses a traditional multi-threaded asynchronous I / O (Input / Output) approach to process services and perform I / O operations. In this model, multiple threads (typically greater than the number of processor cores used by the OSDs) are allocated to form a thread pool. These threads then initiate asynchronous I / O operations on block devices. This process requires initiating a system call and entering kernel state, where the I / O operation is submitted to the storage device via the operating system kernel.

[0034] Here, when a Ceph OSD receives a read or write request, it can place the request in a task queue, and threads in the thread pool can take the task out of the queue for processing. For I / O tasks that require reading or writing block devices, the thread can submit the I / O request to the operating system kernel by initiating a system call. This means that the submission of the I / O request is separated from the actual I / O operation. After submitting the request, the thread can continue to perform other tasks, while the operating system kernel will process the I / O asynchronously and notify the OSD thread through an interrupt or signal after the operation is completed.

[0035] Since the above model requires initiating a system call and entering kernel state, the operating system's call overhead increases and some performance issues arise. For example, thread context switching causes time consumption and cache invalidation. Here, thread context switching refers to the process by which the operating system switches from the currently executing thread to another thread. This process involves saving the current thread's register state, program counter, stack pointer, and other information, while restoring the context of the next thread. Context switching itself consumes CPU (Central Processing Unit) time, especially in a multi-threaded environment. Frequent switching can significantly increase CPU utilization, thereby reducing application throughput. In addition, thread switching can also cause cache invalidation. Since each thread may have its own cached hotspot data, when a thread is switched out of the CPU, the cached data associated with the thread may be replaced to make room for the next thread. When the thread is scheduled again, its cached data may no longer exist and need to be reloaded from a lower cache level or main memory, increasing access latency.

[0036] For example, the context switch caused by falling into kernel state is time-consuming. Here, when a thread falls from user state to kernel state (that is, executes a system call), an additional context switch will be triggered. That is, the system call involves a transition from user state to kernel state. During this transition, the operating system will save the context of user state, switch to kernel state to perform specific operations, and finally return control to user state. Each transition requires complex context saving and restoring operations, which not only consumes CPU time, but may also interrupt the continuous execution of the application, causing additional delays.

[0037] In addition, there may be context switches caused by system interrupts when I / O is completed. In the I / O operation model, when the storage device completes an I / O request, it sends an interrupt signal to the operating system to notify the operating system that the I / O is complete. After the operating system kernel receives the interrupt, it executes the interrupt handler, which also triggers a transition from user mode to kernel mode, executes the interrupt handler, and then switches back to user mode. The execution of the interrupt handler interrupts the currently running user mode thread, causing the context of the thread to be saved, thereby increasing scheduling overhead. In addition, interrupt handling itself may also involve complex logic. Especially when processing multiple concurrent I / O requests, the delay in interrupt handling will directly affect the overall I / O performance.

[0038] To reduce the impact of the above performance issues, high-performance storage systems, such as those using the SPDK (Storage Performance Development Kit), tend to handle I / O operations and device management directly in user mode, avoiding frequent system calls and context switches. Here, SPDK is a tool set that can bypass the operating system kernel and directly access high-performance storage devices through user-mode drivers and optimized programming models. Based on this, user-mode NVMe (Non-Volatile Memory Express) drivers can be introduced to interact with storage devices, reducing dependence on kernel mode and thus reducing the number and overhead of context switches.

[0039] The SPDK user-mode NVMe driver allows applications to directly access the hardware resources of storage devices. It can initiate and manage I / O operations by directly reading and writing device registers, avoiding kernel intervention. Furthermore, unlike interrupt-driven mode, the SPDK user-mode NVMe driver uses a polling mode to check the completion status of I / O operations. In polling mode, applications periodically check device status without waiting for interrupt signals. This not only avoids interrupt processing overhead but also allows for more precise control of polling frequency, thereby finding a balance between reducing CPU usage and responding to I / O completions promptly.

[0040] However, the user-mode driver in the SPDK framework is designed as a single-threaded model, that is, the I / O operation of each device is processed in a circular polling manner in one thread, thereby reducing the context switching overhead in a multi-threaded environment and avoiding the delay caused by interrupt processing. NVMe devices can be directly operated in user mode to achieve more efficient I / O performance; when Ceph tries to use the user-mode driver of SPDK, after the thread submits the I / O request, the thread will cyclically poll the completion status of the I / O request until the I / O request is completed, that is, when Ceph tries to use the user-mode driver of SPDK, it uses a synchronous I / O operation. For the I / O queue of the storage device, each queue actually only serves one SPDK thread, so the queue depth is limited to 1 in actual operation, that is, each queue can only process one I / O command at the same time. For storage devices that support multiple I / O queues, each of which can process a series of I / O commands, the queue depth refers to the number of I / O commands that can be stored in each queue. A higher queue depth means that the storage device can process more I / O operations simultaneously, thereby improving concurrency. However, for storage devices where the depth of each I / O queue is limited to 1 by the SPDK thread model, the performance of the storage device cannot be fully utilized, affecting the overall I / O processing throughput and response time.

[0041] In addition, SPDK's single-threaded I / O model also requires that an independent NVMe queue be allocated to each thread performing I / O operations to avoid competition and data consistency issues between multiple threads. In Ceph, since there are multiple threads (usually a large number) inside the OSD, in order to match the limitations of SPDK, each thread needs to have its own storage device queue. For low-end storage devices, the number of queues they support may be small, which is not enough to allocate an independent queue to each thread in the Ceph OSD. This will not only lead to a waste of device resources, but also may reduce the performance of the Ceph OSD due to insufficient queue allocation, and may even fail to meet the needs of concurrent I / O, limiting the deployment and performance of Ceph on low-end storage devices.

[0042] For example, Figure 3As shown, the current use of SPDK is mainly based on the SPDK framework. By using SPDK's RTC (Reactor Thread Context) mode, the upper-layer business and lower-layer I / O are executed by the same thread at the same time. In this thread model, each thread carries the upper-layer business and lower-layer I / O at the same time, and processes them separately in a continuous loop. When I / O is initiated, SPDK starts to execute other tasks in sequence, thereby realizing asynchronous I / O on a single thread. This thread model is very incompatible with Ceph's current OSD thread model. The current CephOSD thread model is still using the traditional multi-threaded asynchronous I / O model, which executes various tasks asynchronously by scheduling different threads in the thread pool. The current CephOSD uses the SPDK user-mode driven process as shown below. Figure 4 As shown in the figure, during operation, a large number of OSD threads constantly switch and execute different tasks. When using the SPDK user-mode driver interface, a single thread synchronously initiates I / O, waits in a loop, and polls for I / O completion. During this loop, the thread cannot execute other tasks and can only wait or sleep. This results in significant thread switching overhead and undermines the high concurrency performance of the storage device.

[0043] It can be seen that the data interaction methods in related technologies have problems of low efficiency and performance waste.

[0044] In order to at least partially solve the above technical problems, a data interaction method is proposed in this embodiment, which introduces a user-state thread group for thread pool optimization. By creating a user-state thread group, wherein the user-state thread group includes a device interaction thread and M request processing threads, the device interaction thread is the only thread in the user-state thread group that is allowed to interact with the storage device by calling the user-state execution thread, and M is a positive integer greater than or equal to 2; in response to a received first business instruction, the first business instruction is converted into a first data interaction request, and the first data interaction request is assigned to the first request processing thread among the M request processing threads; the first data interaction request is submitted to the device through the first request processing thread. Interaction thread; calling the user-state execution thread through the device interaction thread, sending the first data interaction request to the first storage device, so that the first storage device executes the first data interaction operation corresponding to the first data interaction request, thereby, multiple request processing threads in each user-state thread group can share a device interaction thread to call a user-state execution thread to process the data interaction request, avoiding the situation where each thread requires an independent queue. Since the entire data interaction process is executed in the user state, the context switching overhead is reduced, which can solve the problems of low efficiency and performance waste in the data interaction method in the related technology, and achieve the technical effect of improving data interaction efficiency and improving thread processing performance.

[0045] Alternatively, an M:N model thread library can be created, that is, a thread library including M request processing threads and N system-level threads (equivalent to device interaction threads). The M request processing threads can be mapped to N system-level threads. By reducing the number of system-level threads, the thread switching and scheduling overhead is minimized, while improving the concurrency of the program. However, in this thread library, the M request processing threads may switch between different system-level threads, for example, Figure 5 As shown, a request processing thread may be transferred to other idle system-level threads for execution, which conflicts with SPDK's requirement for resource isolation between threads.

[0046] In this embodiment, a user-state thread group can be created, wherein the user-state thread group includes a device interaction thread and M request processing threads. The device interaction thread is the only thread in the user-state thread group that is allowed to interact with the storage device by calling the user-state execution thread, and M is a positive integer greater than or equal to 2.

[0047] Optionally, a user-mode thread group can be created and added to the storage system. For example, the thread pool in the Ceph OSD can be replaced with a user-mode thread group, where each user-mode thread pool includes only one device interaction thread and runs in the above-mentioned RTC mode.

[0048] Optionally, the device interaction thread in each user-mode thread group can be pre-set as the only thread allowed to interact with the storage device by calling the user-mode execution thread. Here, the user-mode execution thread refers to a lightweight thread in the user-mode execution framework, and is also the environment in which all operations in the user-mode execution process run. It can encapsulate a series of function calls and data processing processes for efficient data interaction directly with the storage device without having to interact with the storage device through the operating system kernel.

[0049] After receiving the business instruction, the business instruction can be converted into a data interaction request that can be understood by the storage device. The business instruction can be used to indicate read and write operations on files, reading of data blocks, etc. The OSD can convert it into a data interaction request after receiving the business instruction. According to the content indicated by the business instruction, the data interaction request may include the requested data information, the requested data address, etc., which is not limited in this embodiment.

[0050] Optionally, after the first business instruction is converted into a first data interaction request, it can be assigned to a request processing thread, namely the first request processing thread. The request processing thread can be one of M request processing threads, which can be directly specified or a randomly assigned thread in an idle state.

[0051] Optionally, after receiving the first data processing request, the first request processing thread can submit the data processing request to the above-mentioned device interaction thread, and then the device interaction thread calls the user-state execution thread to send the first data interaction request to the storage device, so that the storage device executes the first data interaction operation corresponding to the first data interaction request, thereby separating the reception and processing of the data interaction request from the device interaction, and processing multiple data interaction requests in parallel by multiple request processing threads, and the multiple request processing threads correspond to the only device interaction thread in each user-state thread group that can call the user-state execution thread, and the submission of the data interaction request is completed by the device interaction thread, thereby complying with the requirements of SPDK. Each user-state execution thread corresponds to a storage device queue to avoid resource competition and data inconsistency problems.

[0052] Optionally, after receiving a data interaction request, the storage device can execute the data interaction operation corresponding to the data interaction request. It should be noted that each device interaction thread is associated with an independent queue of the storage device. For a user-mode thread group, there can be multiple requests queued in the queue of the storage device waiting for execution, so that the queue depth of the storage device can be utilized and the concurrent processing capabilities of the storage device can be fully utilized.

[0053] Through the embodiments provided by the present application, a user-mode thread group is created, wherein the user-mode thread group includes a device interaction thread and M request processing threads, the device interaction thread is the only thread in the user-mode thread group that is allowed to interact with the storage device by calling the user-mode execution thread, and M is a positive integer greater than or equal to 2; in response to a received first business instruction, the first business instruction is converted into a first data interaction request, and the first data interaction request is assigned to the first request processing thread among the M request processing threads; the first data interaction request is submitted to the device interaction thread through the first request processing thread; the user-mode execution thread is called through the device interaction thread, and the first data interaction request is sent to the storage device, so that the storage device executes the first data interaction operation corresponding to the first data interaction request. This can solve the problems of low efficiency and performance waste in the data interaction method in the related art, and achieve the technical effect of improving data interaction efficiency and improving thread processing performance.

[0054] In an exemplary embodiment, after the first request processing thread submits the first data interaction request to the device interaction thread, the method further includes:

[0055] The first request processing thread is switched to a ready state through the first request processing thread to wait for the completion of the first data interaction operation, and the scheduling is released to release the processing resources occupied by the first request processing thread. After the first request processing thread gives up the scheduling, other user-mode threads in the user-mode thread group are allowed to be executed.

[0056] In this embodiment, after the first request processing thread completes receiving the data interaction request and submits it to the device interaction thread, it does not need to wait for the I / O operation to be completed. Optionally, the thread can give up scheduling, that is, actively switch to the ready state, which means that it releases the currently executing CPU resources and is no longer the active occupant of the resource.

[0057] Here, when the first request processing thread is in the ready state, it has actually completed the current task, and the subsequent tasks, such as actual I / O execution and status polling, can be undertaken by the device interaction thread.

[0058] Optionally, by giving up scheduling, the first request processing thread can actively give up control of the CPU, so that the user-mode thread group can choose to execute other threads in the user-mode thread group that are in the ready state according to a pre-set scheduling policy. The threads can be other request processing threads or device interaction threads. Therefore, even if the first data interaction operation has not been completed, subsequent business requests can still be processed and executed.

[0059] According to this embodiment, the first request processing thread yields scheduling after completing the operation, thereby effectively utilizing resources and improving the efficiency of data interaction request processing.

[0060] In an exemplary embodiment, after the first request processing thread switches the first request processing thread to a ready state, the method further includes:

[0061] When the second request processing thread among the M request processing threads is executed, in response to the received second business instruction, the second business instruction is converted into a second data interaction request, and the second data interaction request is assigned to the second request processing thread; the second data interaction request is submitted to the device interaction thread through the second request processing thread, and the second request processing thread is switched to a ready state to wait for the second data interaction operation corresponding to the second data interaction request to be completed, and the scheduling is released to release the processing resources occupied by the second request processing thread; when the device interaction thread is executed, the user-mode execution thread is called through the device interaction thread to send the second data interaction request to the storage device, so that the storage device performs the second data interaction operation.

[0062] In this embodiment, the system may receive multiple service instructions, for example, the second service instruction.

[0063] Similar to the above embodiment, in response to the received second service instruction, the second service instruction may be converted into a second data interaction request, and the request may be assigned to a second request processing thread, one of the M request processing threads, for processing.

[0064] Optionally, the second request processing thread may submit the second data interaction request to the device interaction thread, and the device interaction thread calls the user state execution thread to be responsible for actual communication with the storage device.

[0065] Optionally, after submitting the request, the second request processing thread can also switch to the ready state, that is, temporarily give up control of the device interaction thread and wait for the completion of the second data interaction operation. In the process of switching to the ready state, the second request processing thread releases the processing resources it occupies so that the thread library can schedule other waiting request processing threads.

[0066] Through this mechanism, even if the first data interaction operation is not completed, the system can immediately respond to new business instructions, converting the second business instruction into a second data interaction request, which is then executed by the second request processing thread. This allows multiple business instructions to be processed in parallel, improving the overall system throughput. In addition, after each request processing thread completes the submission of a data interaction request, it can switch to the ready state and release resources to allow the system to schedule other waiting request processing threads. This mechanism ensures that CPU resources are not locked for long periods by threads in a waiting state, improving the efficiency of system resource utilization.

[0067] Optionally, when more business instructions are received, even if the previous business instructions have not been completed, they can be assigned to other idle request processing processes, such as the third request processing process, the fourth request processing process, etc., which is not limited in this embodiment.

[0068] Through this embodiment, by converting the second business instruction into a data interaction request and assigning it to the second request processing thread for execution, multiple business instructions can be processed in parallel, thereby improving concurrency performance and resource utilization efficiency.

[0069] In an exemplary embodiment, after the device interaction thread calls the user mode execution thread and sends the second data interaction request to the storage device, the method further includes:

[0070] When the device interaction thread queries that there is a completed data interaction operation in the first data interaction operation and the second data interaction operation, the request processing thread corresponding to the completed data interaction operation is awakened through the device interaction thread, the device interaction thread is switched to a ready state, and the scheduling is released to release the processing resources occupied by the device interaction thread; when the request processing thread corresponding to the completed data interaction operation is executed, the associated operation of the completed data interaction operation is executed through the request processing thread corresponding to the completed data interaction operation, the request processing thread corresponding to the completed data interaction operation is switched to a ready state, and the scheduling is released to release the processing resources occupied by the request processing thread corresponding to the completed data interaction operation.

[0071] In this embodiment, after the device interaction thread calls the user mode execution thread to complete the I / O request submission, the thread does not stop or wait immediately, but enters the polling phase to query the execution status of the submitted data interaction request on the storage device.

[0072] Optionally, when the device interaction thread detects that either the first data interaction operation or the second data interaction operation has been completed, it can wake up the request processing thread corresponding to the completed data interaction request. For example, when the first data interaction operation is queried, it can wake up the first request processing thread. When it is queried that both the first data interaction operation and the second data interaction operation have been processed, it can wake up both the first request processing thread and the second request processing thread.

[0073] Optionally, the device interaction thread can wake up the request processing thread associated with the completed data interaction operation through the built-in communication mechanism, so that the request processing thread can quickly resume execution and handle subsequent tasks related to the completed operation, such as data confirmation, logging, or business logic updates.

[0074] Optionally, after waking up the request processing thread, the device interaction thread itself can also switch to the ready state and give up scheduling, releasing the processing resources it occupies, thereby ensuring that the device interaction thread does not occupy CPU resources when the operation has been completed, and can freely allocate resources to other threads waiting to be executed, including but not limited to other request processing threads.

[0075] Optionally, when the awakened request processing thread resumes execution, it can perform subsequent associated operations related to the completed data interaction operation. Similarly, after these associated operations are completed, the request processing thread can switch to the ready state and give up scheduling, releasing the processing resources it occupies.

[0076] For example, the interaction process between the request processing thread and the device interaction thread in the user thread group can be as follows: Figure 6 As shown:

[0077] (1) Request processing thread 1 receives OSD upper layer service requests and submits I / O requests to the device interaction thread;

[0078] (2) Request processing thread 1 waits for the I / O to complete and yields scheduling, and the WorkGroup (i.e., user-mode thread group) begins executing request processing thread 2;

[0079] (3) Request processing thread 2 receives the OSD upper layer service request and submits the I / O request to the device interaction thread;

[0080] (4) Request processing thread 2 waits for the I / O to complete and yields scheduling, and the WorkGroup begins executing the device interaction thread;

[0081] (5) The device interaction thread submits I / O to the storage device;

[0082] (6) The device interaction thread polls I / O completion through the SPDK thread (i.e., the user-mode execution thread);

[0083] (7) When I / O is completed, the device interaction thread wakes up request processing thread 1 and request processing thread 2;

[0084] (8) The device interaction thread gives up scheduling, and WorkGroup starts executing request processing thread 1;

[0085] (9) Request processing thread 1 to perform subsequent processing after I / O completion;

[0086] (10) Request processing thread 1 completes I / O processing, yields scheduling, and begins executing request processing thread 2.

[0087] The OSD backend cycles through the above process to process transactions submitted by the front-end business, submit I / O to the SPDK block device, and complete data storage.

[0088] It should be noted that in the above process, the execution order between threads can be pre-set and can also be modified. For example, after the request processing thread 1 submits the I / O request, the device interaction thread can also directly submit the request to the storage device.

[0089] Optionally, when more request processing threads receive data interaction requests, they can also join the above process. For example, request processing thread 3 can also receive OSD upper-layer service requests and submit I / O requests to the device interaction thread when scheduling is idle.

[0090] Through this embodiment, the device interaction thread wakes up the corresponding request processing thread when it is found that the data interaction operation is completed, thereby improving the response speed and resource utilization efficiency.

[0091] In an exemplary embodiment, after the device interaction thread calls the user mode execution thread and sends the first data interaction request to the storage device, the method further includes:

[0092] The user state execution thread is called through the device interaction thread to poll the execution status of the first data interaction operation.

[0093] Similar to the aforementioned embodiment, the user-mode execution thread can encapsulate a series of function calls and data processing processes for interacting with the storage device, which can be used to perform functions including data reading and writing, status polling, etc. Thus, the device interaction thread can continuously poll the execution status of data interaction operations on the storage device by calling the user-mode execution thread. This process is completed in the user mode, thereby avoiding common performance bottlenecks in traditional I / O operations, such as context switching caused by system interrupts.

[0094] Optionally, the device interaction thread may periodically call the user mode execution thread, and the polling frequency may be preset.

[0095] Through this embodiment, the device interaction thread calls the user state execution thread to poll the execution status of the data interaction operation.

[0096] In an exemplary embodiment, creating a user-mode thread group includes: creating M input / output threads to obtain M request processing threads, wherein the M request processing threads are used to carry services of an object storage daemon process; creating a device interaction thread, and creating a user-mode execution thread through the device interaction thread, wherein the device interaction thread is used to carry the user-mode execution thread;

[0097] After creating the user-mode thread group, the method further includes: enabling a user-mode block device, wherein the user-mode block device is used to provide a driver for the storage device.

[0098] In this embodiment, multiple user-state thread groups can be created. When creating each user-state thread group, M input and output threads can be created to obtain M request processing threads. Among them, the M request processing threads are used to carry the business of the object storage daemon, that is, to carry the business logic of the OSD, which can handle read and write requests, data operations, etc. from the front end.

[0099] For each user-mode thread group, a device interaction thread can be created, and a user-mode execution thread can be created through the device interaction thread. Here, the device interaction thread is a special thread that runs in user mode and is the environment that hosts the user-mode execution thread (such as the SPDK thread).

[0100] Optionally, when the volume of business requests increases significantly, that is, when the business instructions increase significantly, the I / O performance of the storage device can be monitored and analyzed, including but not limited to the number of input and output operations per second, throughput and response time. If the device performance data shows that there is still sufficient I / O processing capacity, that is, the maximum I / O throughput limit of the device has not been reached, the number of request processing threads in the corresponding user-mode thread group can be dynamically increased, so that more business requests can be processed in parallel, making full use of the high concurrency characteristics of the storage device to reduce the waiting time of requests and improve the overall I / O processing efficiency of the system.

[0101] Optionally, if the volume of business requests decreases or the I / O performance of the storage device begins to decline, the number of request processing threads can be reduced, thereby reducing the frequency of access to the storage device, reducing unnecessary thread switching overhead, and maintaining efficient system operation.

[0102] Optionally, if the device I / O latency is detected to be low, it indicates that the storage device has a fast response speed. In this case, the polling frequency of the device interaction thread can be reduced to save system resources and improve overall efficiency.

[0103] In this embodiment, after the user-mode thread group is created, the user-mode block device may be enabled. The user-mode block device is used to provide a driver for the storage device, which is responsible for processing all I / O operations directly related to the storage device.

[0104] In traditional Ceph implementations, I / O operations are performed by kernel block device drivers, which requires frequent system calls and kernel state switches, increasing the scheduling overhead of the operating system.

[0105] Optionally, the user-mode block device layer can allow threads to directly access the hardware of storage devices by using user-mode drivers, avoiding kernel-mode intervention, thereby reducing delays caused by system calls and context switches.

[0106] Here, the user-mode block device can abstract the resources of the physical storage device and provide a unified interface for upper-layer applications.

[0107] In this embodiment, the data interaction method process may be as follows:

[0108] (1) CephOSD initializes the SPDK environment and SPDK thread library (i.e., calls the initialization interface of the SPDK environment and the initialization interface of the SPDK thread library);

[0109] (2) OSD initializes the user-mode thread group;

[0110] (3) Each user-mode thread group creates multiple request processing threads;

[0111] (4) Each user-mode thread group creates a device interaction thread for carrying the user-mode execution thread. The device interaction thread creates a user-mode execution thread and opens the user-mode block device.

[0112] (5) The request processing thread submits the I / O to the device interaction thread and waits asynchronously;

[0113] (6) The device interaction thread submits the I / O to the user-mode block device through the user-mode execution thread, executes the user-mode execution thread, and queries the I / O completion status;

[0114] (7) The I / O on the storage device is completed, waking up the corresponding request processing thread.

[0115] Optionally, the initialization process can be as follows Figure 7 As shown:

[0116] (1) When OSD is initialized, a system thread is started to call the SPDK environment initialization interface and the SPDK thread library initialization interface;

[0117] (2) Initialize the thread pool environment, set the number of user-mode thread groups in the thread pool, and set the number of concurrent threads in the user-mode thread group to 1;

[0118] (3) Start several request processing threads in each user-mode thread group to carry OSD services and enable device interaction threads;

[0119] (4) The device interaction thread creates a user-mode execution thread and opens the user-mode block device for I / O.

[0120] In addition, since each user-mode thread group has its own user-mode execution thread for interacting with I / O devices, it is not only better adapted to user-mode block devices, but the user-mode execution thread is also compatible with multiple types of back-end storage devices (for example, kernel block devices, NVMf (Non-Volatile Memory Express over Fabrics) devices, iSCSI (Internet Small Computer System Interface) devices, etc.). Therefore, no matter what type of storage device is used by the Ceph OSD backend, as long as it can be identified and driven through the user-mode block device, data read and write operations can be performed on it.

[0121] In this embodiment, if Figure 8 As shown, Blue Storage is a backend storage engine in the Ceph storage system, which is used to build data storage on block devices. The OSD messenger is responsible for handling communication between OSDs. The messenger thread pool refers to a set of threads used to handle various communication tasks in Ceph. A thread pool composed of user-mode thread groups can be introduced to replace the original OSD shared thread pool, and the original block device can be replaced by an SPDK block device. The modified OSD can be connected to a variety of storage devices (such as NVMf devices, iSCSI devices, PCIe NVMe devices, etc.) through the SPDK block device driver, so that the thread executing I / O is the above-mentioned request processing thread, wherein the request processing thread can directly communicate with other request processing threads in the same user-mode thread group at will. This is because in the same user-mode thread group, the execution and switching of all request processing threads are run in the context of the same device interaction thread. All request processing threads can share the same context environment and do not need to enter the kernel state to call other threads, thereby reducing the overhead caused by communication between threads and eliminating the need for thread-safe protection of data.

[0122] It can be seen that by modifying the thread model of CephOSD, the original thread pool + asynchronous I / O model is modified to an RTC model based on user-mode thread groups, and the backend block device is replaced by the original kernel block device or SPDK-based NVMe user-mode driver with a user-mode block device. While reducing I / O overhead and system resource usage, compared to the original OSD implementation, it also maintains the compatibility and reliability brought by the introduction of SPDK block devices.

[0123] Through this embodiment, by creating a user-mode thread group and enabling a user-mode block device, an efficient and reliable storage system execution model can be constructed, thereby improving the system's concurrency performance and data processing efficiency.

[0124] In an exemplary embodiment, the method further includes:

[0125] When a state change occurs in a storage device, the user-state execution thread utilizes a lock-free queue mechanism to send device notification information to the user-state thread associated with the storage device in the user-state thread group, wherein the device notification information is used to indicate that a state change occurs in the storage device, and the user-state threads associated with the storage device include: user-state threads corresponding to data interaction operations that have not been completed by the storage device.

[0126] When multiple threads access storage devices, since threads can be executed concurrently on different processor cores, locks, atomic operations or other thread synchronization mechanisms are needed to protect shared data and prevent data race conditions and inconsistent states.

[0127] In this embodiment, since each user-mode thread group has only one device interaction thread for interacting with the storage device, there is no need to perform thread-safe protection on the data. When the state of the storage device changes, the user-mode execution thread can use the lock-free queue mechanism to send device notification information to the user-mode thread associated with the storage device in the user-mode thread group.

[0128] As an efficient inter-thread communication mechanism, lock-free queues offer the core advantage of eliminating the need for operating system-level locking mechanisms to ensure thread safety, significantly reducing the latency and context switching overhead associated with acquiring and releasing locks. This can significantly improve system responsiveness and throughput in highly concurrent environments.

[0129] Optionally, the user-mode threads associated with the storage device may include user-mode threads corresponding to data interaction operations that have not been completed by the storage device, that is, threads that are performing or waiting for the device to perform data interaction operations. For example, if a request processing thread is performing data interaction with a storage device whose state has changed, then it needs to be aware of this change immediately in order to take necessary measures. Similarly, for a thread that has submitted an I / O request but has not yet received completion feedback, it also needs to be promptly informed of the change in the device state to avoid long waiting times or to prepare a fault recovery plan in advance.

[0130] For example, Figure 9 As shown in the figure, when the storage device changes, since the user-mode block device layer is initialized, the user-mode execution thread will automatically communicate through the lock-free queue between threads to notify each thread of the device change, thereby ensuring the reliability of the storage backend.

[0131] Through this embodiment, a lock-free queue mechanism is used to implement rapid notification of device status changes, thereby optimizing the fault response mechanism and improving system performance and reliability.

[0132] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0133] The embodiment of the present application also provides a data interaction device, Figure 10 is a structural block diagram of an optional data interaction device according to an embodiment of the present application, such as Figure 10 As shown, the device may include:

[0134] A creating unit 1002 is configured to create a user-mode thread group, wherein the user-mode thread group includes one device interaction thread and M request processing threads, wherein the device interaction thread is the only thread in the user-mode thread group that is allowed to interact with the storage device by calling the user-mode execution thread, and M is a positive integer greater than or equal to 2.

[0135] The first execution unit 1004 is configured to, in response to the received first business instruction, convert the first business instruction into a first data interaction request, and assign the first data interaction request to a first request processing thread among the M request processing threads;

[0136] A submitting unit 1006 is configured to submit the first data interaction request to the device interaction thread through the first request processing thread;

[0137] The first sending unit 1008 is configured to call the user mode execution thread through the device interaction thread and send the first data interaction request to the storage device, so that the storage device executes the first data interaction operation corresponding to the first data interaction request.

[0138] It should be noted that the creation unit 1002 in this embodiment can be used to execute the above-mentioned step S202, the first execution unit 1004 in this embodiment can be used to execute the above-mentioned step S204, the submission unit 1006 in this embodiment can be used to execute the above-mentioned step S206, and the first sending unit 1008 in this embodiment can be used to execute the above-mentioned step S208.

[0139] Through the above module, a user-mode thread group is created, wherein the user-mode thread group includes a device interaction thread and M request processing threads, the device interaction thread is the only thread in the user-mode thread group that is allowed to interact with the storage device by calling the user-mode execution thread, and M is a positive integer greater than or equal to 2; in response to a received first business instruction, the first business instruction is converted into a first data interaction request, and the first data interaction request is assigned to the first request processing thread among the M request processing threads; the first data interaction request is submitted to the device interaction thread through the first request processing thread; the user-mode execution thread is called through the device interaction thread, and the first data interaction request is sent to the storage device, so that the storage device executes the first data interaction operation corresponding to the first data interaction request. This can solve the problems of low efficiency and performance waste in the data interaction method in the related art, and achieve the technical effect of improving data interaction efficiency and improving thread processing performance.

[0140] For the description of the features in the embodiment corresponding to the data interaction device, please refer to the relevant description of the embodiment corresponding to the data interaction method, and no further details will be given here.

[0141] In an exemplary embodiment, the apparatus further comprises:

[0142] A switching unit is used to switch the first request processing thread to a ready state through the first request processing thread after submitting the first data interaction request to the device interaction thread through the first request processing thread, so as to wait for the first data interaction operation to be completed, and to give up scheduling to release the processing resources occupied by the first request processing thread, wherein after the first request processing thread gives up scheduling, other user-mode threads in the user-mode thread group are allowed to be executed.

[0143] In an exemplary embodiment, the apparatus further comprises:

[0144] a second execution unit configured to, after the first request processing thread switches the first request processing thread to a ready state and, in a case where a second request processing thread among the M request processing threads is executed, convert the second service instruction into a second data exchange request in response to a received second service instruction, and assign the second data exchange request to the second request processing thread;

[0145] a third execution unit, configured to submit the second data interaction request to the device interaction thread through the second request processing thread, switch the second request processing thread to a ready state to wait for completion of a second data interaction operation corresponding to the second data interaction request, and yield scheduling to release processing resources occupied by the second request processing thread;

[0146] The fourth execution unit is configured to, when the device interaction thread is being executed, call the user mode execution thread through the device interaction thread and send the second data interaction request to the storage device, so that the storage device executes the second data interaction operation.

[0147] In an exemplary embodiment, the apparatus further comprises:

[0148] a wake-up unit configured to, after calling the user-mode execution thread through the device interaction thread and sending the second data interaction request to the storage device, wake up the request processing thread corresponding to the completed data interaction operation through the device interaction thread if the device interaction thread finds that one of the first data interaction operation and the second data interaction operation has been completed, switch the device interaction thread to a ready state, and release scheduling to release processing resources occupied by the device interaction thread;

[0149] The fifth execution unit is used to execute the associated operations of the completed data interaction operation through the request processing thread corresponding to the completed data interaction operation when the request processing thread corresponding to the completed data interaction operation is executed, switch the request processing thread corresponding to the completed data interaction operation to a ready state, and give up scheduling to release the processing resources occupied by the request processing thread corresponding to the completed data interaction operation.

[0150] In an exemplary embodiment, the apparatus further comprises:

[0151] The calling unit is configured to call the user state execution thread through the device interaction thread to poll the execution status of the first data interaction operation after calling the user state execution thread through the device interaction thread and sending the first data interaction request to the storage device.

[0152] In an exemplary embodiment,

[0153] The creation unit includes: a first creation module, configured to create M input and output threads to obtain M request processing threads, wherein the M request processing threads are used to carry the services of the object storage daemon process; a second creation module, configured to create a device interaction thread, and create a user-mode execution thread through the device interaction thread, wherein the device interaction thread is used to carry the user-mode execution thread;

[0154] The above-mentioned device further includes: an enabling unit, which is used to enable a user-mode block device after creating the user-mode thread group, wherein the user-mode block device is used to provide a driver for the storage device.

[0155] In an exemplary embodiment, the apparatus further comprises:

[0156] The second sending unit is used to send device notification information to the user-mode threads associated with the storage device in the user-mode thread group by using a lock-free queue mechanism through the user-mode execution thread when the state of the storage device changes, wherein the device notification information is used to indicate that the state of the storage device has changed, and the user-mode threads associated with the storage device include: user-mode threads corresponding to data interaction operations that have not been executed by the storage device.

[0157] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned data interaction method embodiments.

[0158] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above-mentioned data interaction method embodiments when running.

[0159] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0160] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any one of the above-mentioned XX method embodiments are implemented.

[0161] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned data interaction method embodiments are implemented.

[0162] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0163] The above is a detailed introduction to a data interaction method and device, storage medium and electronic device provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core idea of ​​the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A data interaction method, characterized in that: include: Creating a user-state thread group, wherein the user-state thread group includes a device interaction thread and M request processing threads, the device interaction thread is the only thread in the user-state thread group allowed to interact with the storage device by calling the user-state execution thread, and M is a positive integer greater than or equal to 2; In response to the received first business instruction, convert the first business instruction into a first data interaction request, and assign the first data interaction request to a first request processing thread among the M request processing threads; submitting the first data interaction request to the device interaction thread through the first request processing thread; The user-mode execution thread is called through the device interaction thread to send the first data interaction request to a storage device, so that the storage device executes a first data interaction operation corresponding to the first data interaction request.

2. The method according to claim 1, characterized in that After submitting the first data interaction request to the device interaction thread through the first request processing thread, the method further includes: The first request processing thread is switched to a ready state through the first request processing thread to wait for the completion of the first data interaction operation, and the scheduling is released to release the processing resources occupied by the first request processing thread. After the first request processing thread gives up the scheduling, other user-mode threads in the user-mode thread group are allowed to be executed.

3. The method according to claim 2, characterized in that After switching the first request processing thread to a ready state by the first request processing thread, the method further includes: When a second request processing thread among the M request processing threads is executed, in response to a received second service instruction, convert the second service instruction into a second data interaction request, and assign the second data interaction request to the second request processing thread; Submitting the second data interaction request to the device interaction thread through the second request processing thread, switching the second request processing thread to a ready state to wait for completion of a second data interaction operation corresponding to the second data interaction request, and releasing scheduling to release processing resources occupied by the second request processing thread; When the device interaction thread is executed, the user state execution thread is called by the device interaction thread, and the second data interaction request is sent to the storage device, so that the storage device performs the second data interaction operation.

4. The method according to claim 3, characterized in that After calling the user-mode execution thread through the device interaction thread and sending the second data interaction request to the storage device, the method further includes: When the device interaction thread finds that a completed data interaction operation exists between the first data interaction operation and the second data interaction operation, waking up the request processing thread corresponding to the completed data interaction operation through the device interaction thread, switching the device interaction thread to a ready state, and releasing the scheduling to release the processing resources occupied by the device interaction thread; When the request processing thread corresponding to the completed data interaction operation is executed, the associated operations of the completed data interaction operation are executed by the request processing thread corresponding to the completed data interaction operation, the request processing thread corresponding to the completed data interaction operation is switched to the ready state, and the scheduling is released to release the processing resources occupied by the request processing thread corresponding to the completed data interaction operation.

5. The method according to claim 1, wherein After calling the user-mode execution thread through the device interaction thread and sending the first data interaction request to the storage device, the method further includes: The user-mode execution thread is called through the device interaction thread to poll the execution status of the first data interaction operation.

6. The method according to any one of claims 1 to 5, characterized in that The creating of the user-mode thread group includes: creating M input / output threads to obtain the M request processing threads, wherein the M request processing threads are used to carry the services of the object storage daemon process; creating the device interaction thread, and creating the user-mode execution thread through the device interaction thread, wherein the device interaction thread is used to carry the user-mode execution thread; After the user-mode thread group is created, the method further includes: enabling a user-mode block device, wherein the user-mode block device is used to provide a driver for the storage device.

7. The method according to any one of claims 1 to 5, characterized in that The method further comprises: In the event that the state of the storage device changes, the user-state execution thread uses a lock-free queue mechanism to send device notification information to the user-state thread associated with the storage device in the user-state thread group, wherein the device notification information is used to indicate that the state of the storage device has changed, and the user-state threads associated with the storage device include: user-state threads corresponding to data interaction operations that have not been completed by the storage device.

8. A data interaction device, characterized in that: include: a creation unit, configured to create a user-mode thread group, wherein the user-mode thread group includes one device interaction thread and M request processing threads, the device interaction thread being the only thread in the user-mode thread group allowed to interact with the storage device by calling the user-mode execution thread, and M being a positive integer greater than or equal to 2; a first execution unit, configured to, in response to a received first business instruction, convert the first business instruction into a first data interaction request, and assign the first data interaction request to a first request processing thread among the M request processing threads; a submitting unit, configured to submit the first data interaction request to the device interaction thread through the first request processing thread; The first sending unit is configured to call the user-mode execution thread through the device interaction thread and send the first data interaction request to a storage device, so that the storage device executes a first data interaction operation corresponding to the first data interaction request.

9. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the data interaction method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the data interaction method according to any one of claims 1 to 7.

Images