1：问题的引入
过亿访问量站点的性能瓶颈是什么？相信有过经历的朋友一定会告诉你，是数据访问。有关数据访问这个话题可以说是博大精深，我今天就只针对“如何降低数据库的连接数”这个话题来说开去。
2：问题发生的场景
我们来看一下传统三层下的序列图
我们透过现象看一下本质，图中的依赖关系决定我们要有两台服务器【不考虑负载均衡的前提下】。这样我们的问题就来了，什么问题那？接下来听我慢慢道来。
我们知道数据库的链接以及连接池的分配是按照客户端以及应用程序来分配的。换句话说“对于数据库服务器在分配连接的时候是根据客户端以及客户端的应用程序来分配的”，举个例子我们有一台服务器并且这台服务器上运行了三个进程。这种情况下数据库会分配三个Session，三个进程中的链接以及连接池是不能共享的。看出问题了吧。
问题就是：当我们随着公司的业务增加而部署越来越多的应用服务的时候数据库的链接资源就会越来越少。当连接资源到了一定程度的时候，数据库的瓶颈就出来了，这时候众多的请求在数据库端排队但是来自于客户端的请求又不断的压到应用程序服务器上，这样我们的客户端和数据库群殴应用程序服务器。
3：问题的解决方案探索
我们在探索解决方案的时候先来回顾一下问题的场景：以洪水形式的请求压到应用程序服务器，接着应用程序将这种压力转发到数据库上。在数据库上由于连接资源耗尽请求被大量积压。这种积压会增加应用程序服务器的连接资源。应用程序连接资源到一定程度下导致发送到应用程序的请求在应用程序端排队积压。这种情形就像浪涌。
为什么会出现这样的问题那？原来“当我们增加应用的同时数据库的链接资源也在不断的增加”。看来我们应该找到一种方法，这种方法使得在增加新的应用的时候连接资源不会增加。
那么我们是不是应该统一来管理数据库链接资源那？
答案是肯定的。来看看我们的方案看看能不能解决这个问题。
部署图
从图中我们可以看到。我们把链接这种资源进行了统一管理，就好像在数据库前挡了一层代理。你直接向DAC要数据就可以了。
4：遗留问题
我们剩下两个问题给读者思考。
1：为什么对DAC分组，分组的意义是什么？
2：我们建立了数据中心，在这后面实际上就是存储层。存储层分为数据库，文件以及内存。那么我们的存储层该如何设计那？
后记：随后我会追加文章给大家介绍存储层的设计。
如果文中提出的问题恰巧您也遇到了，并且有不一样的解决方案。不吝赐教
