Method and device for supporting high concurrency of database through stateless thread pool
Through the stateless thread pool architecture, the performance degradation of existing databases caused by too many threads and processes in high concurrency scenarios is solved, and efficient thread management and performance improvement is achieved.
Patent Information
- Application Number
- CN202510267641.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-07
- Publication Date
- 2025-06-13
AI Technical Summary
In the high concurrency scenario, existing databases have degraded system performance due to excessive creation and switching of threads and processes, and cannot effectively support high concurrency.
Using a stateless thread pool architecture, when a client and the database establishes a connection, it only creates a memory structure related to the connection information in the memory, and adds the network communication port to the network listening thread to listen. When the connection actually issues a client request, the network listening thread sends the connection information to the dispatch thread after receiving the request, and the dispatch thread obtains an idle stateless thread from the thread pool for processing.
Through the stateless thread pooling method, the overhead of creating and destroying threads is reduced, the performance loss caused by thread switching is avoided, and high concurrency scenarios are effectively supported.
Smart Images
Figure CN120144302A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of general database, and particularly provides a method and device for supporting high concurrency of database through a stateless thread pool. Background Art
[0002] At present, the concurrent architectures of general relational database systems are mainly divided into two types. One is the multi-process architecture, and the other is the multi-thread architecture. For a database with a multi-process architecture, when a user connects to the database, a new process is usually started to establish a connection with the client and provide services to the client. For a database with a multi-thread architecture, when a user connects to the database, a new thread is usually started in the main process to establish a connection with the client and provide services to the client.
[0003] In the multi-process architecture, a separate process is used to establish a connection with the client and provide services. Multiple sub-processes are independent of each other. When a sub-process crashes, it does not affect the execution of other sub-processes. However, the cost of starting a new process in the operating system is very high, the process management is very complex, and the scheduling overhead of the process is also very high, which is not suitable for scenarios with extremely high concurrency. Representative products of the multi-process architecture include commercial Oracle databases and open-source PostgreSQL databases. In order to support high concurrency, Oracle databases also support some thread architecture models in recent versions to reduce concurrent overhead. The PostgreSQL database has always been a multi-process model. When the concurrency exceeds several times the number of CPUs, the performance of PostgreSQL decays extremely, and the process switching consumes the entire CPU, making it basically unable to provide services to customers. Currently, the community is discussing whether to modify the architecture to a multi-thread architecture.
[0004] The multi-threaded architecture mainly creates a new independent thread in the current process to establish a connection with the client when establishing a connection with the client, and allows this thread to continuously receive and process requests for the current connection until the connection is disconnected, at which point the created thread will be destroyed. When establishing and disconnecting a connection in the multi-threaded architecture, it is also accompanied by the creation and destruction of threads. Although the cost of creating and destroying threads is much lower than that of processes, it still occupies a lot of system resources. The open-source database MySQL adopts a multi-threaded architecture. To solve the problem of high overhead in creating and destroying threads, MySQL has established a thread pool. When a connection exits, the thread is added to the connection pool, and when creating a thread, the thread is first obtained from the connection pool. Although MySQL reduces the overhead of creating and destroying threads through the connection pool, it cannot support high concurrency. Because when the number of connections reaches tens of thousands or even hundreds of thousands, there will be tens of thousands of real threads in the operating system. Even if these connections do not execute any client requests, these threads will still be scheduled and executed by the operating system from time to time, resulting in significant performance fluctuations. When each connection executes a client request, the throughput of the database will decrease extremely as the number of connections increases, because the cost of CPU thread switching has a significant impact on the processing ability of the database.
[0005] Regardless of whether the database adopts a multi-process architecture or a multi-threaded architecture, each user connection requires an operating system thread and process to correspond to the client, so more concurrency requires more thread and process resources.
[0006] Creating too many threads or processes in the operating system will cause a series of problems: creating too many threads and processes will exhaust system resources, resulting in a decline in system performance; switching between too many threads and processes requires locking and unlocking resources, and frequent switching will increase system overhead and affect the response speed; a large number of threads and processes may lead to race conditions, increasing the risk of system deadlocks; too many threads and processes will also increase the difficulty of software maintenance. Summary of the Invention
[0007] In view of the above deficiencies of the prior art, the present invention provides a method for supporting high concurrency of a database through a stateless thread pool with strong practicability.
[0008] A further technical task of the present invention is to provide a device for supporting high concurrency of a database through a stateless thread pool with reasonable design, safety and applicability.
[0009] The technical solution adopted by the present invention to solve its technical problems is:
[0010] A method for supporting high concurrency of a database through a stateless thread pool, which adopts a multi-threaded database architecture. When the client establishes a connection with the database, the client first sends a connection request to the main database thread. After receiving the connection request, the main database thread creates a memory structure related to the connection information in the database, creates a port related to network communication, and adds the network communication port to the network listening thread for listening.
[0011] After the network listening thread detects a client request sent by the client over the network, it sends the connection information to the scheduling thread. The scheduling thread obtains an idle stateless thread from the thread pool and binds the connection information to the thread in the thread pool. Thus, the thread in the thread pool starts to process the client request of the connection. After the current thread finishes processing a transaction of the connection, it will return to the thread pool again and wait to process the client requests of other connections.
[0012] Furthermore, when the client establishes a connection with the database, only a memory structure is created in the memory to save the connection-related information, and at the same time, the network port is added to the network listening thread for listening.
[0013] When the connection actually sends a client request, the network listening thread will receive the network data sent by the client, and the listening thread will send a message to the scheduling thread, and then the scheduling thread will allocate a thread for processing.
[0014] Furthermore, the database with the multi-threaded architecture will create many global variables at the thread level. During the implementation of the stateless thread, these thread-level global variables need to be uniformly incorporated into the execution status management structure. By modifying the pointer of the execution status management structure of the stateless thread, the switching of the thread execution task is realized. When the thread returns to the thread pool, the pointer of the execution status management structure is set to null, so as to achieve the purpose of being stateless.
[0015] Furthermore, the threads in the thread pool are all stateless. When processing a connection request, the execution status related to the connection is passed to the processing thread, and then the processing thread can continue to process the client request of the connection.
[0016] Furthermore, after the listening thread detects a client request, it sends the request information to the scheduling thread. The scheduling thread will bind the connection-related information to the background service thread. After the background service thread finishes processing a transaction of the client, the connection will be decoupled and then enter the connection pool again.
[0017] For the scheduling thread and other connections with client requests, other idle background service threads are also allocated to receive and process these requests.
[0018] Further, when the database is started, a certain number of background service threads are started according to the configuration information and placed in the connection pool. The background service threads in the connection pool are always in a blocked state. When the scheduling thread receives a client request, it will wake up an idle background service thread to receive and process the client request.
[0019] Further, when the background service thread processes the client request, after processing one transaction request of the client, the connection will be decoupled and it will enter the connection pool again;
[0020] If the number of threads in the connection pool is insufficient, the scheduling thread decides whether to let the client connection continue to wait or start a new background processing thread to provide services according to the configuration and the number of already started threads;
[0021] If the number of threads in the connection pool does not exceed the maximum value set by the user, the scheduling thread will start a new thread to provide services. If the number of threads in the connection pool has reached the maximum value, it will wait for some background service threads to enter the connection pool.
[0022] An apparatus for supporting high concurrency of a database through a stateless thread pool includes: at least one memory and at least one processor;
[0023] The at least one memory is used to store machine-readable programs;
[0024] The at least one processor is used to call the machine-readable program to execute a method for supporting high concurrency of a database through a stateless thread pool.
[0025] Compared with the prior art, a method and an apparatus for supporting high concurrency of a database through a stateless thread pool of the present invention have the following prominent beneficial effects:
[0026] By making the threads stateless, decoupling the threads from the user connections, and pooling the threads, the present invention reduces the overhead of creating and destroying threads. At the same time, the threads in the stateless thread pool are used to provide services for any connection, solving the problem that too many threads are created, resulting in too large a thread switching cost and being unable to support high concurrency. BRIEF DESCRIPTION OF THE DRAWINGS
[0027] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the following drawings are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.
[0028] Appendix Figure 1It is an architectural diagram of a method for supporting high concurrency of a database through a stateless thread pool;
[0029] Appendix Figure 2 It is a schematic flow diagram of a method for supporting high concurrency of a database through a stateless thread pool. Specific implementation manners
[0030] In order to enable those skilled in the art of the present technology to better understand the solution of the present invention, the present invention will be further described in detail below in conjunction with specific implementation manners. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without making creative efforts fall within the scope of protection of the present invention.
[0031] The following gives a best embodiment:
[0032] For a database with a multi-process architecture that is connected through processes and users, an independent process needs to be created for each client connection. Too many processes will consume a lot of operating system resources, and the cost of process switching is very high. This will cause the performance of the database to be greatly affected in the case of high concurrency, and even the performance will decline linearly. Based on the database with a multi-process architecture, the client will first interact with the main database process, and the main process will start a sub-process to provide services to the client. All subsequent network interactions will be carried out between the sub-process and the client. For a database with a multi-process architecture, the time to add connections will increase significantly after the number of connections exceeds one thousand, because in a busy system, it takes more time to switch to the process of creating a new process, and the more processes there are, the more time is required.
[0033] With the increase in the number of client connections in the multi-process architecture, the processes in the operating system increase accordingly. When the number of processes exceeds one thousand, or even reaches tens of thousands, even for an idle database, the response time will occasionally be several seconds. This is because the cost of switching too many processes is very high, resulting in the situation that when the backend process for executing client requests is not in the ready queue occasionally, it takes several seconds for the operating system to switch to the backend process corresponding to the current connection. When all connections are in a busy state, the cost of creating tens of thousands of connections will be even greater. After the number of connections exceeds one thousand, creating a new connection will result in a delay of several seconds or even dozens of seconds.
[0034] In a database with a multi-threaded architecture, threads are connected to user connections. Each client connection creates a thread. However, too many threads will also consume excessive operating system resources. Although the cost of thread switching is not high, too many threads will have a significant impact on the performance of the operating system. As the number of threads increases, the CPU time consumed by the system will also continuously increase, resulting in performance degradation. In a database based on a multi-threaded architecture, the client first interacts with the main thread of the database process. The main thread will start a thread to provide services to the client, and all subsequent network interactions will occur between the thread and the client. For a database with a multi-threaded architecture, the time to add connections will increase significantly after the number of connections exceeds one thousand. This is because in a busy system, it takes more time to switch to the process of creating a new thread, and the more threads there are, the more time it takes to create them.
[0035] With the increase in the number of client connections in a multi-threaded architecture, the number of threads in the operating system also increases. When the number of threads exceeds ten thousand and even reaches tens of thousands, even in an idle database, the response time will occasionally show large fluctuations. This is because threads also need to switch, and too many threads will also result in obvious switching times. When the backend thread that executes the client request connection is not in the ready queue, it takes more time for the operating system to switch to the backend thread corresponding to the current connection. When the system is in a busy state and the number of threads in the system reaches tens of thousands or even hundreds of thousands, it takes several seconds or even more than ten seconds to create a connection.
[0036] Therefore, whether it is a multi-process or multi-threaded architecture database, there are significant problems in supporting high-concurrency scenarios. When the number of threads or processes in the system reaches a certain level, the cost of operating system switching itself will be very high, resulting in a high cost for creating a thread or process.
[0037] As Figure 1 shown, the present invention adopts a multi-threaded database architecture and realizes a stateless thread pool database architecture by pooling threads and making the threads in the pool stateless. When the client and the database establish a connection in this database architecture, the client first sends a connection request to the main thread of the database. After receiving the connection request, the main thread of the database creates a memory structure related to the connection information in the database, creates a port related to network communication, and adds the network communication port to the network listening thread for listening. When the network listening thread detects a client request sent by the client, it sends the connection information of this connection to the scheduling thread. The scheduling thread obtains an idle stateless thread from the thread pool and binds the connection information to the thread in the thread pool. Thus, the thread in the thread pool can start processing the client request of the connection. After the current thread finishes processing a transaction of the connection, it will return to the thread pool again, waiting to process the client requests of other connections.
[0038] By creating a memory structure only in memory when creating a connection, which stores connection-related information, and adding a network listening thread to listen on the network port, the performance of creating a connection is greatly improved. When the connection actually sends a client request, the network listening thread will receive the network data sent by the client. The listening thread will send a message to the scheduling thread, and then the scheduling thread will allocate a thread for processing. Thus, a small number of threads can be created to handle a large number of concurrent requests, avoiding the creation of too many threads and processes in the existing database architecture under high concurrency, and thus solving the problems existing in the existing database technology when supporting high concurrency.
[0039] As Figure 2 shown, in a database adopting a multi-threaded architecture, for the convenience of processing, many global variables are often created at the thread level. The values of the global variables vary between threads, resulting in many connection execution states being saved in the global variables of the threads. These states cause the background service thread of a user connection to be unable to process the client requests sent by other connections. During the implementation of the stateless thread, these thread-level global variables need to be uniformly incorporated into the execution state management structure. By modifying the pointer of the execution state management structure of the stateless thread, the switching of the thread execution task can be achieved. When the thread returns to the thread pool, the pointer of the execution state management structure is set to null to achieve the stateless purpose. The threads in the thread pool are all stateless. When processing a connection request, the execution state related to the connection is passed to the processing thread, and the thread can then continue to process the client request of the connection.
[0040] There is a network communication connection between each client and the background thread. If the background service thread directly receives the network requests sent by the client, it will cause it to wait directly on the network communication, thus being unable to process the client requests of other connections. The stateless thread pool database architecture separates the network listening and the reception and processing of client requests, allowing an independent network listening thread to listen on the network requests of all connections, thus avoiding the situation where the backend thread corresponding to each connection needs to listen on the network port, and realizing the decoupling of the client connection and the database background service thread.
[0041] After the listening thread monitors a client request, it sends the request information to the scheduling thread, and the scheduling thread will bind the connection-related information to the background service thread. Thus, the purpose of the background service thread to process the client request is achieved, and the process of the background service thread processing the client request is exactly the same as the method without using a connection pool. After the background service thread finishes processing a transaction of the client, it will be decoupled from the connection and enter the connection pool again. The scheduling thread will also allocate other idle background service threads to receive and process these requests for other connections with client requests.
[0042] The implementation of the connection pool is no different from that of an ordinary connection pool. When the database starts, a certain number of background service threads can be started according to the configuration information and put into the connection pool. The background service threads in the connection pool are always in a blocked state. When the scheduling thread receives a client request, it will wake up an idle background service thread to receive and process the client request. The logic for the background service thread to process the client request is consistent with the existing logic. After processing a transaction request from the client, it will decouple from the connection and enter the connection pool again. If there are not enough threads in the connection pool, the scheduling thread decides whether to let the client connection continue to wait or start a new background processing thread to provide services according to the configuration and the number of already started threads. If the number of threads in the connection pool does not exceed the maximum value set by the user, the scheduling thread will start a new thread to provide services. If the number of threads in the connection pool has reached the maximum value, it will wait for some background service threads to enter the connection pool.
[0043] Based on the above method, an apparatus for supporting high concurrency of a database through a stateless thread pool in this embodiment includes: at least one memory and at least one processor;
[0044] The at least one memory is used to store machine-readable programs;
[0045] The at least one processor is used to call the machine-readable program and execute a method for supporting high concurrency of a database through a stateless thread pool.
[0046] The above specific implementation manners are only specific cases of the present invention. The patent protection scope of the present invention includes but is not limited to the above specific implementation manners. Any technical solution that conforms to the technical solutions recorded in the above specific implementation manners of the present invention and any appropriate changes or substitutions made by those of ordinary skill in the art shall fall within the patent protection scope of the present invention.
[0047] Although the embodiments of the present invention have been shown and described, for those of ordinary skill in the art, it can be understood that various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirits of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.
Claims
1. A method for supporting high database concurrency through a stateless thread pool, characterized in that: A multi-threaded database architecture is adopted. When the client and the database establish a connection, the client first sends a connection request to the database main thread. After receiving the connection request, the database main thread creates a memory structure related to the connection information in the database, creates a port related to network communication, and adds the network communication port to the network listening thread for listening; After the network listening thread listens to the client request sent by the client on the network, it sends the connection information to the scheduling thread. The scheduling thread obtains an idle stateless thread in the thread pool and binds the connection information to the thread in the thread pool. Then the thread in the thread pool starts to process the connected client request. After the current thread processes a transaction of the connection, it will return to the thread pool again and wait to process client requests of other connections.
2. According to claim 1, a method for supporting high concurrency of a database through a stateless thread pool is characterized in that: When the client and the database establish a connection, only a memory structure is created in the memory to save the connection-related information, and the network port is added to the network listening thread for listening; When the connection actually sends a client request, the network listening thread will receive the network data sent by the client, and the listening thread will send information to the scheduling thread, and the scheduling thread will assign a thread for processing.
3. A method for supporting high database concurrency through a stateless thread pool according to claim 2, characterized in that: The database of the multi-threaded architecture will create many global variables at the thread level. During the implementation of stateless threads, these thread-level global variables need to be uniformly incorporated into the execution status management structure. The switching of thread execution tasks is achieved by modifying the pointer of the execution status management structure of the stateless thread. When the thread returns to the thread pool, the pointer of the execution status management structure is cleared to achieve the purpose of statelessness.
4. A method for supporting high database concurrency through a stateless thread pool according to claim 3, characterized in that: The threads in the thread pool are all in a stateless state. When processing a connection request, the connection-related execution state is passed to the processing thread, and the processing thread can then process the connected client request.
5. A method for supporting high database concurrency through a stateless thread pool according to claim 4, characterized in that: After the listening thread listens to the client request, it sends the request information to the scheduling thread. The scheduling thread binds the connection related information to the background service thread. After the background service thread handles a transaction of the client, it decouples the connection and enters the connection pool again. The scheduling thread and other connections with client requests also allocate other idle background service threads to receive and process these requests.
6. A method for supporting high database concurrency through a stateless thread pool according to claim 5, characterized in that: When the database is started, a certain number of background service threads are started and put into the connection pool according to the configuration information. The background service threads in the connection pool are always in a blocked state. When the scheduling thread receives a client request, it will wake up an idle background service thread to receive and process the client request.
7. A method for supporting high database concurrency through a stateless thread pool according to claim 6, characterized in that: When the background service thread processes a client request, it will decouple the connection after processing a transaction request from the client and enter the connection pool again; If there are not enough threads in the connection pool, the scheduling thread decides whether to let the client connection continue to wait or start a new background processing thread to provide services based on the configuration and the number of threads that have been started; If the number of threads in the connection pool does not exceed the maximum value set by the user, the scheduling thread will start a new thread to provide services. If the number of threads in the connection pool has reached the maximum value, it will wait for some background service threads to enter the connection pool.
8. A device for supporting high database concurrency through a stateless thread pool, characterized in that: include: at least one memory and at least one processor; The at least one memory is used to store a machine-readable program; The at least one processor is configured to call the machine-readable program to execute the method according to any one of claims 1 to 7.