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

跟地方大小有什么关系？

除非12306是你参与做的，那我道歉。

不管是从头设计也好，优化也好。总要有一些基本的数据、假定和约束。不然就真是纸上谈兵了。Cache当然可以降低数据库的负荷，但是搞清楚付出的代价才是更重要的事情。

另外，做了一两年网站设计的人的想法不一定靠谱，除非他这一两年就做一个网站，看着一个网站从小到大地增长。

我没有做过前端系统，主要的工作经验来源于设备网管。按照我的设想，铁路售票系统的case如下：

1.登陆

2.查询余票

3.预定车票

4.交易付款

5.确认交易成功

大量的数据交互应该在3和5步，在预定车票的时候应该已经在系统中将该数据lock，然后等待付款成功后将车票从系统中提出。如果出现预订后放弃的情况，该车票需要归还票池。

按照上面的设定，使用cache不会有太多的性能提升，所有的查询，预订和出票应该都使用同一个数据库联接，如果有人出现交易失败一直在系统内试图交易的情况，负载将会急剧上升。而且他是一个实时系统，这样的压力不是说搞定就搞定的。

再说了通信交换系统或者银行系统，核心机上数据交换都比较少，并且业务相对来说可以拆分，都比这个铁路订票要容易一些。

我一直在大型网站开发和云计算一线工作，现在的工作就是使用一些成熟技术搭建平台帮助中小网站成长。

从你的回答中提到数据库缓存操作系统缓存可以知道，你没明白我说的cache指的是memcached／redis之类的成熟集中式缓存，所谓隔行如隔山就是如此。很多业界已经成熟的东西，一定要拍脑袋自己想是没啥价值的，多参考参考现有的成熟案例没有错的。

是taobao核心系统部的同学干的。

今年集团的一个技术奖就是给他们，用廉价server组成的mysql集群替换了跑oracle的ibm小型机。这样的意义不仅是成本上的巨大节约，更重要的是保证了数据库层的水平扩张，，，，，

网上看的图片。

这个大约是在何种水平？10万人在线，每秒20笔支付。

应该不会超过淘宝京东之类的一流电商网站吧？和民航订票系统比呢。

说得好，所以，现在的网络定票，其时间应比窗口晚一天而不是早一天。即：这个系统只应当是节约跑路的时间，而不是方便有文化的人。但是，也许正是因为上头的人意识到了，批评的声音永远来自于文化人，所以呢，只要应对好了这一部分人，其它的便不再重要。再也闹不出大的响动来。

想像一下，假如今年的票，系统非常完美，不闹出这个系统瘫换的事出来，然后，在第一天就把所有的票都顺利地卖给那些会在网上订票的人，那么，谁又来再关心那些只会在窗口排队却无票可买的人呢？

再脑补一下，以一个典型的阴谋论者的眼光来看，必定是中间有一个意识到这个问题的伟大黑客，故意在其中做了手脚，来关心那些不会在网上订票的大众，伟哉善哉。

这个次数的来历，应当是反复都进不去，进不去就不断刷新，每刷次一次就计算一次点击，按我自己的习惯，在十秒钟以后页面还不能读出，就会刷新重来。估计还有很多人的可忍受时间也相差不大。

窗口售票不受影响不说明12306和内部票务系统没有连接

也可能是压力不在票务系统上面

反而如果没有连接，那说明设计人员很弱智

我们用一个简单的计算

每天7000万人坐车，假定50%是通过12306购票的

那么可以按照每天通过12306卖出3500万张票

而且可以预期的是这些票中的很大一部分都是在刚开始营业的10分钟内卖出去的，假定是1000万张

那么12306在10分钟内要进行1000万次交易（不含查询/登陆）

1000万/10/60=16666TPS

这还没有考虑峰值压力，这个数字很可怕

又有新闻说12306硬件采购1000多万元

假定都是应用服务器，可能也就100台

已经做的很好了，他们的问题在于业务，不见得是技术

（这个断言是从我的经验来看，我做的系统设计目标只有4000TPS，当然实际上可能能超过8000）

业务上来说，12306应该24小时营业

还有一些规则可以变更，

例如说提前7天可以购票，现在的规定是旅行日期之前7天就可以买

那么大家都拥堵在开始营业的那几分钟

如果改成列车开车时间前7*24小时开始售票

可以将压力均分，就会好得多

非常肯定

而且真正大规模系统印度人就是失败的

你把印度人当成偶像，有些孤陋寡闻

举个例子，State Bank of India是印度最大的银行

他们的系统相当于国内90年代水准

12306估计没用什么分布式数据库，即使不考虑这个，哪怕一个车次使用一个单独的数据库（跟淘宝似的），一趟车1000个座位，假设同时会有10w人来抢票，啥数据库也得被锁等待弄得贼慢。并发多了之后，你在等我，我在等他，谁都很难动得了，这和一大堆人挤安全门是一样的。数据库处理锁等待的时候，都是占着CPU的，所以一锁就慢，慢了更锁。当有锁很多的时候，CPU很容易被耗尽，更关键的是数据库连接数会更容易被耗尽，Oracle数据库连接数上万也就很多了，和急等着回家的网民比，这点量算啥？所以不断会有人被提示用户数过多

查询的时候不被锁很容易，啥脏读呀、UNDO呀，就是干这个的，但这也都是有代价的。

每秒20笔支付其实很少很少——只相当于一个普通的网站而已。

但是10万人在线就人数而言算是一个大规模的网站。

我有一个经验数值，如果你的系统满负荷下可以应付每秒N次请求，那么也可以应付峰值每秒2xN次请求。原因是一般用户可以接受高峰期3-5秒的延迟。超过这个时间用户就会失去耐心，并且开始”不理智“地刷新页面，把系统进一步推向崩溃。不同网站这个系数会有差别，看用户的耐心程度，可以取2-5。

就10万人在线这个数据，我们假设平均思考时间是5秒。那么平均每秒有2万次查询。一般耐心的用户我们可以在大致每秒一万的系统设计能力下满足这个需求而不会出大事。能达到这个级别的处理能力才算得上大规模网站。所以12306在设计能力上还不算。