主题：【原创】无责任推测12306网站遇到的麻烦 -- 代码ABC
家园 余票查询 目前库里有多少是多少， select 的条件从句可以简单很多很多。
当天售票/余额汇总以后如果计划部门重新分配长短途票额的话，那还是今天没有就是没有，明天有的是新的。
不用搞动态资源分配，算法/架构可以数量级的简单
家园 我曾经2次尝试过网上购票 第一次登陆成功，然后查询余票这一块速度是相当快的，但是下订单时候被告知连接数过多失败。第二次登录直接失败，被告知连接数过多。
由此来看我不认为瓶颈在数据库，而在中间件，是中间件活动连接数被撑爆了。因为无论你下单还是登陆都需要通过中间件连接db。但是这并不意味着中间件是问题的根源。
我认为中间件的问题是由于用户在站内停留时间过长造成的，大量用户尝试通过中间件连接db，导致任何人的短暂释放连接都会使其下一次尝试失败。
那么什么原因导致用户在站内停留时间过长？很可能是第三方接口，我认为最大的可能是网银。用户在余票查询完毕，下完单支付时会被直接跳转到网银，这意味要么其原有db连接被cache，要么需要在支付完毕后重新连接db，无论哪种方式在当前这种网银支付速度下都是难以接受的。
而从售票系统的查询余票速度很快这一点来看，铁路售票系统的数据库逻辑设计是相当成熟的，我不认为其逻辑设计会造成性能问题。但是订单支付需要直接调用网银界面，那个不仅是慢的问题，成功支付率都不能保证，如此就会直接导致平均每个用户在站内停留时间过长，进而导致其在中间件的db连接失效，最终订票失败。
支付宝的速度快是因为大多数情况下你的支付宝账号里有足够余额，这样就没有第三方接口的问题。所以要解决平均用户停留时间过长的问题要么开发个支付宝，要么用马云的产品。
家园 我的经验不一样 余票查询不需要登录，我在低谷时间查询是非常快的。但是在高峰期（登录不上的时候）就几乎停顿。这是在1月6日和7日的测试。
我没实验过支付，但我做过支付的网站。中间件不是这样设计的，首先中间件不需要cache连接，数据库访问通过连接池进行，这样每次业务连接数据库的时间会很短。按每天10亿次点击算，大致上连接池有3000-5000就可以满足数据库连接要求。但是这要求每次操作都在1秒的数量级上完成。其次，用户做支付动作的时候是不需要中间件保持活动的，支付完成后支付接口通常有两种方式通知网站支付结果：URL跳转和TCP通知，这时候再通过中间件访问数据库进行交易确认。每笔交易通过事先向支付网关提交的支付单号对应起来。因此订单支付动作对于本网站来说就是两次查询：1、生成订单，并提交支付；2、确认支付。1和2之间可以间隔任意长的时间，不会对本网的中间件有任何影响。而且和用什么支付手段完全无关，支付宝不解决问题。
如果按每个用户都时刻连着数据库来设计的话，这种网站很快就会完蛋。我之所以认为查询有问题，原因就是看到那个30分钟才更新的余票数据的变动。如果查询没问题他们不需要这样修改，这类型的修改大多是因为查询开销太大，需要构造一个汇总表来事先汇总一些中间结果。由此也可以推断出原本的查询是关联了多张表的复合查询。
- 复 我的经验不一样
家园 没错阿 在理论上1和2之间当然可以相隔无限长时间，但是无论是1还是2都要连接数据库，我提到了其连接方式可以是使用已有连接或者重新连接。重新连接的问题在于当用户完成支付返回到本网提交状态时中间件已经没有可用的db连接了，而使用已有连接的问题是一般中间件都会设定连接的ageout时长，用户完成支付时间过长会被ageout，但ageout设定过大又会降低连接效率。
所以最终问题都会表现到中间件到db的可用连接数量上。然而问题的表现形式与其本质并不一致。网银支付才是其本质。
我的point并不在于db连接是否需要cache，也不是这个cache的ageout应该要多长。而在于当中间件可用连接数有限的情况下，应当使每个用户尽快完成交易。我认为目前的售票系统网银支付方法是阻碍用户在短时间内完成交易的主要瓶颈。
btw:我不知道目标读者对IT的熟悉程度所以使用了cache连接这种说法，连接池当然没问题，但也是cache连接的一种方式而已，目的是为了减少连接打开和关闭的资源消耗，提高效率。而且中间件有自己的连接池,在db端oracle自己也有，这二者都是可用的看你怎么选了。
- 复 没错阿
家园 你的设计方法是错的 而在于当中间件可用连接数有限的情况下，应当使每个用户尽快完成交易。这个是设计原则，正确。
我认为目前的售票系统网银支付方法是阻碍用户在短时间内完成交易的主要瓶颈。这个分析是错误的。事实上支付前和支付后确认在本地系统看来是两次交易，之间可以无状态。这样间隔多久对系统都没有影响，和中间件也没关系。你把我们人的交易概念和系统的交易概念混淆了。对系统来说点一次查询就是一次交易。提交订单和确认支付是两个独立的交易——至少我设计的所有有支付功能的网站都是这样的。
最终问题都会表现到中间件到db的可用连接数量上这也是对的，在处理页面请求的时候，我们现在使用数据库都是临时打开连接（用连接池），批量执行，然后立刻关闭连接——即将连接交回连接池。保持数据库连接使用时间尽可能短。但是连接为何会不足，原因通常是查询变慢，就像一条拥挤的车道，前面某辆车稍微减一下速。就会导致后面一段车要停下来一样。当某些查询时间超长，无法迅速归还数据库连接的时候。这时连接数就不够了。因此瓶颈在数据库上，和用户无关。如果所有查询可以在20毫秒内完成，10个连接至少可以支持1000个用户同时查询。
如果12306的网站需要用户缩短支付周期来避免瓶颈，先不说这种设计是否能实现。在设计思路上就是大错特错，无论如何不能把系统性能依赖于用户怎么使用上。尤其是公共网站。
还有，中间件的设计也应该和用户无关，要尽可能做到不受用户会话进程影响无状态编码。这样才可以做到横向扩展和负载均衡。这也是一条基本原则。所以我不怀疑中间件，由于没有足够的情报，我总是先怀疑最大嫌疑者——数据库。
家园 远没有7000万人次/天那么多 2011年10月1号的数据：
10月1日，全国铁路运输旅客892.8万人，同比增加63.5万人，增长7.7％，创铁路单日发送旅客最高纪录。全国铁路当日加开临客310列。最近几天的数据：
1月9日，全国铁路发送人数524.6万人次，同比增加28.2万人次，同比增长5.7%。1月10日，铁路部门计划加开旅客列车548列。1月10日，全国铁路共发送旅客534.3万人次，同比增加17.4万人次，同比增长3.4%。1月11日，全国铁路发送旅客551.6万人次，同比增加23.8万人次，增长4.5%。当天，铁路部门加开旅客列车570列。铁道部官员如是说：
铁道部部长盛光祖说，2012年春运客运总量将大幅增长。春运40天，全国铁路将发送旅客2.35亿人次，同比增长6.1%，日均588万人次。2012年春运期间，铁路将增开图定旅客列车131对，总量将达到2064对。按同口径测算，全路春运图定客车节前能力达到479.8万、节后能力达到468.8万，同平时相比增长约25%。家园 谢谢，那我的估计偏大了一个数量级 日，我发现我用了总客运量了。算了，不改了。
家园 既然是窗口和网站并行 从求稳的角度来说
恐怕最底层库还是沿用原来窗口系统的来保证对接
对于逻辑结构大动的难度太大了
而且,票数并没有增加,所以和原系统相比,数据量并没有增加
主要的问题应该出在访问量过大上,这个东西的瓶颈只怕不在数据库上
另外,关于锁定的问题,是不是直接当作已出票处理,然后半小时后REVIEW一下,发现尚未到帐就直接释放掉就行,不用搞锁定这么复杂的东西
家园 不会用原有的系统 不然网站就会拖累窗口系统。而且我估计票源还是象以往那样分发，即网站是一个超级代理点，这样铁路系统的业务不需要做太大的改动，风险也小。所以网站是一个相对独立的系统，怎么设计都行。
访问量过大，瓶颈90%以上是数据库设计问题。现在的网站对于静态内容的访问处理效率是很高的，所以不会是带宽问题，即使是带宽问题我觉得以铁路的地位，电信的资源不难调度。
我说的锁定不是锁住车票数据等支付，而是确保多人竞争的时候不会出现冲突或者超卖的情况。这个锁定时间是很短的（理论上）。这个锁定是数据库内部的一个基本功能而已。一般来说为保证数据的一致性，即使是查询动作在数据库内部也是有锁的。
家园 后台好象是ORACLE？ 数据量很大的话传统的数据库如DB2、ORACLE之类的肯定力不从心，用NETEZZA之类的数据库比较好。
首先最笨的方法是，每个车次只存一条数据记录，然后关联另一张节点表（存放经停站点用）。这样查询余票的时候需要联合这两张表（还可能有计算）并汇总已有订票记录表。这种存放方式的特点在于数据冗余少。但是查询开销极大，因为需要访问一个庞大的订票数据表（每天2000万的增长）。如果哪个坚持数据库范式的DBA这么干，那么一定就悲剧鸟。每天2000万增长其实还好，可以将日期设为PARTITION KEY进行分割，相当于把数据量固定在2000万。估计主要瓶颈还是你后面说的，不同起止点的组合查询，