我负责开发和维护一组以相似数据为中心的 Web 应用程序。我当时决定的架构是每个应用程序都有自己的数据库和 Web 根应用程序。每个应用程序都维护一个到自己的数据库的连接池和一个用于共享数据(登录等)的中央数据库
一位同事一直认为这种策略不会扩展，因为有这么多不同的连接池将无法扩展，我们应该重构数据库，以便所有不同的应用程序使用单个中央数据库，并且任何修改这可能是系统独有的，需要从该数据库中反射(reflect)出来，然后使用由 Tomcat 提供支持的单个池。他假设有很多“元数据”在网络中来回传输以维护连接池。
我的理解是，通过适当调整以仅在不同池中使用尽可能多的连接(低容量应用程序获得更少的连接，高容量应用程序获得更多连接等)，池的数量 与 连接数 相比，或者更正式地说，与 1 个 30 个连接池相比，维护 3 个 10 个连接池所需的开销差异可以忽略不计。
最初将系统分解为一个应用程序一个数据库设计的原因是，应用程序之间可能存在差异，并且每个系统都可以根据需要对架构进行修改。同样，它消除了系统数据泄露到其他应用程序的可能性。
不幸的是，公司没有强有力的领导来做出艰难的决定。尽管我的同事只是模糊地支持他的担忧，但我想确保我了解多个小型数据库/连接与一个大型数据库/连接池的后果。
最佳答案
您的原始设计基于合理的原则。如果它对您的情况有所帮助，此策略称为 horizontal partitioning or sharding .它提供:
1) 更大的可扩展性 - 因为如果需要，每个分片都可以存在于单独的硬件上。
2) 更高的可用性 - 因为单个分片的故障不会影响其他分片
3) 更高的性能 - 因为被搜索的表的行数更少，因此索引更小，从而产生更快的搜索。
您同事的建议将您转移到单点故障设置。
至于您关于 3 个大小为 10 的连接池与 1 个大小为 30 的连接池的问题，解决该争论的最佳方法是使用基准测试。以各种方式配置您的应用程序，然后使用 ab (Apache Benchmark) 进行一些压力测试，看看哪种方式性能更好。我怀疑不会有显着差异，但做基准来证明这一点。
关于java - 连接池策略 : Good, 坏还是丑？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1456664/