Prefácio

No artigo anterior, apresentamos o histórico da falha na conexão elástica do banco de dados e discutimos o conteúdo relevante das estratégias de detecção de pool de conexões HikariCP e Druid. Neste artigo, continuaremos a explorar outro pool de conexões online comumente usado - DBCP, e apresentaremos como implementar a estratégia de exploração de pool de conexões de banco de dados elástico de melhores práticas ao usar DBCP.

DBCP

Existem duas versões do DBCP: 1.xe 2.x (também conhecido como DBCP2). DBCP 2 é baseado no Commons Pool 2 e melhorou desempenho, suporte JMX e muitos outros aspectos em comparação com a versão 1.x. Como o DBCP 2.x não é compatível em termos binários com o DBCP 1.x, os usuários que atualizam para o 2.x devem estar cientes de que os nomes dos pacotes Java foram alterados, bem como as coordenadas do Maven.

Primeiro, vamos listar os parâmetros relacionados à detecção de DBCP:

nome do parâmetro	ilustrar	Padrões
tamanho inicial	O número de conexões físicas estabelecidas durante a inicialização.	0
minIdle	Conexão ociosa mínima: O número mínimo de conexões que podem permanecer ociosas no pool de conexões, abaixo do qual uma nova conexão será criada, se for definido como 0, ela não será criada	0
maxIdle	Conexão ociosa máxima: o número máximo de conexões que podem permanecer ociosas no pool de conexões, o excesso de conexão ociosa será liberado, se for definido como um número negativo, significa que não há limite	8
maxAtivo/maxTotal	Conexão ativa máxima: O número máximo de conexões ativas que o pool de conexões pode alocar ao mesmo tempo. Solicitações que excedem esse valor entram na fila de espera. Se for definido como um número não positivo, significa ilimitado (versão 1.x maxActive Versão 2.x maxTotal)	8
testOnBorrow	Indica se deve verificar antes de remover a conexão do pool. Se a verificação falhar, remova a conexão do pool e tente remover outra.	verdadeiro
testOnReturn	Indica se deve ser inspecionado antes de retornar ao pool.	falso
testWhileIdle	Indica se a conexão é verificada pelo coletor de conexões inativas. Se a detecção falhar, a conexão será removida do pool. Nota: Se for para entrar em vigor após ser definido como verdadeiro, o parâmetro validaçãoQuery deve ser definido como uma string não vazia.	falso
timeBetweenEvictionRunsMillis	O intervalo de tempo,em milissegundos,para o thread expulsar as conexões para execução.Se definido como um número não positivo,o thread do coletor de conexão ociosa não será executado.	-1
validaçãoQuery	O sql usado para verificar se a conexão é válida requer uma instrução de consulta.	selecione 1
validaçãoQueryTimeout	Unidade: segundos, tempo limite para detectar se a conexão é válida. O método subjacente chama o método void setQueryTimeout(intseconds) do objeto jdbc Statement
minEvictableIdleTimeMills	O tempo mínimo que uma conexão permanece inativa no pool antes de ser removida.	30 minutos
softMinEvictableIdleTimeMillis	Comparado com minEvictableIdleTimeMillis, este parâmetro é limitado por minIdle. Quando este valor é atingido, apenas o número de conexões maior que minIdle será removido.	-1
numTestsPerEvictionRun	O número de conexões verificadas cada vez que o encadeamento do coletor de conexões inativas é executado.	3

Em comparação com a configuração do probe Druid, embora muitos de seus nomes de parâmetros e funções sejam semelhantes, há diferenças nos detalhes e nos valores padrão. Por exemplo, o parâmetro testWhileIdle é usado no Druid para determinar se a detecção ao vivo deve ser habilitada ao solicitar uma conexão e deve ser maior que o valor do parâmetro timeBetweenEvictionRunsMillis. No DBCP, este parâmetro é julgado ao expulsar uma conexão. Se estiver ativado, é verificado diretamente, semelhante ao parâmetro keepAlive no Druid. Em ambos os conjuntos de conexões, o intervalo de tempo para remover conexões inativas é controlado pelo parâmetro timeBetweenEvictionRunsMillis. Além disso, a função do parâmetro testOnBorrow é a mesma, mas o valor padrão é diferente.

Além disso, o DBCP também é afetado pelo parâmetro numTestsPerEvictionRun no thread de despejo. Este parâmetro se refere ao número de conexões a serem despejadas cada vez que o thread de despejo é executado. Todas as conexões no pool não serão verificadas de uma só vez. Além disso, o minEvictableIdleTimeMillis do DBCP é diferente do Druid. O número de conexões removidas pelo tempo limite não é controlado pelo minidle.

