例如：有1个数据库服务器，最大连接数允许300。但是我有1000个c/s结构的客户端采用连接池访问此数据库，如果连接池里面设置最小连接数是1，那么不是已经达到最大连接数300了吗？还有700个客户端怎么办？
请问采用什么样的架构解决此问题?
------解决思路----------------------
恕我直言，都没有说到点子上去，没有解释楼主最根本的问题
第一，有1个数据库服务器，最大连接数允许300。我不明白为什么你的数据库最大连接数是300，
可以通过select @@MAX_CONNECTIONS查看最大连接数，即便如此，也罢，往下看
第二，即便是最大连接数是300，你有1000个客户端，客户端启用了连接池，也没有关系，连接池是一种客户端机制，如果服务器端强制断开，那客户端缓存的连接也没用，我的意思就是，即便是客户端开启了连接池，客户端的连接池也不会“绑架”数据库连接，对于数据库的连接，是数据库服务器说了算的，不会因为客户端启用了连接池，同时不释放连接，服务器就无法工作了。
举个极端的例子，数据库服务器，最大连接数允许300，一个客户启用连接池之后，端缓存了300个连接，那岂不是所有的其他的客户端都无法访问数据库了，等于是数据库被这一个客户端“绑架”了。可能吗？
要知道服务器是主动的，客户端是被动的，服务器需要新建连接的时候，如果发现连接资源没有了，将会去释放其他客户端缓存的连接池中建立的连接的。
客户端启用连接池之后，使用连接池中的数据库连接的时候不是没有任何校验措施的，最起码，使用之前，要看看这个连接是否有效，是否被服务器强制断开（踢掉）等等。
另外一个问题，我觉得楼主还没弄清楚，就是并发的，你并发访问数据库，也就是多个客户端访问之后立马断开，比如你最大连接数是300，如果有1000个人同时（我是说同时，是同一个时间点，同一分钟同一秒同一毫秒同一微妙，你明白这个同时的含义吧）去点击一个按钮，访问数据库，那么，此时数据库会先对一部分连接进行数据库操作，待先拿到数据库连接资源的会话操作完成之后，其他的会话才能建立连接，此时也并不是说其他客户端无法访问数据库，而是说要等待，至于等待多久，要看你连接一次数据库经过多久再去释放这个连接，并不是说你有超过了数据库最大连接的用户数，这些用户就无法访问数据库了，除非（我是说除非）你这1000个客户端同一时刻去访问数据库，会出现因为数据库连接资源不足而等待（获取数据库连接资源）延迟（也就是延迟，还不是不可访问），否则，根本就不会出现你说的什么并发问题。
------解决思路----------------------
同时也还是操作完毕就及时释放物理连接 --> 同时也还是操作完毕就及时释放逻辑连接
如果你的应用首先使用20毫秒访问（查询）了一下数据库记录，然后过了200毫秒又依次访问数据库，那么你第一次访问数据库之后就应该立刻调用 close 操作来关闭逻辑连接。这样物理连接就能自动共享给其它客户端的请求。这就是为什么1000个c/s客户端使用数据库，往往在连接池中只要有不到30个物理连接就够用的道理。
如果你自作聪明地使用static变量去“共享”什么逻辑连接，用在前后两个数据库访问中，那就意味着你占用一个“茅坑”的时间长度是220毫秒以上，而不是10毫秒。你可以算算看，这将让“茅坑”的并发使用率降低多少倍？
连接池只有利、没有弊！
如果你的应用程序不去即使释放逻辑连接，所谓“缓存连接”，那么跟数据库连接池毫无关系。又不是人家数据库连接池给你“缓存连接”的，纯粹是你编写的程序的问题。因此连接池没有弊，只有利。