主题：【原创】无责任推测12306网站遇到的麻烦 -- 代码ABC

这个是设计原则，正确。

这个分析是错误的。事实上支付前和支付后确认在本地系统看来是两次交易，之间可以无状态。这样间隔多久对系统都没有影响，和中间件也没关系。你把我们人的交易概念和系统的交易概念混淆了。对系统来说点一次查询就是一次交易。提交订单和确认支付是两个独立的交易——至少我设计的所有有支付功能的网站都是这样的。

这也是对的，在处理页面请求的时候，我们现在使用数据库都是临时打开连接（用连接池），批量执行，然后立刻关闭连接——即将连接交回连接池。保持数据库连接使用时间尽可能短。但是连接为何会不足，原因通常是查询变慢，就像一条拥挤的车道，前面某辆车稍微减一下速。就会导致后面一段车要停下来一样。当某些查询时间超长，无法迅速归还数据库连接的时候。这时连接数就不够了。因此瓶颈在数据库上，和用户无关。如果所有查询可以在20毫秒内完成，10个连接至少可以支持1000个用户同时查询。

如果12306的网站需要用户缩短支付周期来避免瓶颈，先不说这种设计是否能实现。在设计思路上就是大错特错，无论如何不能把系统性能依赖于用户怎么使用上。尤其是公共网站。

还有，中间件的设计也应该和用户无关，要尽可能做到不受用户会话进程影响无状态编码。这样才可以做到横向扩展和负载均衡。这也是一条基本原则。所以我不怀疑中间件，由于没有足够的情报，我总是先怀疑最大嫌疑者——数据库。