超级军网关于12306“排队”系统引发的争议
来源：百度文库 编辑：超级军网 时间：2024/04/29 12:16:46
http://blog.sina.com.cn/s/blog_3e489c7101019u2z.html
全文在此http://blog.sina.com.cn/s/blog_3e489c7101019u2z.html
全文在此
全文在此http://blog.sina.com.cn/s/blog_3e489c7101019u2z.html
全文在此
忘情兄，一个“供给关系”和“隐性显性”不能拿来替这个白痴的12306系统开脱，淘宝京东库巴网，每家也都有买空某种货物的，咋就没见人家排30分钟队呢？不知道这两天您是否亲自用过这个系统呢？
就拿我昨晚的订票过程来说，1900开始订票，第一把成功登陆，刷班次……失败……再刷，出来了，选票，下订单……额，显示102人排队，要求我等待30分钟，而且不保证成功订票。好吧，我等……中间退出，想再进的时候，完了，反复显示人员过多不让登陆。过了半小时，勉强上去了，一看人数过多订单作废，那我再定……又是30分钟……又是订单作废……这个时候显示这个班次还有余票……期间重复若干次就不提了，一会儿显示56人排队，一会儿显示42人排队，反正到最后订单就没成功过，不知道谁有这好脾气？
等到2230，这个班次终于没票了，订下一班，赫然显示订单等待时间15秒，14秒，13秒……正美滋滋呢，显示5秒的时候……尼玛又跳回15秒了……继续倒数……到8秒的时候又跳回15秒，我当场就斯巴达了，继续倒数，这回直接跳到6分40秒……艹，有这么耍人的么？让他继续等待，我一边喝水去，等回来的时候显示倒计时18分50秒……忘情兄你见过越数越多的倒计时么？我不订了还不行么！！！气鼓鼓地睡觉去了，呵呵。
睡觉前看到一则新闻，太极集团1.9亿中标新一代12306系统，这算是现实版的“钱多，人傻，速来”么？
忘情兄，一个“供给关系”和“隐性显性”不能拿来替这个白痴的12306系统开脱，淘宝京东库巴网，每家也都有买空某种货物的，咋就没见人家排30分钟队呢？不知道这两天您是否亲自用过这个系统呢？
就拿我昨晚的订票过程来说，1900开始订票，第一把成功登陆，刷班次……失败……再刷，出来了，选票，下订单……额，显示102人排队，要求我等待30分钟，而且不保证成功订票。好吧，我等……中间退出，想再进的时候，完了，反复显示人员过多不让登陆。过了半小时，勉强上去了，一看人数过多订单作废，那我再定……又是30分钟……又是订单作废……这个时候显示这个班次还有余票……期间重复若干次就不提了，一会儿显示56人排队，一会儿显示42人排队，反正到最后订单就没成功过，不知道谁有这好脾气？
等到2230，这个班次终于没票了，订下一班，赫然显示订单等待时间15秒，14秒，13秒……正美滋滋呢，显示5秒的时候……尼玛又跳回15秒了……继续倒数……到8秒的时候又跳回15秒，我当场就斯巴达了，继续倒数，这回直接跳到6分40秒……艹，有这么耍人的么？让他继续等待，我一边喝水去，等回来的时候显示倒计时18分50秒……忘情兄你见过越数越多的倒计时么？我不订了还不行么！！！气鼓鼓地睡觉去了，呵呵。
睡觉前看到一则新闻，太极集团1.9亿中标新一代12306系统，这算是现实版的“钱多，人傻，速来”么？
铁路~~
平时用用就行了（经常买票，从未感到不爽）~~
高峰假期远离吧（高峰时期没用过，看大家的痛苦经历得出）~~
平时用用就行了（经常买票，从未感到不爽）~~
高峰假期远离吧（高峰时期没用过，看大家的痛苦经历得出）~~
昨天上12306买票，排了整整一下午，始终是等待30分钟，哥一生气，打个的直接去火车站买票，排队5分钟搞定！加上来回时间，不超过半个小时。
系统做得太烂有什么可开脱的
多少人不是问题，排队30分钟？真要人多排个300分钟也没啥，关键是排完队订单经常作废，我真是奇了，把余票数和排队人数对应下是个很难事情吗？100张余票给个100人的队列，再加上10个顺序的候补，后面的直接显示队列满会不就完事了
系统又随时登不上，堂堂一个铁道部连服务器都舍不得投入？
多少人不是问题，排队30分钟？真要人多排个300分钟也没啥，关键是排完队订单经常作废，我真是奇了，把余票数和排队人数对应下是个很难事情吗？100张余票给个100人的队列，再加上10个顺序的候补，后面的直接显示队列满会不就完事了
系统又随时登不上，堂堂一个铁道部连服务器都舍不得投入？
你们相信真能从这网站上订到票么。没错，今天早上哥们真的抢到了。根据这两天的刷票经历总结，假如刷中的话，在订单确认页面点击确定是直接跳转到订票成功页面的。
我们政府部门开发或者下属部门开发的信息系统水平那可是相当高
，鄙人有幸也是一个建设者
，鄙人有幸也是一个建设者哼，中午又试了，9月30日的D6210，昨晚没票来着，中午又有了，排队2个人，提示等待30分钟以上……
突然觉得，这特么是不是前台下订单，然后记录到excel表上，再传到后台人工出票啊？？？？ >_<
哼，中午又试了，9月30日的D6210，昨晚没票来着，中午又有了，排队2个人，提示等待30分钟以上……
突然觉得，这特么是不是前台下订单，然后记录到excel表上，再传到后台人工出票啊？？？？ >_<
忘情兄，我希望您可以亲自试一试这改版后的系统，挑一个您认为不可能抢手的线路、时间和票种，看看是不是要强制排队，是不是排队后成功的概率极低，然后再发表评论。
还是用电话订票或排队去吧！！！
还是用电话订票或排队去吧！！！
好奇怪的说法。
系统烂就是系统烂，跟供给关系扯不上边的事。
你系统有100张票，200个人买，卖前100个就是。
以前买到买不到的，很快出结果，不像现在动不动的让人等几十分钟。
系统烂就是系统烂，跟供给关系扯不上边的事。
你系统有100张票，200个人买，卖前100个就是。
以前买到买不到的，很快出结果，不像现在动不动的让人等几十分钟。
个人感觉推出网上订票系统后更难买到票了,以前去旅游提前二三天还能买到卧铺票.现在提前十天硬座都没票卖了.
今天我买票,倒计时30分钟,告诉我前面有9人等候,倒计时结束,出票失败。这还是在刚放票3秒钟我就刷出来票的情况下。我怀疑这个排队程序有bug
kk01 发表于 2012-9-20 22:50 ![]()
好奇怪的说法。
系统烂就是系统烂，跟供给关系扯不上边的事。
你系统有100张票，200个人买，卖前100个就是 ...
一样是有100人买不到票，只要买不到，就一定会吐槽，只是由头不一样而已，结果都一样。现在你们说还是以前的系统好。可是系统升级前，你们又何尝有人说过旧系统的半句好话？
好奇怪的说法。
系统烂就是系统烂，跟供给关系扯不上边的事。
你系统有100张票，200个人买，卖前100个就是 ...
一样是有100人买不到票，只要买不到，就一定会吐槽，只是由头不一样而已，结果都一样。现在你们说还是以前的系统好。可是系统升级前，你们又何尝有人说过旧系统的半句好话？
everest_wf 发表于 2012-9-20 23:27 ![]()
今天我买票,倒计时30分钟,告诉我前面有9人等候,倒计时结束,出票失败。这还是在刚放票3秒钟我就刷出来票的情 ...
程序有bug那是铁定无疑的，我的意思是说即使程序完美无缺（事实上是办不到的），也一样解决不了问题。只要没买到票的人，总得找个由头发泄不满，这回是程序bug，如果程序上挑不出什么大毛病，照样会找其他方面的由头吐槽。所以只要供不应求的问题不根本解决，这个问题无解。这才是我这篇文章的中心意思。
今天我买票,倒计时30分钟,告诉我前面有9人等候,倒计时结束,出票失败。这还是在刚放票3秒钟我就刷出来票的情 ...
程序有bug那是铁定无疑的，我的意思是说即使程序完美无缺（事实上是办不到的），也一样解决不了问题。只要没买到票的人，总得找个由头发泄不满，这回是程序bug，如果程序上挑不出什么大毛病，照样会找其他方面的由头吐槽。所以只要供不应求的问题不根本解决，这个问题无解。这才是我这篇文章的中心意思。
我才是忘情 发表于 2012-9-21 06:06
一样是有100人买不到票，只要买不到，就一定会吐槽，只是由头不一样而已，结果都一样。现在你们说还是以前 ...
你说系统bug那是可以理解的。
但你的文章明显是以供需关系来为排队系统的问题做辩护，而这显然是不成立的。
“只要有人买不到票就一定吐槽”跟“新排队系统甚至比原系统更差”这两码事之间没有任何逻辑上的关系
所以不要混为一谈。
就比如你所说旧系统是隐形排队，新系统只是显性化了。这个解释恐怕很难让人信服。以前也会有买不到票的情况，但可以很快选择其他车次，现在呢？
我才是忘情 发表于 2012-9-21 06:06
一样是有100人买不到票，只要买不到，就一定会吐槽，只是由头不一样而已，结果都一样。现在你们说还是以前 ...
你说系统bug那是可以理解的。
但你的文章明显是以供需关系来为排队系统的问题做辩护，而这显然是不成立的。
“只要有人买不到票就一定吐槽”跟“新排队系统甚至比原系统更差”这两码事之间没有任何逻辑上的关系
所以不要混为一谈。
就比如你所说旧系统是隐形排队，新系统只是显性化了。这个解释恐怕很难让人信服。以前也会有买不到票的情况，但可以很快选择其他车次，现在呢？
在12306的网站上查余票，然后打95105105订票，速度比较快。
宁愿坐在电脑前数小时刷12306,不愿打个电话或者直接去火车站排队,现在的人啊
这个排队系统倒也没什么,只是需要加上几个选择,比如车次提供1-3个,坐席类别1-3个,自己可以排优先顺序,比如车次优先或坐席优先,系统处理时依次匹配,这样其实才真正与窗口买票的模式一致了,也可以减少刷新和排队的数量,真买不到也死心,不至于气愤.感觉是30日上午的票难买,其它时间好一些.
由12306.cn谈谈网站性能技术
12306.cn网站挂了，被全国人民骂了。我这两天也在思考这个事，我想以这个事来粗略地和大家讨论一下网站性能的问题。因为仓促，而且完全基于本人有限的经验和了解，所以，如果有什么问题还请大家一起讨论和指正。（这又是一篇长文，只讨论性能问题，不讨论那些UI，用户体验，或是是否把支付和购票下单环节分开的功能性的东西）
业务
任何技术都离不开业务需求，所以，要说明性能问题，首先还是想先说说业务问题。
其一，有人可能把这个东西和QQ或是网游相比。但我觉得这两者是不一样的，网游和QQ在线或是登录时访问的更多的是用户自己的数据，而订票系统访问的是中心的票量数据，这是不一样的。不要觉得网游或是QQ能行你就以为这是一样的。网游和QQ 的后端负载相对于电子商务的系统还是简单。
其二，有人说春节期间订火车的这个事好像网站的秒杀活动。的确很相似，但是如果你的思考不在表面的话，你会发现这也有些不一样。火车票这个事，还有很多查询操作，查时间，查座位，查铺位，一个车次不 行，又查另一个车次，其伴随着大量的查询操作，下单的时候需要对数据库操作。而秒杀，直接杀就好了。另外，关于秒杀，完全可以做成只接受前N个用户的请求（完全不操作后端的任何数据， 仅仅只是对用户的下单操作log），这种业务，只要把各个服务器的时间精确同步了就可以了，无需在当时操作任何数据库。可以订单数够后，停止秒杀，然后批量写数据库。火车票这个岂止是秒杀那么简单。能不能买到票得当时告诉用户啊。
其三，有人拿这个系统和奥运会的票务系统比较。我觉得还是不一样。虽然奥运会的票务系统当年也一上线就废了。但是奥运会用的是抽奖的方式，也就是说不存在先来先得的抢的方式，而且，是事后抽奖，事前只需要收信息，事前不需要保证数据一致性，没有锁，很容易水平扩展。
其四，订票系统应该和电子商务的订单系统很相似，都是需要对库存进行：1）占住库存，2）支付（可选），3）扣除库存的操作。这个是需要有一致性的检查的，也就是在并发时需要对数据加锁的。B2C的电商基本上都会把这个事干成异步的，也就是说，你下的订单并不是马上处理的，而是延时处理的，只有成功处理了，系统才会给你一封确认邮件说是订单成功。我相信有很多朋友都收到认单不成功的邮件。这就是说，数据一致性在并发下是一个瓶颈。
其五，铁路的票务业务很变态，其采用的是突然放票，而有的票又远远不够大家分，所以，大家才会有抢票这种有中国特色的业务的做法。于是当票放出来的时候，就会有几百万人甚至上千万人杀上去，查询，下单。几十分钟内，一个网站能接受几千万的访问量，这个是很恐怖的事情。据说12306的高峰访问是10亿PV，集中在早8点到10点，每秒PV在高峰时上千万。
多说几句：
库存是B2C的恶梦，库存管理相当的复杂。不信，你可以问问所有传统和电务零售业的企业，看看他们管理库存是多么难的一件事。不然，就不会有那么多人在问凡客的库存问题了。（你还可以看看《乔布斯传》，你就知道为什么Tim会接任Apple的CEO了，因为他搞定了苹果的库存问题）
对于一个网站来说，浏览网页的高负载很容易搞定，查询的负载有一定的难度去处理，不过还是可以通过缓存查询结果来搞定，最难的就是下单的负载。因为要访问库存啊，对于下单，基本上是用异步来搞定的。去年双11节，淘宝的每小时的订单数大约在60万左右，京东一天也才能支持40万（居然比12306还差），亚马逊5年前一小时可支持70万订单量。可见，下订单的操作并没有我们相像的那么性能高。
淘宝要比B2C的网站要简单得多，因为没有仓库，所以，不存在像B2C这样有N个仓库对同一商品库存更新和查询的操作。下单的时候，B2C的 网站要去找一个仓库，又要离用户近，又要有库存，这需要很多计算。试想，你在北京买了一本书，北京的仓库没货了，就要从周边的仓库调，那就要去看看沈阳或 是西安的仓库有没有货，如果没有，又得看看江苏的仓库，等等。淘宝的就没有那么多事了，每个商户有自己的库存，库存分到商户头上了，反而有利于性能。
数据一致性才是真正的性能瓶颈。有 人说nginx可以搞定每秒10万的静态请求，我不怀疑。但这只是静态请求，理论值，只要带宽、I/O够强，服务器计算能力够，并支持的并发连接数顶得住10万TCP链接的建立 的话，那没有问题。但在数据一致性面前，这10万就完完全全成了一个可望不可及的理论值了。
我说那么多，我只是想从业务上告诉大家，我们需要从业务上真正了解春运铁路订票这样业务的变态之处。
前端性能优化技术
要解决性能的问题，有很多种常用的方法，我在下面列举一下，我相信12306这个网站使用下面的这些技术会让其性能有质的飞跃。
一、前端负载均衡
通过DNS的负载均衡器（一般在路由器上根据路由的负载重定向）可以把用户的访问均匀地分散在多个Web服务器上。这样可以减少Web服务器的请求负载。因为http的请求都是短作业，所以，可以通过很简单的负载均衡器来完成这一功能。最好是有CDN网络让用户连接与其最近的服务器（CDN通常伴随着分布式存储）。（关于负载均衡更为详细的说明见“后端的负载均衡”）
二、减少前端链接数
我看了一下12306.cn，打开主页需要建60多个HTTP连接，车票预订页面则有70多个HTTP请求，现在的浏览器都是并发请求的。所以，只要有100万个用户，就会有6000万个链接，太多了。一个登录查询页面就好了。把js打成一个文件，把css也打成一个文件，把图标也打成一个文件，用css分块展示。把链接数减到最低。
三、减少网页大小增加带宽
这个世界不是哪个公司都敢做图片服务的，因为图片太耗带宽了。现在宽带时代很难有人能体会到当拨号时代做个图页都不敢用图片的情形（现在在手机端浏览也是这个情形）。我查看了一下12306首页的需要下载的总文件大小大约在900KB左右，如果你访问过了，浏览器会帮你缓存很多，只需下载10K左右的文件。但是我们可以想像一个极端一点的案例，1百万用户同时访问，且都是第一次访问，每人下载量需要1M，如果需要在120秒内返回，那么就需要，1M * 1M /120 * 8 = 66Gbps的带宽。很惊人吧。所以，我估计在当天，12306的阻塞基本上应该是网络带宽，所以，你可能看到的是没有响应。后面随着浏览器的缓存帮助12306减少很多带宽占用，于是负载一下就到了后端，后端的数据处理瓶颈一下就出来。于是你会看到很多http 500之类的错误。这说明服务器垮了。
四、前端页面静态化
静态化一些不常变的页面和数据，并gzip一下。还有一个并态的方法是把这些静态页面放在/dev/shm下，这个目录就是内存，直接从内存中把文件读出来返回，这样可以减少昂贵的磁盘I/O。
五、优化查询
很多人查询都是在查一样的，完全可以用反向代理合并这些并发的相同的查询。这样的技术主要用查询结果缓存来实现，第一次查询走数据库获得数据，并把数据放到缓存，后面的查询统统直接访问高速缓存。为每个查询做Hash，使用NoSQL的技术可以完成这个优化。（这个技术也可以用做静态页面）
对于火车票量的查询，个人觉得不要显示数字，就显示一个“有”或“无”就好了，这样可以大大简化系统复杂度，并提升性能。
六、缓存的问题
缓存可以用来缓存动态页面，也可以用来缓存查询的数据。缓存通常有那么几个问题：
1）缓存的更新。也叫缓存和数据库的同步。有这么几种方法，一是缓存time out，让缓存失效，重查，二是，由后端通知更新，一量后端发生变化，通知前端更新。前者实现起来比较简单，但实时性不高，后者实现起来比较复杂 ，但实时性高。
2）缓存的换页。内存可能不够，所以，需要把一些不活跃的数据换出内存，这个和操作系统的内存换页和交换内存很相似。FIFO、LRU、LFU都是比较经典的换页算法。相关内容参看Wikipeida的缓存算法。
3）缓存的重建和持久化。缓存在内存，系统总要维护，所以，缓存就会丢失，如果缓存没了，就需要重建，如果数据量很大，缓存重建的过程会很慢，这会影响生产环境，所以，缓存的持久化也是需要考虑的。
诸多强大的NoSQL都很好支持了上述三大缓存的问题。
后端性能优化技术
前面讨论了前端性能的优化技术，于是前端可能就不是瓶颈问题了。那么性能问题就会到后端数据上来了。下面说几个后端常见的性能优化技术。
一、数据冗余
关于数据冗余，也就是说，把我们的数据库的数据冗余处理，也就是减少表连接这样的开销比较大的操作，但这样会牺牲数据的一致性。风险比较大。很多人把NoSQL用做数据，快是快了，因为数据冗余了，但这对数据一致性有大的风险。这需要根据不同的业务进行分析和处理。（注意：用关系型数据库很容易移植到NoSQL上，但是反过来从NoSQL到关系型就难了）
二、数据镜像
几乎所有主流的数据库都支持镜像，也就是replication。数据库的镜像带来的好处就是可以做负载均衡。把一台数据库的负载均分到多台上，同时又保证了数据一致性（Oracle的SCN）。最重要的是，这样还可以有高可用性，一台废了，还有另一台在服务。
数据镜像的数据一致性可能是个复杂的问题，所以我们要在单条数据上进行数据分区，也就是说，把一个畅销商品的库存均分到不同的服务器上，如，一个畅销商品有1万的库存，我们可以设置10台服务器，每台服务器上有1000个库存，这就好像B2C的仓库一样。
三、数据分区
数据镜像不能解决的一个问题就是数据表里的记录太多，导致数据库操作太慢。所以，把数据分区。数据分区有很多种做法，一般来说有下面这几种：
1）把数据把某种逻辑来分类。比如火车票的订票系统可以按各铁路局来分，可按各种车型分，可以按始发站分，可以按目的地分……，反正就是把一张表拆成多张有一样的字段但是不同种类的表，这样，这些表就可以存在不同的机器上以达到分担负载的目的。
2）把数据按字段分，也就是竖着分表。比如把一些不经常改的数据放在一个表里，经常改的数据放在另外多个表里。把一张表变成1对1的关系，这样，你可以减少表的字段个数，同样可以提升一定的性能。另外，字段多会造成一条记录的存储会被放到不同的页表里，这对于读写性能都有问题。但这样一来会有很多复杂的控制。
3）平均分表。因为第一种方法是并不一定平均分均，可能某个种类的数据还是很多。所以，也有采用平均分配的方式，通过主键ID的范围来分表。
4）同一数据分区。这个在上面数据镜像提过。也就是把同一商品的库存值分到不同的服务器上，比如有10000个库存，可以分到10台服务器上，一台上有1000个库存。然后负载均衡。
这三种分区都有好有坏。最常用的还是第一种。数据一旦分区，你就需要有一个或是多个调度来让你的前端程序知道去哪里找数据。把火车票的数据分区，并放在各个省市，会对12306这个系统有非常有意义的质的性能的提高。
四、后端系统负载均衡
前面说了数据分区，数据分区可以在一定程度上减轻负载，但是无法减轻热销商品的负载，对于火车票来说，可以认为是大城市的某些主干线上的车票。这就需要使用数据镜像来减轻负载。使用数据镜像，你必然要使用负载均衡，在后端，我们可能很难使用像路由器上的负载均衡器，因为那是均衡流量的，因为流量并不代表服务器的繁忙程度。因此，我们需要一个任务分配系统，其还能监控各个服务器的负载情况。
任务分配服务器有一些难点：
负载情况比较复杂。什么叫忙？是CPU高？还是磁盘I/O高？还是内存使用高？还是并发高？还是内存换页率高？你可能需要全部都要考虑。这些信息要发送给那个任务分配器上，由任务分配器挑选一台负载最轻的服务器来处理。
任务分配服务器上需要对任务队列，不能丢任务啊，所以还需要持久化。并且可以以批量的方式把任务分配给计算服务器。
任务分配服务器死了怎么办？这里需要一些如Live-Standby或是failover等高可用性的技术。我们还需要注意那些持久化了的任务的队列如何转移到别的服务器上的问题。
我看到有很多系统都用静态的方式来分配，有的用hash，有的就简单地轮流分析。这些都不够好，一个是不能完美地负载均衡，另一个静态的方法的致命缺陷是，如果有一台计算服务器死机了，或是我们需要加入新的服务器，对于我们的分配器来说，都需要知道的。
还有一种方法是使用抢占式的方式进行负载均衡，由下游的计算服务器去任务服务器上拿任务。让这些计算服务器自己决定自己是否要任务。这样的好处是可以简化系统的复杂度，而且还可以任意实时地减少或增加计算服务器。但是唯一不好的就是，如果有一些任务只能在某种服务器上处理，这可能会引入一些复杂度。不过总体来说，这种方法可能是比较好的负载均衡。
五、异步、 throttle 和 批量处理
异步、throttle（节流阀） 和批量处理都需要对并发请求数做队列处理的。
异步在业务上一般来说就是收集请求，然后延时处理。在技术上就是可以把各个处理程序做成并行的，也就可以水平扩展了。但是异步的技术问题大概有这些，a）被调用方的结果返回，会涉及进程线程间通信的问题。b）如果程序需要回滚，回滚会有点复杂。c）异步通常都会伴随多线程多进程，并发的控制也相对麻烦一些。d）很多异步系统都用消息机制，消息的丢失和乱序也会是比较复杂的问题。
throttle 技术其实并不提升性能，这个技术主要是防止系统被超过自己不能处理的流量给搞垮了，这其实是个保护机制。使用throttle技术一般来说是对于一些自己无法控制的系统，比如，和你网站对接的银行系统。
批量处理的技术，是把一堆基本相同的请求批量处理。比如，大家同时购买同一个商品，没有必要你买一个我就写一次数据库，完全可以收集到一定数量的请求，一次操作。这个技术可以用作很多方面。比如节省网络带宽，我们都知道网络上的MTU（最大传输单元），以态网是1500字节，光纤可以达到4000多个字节，如果你的一个网络包没有放满这个MTU，那就是在浪费网络带宽，因为网卡的驱动程序只有一块一块地读效率才会高。因此，网络发包时，我们需要收集到足够多的信息后再做网络I/O，这也是一种批量处理的方式。批量处理的敌人是流量低，所以，批量处理的系统一般都会设置上两个阀值，一个是作业量，另一个是timeout，只要有一个条件满足，就会开始提交处理。
所以，只要是异步，一般都会有throttle机制，一般都会有队列来排队，有队列，就会有持久化，而系统一般都会使用批量的方式来处理。
云风同学设计的“排队系统” 就是这个技术。这和电子商务的订单系统很相似，就是说，我的系统收到了你的购票下单请求，但是我还没有真正处理，我的系统会跟据我自己的处理能力来throttle住这些大量的请求，并一点一点地处理。一旦处理完成，我就可以发邮件或短信告诉用户你来可以真正购票了。
在这里，我想通过业务和用户需求方面讨论一下云风同学的这个排队系统，因为其从技术上看似解决了这个问题，但是从业务和用户需求上来说可能还是有一些值得我们去深入思考的地方：
1）队列的DoS攻击。首先，我们思考一下，这个队是个单纯地排队的吗？这样做还不够好，因为这样我们不能杜绝黄牛，而且单纯的ticket_id很容易发生DoS攻击，比如，我发起N个 ticket_id，进入购票流程后，我不买，我就耗你半个小时，很容易我就可以让想买票的人几天都买不到票。有人说，用户应该要用身份证来排队， 这样在购买里就必需要用这个身份证来买，但这也还不能杜绝黄牛排队或是号贩子。因为他们可以注册N个帐号来排队，但就是不买。黄牛这些人这个时候只需要干一个事，把网站搞得正常人不能访问，让用户只能通过他们来买。
2）对列的一致性？对这个队列的操作是不是需要锁？只要有锁，性能一定上不去。试想，100万个人同时要求你来分配位置号，这个队列将会成为性能瓶颈。你一定没有数据库实现得性能好，所以，可能比现在还差
3）队列的等待时间。购票时间半小时够不够？多不多？要是那时用户正好不能上网呢？如果时间短了，用户不够时间操作也会抱怨，如果时间长了，后面在排队的那些人也会抱怨。这个方法可能在实际操作上会有很多问题。另外，半个小时太长了，这完全不现实，我们用15分钟来举例：有1千万用户，每一个时刻只能放进去1万个，这1万个用户需要15分钟完成所有操作，那么，这1千万用户全部处理完，需要1000*15m = 250小时，10天半，火车早开了。（我并非乱说，根据铁道部专家的说明：这几天，平均一天下单100万，所以，处理1000万的用户需要十天。这个计算可能有点简单了，我只是想说，在这样低负载的系统下用排队可能都不能解决问题）
4）队列的分布式。这个排队系统只有一个队列好吗？还不足够好。因为，如果你放进去的可以购票的人如果在买同一个车次的同样的类型的票（比如某动车卧铺），还是等于在抢票，也就是说系统的负载还是会有可能集中到其中某台服务器上。因此，最好的方法是根据用户的需求——提供出发地和目的地，来对用户进行排队。而这样一来，队列也就可以是多个，只要是多个队列，就可以水平扩展了。
我觉得完全可以向网上购物学习。在排队（下单）的时候，收集好用户的信息和想要买的票，并允许用户设置购票的优先级，比如，A车次卧铺买 不到就买 B车次的卧铺，如果还买不到就买硬座等等，然后用户把所需的钱先充值好，接下来就是系统完全自动地异步处理订单。成功不成功都发短信或邮件通知用户。这样，系统不仅可以省去那半个小时的用户交互时间，自动化加快处理，还可以合并相同购票请求的人，进行批处理（减少数据库的操作次数）。这种方法最妙的事是可以知道这些排队用户的需求，不但可以优化用户的队列，把用户分布到不同的队列，还可以像亚马逊的心愿单一样，让铁道部做车次统筹安排和调整（最后，排队系统（下单系统）还是要保存在数据库里的或做持久化，不能只放在内存中，不然机器一down，就等着被骂吧）。
小结
写了那么多，我小结一下：
0）无论你怎么设计，你的系统一定要能容易地水平扩展。也就是说，你的整个数据流中，所有的环节都要能够水平扩展。这样，当你的系统有性能问题时，“加3倍的服务器”才不会被人讥笑。
1）上述的技术不是一朝一夕能搞定的，没有长期的积累，基本无望。我们可以看到，无论你用哪种都会引发一些复杂性。
2）集中式的卖票很难搞定，使用上述的技术可以让订票系统能有几佰倍的性能提升。而在各个省市建分站，分开卖票，是能让现有系统性能有质的提升的最好方法。
3）春运前夕抢票且票量供远小于求这种业务模式是相当变态的，让几千万甚至上亿的人在某个早晨的8点钟同时登录同时抢票的这种业务模式是变态中的变态。业务形态的变态决定了无论他们怎么办干一定会被骂。
4）为了那么一两个星期而搞那么大的系统，而其它时间都在闲着，有些可惜了，这也就是铁路才干得出来这样的事了。
http://coolshell.cn/articles/6470.html
12306.cn网站挂了，被全国人民骂了。我这两天也在思考这个事，我想以这个事来粗略地和大家讨论一下网站性能的问题。因为仓促，而且完全基于本人有限的经验和了解，所以，如果有什么问题还请大家一起讨论和指正。（这又是一篇长文，只讨论性能问题，不讨论那些UI，用户体验，或是是否把支付和购票下单环节分开的功能性的东西）
业务
任何技术都离不开业务需求，所以，要说明性能问题，首先还是想先说说业务问题。
其一，有人可能把这个东西和QQ或是网游相比。但我觉得这两者是不一样的，网游和QQ在线或是登录时访问的更多的是用户自己的数据，而订票系统访问的是中心的票量数据，这是不一样的。不要觉得网游或是QQ能行你就以为这是一样的。网游和QQ 的后端负载相对于电子商务的系统还是简单。
其二，有人说春节期间订火车的这个事好像网站的秒杀活动。的确很相似，但是如果你的思考不在表面的话，你会发现这也有些不一样。火车票这个事，还有很多查询操作，查时间，查座位，查铺位，一个车次不 行，又查另一个车次，其伴随着大量的查询操作，下单的时候需要对数据库操作。而秒杀，直接杀就好了。另外，关于秒杀，完全可以做成只接受前N个用户的请求（完全不操作后端的任何数据， 仅仅只是对用户的下单操作log），这种业务，只要把各个服务器的时间精确同步了就可以了，无需在当时操作任何数据库。可以订单数够后，停止秒杀，然后批量写数据库。火车票这个岂止是秒杀那么简单。能不能买到票得当时告诉用户啊。
其三，有人拿这个系统和奥运会的票务系统比较。我觉得还是不一样。虽然奥运会的票务系统当年也一上线就废了。但是奥运会用的是抽奖的方式，也就是说不存在先来先得的抢的方式，而且，是事后抽奖，事前只需要收信息，事前不需要保证数据一致性，没有锁，很容易水平扩展。
其四，订票系统应该和电子商务的订单系统很相似，都是需要对库存进行：1）占住库存，2）支付（可选），3）扣除库存的操作。这个是需要有一致性的检查的，也就是在并发时需要对数据加锁的。B2C的电商基本上都会把这个事干成异步的，也就是说，你下的订单并不是马上处理的，而是延时处理的，只有成功处理了，系统才会给你一封确认邮件说是订单成功。我相信有很多朋友都收到认单不成功的邮件。这就是说，数据一致性在并发下是一个瓶颈。
其五，铁路的票务业务很变态，其采用的是突然放票，而有的票又远远不够大家分，所以，大家才会有抢票这种有中国特色的业务的做法。于是当票放出来的时候，就会有几百万人甚至上千万人杀上去，查询，下单。几十分钟内，一个网站能接受几千万的访问量，这个是很恐怖的事情。据说12306的高峰访问是10亿PV，集中在早8点到10点，每秒PV在高峰时上千万。
多说几句：
库存是B2C的恶梦，库存管理相当的复杂。不信，你可以问问所有传统和电务零售业的企业，看看他们管理库存是多么难的一件事。不然，就不会有那么多人在问凡客的库存问题了。（你还可以看看《乔布斯传》，你就知道为什么Tim会接任Apple的CEO了，因为他搞定了苹果的库存问题）
对于一个网站来说，浏览网页的高负载很容易搞定，查询的负载有一定的难度去处理，不过还是可以通过缓存查询结果来搞定，最难的就是下单的负载。因为要访问库存啊，对于下单，基本上是用异步来搞定的。去年双11节，淘宝的每小时的订单数大约在60万左右，京东一天也才能支持40万（居然比12306还差），亚马逊5年前一小时可支持70万订单量。可见，下订单的操作并没有我们相像的那么性能高。
淘宝要比B2C的网站要简单得多，因为没有仓库，所以，不存在像B2C这样有N个仓库对同一商品库存更新和查询的操作。下单的时候，B2C的 网站要去找一个仓库，又要离用户近，又要有库存，这需要很多计算。试想，你在北京买了一本书，北京的仓库没货了，就要从周边的仓库调，那就要去看看沈阳或 是西安的仓库有没有货，如果没有，又得看看江苏的仓库，等等。淘宝的就没有那么多事了，每个商户有自己的库存，库存分到商户头上了，反而有利于性能。
数据一致性才是真正的性能瓶颈。有 人说nginx可以搞定每秒10万的静态请求，我不怀疑。但这只是静态请求，理论值，只要带宽、I/O够强，服务器计算能力够，并支持的并发连接数顶得住10万TCP链接的建立 的话，那没有问题。但在数据一致性面前，这10万就完完全全成了一个可望不可及的理论值了。
我说那么多，我只是想从业务上告诉大家，我们需要从业务上真正了解春运铁路订票这样业务的变态之处。
前端性能优化技术
要解决性能的问题，有很多种常用的方法，我在下面列举一下，我相信12306这个网站使用下面的这些技术会让其性能有质的飞跃。
一、前端负载均衡
通过DNS的负载均衡器（一般在路由器上根据路由的负载重定向）可以把用户的访问均匀地分散在多个Web服务器上。这样可以减少Web服务器的请求负载。因为http的请求都是短作业，所以，可以通过很简单的负载均衡器来完成这一功能。最好是有CDN网络让用户连接与其最近的服务器（CDN通常伴随着分布式存储）。（关于负载均衡更为详细的说明见“后端的负载均衡”）
二、减少前端链接数
我看了一下12306.cn，打开主页需要建60多个HTTP连接，车票预订页面则有70多个HTTP请求，现在的浏览器都是并发请求的。所以，只要有100万个用户，就会有6000万个链接，太多了。一个登录查询页面就好了。把js打成一个文件，把css也打成一个文件，把图标也打成一个文件，用css分块展示。把链接数减到最低。
三、减少网页大小增加带宽
这个世界不是哪个公司都敢做图片服务的，因为图片太耗带宽了。现在宽带时代很难有人能体会到当拨号时代做个图页都不敢用图片的情形（现在在手机端浏览也是这个情形）。我查看了一下12306首页的需要下载的总文件大小大约在900KB左右，如果你访问过了，浏览器会帮你缓存很多，只需下载10K左右的文件。但是我们可以想像一个极端一点的案例，1百万用户同时访问，且都是第一次访问，每人下载量需要1M，如果需要在120秒内返回，那么就需要，1M * 1M /120 * 8 = 66Gbps的带宽。很惊人吧。所以，我估计在当天，12306的阻塞基本上应该是网络带宽，所以，你可能看到的是没有响应。后面随着浏览器的缓存帮助12306减少很多带宽占用，于是负载一下就到了后端，后端的数据处理瓶颈一下就出来。于是你会看到很多http 500之类的错误。这说明服务器垮了。
四、前端页面静态化
静态化一些不常变的页面和数据，并gzip一下。还有一个并态的方法是把这些静态页面放在/dev/shm下，这个目录就是内存，直接从内存中把文件读出来返回，这样可以减少昂贵的磁盘I/O。
五、优化查询
很多人查询都是在查一样的，完全可以用反向代理合并这些并发的相同的查询。这样的技术主要用查询结果缓存来实现，第一次查询走数据库获得数据，并把数据放到缓存，后面的查询统统直接访问高速缓存。为每个查询做Hash，使用NoSQL的技术可以完成这个优化。（这个技术也可以用做静态页面）
对于火车票量的查询，个人觉得不要显示数字，就显示一个“有”或“无”就好了，这样可以大大简化系统复杂度，并提升性能。
六、缓存的问题
缓存可以用来缓存动态页面，也可以用来缓存查询的数据。缓存通常有那么几个问题：
1）缓存的更新。也叫缓存和数据库的同步。有这么几种方法，一是缓存time out，让缓存失效，重查，二是，由后端通知更新，一量后端发生变化，通知前端更新。前者实现起来比较简单，但实时性不高，后者实现起来比较复杂 ，但实时性高。
2）缓存的换页。内存可能不够，所以，需要把一些不活跃的数据换出内存，这个和操作系统的内存换页和交换内存很相似。FIFO、LRU、LFU都是比较经典的换页算法。相关内容参看Wikipeida的缓存算法。
3）缓存的重建和持久化。缓存在内存，系统总要维护，所以，缓存就会丢失，如果缓存没了，就需要重建，如果数据量很大，缓存重建的过程会很慢，这会影响生产环境，所以，缓存的持久化也是需要考虑的。
诸多强大的NoSQL都很好支持了上述三大缓存的问题。
后端性能优化技术
前面讨论了前端性能的优化技术，于是前端可能就不是瓶颈问题了。那么性能问题就会到后端数据上来了。下面说几个后端常见的性能优化技术。
一、数据冗余
关于数据冗余，也就是说，把我们的数据库的数据冗余处理，也就是减少表连接这样的开销比较大的操作，但这样会牺牲数据的一致性。风险比较大。很多人把NoSQL用做数据，快是快了，因为数据冗余了，但这对数据一致性有大的风险。这需要根据不同的业务进行分析和处理。（注意：用关系型数据库很容易移植到NoSQL上，但是反过来从NoSQL到关系型就难了）
二、数据镜像
几乎所有主流的数据库都支持镜像，也就是replication。数据库的镜像带来的好处就是可以做负载均衡。把一台数据库的负载均分到多台上，同时又保证了数据一致性（Oracle的SCN）。最重要的是，这样还可以有高可用性，一台废了，还有另一台在服务。
数据镜像的数据一致性可能是个复杂的问题，所以我们要在单条数据上进行数据分区，也就是说，把一个畅销商品的库存均分到不同的服务器上，如，一个畅销商品有1万的库存，我们可以设置10台服务器，每台服务器上有1000个库存，这就好像B2C的仓库一样。
三、数据分区
数据镜像不能解决的一个问题就是数据表里的记录太多，导致数据库操作太慢。所以，把数据分区。数据分区有很多种做法，一般来说有下面这几种：
1）把数据把某种逻辑来分类。比如火车票的订票系统可以按各铁路局来分，可按各种车型分，可以按始发站分，可以按目的地分……，反正就是把一张表拆成多张有一样的字段但是不同种类的表，这样，这些表就可以存在不同的机器上以达到分担负载的目的。
2）把数据按字段分，也就是竖着分表。比如把一些不经常改的数据放在一个表里，经常改的数据放在另外多个表里。把一张表变成1对1的关系，这样，你可以减少表的字段个数，同样可以提升一定的性能。另外，字段多会造成一条记录的存储会被放到不同的页表里，这对于读写性能都有问题。但这样一来会有很多复杂的控制。
3）平均分表。因为第一种方法是并不一定平均分均，可能某个种类的数据还是很多。所以，也有采用平均分配的方式，通过主键ID的范围来分表。
4）同一数据分区。这个在上面数据镜像提过。也就是把同一商品的库存值分到不同的服务器上，比如有10000个库存，可以分到10台服务器上，一台上有1000个库存。然后负载均衡。
这三种分区都有好有坏。最常用的还是第一种。数据一旦分区，你就需要有一个或是多个调度来让你的前端程序知道去哪里找数据。把火车票的数据分区，并放在各个省市，会对12306这个系统有非常有意义的质的性能的提高。
四、后端系统负载均衡
前面说了数据分区，数据分区可以在一定程度上减轻负载，但是无法减轻热销商品的负载，对于火车票来说，可以认为是大城市的某些主干线上的车票。这就需要使用数据镜像来减轻负载。使用数据镜像，你必然要使用负载均衡，在后端，我们可能很难使用像路由器上的负载均衡器，因为那是均衡流量的，因为流量并不代表服务器的繁忙程度。因此，我们需要一个任务分配系统，其还能监控各个服务器的负载情况。
任务分配服务器有一些难点：
负载情况比较复杂。什么叫忙？是CPU高？还是磁盘I/O高？还是内存使用高？还是并发高？还是内存换页率高？你可能需要全部都要考虑。这些信息要发送给那个任务分配器上，由任务分配器挑选一台负载最轻的服务器来处理。
任务分配服务器上需要对任务队列，不能丢任务啊，所以还需要持久化。并且可以以批量的方式把任务分配给计算服务器。
任务分配服务器死了怎么办？这里需要一些如Live-Standby或是failover等高可用性的技术。我们还需要注意那些持久化了的任务的队列如何转移到别的服务器上的问题。
我看到有很多系统都用静态的方式来分配，有的用hash，有的就简单地轮流分析。这些都不够好，一个是不能完美地负载均衡，另一个静态的方法的致命缺陷是，如果有一台计算服务器死机了，或是我们需要加入新的服务器，对于我们的分配器来说，都需要知道的。
还有一种方法是使用抢占式的方式进行负载均衡，由下游的计算服务器去任务服务器上拿任务。让这些计算服务器自己决定自己是否要任务。这样的好处是可以简化系统的复杂度，而且还可以任意实时地减少或增加计算服务器。但是唯一不好的就是，如果有一些任务只能在某种服务器上处理，这可能会引入一些复杂度。不过总体来说，这种方法可能是比较好的负载均衡。
五、异步、 throttle 和 批量处理
异步、throttle（节流阀） 和批量处理都需要对并发请求数做队列处理的。
异步在业务上一般来说就是收集请求，然后延时处理。在技术上就是可以把各个处理程序做成并行的，也就可以水平扩展了。但是异步的技术问题大概有这些，a）被调用方的结果返回，会涉及进程线程间通信的问题。b）如果程序需要回滚，回滚会有点复杂。c）异步通常都会伴随多线程多进程，并发的控制也相对麻烦一些。d）很多异步系统都用消息机制，消息的丢失和乱序也会是比较复杂的问题。
throttle 技术其实并不提升性能，这个技术主要是防止系统被超过自己不能处理的流量给搞垮了，这其实是个保护机制。使用throttle技术一般来说是对于一些自己无法控制的系统，比如，和你网站对接的银行系统。
批量处理的技术，是把一堆基本相同的请求批量处理。比如，大家同时购买同一个商品，没有必要你买一个我就写一次数据库，完全可以收集到一定数量的请求，一次操作。这个技术可以用作很多方面。比如节省网络带宽，我们都知道网络上的MTU（最大传输单元），以态网是1500字节，光纤可以达到4000多个字节，如果你的一个网络包没有放满这个MTU，那就是在浪费网络带宽，因为网卡的驱动程序只有一块一块地读效率才会高。因此，网络发包时，我们需要收集到足够多的信息后再做网络I/O，这也是一种批量处理的方式。批量处理的敌人是流量低，所以，批量处理的系统一般都会设置上两个阀值，一个是作业量，另一个是timeout，只要有一个条件满足，就会开始提交处理。
所以，只要是异步，一般都会有throttle机制，一般都会有队列来排队，有队列，就会有持久化，而系统一般都会使用批量的方式来处理。
云风同学设计的“排队系统” 就是这个技术。这和电子商务的订单系统很相似，就是说，我的系统收到了你的购票下单请求，但是我还没有真正处理，我的系统会跟据我自己的处理能力来throttle住这些大量的请求，并一点一点地处理。一旦处理完成，我就可以发邮件或短信告诉用户你来可以真正购票了。
在这里，我想通过业务和用户需求方面讨论一下云风同学的这个排队系统，因为其从技术上看似解决了这个问题，但是从业务和用户需求上来说可能还是有一些值得我们去深入思考的地方：
1）队列的DoS攻击。首先，我们思考一下，这个队是个单纯地排队的吗？这样做还不够好，因为这样我们不能杜绝黄牛，而且单纯的ticket_id很容易发生DoS攻击，比如，我发起N个 ticket_id，进入购票流程后，我不买，我就耗你半个小时，很容易我就可以让想买票的人几天都买不到票。有人说，用户应该要用身份证来排队， 这样在购买里就必需要用这个身份证来买，但这也还不能杜绝黄牛排队或是号贩子。因为他们可以注册N个帐号来排队，但就是不买。黄牛这些人这个时候只需要干一个事，把网站搞得正常人不能访问，让用户只能通过他们来买。
2）对列的一致性？对这个队列的操作是不是需要锁？只要有锁，性能一定上不去。试想，100万个人同时要求你来分配位置号，这个队列将会成为性能瓶颈。你一定没有数据库实现得性能好，所以，可能比现在还差
3）队列的等待时间。购票时间半小时够不够？多不多？要是那时用户正好不能上网呢？如果时间短了，用户不够时间操作也会抱怨，如果时间长了，后面在排队的那些人也会抱怨。这个方法可能在实际操作上会有很多问题。另外，半个小时太长了，这完全不现实，我们用15分钟来举例：有1千万用户，每一个时刻只能放进去1万个，这1万个用户需要15分钟完成所有操作，那么，这1千万用户全部处理完，需要1000*15m = 250小时，10天半，火车早开了。（我并非乱说，根据铁道部专家的说明：这几天，平均一天下单100万，所以，处理1000万的用户需要十天。这个计算可能有点简单了，我只是想说，在这样低负载的系统下用排队可能都不能解决问题）
4）队列的分布式。这个排队系统只有一个队列好吗？还不足够好。因为，如果你放进去的可以购票的人如果在买同一个车次的同样的类型的票（比如某动车卧铺），还是等于在抢票，也就是说系统的负载还是会有可能集中到其中某台服务器上。因此，最好的方法是根据用户的需求——提供出发地和目的地，来对用户进行排队。而这样一来，队列也就可以是多个，只要是多个队列，就可以水平扩展了。
我觉得完全可以向网上购物学习。在排队（下单）的时候，收集好用户的信息和想要买的票，并允许用户设置购票的优先级，比如，A车次卧铺买 不到就买 B车次的卧铺，如果还买不到就买硬座等等，然后用户把所需的钱先充值好，接下来就是系统完全自动地异步处理订单。成功不成功都发短信或邮件通知用户。这样，系统不仅可以省去那半个小时的用户交互时间，自动化加快处理，还可以合并相同购票请求的人，进行批处理（减少数据库的操作次数）。这种方法最妙的事是可以知道这些排队用户的需求，不但可以优化用户的队列，把用户分布到不同的队列，还可以像亚马逊的心愿单一样，让铁道部做车次统筹安排和调整（最后，排队系统（下单系统）还是要保存在数据库里的或做持久化，不能只放在内存中，不然机器一down，就等着被骂吧）。
小结
写了那么多，我小结一下：
0）无论你怎么设计，你的系统一定要能容易地水平扩展。也就是说，你的整个数据流中，所有的环节都要能够水平扩展。这样，当你的系统有性能问题时，“加3倍的服务器”才不会被人讥笑。
1）上述的技术不是一朝一夕能搞定的，没有长期的积累，基本无望。我们可以看到，无论你用哪种都会引发一些复杂性。
2）集中式的卖票很难搞定，使用上述的技术可以让订票系统能有几佰倍的性能提升。而在各个省市建分站，分开卖票，是能让现有系统性能有质的提升的最好方法。
3）春运前夕抢票且票量供远小于求这种业务模式是相当变态的，让几千万甚至上亿的人在某个早晨的8点钟同时登录同时抢票的这种业务模式是变态中的变态。业务形态的变态决定了无论他们怎么办干一定会被骂。
4）为了那么一两个星期而搞那么大的系统，而其它时间都在闲着，有些可惜了，这也就是铁路才干得出来这样的事了。
http://coolshell.cn/articles/6470.html
哎呦，忍不住说几句，我是18日那天买29日傍晚的票，因为有小孩，想买卧铺，早早的9点半登陆，等待10点放票，看着校时网站10点准时刷，没有票，继续刷，一直到10点10分不到点突然显示有票，点预订，提示登陆时间过长，要重新登陆，然后一直登陆不了，提示用户过来，一直尝试登陆，几十下以后进去了，整个网站非常慢，预订，填好资料，提交订单，提示正在处理请稍后，下面有一行“请到未完成订单查看”，我等了1分多种没反应，就点了下面的那行“未完成订单”，结果说我没有未完成订单，继续重复订票，提交订单后一片空白，我想要么刚才提交过的缘故，再返回未完成订单，还是没有，中间每打开一个网页都非常慢。难道要重新登陆，管理窗口，重新来，就一直登陆不了，继续试，很长时间后终于登陆，显示只有18张票了，点预订，提示系统忙，确认订单状态再继续，再去查看未完成订单，没有，再去订票，已经没有票了，时间也已经快到12点了，整个上午就为了这个事情弄得心情很糟糕，结果还是没有买到票，你去肯爹吧，那时要是知道电话好订，早打电话了，去年的时候试过电话订票，就没对电话订票抱希望了。
后来到下午3点样子，网站的速度可以接受了，看到傍午的卧铺显示有2张，一行3人，决定买2个卧铺，1张硬座，订单提交后说等待时间大于半小时，等啊等啊，等到5点30，开始半小时倒计时，期间也不断的延后，终于处理了，结果一行3人，只有一张硬座成功，只好取消。断然决定29日请一天假，买早上的票，这次比较顺利，等了4分钟，买到票了。
你说为了买票，花了多少尽力，可气的是明明订单提交了，却没有，如果说我晚了排队没排上，还可以接受，明明是那个时段还有票的，这个破网站的问题，导致订不上票，无力吐槽了。。。
后来到下午3点样子，网站的速度可以接受了，看到傍午的卧铺显示有2张，一行3人，决定买2个卧铺，1张硬座，订单提交后说等待时间大于半小时，等啊等啊，等到5点30，开始半小时倒计时，期间也不断的延后，终于处理了，结果一行3人，只有一张硬座成功，只好取消。断然决定29日请一天假，买早上的票，这次比较顺利，等了4分钟，买到票了。
你说为了买票，花了多少尽力，可气的是明明订单提交了，却没有，如果说我晚了排队没排上，还可以接受，明明是那个时段还有票的，这个破网站的问题，导致订不上票，无力吐槽了。。。
我才是忘情 发表于 2012-9-21 06:06 ![]()
一样是有100人买不到票，只要买不到，就一定会吐槽，只是由头不一样而已，结果都一样。现在你们说还是以前 ...
问题是见得比就系统好？同样登陆不了，同样中途状态百出，同样眼睁睁的看着余票变为无。
刚才的回复要审核，等会出来，你看看我的过程。
一样是有100人买不到票，只要买不到，就一定会吐槽，只是由头不一样而已，结果都一样。现在你们说还是以前 ...
问题是见得比就系统好？同样登陆不了，同样中途状态百出，同样眼睁睁的看着余票变为无。
刚才的回复要审核，等会出来，你看看我的过程。
其实最根本的问题lz已经说了 就是票只有100张却有200人想买票，于是所有的一切就产生了。。。。。
这个和供求关系说不上吧，那你说飞机票就都能解决供求？
我才是忘情 发表于 2012-9-21 06:06 ![]()
一样是有100人买不到票，只要买不到，就一定会吐槽，只是由头不一样而已，结果都一样。现在你们说还是以前 ...
现在的情况是新系统比旧系统更烂，没有进步就不用说了，难道退步了还要表扬吗？
一样是有100人买不到票，只要买不到，就一定会吐槽，只是由头不一样而已，结果都一样。现在你们说还是以前 ...
现在的情况是新系统比旧系统更烂，没有进步就不用说了，难道退步了还要表扬吗？
这就一普通数学问题嘛，买票问题，上个世纪都已经出来了很多经典算法，估计应该是到了中国这个人口基数上发现以前的小概率也不行了。这算法要优化或者彻底改变，中间过渡还是比较麻烦的，也可能是在用这种方法进行是数据摸底。不过不论怎么说这都称不上是个太麻烦的问题，给点时间，应该能解决吧，希望能够催生出新的买票算法模型来。这么久，都记不清这是不是属于图论的内容了。
都网上订票、电话订票，让原来那些代售点喝西北风去？
给21楼提供一个对比数据，腾讯自称自己的最高日访问量是1.6个亿，而12306这几天的最高日访问量是18个亿，是腾讯的11倍多。而且腾讯是24小时访问，12306后半夜维护，实际开放时间是16个小时左右，那些质疑说为什么腾讯能应付大访问量的同学们可以对比一下。
给21楼提供一个对比数据，腾讯自称自己的最高日访问量是1.6个亿，而12306这几天的最高日访问量是18个亿，是 ...
facebook早在2010年正常日pv量就是220亿多，每月7000亿左右，今年月pv曾突破万亿大关
对此一下铁道部的官方数据
铁路运输部门有关负责同志21日在此间对记者解释说，近日正处在中秋和“十一”黄金周售票的高峰期，12306网站日点击量达到14.9亿次(pv量)，在网上发售客票超过今年春运最高值，导致出现网络拥堵、重复排队等现象。对此，铁路部门表示歉意。
中立统计数据
铁道部12306网站日访问量、日页面浏览量
根据 ALEXA 统计数据9月20日估算网站 IP & PV 值，以下数据有一定误差仅供参考(IP:独立IP地址,PV:页面浏览量,PV值>IP值)
网站平均统计 日均 IP 访问量估算 日均 PV 页面浏览量估算
昨日统计值 ≈ 5,840,000 ≈ 21,024,000 （日页面浏览量2100万人次）
近一周平均值 ≈ 2,208,000 ≈ 8,235,840
近一月平均值 ≈ 1,168,000 ≈ 4,461,760
近三月平均值 ≈ 980,800 ≈ 3,864,352
ipad发帖有点慢,问题就是问题，不要持比烂态度，特别是作为铁路职工，说话要有分寸
facebook早在2010年正常日pv量就是220亿多，每月7000亿左右，今年月pv曾突破万亿大关
对此一下铁道部的官方数据
铁路运输部门有关负责同志21日在此间对记者解释说，近日正处在中秋和“十一”黄金周售票的高峰期，12306网站日点击量达到14.9亿次(pv量)，在网上发售客票超过今年春运最高值，导致出现网络拥堵、重复排队等现象。对此，铁路部门表示歉意。
中立统计数据
铁道部12306网站日访问量、日页面浏览量
根据 ALEXA 统计数据9月20日估算网站 IP & PV 值，以下数据有一定误差仅供参考(IP:独立IP地址,PV:页面浏览量,PV值>IP值)
网站平均统计 日均 IP 访问量估算 日均 PV 页面浏览量估算
昨日统计值 ≈ 5,840,000 ≈ 21,024,000 （日页面浏览量2100万人次）
近一周平均值 ≈ 2,208,000 ≈ 8,235,840
近一月平均值 ≈ 1,168,000 ≈ 4,461,760
近三月平均值 ≈ 980,800 ≈ 3,864,352
ipad发帖有点慢,问题就是问题，不要持比烂态度，特别是作为铁路职工，说话要有分寸
访问量多不是关键 问题是库存管理没错 楼上说facebook google什么的是没有可比性的 铁道部这玩意跟淘宝京东当当亚马逊才有可比性 必须保证各方面数据的一致性 亚马逊的全球订单的最高纪录才能勉强跟12306差不多 但是亚马逊的库存不同地区是分开的 12306的压力要大上十几倍
能不能不要不懂装懂……上面先说PV量，发现PV量跟别人不是一个档次上又转进
先说网站的流量统计是以Pageviews和IPUser来作为主要统计对象的，而不是以数据流多少来区分的，就算是以数据流来计算，对于一个像淘宝这样的购物网站来说，以action数据（用户与网页交互动作数据）label数据（事件额外数据）和value数据（事件相关数据）所组成的事件数据总和远远小于网页自身承载的其它数据流，而对于没有大量图片和文字信息的12306来说，流量统计以PV来计就算是客气的了，你以为facebook上的无论是普通浏览还是游戏视频等网页不需要事件数据么，不要以为data stream的计算模式还是800年前的那种将数据元素保存到传统的数据库当中再进行处理，订单数据流的处理？笑话……退一步讲，就算搞不定多终端库存的同步运营操作，改变支撑的方式很多，分布同步操作，将短时并发改成长时间而选用排队也可以理解，可以这排队系统搞了个屁么，没有任何可操作性，反而增加了人群单位时间内点击量（没有其它提示方式只好不停刷新）和处理数据量（比如反复下、撤单），搬石头砸自己脚，而12306自身的处理问题就可可疑了，浏览端没有计算处理，不搞数据库切分，只有一个中央数据库还好意思说并发数据巨大，还有哪家是这么搞的?
还好意思提淘宝，信不信，这事分包给淘宝，淘宝就算现租用别人的云服务器，给同样权限用同样的资金，处理的肯定比铁道部的好的多的多，憋出内伤憋出这么个排队系统，真是不让人骂死不作休……
所以，铁道部迟早要政企分离，大交通部是趋势所为，就这种作派，铁道部迟早把自己作死……
先说网站的流量统计是以Pageviews和IPUser来作为主要统计对象的，而不是以数据流多少来区分的，就算是以数据流来计算，对于一个像淘宝这样的购物网站来说，以action数据（用户与网页交互动作数据）label数据（事件额外数据）和value数据（事件相关数据）所组成的事件数据总和远远小于网页自身承载的其它数据流，而对于没有大量图片和文字信息的12306来说，流量统计以PV来计就算是客气的了，你以为facebook上的无论是普通浏览还是游戏视频等网页不需要事件数据么，不要以为data stream的计算模式还是800年前的那种将数据元素保存到传统的数据库当中再进行处理，订单数据流的处理？笑话……退一步讲，就算搞不定多终端库存的同步运营操作，改变支撑的方式很多，分布同步操作，将短时并发改成长时间而选用排队也可以理解，可以这排队系统搞了个屁么，没有任何可操作性，反而增加了人群单位时间内点击量（没有其它提示方式只好不停刷新）和处理数据量（比如反复下、撤单），搬石头砸自己脚，而12306自身的处理问题就可可疑了，浏览端没有计算处理，不搞数据库切分，只有一个中央数据库还好意思说并发数据巨大，还有哪家是这么搞的?
还好意思提淘宝，信不信，这事分包给淘宝，淘宝就算现租用别人的云服务器，给同样权限用同样的资金，处理的肯定比铁道部的好的多的多，憋出内伤憋出这么个排队系统，真是不让人骂死不作休……
所以，铁道部迟早要政企分离，大交通部是趋势所为，就这种作派，铁道部迟早把自己作死……
即使是分布式数据库或高性能数据库集群，面对海量数据库操作都是很无力的。所谓PV，可以用动态HTML生成(实际上可以看成一种页面缓存的实现机制），其性能支持取决于应用服务器，可以通过负载均衡快速提高。但是数据库操作，不管你做多少集群负载，能够直观提高的还是查询、计算速度，而实际上在海量并发操作时，数据库事务操作的一致性要求导致数据库瓶颈已经转移到了所访问数据文件上了（包括磁盘IO、磁盘数据传输通道）。总而言之，性能优化并非想象中的事，当然受限于自己的见识水平，也许ORACLE、sap、IBM等少数巨头还有更加优化的方案。
至于说数据查询结果缓存，这个是现代数据库管理系统的基本功能，如果学习oracle的话，在最开始的oracle数据库体系机构基础知识中就会介绍到SGA构成，其中最重要的组成部分就是database buffer cache、library cache、dictionary cache等缓存区域，包括SQL语句的缓存、数据库字典的缓存、查询结果的缓存等等。否则现代数据库哪里能够提供如今这么强大的性能。
不管谁做的系统，不管花多少钱，不管性能怎么先进算法怎么优化！
只要没在第一时间买的理想的车票，网上售票系统就是失败的！！
只要没在第一时间买的理想的车票，网上售票系统就是失败的！！
有兄弟说到数据库同步，对于一个实时售票系统来说，如果存在一个总库，那么必然涉及到大量的数据同步，必然涉及到网络性能、计算性能、数据库管理系统锁机制、磁盘IO等等一系列问题。关键在于铁路售票机制本身，如果可以确定的将某条线路售票工作分布到沿线有限个数据库中，那倒是可以做成为多中心处理系统实现区域售票自治，总库仅进行定时同步获取总体情况，这样可以将数据操作和数据流量进行定向分散从而减少瓶颈环节。
包括网格式计算在内的分布式计算行为，从算法上来讲应该都需要将计算任务分割成若干自洽计算单元，而铁路票务发放机制是否支持这样的分割才是关键。
怎么说呢,上周吞了我100多块,却显示购票失败,到现在还没退款给我,这会让人怎么想呢
新排队系统的用户体验比原系统更差
宁愿坐在电脑前数小时刷12306,不愿打个电话或者直接去火车站排队,现在的人啊
网上订票提前12天,车站售票提前10天仅此而已
网上订票提前12天,车站售票提前10天仅此而已