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

Question

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

经典的n层看起来像这样：

Client -> BusinessServer -> DBServer

我认为负载平衡解决方案看起来像这样：

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

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

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

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

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

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

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

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

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

还能做些什么？

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

Answer 1

最后，我选择了一个与我在问题中提到的两个混合的设计。我已经将Broker和SessionServer变成了动态组件，然后每个组件都可以配置为在运行中使用BusinessServer或out-of-proc运行，从而覆盖所有可能的组合。

从本质上讲，我选择了更多的工作来使系统可自定义，以便我能够逐个确定最佳方法。