Problems with druid, connection pooling and microservices

the druid configuration I know is configured on a service
if mysql is installed on a machine
when we connect with a connection pool
according to https://blog.csdn.net/w059805.
the size formula of the connection pool is:

number of connections = ((number of cores * 2) + number of valid disks)

it should be said here that it is assumed that the configuration of the connection pool size is configured on a single service (project)

if we consider the situation that the microservice
has N services accessing the mysql machine
if the configuration of each service is the above formula
, then the total number of connection pools is N ((core 2) + effective disk)
this should not be correct
, but it doesn"t feel like you can divide the number of connections by N to assign the number of connections to each service
because N is uncertain. Because you don"t know when a service will fail, or when to add a few more services
secondly, the amount of database accessed by each service is also different
how do you understand this?

secondly, druid"s configuration monitoring system Servlet also configures
under a single service and accesses url such as
http://IP:PORT/druid
. Won"t N micro-services have N configured monitoring system Servlet?
if there are several micro-services on the same machine
, then you have to configure different url
, which feels weird?

maybe one solution is to extract all the dao layers that access the same mysql machine
from each microservice and operate independently into a microservice that can solve the above problems?
is such an architecture strange?


while the configuration of connection pool size is configured on a single service
in the case of N services accessing the mysql machine
the configuration of each service is the above formula
so the total number of connection pools is the number of N ((cores 2) + the number of effective disks.
isn't this a paradox?
how to understand?

there is no paradox. For example, if a mysql supports up to 100 concurrent connections, you have three microservice applications that need to connect to the database at the same time, each microservice is deployed on a separate machine, with 8 cores and 2 disks per machine. 3 (2 8 + 2) is much less than 100.

even if the mysql exceeds the maximum number of concurrency, you can slightly reduce the number of connection pooled connections for some micro-services, not to mention that the number of connections in the connection pool must be (core * 2) + the number of valid disks.

secondly, configuring the monitoring system Servlet also configures
under a single service and accesses the url such as
http://IP:PORT/druid
. Then there will be N micro-services configured with the monitoring system Servlet?
. If there are several micro-services on the same machine
, then it feels strange to configure different url
?

it's not surprising that different microservices only need to pay attention to their own druid monitoring. If you need general monitoring information, mysql provides a lot of status variables, related logs (proportion slow check date) and so on, of course, there are many monitoring tools for mysql, these tools collect and analyze these logs, variables and other information, and provide a very friendly interface display.

maybe one solution is to extract all the dao layers that access the same mysql machine
from each microservice, and separate operations into a microservice can solve the above problems?
is such an architecture strange?

strangely, there are some mysql middleware that provide connection pooling so that there is no need to initialize connection pooling in the application, and multiple microservices share a connection pool.

Menu