How to access commonly connected downstream?
There are a lot of demand for infrastructure projects to access downstream downstream, including but not limited to the service / database / cache, its communication steps are as follows:
(1) establishes a connection to the downstream;
(2) Through this connection, send and receive requests;
(3) the end of the interaction, the connection is closed, the release of resources;
Whether the service / database / cache, the official will be provided in different languages Driver, Document, DemoCode to guide the use of entering into connection with the call interface.
In C ++ official DriverAPI MongoDB example:
DBClientConnection* c = new DBClientConnection();
c->connect(“127.0.0.1:8888”);
c->insert(“db.s”, BSON(”shenjian”));
c->close();
Voice-over: to establish a connection, send a request to close the connection is very clear.
The DBClientConnection is a connection to MongoDB, the official Driver by providing a number of API, so that users can connect to MongoDB, additions and deletions to change search, shut down operations in order to achieve different business logic.
Why do I need a connection pool?
When the amount of concurrency is very low when temporarily establish a connection, but the service throughput when hundreds, thousands, and establish a connection to connect and destroy a connection close will become a bottleneck, this time how to optimize it?
(1) when the service starts, first establish a good number of connections Array [DBClientConnection];
(2) When a request arrives, then removed from an Array, performed downstream operations, executing the back;
Thus avoiding repeated to create and destroy connections to improve performance.
And this for Array [DBClientConnection] to maintain a data structure, is connected to the pool.
Once we have a pool of database operations becomes pseudocode:
DBClientConnection* c =
ConnectionPool::GetConnection();
c->insert(“db.s”, BSON(”shenjian”));
ConnectionPool::FreeConnection(c);
VO: Remove the connection, sends a request, be put back, it is also very clear.
The core principles and implementation of connection pooling is kind of how it?
You can see the connection pool ConnectionPool There are three core interface:
(1) Init: Initialization Array [DBClientConnection], this interface is called only when the service starts once;
(2) GetConnection: each time a request to access a database need not connect a new connection, but is connected through the interface to come and collect pools;
(3) FreeConnection: requesting access to the database after each session, not close a connection, but the connection back to the connection pool;
Connection pooling core data structure is what is it?
Connection pool comprising at least two core data structures:
(1) connected to the array Array DBClientConnection [N];
(2) a mutex Array Array lock [N];
Connection pooling core interface, is how to manipulate the core data structure, realize the connection pooling feature of it?
Init(){
for i = 1 to N {
Array DBClientConnection [i] = new();
Array DBClientConnection [i]->connect();
Array lock[i] = 0;
}
}
Voice-over: all connections and mutex initialized.
GetConnection()
for i = 1 to N {
if(Array lock[i] == 0){
Array lock[i] = 1;
return Array DBClientConnection[i];
}
}
}
Voice-over: find a connection is available, lock, and returns the connection.
FreeConnection(c)
for i = 1 to N {
if(Array DBClientConnection [i] == c){
Array lock[i] = 0;
}
}
}
Voice-over: find the connector, the lock is released.
You will find that the connection pool management did not imagine the core of the complex.
In addition to the core code, connection pooling also need to consider what factors do?
(1) need to implement connection availability detection, if the connection fails, the connection needs to be rebuilt;
(2) by freeArray, connectionMap data structures, etc., that allows to remove the connection and put back into reached complexity of O (1) time;
(3) can be taken via hash, serialization achieved id;
(4) the probability of each connection is taken to be the same, in order to achieve load balancing;
(5) if a downstream fault, failure must be rejected connection, in order to achieve automatic fault metastasis;
(6) if there is additional downstream, dynamically connected to the expansion tank, to achieve automatic service discovery;
No micro-channel public attention and headlines today, excellent article continued update. . . . .
