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

余票查询不需要登录，我在低谷时间查询是非常快的。但是在高峰期（登录不上的时候）就几乎停顿。这是在1月6日和7日的测试。

我没实验过支付，但我做过支付的网站。中间件不是这样设计的，首先中间件不需要cache连接，数据库访问通过连接池进行，这样每次业务连接数据库的时间会很短。按每天10亿次点击算，大致上连接池有3000-5000就可以满足数据库连接要求。但是这要求每次操作都在1秒的数量级上完成。其次，用户做支付动作的时候是不需要中间件保持活动的，支付完成后支付接口通常有两种方式通知网站支付结果：URL跳转和TCP通知，这时候再通过中间件访问数据库进行交易确认。每笔交易通过事先向支付网关提交的支付单号对应起来。因此订单支付动作对于本网站来说就是两次查询：1、生成订单，并提交支付；2、确认支付。1和2之间可以间隔任意长的时间，不会对本网的中间件有任何影响。而且和用什么支付手段完全无关，支付宝不解决问题。

如果按每个用户都时刻连着数据库来设计的话，这种网站很快就会完蛋。我之所以认为查询有问题，原因就是看到那个30分钟才更新的余票数据的变动。如果查询没问题他们不需要这样修改，这类型的修改大多是因为查询开销太大，需要构造一个汇总表来事先汇总一些中间结果。由此也可以推断出原本的查询是关联了多张表的复合查询。