FlexyPool 连接池剖析

介绍

所有的项目都在使用数据库连接池的原因是效果非常好。有时我们可能会忘记我们为什么要采用一种设计模式或一种特定的技术，所以值得回踩和推理。每项技术或技术决策都有其优缺点，如果您看不到任何缺点，您需要知道您错过了什么。

数据库连接的生命周期

每个数据库读取或写入操作都需要连接。那么让我们看看数据库连接流如何看起来像：

流程如下所示：

1. 应用程序数据层向数据源请求数据库连接
2. DataSource将使用数据库Driver来打开数据库连接
3. 数据库连接被创建并打开一个TCP套接字
4. 应用程序读取/写入数据库
5. 连接不再需要，因此它被关闭
6. 插座关闭

你可以很容易地推断出开放/关闭连接是一个相当昂贵的操作。PostgreSQL 为每个客户端连接使用一个单独的OS进程，因此高速的打开/关闭连接会给数据库管理系统带来压力。

重用数据库连接最明显的原因是：

• 减少应用程序和数据库管理系统的OS I/O开销，用于创建/销毁TCP连接
• 减少JVM对象垃圾

 

合并vs不合池

让我们来比较一下 非连接池 解决方案与HikariCP的比较，HikariCP可能是最快的连接池框架。

测试将打开和关闭1000个连接。

private static final Logger LOGGER = LoggerFactory.getLogger(DataSourceConnectionTest.class);

private static final int MAX_ITERATIONS = 1000;

private Slf4jReporter logReporter;

private Timer timer;

protected abstract DataSource getDataSource();

@Before
public void init() {
	MetricRegistry metricRegistry = new MetricRegistry();
	this.logReporter = Slf4jReporter
			.forRegistry(metricRegistry)
			.outputTo(LOGGER)
			.build();
	timer = metricRegistry.timer("connection");
}

@Test
public void testOpenCloseConnections() throws SQLException {
	for (int i = 0; i < MAX_ITERATIONS; i++) {
		Timer.Context context = timer.time();
		getDataSource().getConnection().close();
		context.stop();
	}
	logReporter.report();
}

图表显示了在打开和关闭连接时花费的时间，所以越低越好。

该连接池是600的时间比那更快 非连接池 替代。我们的企业系统由数十个应用程序组成，只有一个批处理器系统每小时可以发出超过200万个数据库连接，因此需要考虑2个数量级的优化。

类型	非连接池（毫秒）	使用连接池（毫秒）
最小	74.551414	0.002633
最大	146.69324	125.528047
平均	78.216549	0.128900
标准差	5.9438335	3.969438
中位数	76.150440	0.003218

为什么 pooling 这么快？

为了理解 连接池 解决方案为什么表现如此出色，我们需要分析 连接池 连接管理流程：

 

每当请求连接时，连接池数据源将使用可用的连接池来获取新的连接。连接池只会在没有剩余空闲池的情况下创建新连接，游泳池尚未达到最大尺寸。池连接close（）方法将返回连接池，而不是实际关闭它。

更快，更安全

连接池充当传入连接请求的有界缓冲区。如果存在流量峰值，则连接池将对其进行调整，而不是使所有可用的数据库资源饱和。

等待步骤和超时机制是安全挂钩，防止数据库服务器过载。如果一个应用程序获得太多的数据库流量，连接池将减轻它，因此，防止它将数据库服务器关闭（从而影响整个企业系统）。

拥有权利的同时也被赋予了重大的责任

所有这些好处都是以一定的代价来实现的，尤其是在大型企业系统中，更加复杂的池配置。所以这不是银弹，你需要注意许多游泳池的设置，如：

• 最小尺寸
• 最大尺寸
• 最大空闲时间
• 获取超时
• 超时重试尝试

 

 

项目源代码：https://github.com/vladmihalcea/flexy-pool

 

 

 

 

 

转载于:https://my.oschina.net/Rayn/blog/1573285