用于 Java/JDBC 应用程序的 PgPool 负载平衡答案

【问题标题】：PgPool Load balancing for Java/JDBC application用于 Java/JDBC 应用程序的 PgPool 负载平衡
【发布时间】：2014-03-18 09:02:26
【问题描述】：

在 CentOS 上设置好 PgPool 的所有可能设置后，当我使用我的 Java 应用程序对其进行测试时，我发现它无法正常工作。
在网上阅读手册后（你可以找到here），我发现如果JDBC语句被设置为false（自动提交），它就不能工作了。
由于我使用的是 Hibernate，因此我很确定它正在使用事务来设置值。
我的问题是，如果这是真的，哪种方法对复制我的数据库有用。我听说过并行模式，但我不确定它是否适用于 Java 应用程序。任何人都可以指导并为我提供样品吗？

【问题讨论】：

反对者请评论你在这个问题中看到了什么问题

标签： java hibernate centos pgpool

【解决方案1】：

如果通过并行模式你的意思是事务隔离级别，从这个页面你可以看到PostgreSQL supports 4 level of isolations，它可以通过设置属性从休眠配置：hibernate.connection.isolation 到 1、2、4 或 8 ，从低到高。

已提交读是 PostgreSQL 中默认的隔离级别，比脏读高一级。

序列化是最高级别并且非常昂贵，因为如果要在同一个表上进行 2 个事务，就会有一个锁，如果锁发生的时间超过了在数据库/休眠中设置的超时时间，那么它会抛出一个超时异常。

不确定您是否听说过它们，但以下是可与 hibernate 一起使用以提高性能的框架：

C3P0 用于更高级的连接池
Ehcache 通过启用缓存来提高性能

它们易于配置且不依赖于操作系统。我对 PgPool 没有任何经验，所以我无法给 cmets 提供性能比较。

以下是您可能想尝试的示例休眠设置：

<prop key="hibernate.show_sql">false</prop>
<prop key="hibernate.format_sql">false</prop>
<prop key="hibernate.connection.isolation">4</prop>
<prop key="hibernate.connection.autocommit">false</prop>
<prop key="hibernate.c3p0.min_size">5</prop>
<prop key="hibernate.c3p0.max_size">20</prop>
<prop key="hibernate.c3p0.timeout">1800</prop>
<prop key="hibernate.c3p0.max_statements">50</prop>
<prop key="hibernate.cache.provider_class"> org.hibernate.cache.EhCacheProvider</prop>
<prop key="net.sf.ehcache.configurationResourceName">WEB-INF/ehcache.xml</prop>

我希望这可以帮助您在数据库事务方面优化您的应用程序。您实际上可以检查更多内容，例如表索引，或使用分析器找出哪些事务成本最高。

【讨论】：

我在询问有关在 PgPool 中设置数据库备份和负载平衡的问题。做这个答案，在这种情况下有帮助吗？
在那种情况下，我的错误和这个答案确实没有帮助。

【解决方案2】：

业务方法结束时的修改事务如您所描述的那样工作：创建一个 BEGIN/END 块，其中包含所有已提交或回滚的修改查询。

这是通过将 autocommit 设置为 false 来完成的，但这并不意味着 Hibernate 进行的所有查询都在此模式下完成。根据所需的隔离模式，可以在自动提交或非自动提交模式下执行相同的查询。

对于READ_COMMITED 模式下的事务的通常情况，诸如按 Id 查找或命名查询之类的查询将在其自己的数据库事务中运行，自动提交为 true（因此没有 BEGIN/END 块）。

按 ID 查找和其他读取查询只有在至少以 REPEATABLE_READ 隔离模式运行时才会触发 BEGIN 块。

这意味着如果您使用默认的REPEATABLE_READ 隔离模式，负载平衡将正常工作，因为大多数选择查询将在 auto-commit = true 时运行。

您可以通过记录发送到数据库的所有 SQL 查询来确认这一点，例如使用 log4jdbc。这将打印所有实际发送到数据库的 SQL。

【讨论】：