自认为在大
并发，
高可用方面有所积累，大家有什么问题可以问问，看本人能不能解决
解决方案
10
有这样一个场景：
一个web应用服务器器连一个MySQL数据库。web容器的数据库连接池配置100，MySQL服务器的最大连接数配置1000。在实际压测的时候（使用LoadRunner），当虚拟用户数达到110多，就开始出现“无法获取数据库连接”的报错。我们统计了部分机器，它连接数据库确实超过100了。也就是说，几乎每个请求都会获取一个数据库连接，这应该是违背了数据库连接池，池化的本意。
问一下你们在实际使用过程中，假如碰到这种数据库连接池恶性创建连接的现象，都会怎么处理？或会从哪些方面去分析解决这样的，或相似的问题？
10
是这样的，我们的容器链接和数据库连接池等，这些链接资源都是有限的。一般超过这个访问量，都会存在一定的等待，但是这个等待不会太长。一个优秀的处理机制，甚至用户不会感觉到等待。
本人碰到的问题，容器链接100，并发110真心不过分。其实根本原因是数据库那块的处理做的不够好，等待过久导致的。
10
那这个就是数据库瓶颈了，可以优化sql啦，索引啦，加缓存啦，异步处理啦等等。
10
行，我们就用食堂大妈为例。每次建立连接，释放连接，实际上是相当于，有人来打饭了，大妈从休息室跑过来，戴好口罩，拿起大勺。释放连接，相当于，这个学生打完饭走了，大妈放下大勺，去掉口罩，回到休息室。
本人想说明的是，数据库建立连接的过程，相对于机器速度来说，是很慢的一个过程。我们真实使用数据库连接的时候，尤其是对性能要求比较高的时候，是不会每次都“获取连接、使用、释放连接”的。而是将获取的链接暂时（有时效）放在一个池中，其它数据库请求来了，优先从池里直接拿到数据库连接的句柄，直接使用。
再用大妈打饭来说，相当于，大妈来给学生打完饭，会在窗口那等一会儿，假如有人打饭，继续，假如等的时间长了，就回去休息。这个等的过程，就是池化要达到的效果。