database - 系统设计问题：负载平衡 n 层中的数据库连接管理

Question

我想知道为负载平衡的 n 层系统设计数据库连接管理器的最佳方法。

经典的 n 层如下所示：

Client -> BusinessServer -> DBServer

我看到的负载平衡解决方案将如下所示：

                    +--> ...            +--+
                    +--> BusinessServer +--+--> SessionServer --+
Client -> Gateway --+--> BusinessServer +--|                    +--> DBServer
                    +--> BusinessServer +--+--------------------+
                    +--> ...            +--+

如图所示，业务服务器组件通过多个实例进行负载平衡，硬件网关在它们之间分配负载。

会话服务器可能需要位于负载平衡阵列之外，因为它管理状态，不能重复。

到目前为止，除非设计中出现任何重大错误，否则实现数据库连接管理的最佳方式是什么？

我想出了几个选项，但可能还有其他我不知道的选项：

1. 在 DBServer 和其他组件之间引入一个新的 Broker 组件，让它处理 DB 连接。

   • 好处是可以从单点管理所有连接，非常方便。
   • 缺点是现在系统中多了一个“单点故障”。对于以某种方式涉及 DB 的每个请求，其他组件都必须经过它，这也成为了瓶颈。
     
     

2. 将 DB 连接管理移到 BusinessServer 和 SessionServer 组件中，让每个组件处理自己的 DB 连接。

   • 好处是没有额外的“单点故障”或瓶颈组件。
   • 缺点是除了 DBServer 本身可以提供的之外，也无法控制可能的冲突和死锁。

还有什么可以做的？

FWIW：技术是 .NET，但没有使用任何供应商特定的堆栈（例如，没有 WCF、MSMQ 等）。

Answer 1

最后，我选择了一个混合了我在问题中提到的两者的设计。我已将 Broker 和 SessionServer 制成动态组件，然后可以将它们各自配置为在带有 BusinessServer 的进程内或进程外运行，从而涵盖所有可能的组合。

从本质上讲，我选择投入更多的工作来使系统可定制，这样我就能够逐案确定最佳方法。