灵活池，反应式连接池

介绍

当我开始从事企业项目时，我们正在使用J2EE，并且池数据源是由应用程序服务器提供的。

扩大规模意味着购买功能更强大的硬件以支持不断增长的需求。 纵向扩展意味着为了支持更多请求，我们将必须相应地增加连接池的大小。

水平缩放

我们最近的架构已从向上扩展到向外扩展。 因此，我们现在不再拥有一台托管我们所有企业服务的大型机器，而是拥有一个分布式服务网络。

这具有许多优点：

• 每个JVM根据托管服务的固有行为进行调整。 Web节点使用并发的低暂停收集器 ，而批处理服务使用吞吐量的收集器
• 部署批处理服务不会影响前端服务
• 如果一项服务出现故障，则不会影响其余服务

数据库连接设置

但是所有这些服务最终都将调用数据库，并且通常都是通过数据库连接来完成的。 数据库服务器只能提供有限数量的并发连接，因此必须提供连接。

当前的连接池解决方案仅提供有限的监视和故障转移支持。 这就是我们最近一直在努力的原因，这就是为什么我决定构建Flexy Pool的原因 。

城里有个新人

Flexy Pool是一个数据源代理，可为以下连接池提供更好的监视和故障转移：

• Bitronix交易管理器
• Apache DBCP
• Apache DBCP2
• C3P0
• 骨CP
• 光ikaCP

我们得出的结论是，调整连接池的大小不是一项预先的设计决定。 在大型企业系统中，您需要适应性，而监视是做出正确决策的第一步。

预先监控

名称	描述
parallelConnectionCount	这表明一次使用了多少个连接。
parallelConnectionRequestCount	这表明一次请求了多少个连接。
connectionAcquireMillis	目标数据源连接获取时间间隔的时间直方图。
连接租赁Millis	租用时间是指从获取连接到释放连接之间的持续时间。
maxPoolSizeHistogram	目标池大小的直方图。
totalConnectionAcquireMillis	总连接获取间隔的时间直方图。
overflowPoolSizeHistogram	池大小溢出的直方图。
retryAttempts直方图	重试次数的直方图。

故障转移策略

当所有池化连接都被使用时，新的连接获取请求将在放弃之前等待有限的时间。 这样可以防止系统过载，但为避免拒绝连接请求，您必须正确配置连接池大小。 您还必须考虑流量高峰，并考虑所有其他服务争夺有限数量的数据库连接。 监视的数据可以使您更好地了解连接的使用情况，因此在确定合适的池大小时，您将得到更好的装备。

Flexy Pool被设计为可响应的，因此它可以更好地适应流量高峰。 为此，它提供了可配置的故障转移策略机制。

策略是一种获取安全机制的连接，一种从未成功从目标连接池中获取连接时调用的手段。

Flexy Pool随附以下默认策略

• 超时时增加池此策略将在连接获取超时时增加目标连接池的最大大小。连接池具有最小大小，并且根据需要可以增长到最大大小 。 溢出是额外连接的缓冲区，允许连接池超出其初始最大大小 。 每当检测到连接获取超时时，如果池没有增长到其最大溢出大小 ，当前请求就不会失败。
  
• 重试尝试此策略对于缺少连接获取重试机制的连接池很有用

敬请关注。 我的下一篇文章将演示Flexy Pool如何帮助您找到合适的池大小。

翻译自: https://www.javacodegeeks.com/2014/04/flexy-pool-reactive-connection-pooling.html