Detailed Description
According to the prior art implementation scheme, the application server interacts with the database in a synchronous call manner, as shown in fig. 1, the application server needs to allocate a processing thread to each access request sent from the user side, and the thread is occupied during a period from the time when the application server sends a data access request to the Database (DB) side until the database returns data.
Assuming that an average database time consumption is 200 ms in one data reading process, under the condition of ignoring other time occupation such as internal processing of an application server and data interaction, it can be approximately considered that each thread needs to be occupied for 200 ms, that is, 1 thread can process 5 threads in 1 second at most. If the design requirement of the application server is to be able to support 500 accesses per second, the size of the thread pool may be set to 100. However, once a problem occurs in the database, for example, the average elapsed time in a certain period of time is increased from 200 milliseconds to 1 second, the thread of the application server is exhausted by the request amount of 100 times/second, so that the supportable access amount of the application server is reduced from 500 times/second to 100 times/second, and the service processing capability is seriously reduced. In addition, other resources such as the CPU of the application server do not reach the upper limit of use at this time, and thus the problem of resource waste is also serious.
In order to solve the above problems, the present application proposes a scheme that: the application server processes the access request to the database by using an asynchronous IO mode, and simultaneously stores the connection between the application server and the database by using the task queue, so that the connection is not bound with the thread.
In order to make those skilled in the art better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be described in detail below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all embodiments. All other embodiments that can be derived from the embodiments given herein by a person of ordinary skill in the art are intended to be within the scope of the present disclosure.
Fig. 2 is a flowchart of a data access request method provided in the present application, where the method may be executed by an application server, and includes the following steps:
s101, receiving a user access request sent by a user side;
s102, according to the received user access request, sending a database access request to a database side by using an NIO mode;
the application server firstly determines a target database/table according to the access content of the user, constructs a data access instruction, then establishes long connection with target database equipment, and sends the data access instruction through the long connection.
And S103, after the data access request is successfully sent, generating a database access request task, and adding the task to the work queue.
In the generated database access request task, the following information needs to be carried:
the identifier of the database access request has the function of finding the corresponding task from the task queue after the database returns an access result.
The identifier of the user access request is used for determining corresponding user access request information according to the binding relation between the database access request and the user access request after the database returns an access result
Carrying the user access request identification and the database access request identification;
and S104, releasing the current processing thread.
NIO is an IO API provided in JAVA version 1.4 that can replace the standard JAVA IO API, and is capable of supporting an asynchronous IO mode, compared to standard IO. In the scheme provided by the application, the application server processes the access request to the database by using the asynchronous IO mode, and simultaneously, the task queue is used for storing the connection information between the application server and the database. Based on the NIO characteristic, after the application server sends the data access request to the database, the current processing thread can be released, and the thread does not need to be set to monitor the database side. When the time consumption of the database rises, the number of tasks in the work queue is only increased, the occupation of the thread of the application server is not influenced, and the reduction of the service processing capacity of the application server is not caused. On the other hand, the CPU resource of the application server can be fully used for processing the service.
In an improved embodiment of the present application, the interaction between the application server and the user side may also use an NIO method, and specifically, in S101 to S102, the application server receives a user access request sent by the user side using the NIO method; generating a user access request task according to a received user access request, and adding the task to a work queue; and subsequently, acquiring a user access request task from the work queue, and then sending a database access request to the database side by using an NIO (network information object) mode aiming at the acquired user access request task.
On the basis of the above data access request method, the present application further provides a data access response method, where the method is executed by an application server, and as shown in fig. 3, the method may include the following steps:
s201, receiving a database access response sent by a database side by using an NIO mode;
s202, according to the database access request identification carried in the database access response, obtaining a database access request task with the same identification from a work queue;
and S203, sending a user access response to the user side according to the user access request identifier carried in the acquired database access request task.
According to the data access request method provided by the application, the task queue is used for storing the connection information between the application server and the database, and the processing thread can be released after the application server sends the data access request to the database, without setting a thread to monitor the database side. And after the database returns the access result to the application server, the application server firstly finds the corresponding task from the work queue according to the database access request identifier carried in the database access response, and then further feeds the access result back to the user side which originally sends the access request according to the user access request identifier carried in the task, thereby completing the whole access operation.
In the database access response process, the interaction between the application server and the user side can also use an NIO mode, specifically, in S202-S203, the application server generates a database access response task according to a user access request identifier carried in the acquired database access request task, and puts the task into a work queue; and subsequently, acquiring a database access response task from the work queue, and then sending a user access response to the user side by using an NIO mode aiming at the acquired database access response task.
Fig. 4 shows a schematic flow chart of a method including a complete data access request and data access response process, and to facilitate understanding of the interaction process inside the application server, the inside of the application server is divided into 5 interaction units: the system comprises a user side NIO module, a user interaction task queue, a work thread pool, a database driving layer NIO module and a database interaction task queue, and has the following basic functions:
the user side NIO module and the database driver layer NIO module: the two modules can use threads independent of the working thread pool and both adopt an NIO mode to communicate with external equipment.
The user interaction task queue and the database interaction task queue are equivalent to the logical division of the "work queue" from the perspective of the "user side" and the "database side" in the previous embodiment, and the division is only for convenience of explanation, and the actual function is the same as the "work queue" described above.
A working thread pool: the function is the same as that of the working thread pool in the prior art, and the service supporting capacity of the application server is directly determined.
The steps in fig. 4 are explained below:
a data request stage:
s301, the NIO module of the user side receives the user access request sent by the user side in the NIO mode.
S302, generating a user access request task, adding the task to a user interaction task queue, and marking the task as a to-be-processed state.
S303-S304, the working thread pool asynchronously reads all the user access request tasks in the state to be processed, and forwards the read tasks to the NIO module of the database driving layer after necessary processing; and modifying the state of the user access request task which is read from the user interaction task queue into processed state correspondingly.
S305, the database driving layer NIO module determines a target database/table and constructs a data access instruction according to the user access request task, then long connection is established with target database equipment, and the data access instruction is sent through the long connection.
S306, after the data access request is successfully sent, generating a database access request task, adding the task to a database interaction task queue, and marking the task as a to-be-processed state;
in the generated database access request task, the following information needs to be carried:
the identifier of the database access request has the function of finding the corresponding task from the task queue after the database returns an access result.
And S307, the work thread pool releases the current task, because the access connection information is stored after the task is added to the database interaction task queue, and the thread is not required to be used for monitoring all the time, the resource can be released for processing the next task after the current task is added to the database interaction task queue.
And a data response stage:
and S308, receiving the database access response sent by the database side by the NIO module of the database side.
S309, updating the database interaction task queue:
firstly, according to a database access request identifier carried in a database access response, a database access request task which has the same identifier and is in a state of waiting for processing is read from a database interaction task queue. And reading the finished tasks from the database interaction task queue, and correspondingly modifying the state into processed state.
And further, generating a database access response task according to the user access request identifier carried in the acquired database access request task, putting the task into a database interaction task queue, and marking the task as a to-be-processed state.
S310-S311, the working thread pool asynchronously reads all database access response tasks in the state to be processed, and transfers the read tasks to the NIO module at the user side after necessary processing; and modifying the state of the database access response task which is read from the database interaction task queue into processed state correspondingly.
S312, the NIO module of the user side sends the user access response to the user side by using the NIO mode according to the acquired database access response task.
According to the scheme, after the application server sends the access request to the database, the processing thread is released, if the time consumption of the database side is increased, the number of tasks in the work queue is increased, the occupation of the thread of the application server is not affected, the thread of the application server is not exhausted, the service access amount is not affected, and the CPU resource of the application server can be fully used for processing the service. Further, since the number of working threads is independent of the traffic access, the number of threads actually consumed can be maintained at a relatively small number, thereby reducing thread switching overhead.
Corresponding to the above method embodiment, the present application further provides a database access apparatus, as shown in fig. 5, the apparatus may include:
a user access request receiving module 110, configured to receive a user access request sent by a user side;
a database access request sending module 120, configured to send a database access request to a database side in an NIO manner according to the received user access request;
a database access request task adding module 130, configured to generate a database access request task after it is confirmed that the data access request is successfully sent, and add the task to the work queue, where the database access request task carries the current user access request identifier and the database access request identifier;
and a thread releasing module 140, configured to release the current processing thread.
In a specific embodiment of the present application, the user access request receiving module 110 may be specifically configured to: and receiving a user access request sent by a user side by using an NIO mode, generating a user access request task according to the received user access request, and adding the task to a work queue.
Correspondingly, the database access request sending module 120 may be specifically configured to: and acquiring a user access request task from the work queue, and sending a database access request to a database side by using an NIO (network information object) mode aiming at the acquired user access request task.
Referring to fig. 6, in an embodiment of the present application, the database access device may further include:
a database access response receiving module 210, configured to receive a database access response sent by a database side in an NIO manner;
a database access request task obtaining module 220, configured to obtain, according to a database access request identifier carried in a database access response, a database access request task with the same identifier from a work queue;
and the user access response sending module 230 is configured to send a user access response to the user side according to the user access request identifier carried in the acquired database access request task.
In a specific embodiment of the present application, the user access response sending module 230 may be specifically configured to: and sending a user access response to the user side by using an NIO mode.
Specifically, the database access request task obtaining module 220 may further generate a database access response task according to a user access request identifier carried in the obtained database access request task, and add the task to the work queue; accordingly, the user access response sending module 230 obtains the database access response task from the work queue, and sends the user access response to the user side in the NIO manner for the obtained database access response task.
The implementation process of the functions and actions of each module in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
From the above description of the embodiments, it is clear to those skilled in the art that the present application can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the present application may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments of the present application.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the apparatus embodiment, since it is substantially similar to the method embodiment, it is relatively simple to describe, and reference may be made to some descriptions of the method embodiment for relevant points. The above-described apparatus embodiments are merely illustrative, and the modules described as separate components may or may not be physically separate, and the functions of the modules may be implemented in one or more software and/or hardware when implementing the solution of the present application. And part or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
The foregoing is directed to embodiments of the present application and it is noted that numerous modifications and adaptations may be made by those skilled in the art without departing from the principles of the present application and are intended to be within the scope of the present application.