A figura a seguir é o código-fonte do thread de conexão de despejo do DBCP1.4.0: org.apache.commons.pool.impl.GenericObjectPool#evict

Podemos ver no código-fonte que o número de conexões despejadas é obtido de getNumTests. getNumTests retorna o valor mínimo do tamanho existente do pool de conexões e numTestsPerEvictionRun. A primeira etapa no processo de despejo é primeiro determinar se o tempo ocioso excede minEvictableIdleTimeMillis. Caso contrário, determine se softMinEvictableIdleTimeMillis expirou e se a conexão existente é maior que minIdle. O terceiro if é determinar quando a configuração de testWhileIdle é verdadeiro e a ligação não é reciclada acima.No quarto passo,a ligação é detectada.

Resumo: DBCP tem poucas alterações na detecção de atividade em várias versões. Geralmente, testWhileIdle pode ser usado para detectar atividade ao remover o número de conexões. O intervalo entre as execuções do encadeamento de despejo é o valor do parâmetro timeBetweenEvictionRunsMillis. Além disso, o numTestsPerEvictionRun parâmetro é o valor de cada thread de despejo. Portanto, contanto que usemos essas duas configurações de parâmetro para detectar todas as conexões no pool (o valor máximo é maxActive/maxTotal) dentro de 10 minutos, podemos efetivamente evitar a falha na conexão do JED Porta de entrada.

Em geral, o DBCP apresenta poucas alterações na implementação da exploração ao vivo em diferentes versões. Normalmente, você pode testar a conexão usando o parâmetro testWhileIdle ao remover a conexão. O intervalo de execução do encadeamento de despejo é controlado pelo parâmetro timeBetweenEvictionRunsMillis, enquanto o parâmetro numTestsPerEvictionRun determina o número de conexões que o encadeamento de despejo pode manipular a cada vez. Recomenda-se que o valor configurado de numTestsPerEvictionRun seja consistente com maxActive/maxTotal e que timeBetweenEvictionRunsMillis seja configurado para ser inferior a 10 minutos para garantir que todas as conexões estejam ativas e evitar conexões com gateways com falha.

Além disso, quando o aplicativo usa DBCP, ativar o parâmetro testOnBorrow por padrão geralmente pode evitar efetivamente a obtenção de conexões inválidas, enquanto o Druid não ativa o parâmetro testOnBorrow por padrão. O aplicativo pode avaliar se o parâmetro testOnBorrow deve ser habilitado sozinho. Embora ativar o parâmetro testOnBorrow execute a verificação da conexão antes de cada conexão ser obtida, o que consome uma pequena quantidade de desempenho, ele pode destruir conexões inválidas a tempo e restabelecer novas conexões, o que pode efetivamente evitar erros de aplicativo ao encontrar uma falha no gateway JED e reiniciando.

Modelo de configuração JED:

DBCP1.4

<propertyname="minIdle"value="5"/> 
<propertyname="maxActive"value="10"/> 
<propertyname="testWhileIdle"value="true"/>    
<propertyname="validationQuery"value="SELECT 1"/>    
<propertyname="timeBetweenEvictionRunsMillis"value="300000"/>    
<propertyname="numTestsPerEvictionRun"value="10"/>

DBCP2.2.0

<propertyname="minIdle"value="5"/> 
<propertyname="maxTotal"value="10"/> 
<propertyname="testWhileIdle"value="true"/>    
<propertyname="validationQuery"value="SELECT 1"/>    
<propertyname="timeBetweenEvictionRunsMillis"value="300000"/>    
<propertyname="numTestsPerEvictionRun"value="10"/>

DBCP2.1.1

Igual a 2.2.0

Resumir

Este artigo usa o erro de tempo limite do gateway do JED como plano de fundo para investigar pools de conexões de banco de dados comuns e apresenta os parâmetros e a lógica de detecção relacionados à detecção de atividade do pool de conexões. Através do conteúdo deste artigo, os leitores devem compreender o conteúdo de detecção de atividade de diferentes pools de conexões e podem definir o pool de conexões de acordo com diferentes parâmetros para evitar efetivamente que os aplicativos fechem as conexões pelo gateway. Este artigo fornece um modelo de configuração do pool de conexões no banco de dados JED, que os leitores podem ajustar de acordo com as necessidades de suas próprias aplicações.

Autor: Jingdong Varejo Wang Leixin

Fonte: Reimpresso pela comunidade de desenvolvedores JD Cloud, indique a fonte

Pesquisa sobre estratégia de exploração de pool de conexão de banco de dados elástico (3) - DBCP | Equipe técnica da JD Cloud