高性能数据库连接池的内幕

摘要

如何打造高性能的数据库连接池框架，可以从哪些角度进行优化，连接池的大量优化实践如何为你的系统保驾护航，本专题将带你走进连接池的世界，为你一一揭晓。

大家可能会有这样疑问：连接池类似于线程池或者对象池，就是一个放连接的池子，使用的时候从里面拿一个，用完了再归还，功能非常简单，有什么可讲的。

可能还会有这样的疑问：高性能这么高大上，一个小小的连接池，如何跟高大上靠上边的。

本主题将会全面介绍连接池原理，高性能的设计，优化实践，现有连接池的瓶颈及解决方案。同时也会介绍唯品会自研数据库连接池产品(代号：Caelus)

为什么要有连接池

先看一下连接池所处的位置：

应用框架的业务实现一般都会访问数据库，缓存或者HTTP服务。为什么要在访问的地方加上一个连接池呢?

下面以访问MySQL为例，执行一个SQL命令，如果不使用连接池，需要经过哪些流程。

1：TCP建立连接的三次握手

2：MySQL认证的三次握手

3：真正的SQL执行

4：MySQL的关闭

5：TCP的四次握手关闭

可以看到，为了执行一条SQL，却多了非常多我们不关心的网络交互。

优点：实现简单。

缺点：

1：网络IO较多

2：数据库的负载较高

3：响应时间较长及QPS较低

4：应用频繁的创建连接和关闭连接，导致临时对象较多，GC频繁

5：在关闭连接后，会出现大量TIME_WAIT 的TCP状态(在2个MSL之后关闭)

使用连接池流程

第一次访问的时候，需要建立连接。 但是之后的访问，均会复用之前创建的连接。

优点：

1：较少了网络开销

2：系统的性能会有一个实质的提升

3：没了麻烦的TIME_WAIT状态

当然，现实往往是残酷的，当我们解决了一个问题的时候，同时伴随着另外一个问题的产生。

使用连接池面临的最大挑战： 连接池的性能

连接数和线程数性能优化

分库DB部署结构：

假设有128个分库：32个服务器，每个服务器有4个schema。按照128个分库的设计，便会新建128个独立数据库连接池。

数据库连接池的模型

特点：

1：128个连接池完全独立，不同的schema也对应不同的连接池

2：先通过拆库，读写等策略选择对应的连接池，再从连接池获取一个连接进行操作

3：操作完后，再将连接归还到对应的连接池中。

优点：

结构简单，分散竞争

面临的问题：

1：线程数过多

先看一下新建一个连接池，需要新建的线程数的个数。

连接池

线程数

描述

128个分库需要的线程数

C3P0

4

3个helperThread (pollerThread)，1个定时任务AdminTaskTimer(DeadlockDetector)

4*128=512

DBCP

1

负责心跳，最小连接数维持，最大空闲时间和防连接泄露

1*128=128

Druid

2

一个异步创建连接。一个异步关闭连接。

2*128=256

可以看到随着分库的增加，不管选用哪个连接池，线程的个数均会线性增长。线程数过多将会导致内存占用较大: 默认1个线程会占用1M的空间，如果是512个线程，则会占用1M*512=512M上下文切换开销。

Tips：由于stack和heap申请为虚地址空间，但是一旦使用就不会释放。(线程也不一定会占用1M的空间)

2：连接数过多

数据库的连接资源比较重，并且随着连接的增加，数据库的性能会有明显的下降。DBA一般会限制每个DB建立连接的个数，比如限制为3K 。假设数据库单台限制3K，32台则容量为3K*32=96K。如果应用最大，最小连接数均为10，则每个应用总计需要128*10=1.28K个连接。那么数据库理论上支持的应用个数为96K/1.28K= 80 台

3：不能连接复用

同一个物理机下面不同的schema完全独立，连接不能复用

优化后的数据库连接池模型

特点：

1：只有一个连接池,所有节点共享线程 (解决了线程数过多的问题)

2：每个物理机对应一个host, host里面维护多个schema，schema存放连接。

3：同一个host下面的不同schema 可以进行连接复用(解决连接数过多的问题)

获取连接流程：

1：获取连接需要带上 ip,port和schema信息：比如获取的是host31的schema1

2：先到host31的schema1中获取空闲连接，但是schema1无空闲连接，便会从schema2中获取空闲连接。

3：从schema2中获取的连接执行useschema1，该连接便切换到schema1上面。

4：执行对应的SQL操作，执行完成后，归还连接到schema1的池子里面。

优点：

1：连接复用：有效减少连接数。

2：提升性能：避免频繁的新建连接。新建连接的开销比较大，而使用use schema开销非常小

3：有效减少线程数。按现有方案大概只需要4个线程即可。而优化前需要512个线程

缺点：

1：管理较为复杂

2：不符合JDBC接口规范。DataSource只有简单的getConnection()接口，没有针对获取对应schema的连接的接口。需要继承DataSouce，实现特定接口。

事务语句性能优化

优化前执行事务的模型

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!