Clever Geek Handbook

Systems design issue: DB connection management in n-tier balanced load

I am curious about the best approach to designing a DB connection manager for an n-tier load balanced system.

The classic n-level looks like this:

Client -> BusinessServer -> DBServer

The load balancing solution, as I see it, will look like this:

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

As shown in the figure, the business server component is load balanced across multiple instances, and the hardware gateway balances the load between them.

The session server should probably be located outside of the load balancer array as it manages state that should not be duplicated.

Barring any major design mistakes so far, what is the best way to implement DB connection management?

I came up with a couple of options, but there may be others that I am not aware of:

  • Introduce a new Broker component between the DBServer and other components and let it handle DB connections.

    • The good news is that all connections can be controlled from one point, which is very convenient.
    • The disadvantage is that there is now an additional "single point of failure" in the system. Other components have to go through this for every request that is connected to the DB in some way, which also makes this a bottleneck.

  • Move DB connection management to the BusinessServer and SessionServer components and let each handle its own DB connections.

    • On the plus side, there is no additional "single point of failure" or component bottlenecks.
    • The downside is that there is also no control over possible conflicts and deadlocks beyond what the DBServer itself can provide.

What else can you do?

FWIW: .NET technology, but none of the vendor-specific stacks are in use (e.g. WCF, MSMQ, etc.).

+2


source to share


1 answer


In the end, I went with a design that is a hybrid of the two mentioned in the question. I made Broker and SessionServer dynamic components that can then be configured to run either in proc with BusinessServer or in proc, covering all possible combinations.



In essence, I decided to put in a little more work to make the system customizable, so I can determine the best approach in each case.

0


source






More articles:


All Articles