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

我真不知道具体情况。如果是这样，那么数据其实已经简化到我最后介绍的设计了。而且具下面的回复，我的估计还大了一个数量级。应该不会出现那么严重的问题，难道他们余票查询还需要去汇总售票记录？

其实用什么支付对于网站来说都一样

订票数据库应该是和窗口共用的，这个没有什么太大的压力

在没有网络订票之前，所有售票点+车站窗口已经是一个非常大的流量访问了，要考虑到窗口专业人员和专用软件的输入速度远远超过网站输入，这个系统是经受过时间考验的，应该不会有问题。

一个证明是你也提到过的，登录难，但是登录之后查票并不难。

估计是将用户数据这一块独立存放，毕竟窗口订票根本无需这个用户登录，为了保证与窗口联动的订票系统的稳定，控制了并发的用户登录数，毕竟窗口的稳定性和速度是要优先保证的。

余票查询系统是非实时的，这个应该是题中应有之义。

貌似一趟车1000人的标准似乎有点低啊，7.23的两趟D车，一趟定员1299人，一趟定员810人，考虑到春节期间多少都要超员，D车宽大的座椅，车均1500人应该更靠谱些。

7000万人应该是700万人的笔误？新华网的消息是预计588万。

送花成功。有效送花赞扬。感谢：作者获得通宝一枚。

参数变化，作者，声望:1；铢钱:16。你，乐善:1；铢钱:-1。本帖花:1

这样的帖子才是应该提倡的 而非神马放着十八摸不用的NC宣传软文 要说回扣党09/10年十八摸的紫色风暴就是例子。。。

虽然我做的不是这种业务，面对一堆各种来源数据做统计，还是很考验数据库设计的，这种设计和教科书教的既有关也无关。

BTW:稍微晚点，避开高峰，刷一下，还是能买到的，我每周都在买往返票，确实方便啊

在理论上1和2之间当然可以相隔无限长时间，但是无论是1还是2都要连接数据库，我提到了其连接方式可以是使用已有连接或者重新连接。重新连接的问题在于当用户完成支付返回到本网提交状态时中间件已经没有可用的db连接了，而使用已有连接的问题是一般中间件都会设定连接的ageout时长，用户完成支付时间过长会被ageout，但ageout设定过大又会降低连接效率。

所以最终问题都会表现到中间件到db的可用连接数量上。然而问题的表现形式与其本质并不一致。网银支付才是其本质。

我的point并不在于db连接是否需要cache，也不是这个cache的ageout应该要多长。而在于当中间件可用连接数有限的情况下，应当使每个用户尽快完成交易。我认为目前的售票系统网银支付方法是阻碍用户在短时间内完成交易的主要瓶颈。

btw:我不知道目标读者对IT的熟悉程度所以使用了cache连接这种说法，连接池当然没问题，但也是cache连接的一种方式而已，目的是为了减少连接打开和关闭的资源消耗，提高效率。而且中间件有自己的连接池,在db端oracle自己也有，这二者都是可用的看你怎么选了。

铁路售票与航空售票及电子商务网站的主要区别：

航空售票：一人一个座位。没有中途下飞机的。

电子商务：每次买一个商品。商品基本是固定的。就是一个数量而已。买一个少一个。

这两个主要的难点在与定价及优惠的灵活性。大部分的时候大家不用抢同一个资源。

拍卖之类的交易行为只占网站很少一部分。

铁路售票有一个比较不同的地方：最后时候大家都在抢统一资源并且资源的数量比较少。

另外铁路还有一个公用复用的问题。

以复用为例：假设北京到上海中间经停10个站，以A-Z代替。

起始时刻，每个站都可以卖。假设有多个售票渠道的话，例如从电话卖了一张B-D的票。

那么其他的售票终端例如互联网上就应该可以买A-B，及D-Z的票。但假如说要想买一张

A-C的票，对不起，没有。从这个方面来说，A-Z中任意一个节点都会影响到其他节点。

在实际中为了降低冲突，可能预先生成相应的区段车票。如果是这样的话则系统中实际

产生的电子票的数量可能比实际的车票多个量级。

前面提到了，全国日均588万人次。意思是至少有大约600万实际的车票，则大

约每天至少生产大约6000万票（假设每列车有10个停靠站)。

还有一个实际的预售期的问题，一般的预售期例如10天的话，意思是10天内产生的车票

都可以卖。这样的话，实际上可能就是6000万*10张车票。所以实际的数据量应该还是挺

大的。

从这种情况来说，票并不是固定的。因此余票信息也不是固定的。大家其实抢的可能不是

同一张票，而是同一个座位在不同区间所产生的不同的票。

这种信息在电子商务网站上比较少见。

从开发的角度来说，如果不确定票的准确性的话，系统的压力会大为降低。目前所有的售

票终端当锁票的阶段，座位号就已经固定了。假如说系统此时不固定座位号，只提供余票

信息，当实际支付的时候在锁固定座位（此时有可能锁票不成功),如果这样的话，系统的

压力降低的不是一点半点。但实际情况是如果这样做的话，会被骂的更狠。

从我自身的经历来看，这种需求还是比较变态的。与淘宝之类的压力还是应该不太一样的。

假如说淘宝上大家向春运这样都在买同一件东西或几件东西，也是比较够呛的。

DB2不好说

这个是设计原则，正确。

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

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

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

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

今日得闲，做一集群初步设计图，发上来抛砖引玉。。

关乎大家的订票系统，让大家也都来设计设计，凑凑趣。

感觉关键是做好应用逻辑分析，将整个系统有条理的切分成多个集群，应该是能够应对大访问量的。不要迷信所谓软件公司既有系统，没有针对性的既有系统，就是个噱头罢了。

另外，俺的思路主要是要做成分布式，包括分布式数据库、分布式商业逻辑，以及分布式WEB展现。一旦合理展开，可以减少很多复杂性。当然，代价是要高质量的管理和维护一个分布式系统，但总的来说，这是较优选择。

图中的方案，核心是车次-车站-车票子系统。作图时考虑不周，其实最小单位是：日期-车次-车站-车票子系统更好。另外，子系统中的数据库服务器和商业逻辑服务器也可分开为独立硬件服务器。分流到这一步，每个服务器的负载是很低的，普通入门级服务器即可负担。

既公平，又简化系统，还能避免无谓的资源浪费。

“前面提到了，全国日均588万人次。意思是至少有大约600万实际的车票，则大约每天至少生产大约6000万票（假设每列车有10个停靠站)。”

588万人次应该基本对应588万张票

这个人次应该是检票口的计数