12306挂的最终还是用户体验

原文地址：http://coolshell.cn/articles/6470.html/

编者内容为后续整理内容，黑色较大字体为原文内容

编者：没有任何技术是邪恶的。就算12306.cn是上世纪程序员使用asp+iis3.0+windows 98搞出来的，只要能够处理掉人们对其发起的购票请求，它就是不会被横加指责的。但现况却是，12306.cn在中华13亿人民面前赤裸裸的挂了，一些有技术的人点开源代码查看后又更怒了，再看看12306.cn所谓的身价，那种怒火就变得更加热烈了。也正是所谓近朱者赤近墨者黑，可能高手才会犯的编程问题在这种事情上也会被贬低的猪狗不如。人们会说，看看吧，就是因为你这个错误才导致整个网站这种垃圾表现的。如果要真从技术上来，那么就用等号去比对。有色眼镜要不得。

12306.cn 网站挂了，被全国人民骂了，以这个事来粗略地讨论一下网站性能的问题。这是一篇长文，只讨论性能问题，不讨论那些UI，用户体验，或是是否把支付和购票下单环节分开的功能性的东西。

业务

 

任何技术都离不开业务需求，所以，要说明性能问题，首先还是想先说说业务问题。

• 其一，有人可能把这个东西和QQ或是网游相比。

• 但我觉得这两者是不一样的，网游和QQ在线或是登录时访问的更多的是用户自己的数据，而订票系统访问的是中心的票量数据，这是不一样的。不要觉得网游或是QQ能行你就以为这是一样的。网游和QQ 的后端负载相对于电子商务的系统还是简单。

编者注：这个大标题是一种自问自答的形式。但是有点答非所问的味道。问，只提到了人们把12306.cn这个网站与QQ和网游进行比对这个事情；答，却没有分析出正确的原因、给出针对性的解答。问题明显要比答案包含了太多内容。我也曾经把这个东西和自己常用的网络应用做过比对，比对的原因是我觉得这个东西和我常用的QQ和网游的体验不一样。因为它常用，QQ和网游我也常用。显然原作者已经提及不要和用户体验掺和了.所以，我又进行了一次对比，QQ和网游同时使用的人数也是百万千万级的，他们的服务器就能承受这么多人登陆和在线啊。况且，网游里面是需要处理同时发生的多人移动和交战的。那为什么12306.cn直接被访问的当掉了，我还没有看到购票的页面呢？所以，如果原作者真的要想提人们把12306.cn和QQ和网游进行对比的话，就应该阐述更详细一点。比如：问：有人认为这个东西和QQ和网游一样；答：其实，他们不一样。QQ是QQ，网游是网游，12306.cn是12306.cn，购票是购票。最后再加上一句：明显不是一样的事物，怎么能对比呢？完全是风马牛不相及啊。突然有一天nokia 3100拿在手里明显感觉不爽了，我也很情愿拿他和苹果手机进行对比。但你千万不要告诉我：苹果是苹果，nokia是nokia。 可能有人会对我的表述进行抨击了，原文明明指出QQ访问的是用户的自己的数据，而订票访问的是中心的票量数据。那，访问用户自己的数据和访问中心票量数据有什么不同呢？倘若QQ刚开始，服务器不也是只有一台么？那应该是访问“中心数据”了吧？为什么现在QQ变成访问用户自己的数据了？你12306办不到吗？我提供身份证，够唯一了吧？我提供原籍地址和现住地址，精确了吧？我提供最近三天的出行计划，够详细了吧？为什么12306是访问中心数据不是访问用户自己的数据呢？

 

• 其二，有人说春节期间订火车的这个事好像网站的秒杀活动。

• 的确很相似，但是如果你的思考不在表面的话，你会发现这也有些不一样。火车票这个事，还有很多查询操作，查时间，查座位，查铺位，一个车次不 行，又查另一个车次，其伴随着大量的查询操作，下单的时候需要对数据库操作。而秒杀，直接杀就好了。另外，关于秒杀，完全可以做成只接受前N个用户的请求（完全不操作后端的任何数据， 仅仅只是对用户的下单操作log），这种业务，只要把各个服务器的时间精确同步了就可以了，无需在当时操作任何数据库。可以订单数够后，停止秒杀，然后批量写数据库。火车票这个岂止是秒杀那么简单。能不能买到票得当时告诉用户啊。

  
  

  
  

编者注：由于不能讨论用户体验相关的东西。所以在这里我只能说，秒杀活动到了秒杀这一步，你12306.cn还有好多事情要做啊？咱不能拿买到票的人和千千万万排了半天队没有买到票的人相比吧？这样，不管那个买到票的是不是排队的，比对焦点都落在那张票上了。为什么有人说春节期间订火车票好想秒杀呢？不就是一大堆人抢一点有限资源吗？秒杀能够做的好，所以你12306.cn或许能够借鉴啊，你12306.cn能不能把你查座位、查时间、查车次和购票分开？想查询要什么时间什么车次什么位子的票的请到左边查询，已经取钱要买票的请至右手边，PS：售票系统不提供售票查询功能，请做好思想准备。原作者可能是把这个问题当作凤凰与鸡对比了。你凤凰就是凤凰，我鸡祖祖辈辈都是鸡，怎么变啊？

 

• 其三，有人拿这个系统和奥运会的票务系统比较。

• 我觉得还是不一样。虽然奥运会的票务系统当年也一上线就废了。但是奥运会用的是抽奖的方式，也就是说不存在先来先得的抢的方式，而且，是事后抽奖，事前只需要收信息，事前不需要保证数据一致性，没有锁，很容易水平扩展。

编者又注：人们或许又是在想，既然你跟他这么像，这次给变个凤凰吧。原文指出：就算是老母鸡要生，也是生的鸡蛋。

 

• 其四，订票系统应该和电子商务的订单系统很相似。

• 都是需要对库存进行：1）占住库存，2）支付（可选），3）扣除库存的操作。这个是需要有一致性的检查的，也就是在并发时需要对数据加锁的。B2C的电商基本上都会把这个事干成异步的，也就是说，你下的订单并不是马上处理的，而是延时处理的，只有成功处理了，系统才会给你一封确认邮件说是订单成功。我相信有很多朋友都收到认单不成功的邮件。这就是说，数据一致性在并发下是一个瓶颈。

编者注：这里比对的是接收订单的性能，因为电子商务订单系统接受了用户的订单以后后面就一定是仓库发货用户签收的完整流程了。虽然部分遇到过订单被取消的情况的人不在这个一定是的范围内。但是，这里没有考虑的情况就是，电子商务的仓库是可变的(商场在不停生产，显示给客户的是一个流动库存量，如果商家不赚钱了，当然后面部分订单就失效了)，而订票系统的仓库是不可变的（对某时间某列车的车票，就算铁道部能够生产，也不会出现“合法”的第二张）。所以，两者取消订单的原因不一样，和发生几率也不一样。放在一起对比，不可以。

 

• 其五，铁路的票务业务很变态。

• 其采用的是突然放票，而有的票又远远不够大家分，所以，大家才会有抢票这种有中国特色的业务的做法。于是当票放出来的时候，就会有几百万人甚至上千万人杀上去，查询，下单。几十分钟内，一个网站能接受几千万的访问量，这个是很恐怖的事情。据说12306的高峰访问是10亿PV，集中在早8点到10点，每秒PV在高峰时上千万。

编者注：原作者后面就想要去增加自己的服务器服务能力来处理这种大量的访问请求。所以，这里一点都没有错。变态的瞬时间高并发的访问量，如果不考虑用户体验的话。

 

多说几句：

• 库存是B2C的恶梦，库存管理相当的复杂。

• 不信，你可以问问所有传统和电务零售业的企业，看看他们管理库存是多么难的一件事。不然，就不会有那么多人在问凡客的库存问题了。（你还可以看看《乔布斯传》，你就知道为什么Tim会接任Apple的CEO了，因为他搞定了苹果的库存问题）

编者注：这里不明白的就是什么是相当复杂？传统和电务零售业企业的库存管理难题和12306.cn有关系？或许库存管理真的困难，但是铁道部为什么不能又去养猪？

 

• 对于一个网站来说，浏览网页的高负载很容易搞定，查询的负载有一定的难度去处理，不过还是可以通过缓存查询结果来搞定，最难的就是下单的负载。

• 因为要访问库存啊，对于下单，基本上是用异步来搞定的。去年双11节，淘宝的每小时的订单数大约在60万左右，京东一天也才能支持40万（居然比12306还差），亚马逊5年前一小时可支持70万订单量。可见，下订单的操作并没有我们相像的那么性能高。

编者注：看样子每一个访问库存的请求都要在半路上找王大爷喝杯茶水并聊聊天。我认为，路边王大爷才是扰乱世界和平的罪魁祸首。

 

• 淘宝要比B2C的网站要简单得多，因为没有仓库。

• 所以，不存在像B2C这样有N个仓库对同一商品库存更新和查询的操作。下单的时候，B2C的 网站要去找一个仓库，又要离用户近，又要有库存，这需要很多计算。试想，你在北京买了一本书，北京的仓库没货了，就要从周边的仓库调，那就要去看看沈阳或 是西安的仓库有没有货，如果没有，又得看看江苏的仓库，等等。淘宝的就没有那么多事了，每个商户有自己的库存，库存分到商户头上了，反而有利于性能。

编者注：答案是一个同步答案，谷歌早就不这么干了。要不然，你要查询米国的奥巴马是什么食品，百度要先分析你的查询语句，然后到北京查询（因为人们很关注北京的事态，所以百度很幸运的在北京的服务器上查询到了你可能感兴趣的内容，这样就不用去问候余下几个省市的大姨妈了），在北京查询出这是米国的人后，百度需要穿越国境线找米国，在GFW处受到无理阻挠而恼羞成怒终于在扒光衣服的前提下FQ而出之后跳进了死海，在死海遨游了数小时之后终于找到了第一台陆地上属于刚果共和国的80386架构的服务器....... 你伸出中指叉掉了页面。

 

• 数据一致性才是真正的性能瓶颈。

• 有 人说nginx可以搞定每秒10万的静态请求，我不怀疑。但这只是静态请求，理论值，只要带宽、I/O够强，服务器计算能力够，并支持的并发连接数顶得住10万TCP链接的建立 的话，那没有问题。但在数据一致性面前，这10万就完完全全成了一个可望不可及的理论值了。

编者注：人家都说了nginx能搞定每秒10万的静态请求，你让他去搞数据一致性？你要闹哪样？分明是一个大兵上来对你说：我能耍大刀。你说：很好啊，我们就需要这样的人才，你看那是关公，以后你就在他下面效力了。

 

我说那么多，我只是想从业务上告诉大家，我们需要从业务上真正了解春运铁路订票这样业务的变态之处。

编者注：春运铁路订票这样的业务的确挺变态的，不用分析，但就从这么多人订票又这么多人订不到又这么多人继续使用来看，就知道是一个在程序员史上的丰碑。无论刮风下雨，其自屹立不倒。

 

前端性能优化技术

要解决性能的问题，有很多种常用的方法，我在下面列举一下，我相信12306这个网站使用下面的这些技术会让其性能有质的飞跃。

编者又注：上面的几个问题里面，如果能够通过使用下面技术中的一种和几种来飞跃的话，这篇文章就不复存在了。前面的问题已解决，后面的答案已消失。所以，后面纯技术分析，和12306.cn没有半毛钱的关系。

 

一、前端负载均衡

通过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的技术可以完成这个优化。（这个技术也可以用做静态页面）

对于火车票量的查询，个人觉得不要显示数字，就显示一个“有”或“无”就好了，这样可以大大简化系统复杂度，并提升性能。

编者注：只显示有无是不行的。有的人不是仅仅买一张火车票，如果女朋友不能去我也就不买了。虽然我没有女朋友，但是这种需求由于变态不得不考虑。优化查询应该是优化查询的复杂度，这里偏重凸显优化查询过程中数据缓存的作用了。优化查询的复杂度没有提及：以前你需要联合三张表反复查询100遍，而优化之后能够做到一遍完成，那是非常好的。在web前端，快男是很有市场的。

 

六、缓存的问题

缓存可以用来缓存动态页面，也可以用来缓存查询的数据。缓存通常有那么几个问题：

1）缓存的更新。也叫缓存和数据库的同步。有这么几种方法，一是缓存time out，让缓存失效，重查，二是，由后端通知更新，一量后端发生变化，通知前端更新。前者实现起来比较简单，但实时性不高，后者实现起来比较复杂 ，但实时性高。

2）缓存的换页。内存可能不够，所以，需要把一些不活跃的数据换出内存，这个和操作系统的内存换页和交换内存很相似。FIFO、LRU、LFU都是比较经典的换页算法。相关内容参看Wikipeida的缓存算法。

3）缓存的重建和持久化。缓存在内存，系统总要维护，所以，缓存就会丢失，如果缓存没了，就需要重建，如果数据量很大，缓存重建的过程会很慢，这会影响生产环境，所以，缓存的持久化也是需要考虑的。

诸多强大的NoSQL都很好支持了上述三大缓存的问题。

编者注：由于没有和12306.cn扯上半毛钱关系，表基本同意。缓存重建和持久化在一个需要状态恢复的系统里可能会有需要。大部分情况都可以从头再来吧？

 

 

后端性能优化技术

前面讨论了前端性能的优化技术，于是前端可能就不是瓶颈问题了。那么性能问题就会到后端数据上来了。下面说几个后端常见的性能优化技术。

 

编者注：和12306.cn没有半毛钱关系。纯技术，还是相当有用的，我认为。

一、数据冗余

关于数据冗余，也就是说，把我们的数据库的数据冗余处理，也就是减少表连接这样的开销比较大的操作，但这样会牺牲数据的一致性。风险比较大。很多人把NoSQL用做数据，快是快了，因为数据冗余了，但这对数据一致性有大的风险。这需要根据不同的业务进行分析和处理。（注意：用关系型数据库很容易移植到NoSQL上，但是反过来从NoSQL到关系型就难了）

编者注：怎样才能够用好数据冗余呢？

 

二、数据镜像

几乎所有主流的数据库都支持镜像，也就是replication。数据库的镜像带来的好处就是可以做负载均衡。把一台数据库的负载均分到多台上，同时又保证了数据一致性（Oracle的SCN）。最重要的是，这样还可以有高可用性，一台废了，还有另一台在服务。

数据镜像的数据一致性可能是个复杂的问题，所以我们要在单条数据上进行数据分区，也就是说，把一个畅销商品的库存均分到不同的服务器上，如，一个畅销商品有1万的库存，我们可以设置10台服务器，每台服务器上有1000个库存，这就好像B2C的仓库一样。

编者注：后面举得例子很诡异的像分布式存储啊。你一万的库存分十台存储，有一台挂掉了，你还继续服务？如果九台挂掉了你今天就只卖1000啊？应该是有10万，你存储到100台上，一台服务其它同步更新。有一台挂掉了，毛毛雨啊，继续服务，PS：今天目标销量1万。

三、数据分区

数据镜像不能解决的一个问题就是数据表里的记录太多，导致数据库操作太慢。所以，把数据分区。数据分区有很多种做法，一般来说有下面这几种：

1）把数据把某种逻辑来分类。比如火车票的订票系统可以按各铁路局来分，可按各种车型分，可以按始发站分，可以按目的地分……，反正就是把一张表拆成多张有一样的字段但是不同种类的表，这样，这些表就可以存在不同的机器上以达到分担负载的目的。

2）把数据按字段分，也就是竖着分表。比如把一些不经常改的数据放在一个表里，经常改的数据放在另外多个表里。把一张表变成1对1的关系，这样，你可以减少表的字段个数，同样可以提升一定的性能。另外，字段多会造成一条记录的存储会被放到不同的页表里，这对于读写性能都有问题。但这样一来会有很多复杂的控制。

3）平均分表。因为第一种方法是并不一定平均分均，可能某个种类的数据还是很多。所以，也有采用平均分配的方式，通过主键ID的范围来分表。

4）同一数据分区。这个在上面数据镜像提过。也就是把同一商品的库存值分到不同的服务器上，比如有10000个库存，可以分到10台服务器上，一台上有1000个库存。然后负载均衡。

这三种分区都有好有坏。最常用的还是第一种。数据一旦分区，你就需要有一个或是多个调度来让你的前端程序知道去哪里找数据。把火车票的数据分区，并放在各个省市，会对12306这个系统有非常有意义的质的性能的提高。

 

编者注：数据分区还真得这么干。但是，你要把12306系统里的车票数据分存到各省市，还嫌系统不够乱啊。在一个区市发生的购票需求不仅仅局限于所在的省。

 

四、后端系统负载均衡

前面说了数据分区，数据分区可以在一定程度上减轻负载，但是无法减轻热销商品的负载，对于火车票来说，可以认为是大城市的某些主干线上的车票。这就需要使用数据镜像来减轻负载。使用数据镜像，你必然要使用负载均衡，在后端，我们可能很难使用像路由器上的负载均衡器，因为那是均衡流量的，因为流量并不代表服务器的繁忙程度。因此，我们需要一个任务分配系统，其还能监控各个服务器的负载情况。

任务分配服务器有一些难点：

• 负载情况比较复杂。什么叫忙？是CPU高？还是磁盘I/O高？还是内存使用高？还是并发高？还是内存换页率高？你可能需要全部都要考虑。这些信息要发送给那个任务分配器上，由任务分配器挑选一台负载最轻的服务器来处理。

• 任务分配服务器上需要对任务队列，不能丢任务啊，所以还需要持久化。并且可以以批量的方式把任务分配给计算服务器。

• 任务分配服务器死了怎么办？这里需要一些如Live-Standby或是failover等高可用性的技术。我们还需要注意那些持久化了的任务的队列如何转移到别的服务器上的问题。

我看到有很多系统都用静态的方式来分配，有的用hash，有的就简单地轮流分析。这些都不够好，一个是不能完美地负载均衡，另一个静态的方法的致命缺陷是，如果有一台计算服务器死机了，或是我们需要加入新的服务器，对于我们的分配器来说，都需要知道的。

还有一种方法是使用抢占式的方式进行负载均衡，由下游的计算服务器去任务服务器上拿任务。让这些计算服务器自己决定自己是否要任务。这样的好处是可以简化系统的复杂度，而且还可以任意实时地减少或增加计算服务器。但是唯一不好的就是，如果有一些任务只能在某种服务器上处理，这可能会引入一些复杂度。不过总体来说，这种方法可能是比较好的负载均衡。

 

编者注：什么都好，什么都不好。12306很茫然。

 

五、异步、 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，就等着被骂吧）。

编者注：异步是为了将互不影响的多个任务的多个处理过程通过假同时处理来产生更长的处理时间，这里的分析却是视异步的这一特点为弱势，更进一步的阐述将这种弱势应用到了一种不符合其处理特点的场景里。如果表述成这样，服务器需要完成100万的购票请求，购票请求时查询-下订单-服务器处理完成。如果让服务器同步完成，那么最后一个用户可以买票的时候就需要快递员掘开他的坟墓来订购下个世纪的票了。所以，我们采用异步的形式，完成第一个查询结果以后直接处理第二个查询，而不考虑前一用户是否下订单。在有下订单需求后服务器立即停止查询相应处理下订单的请求。所以，接受订单就意味着一定完成。确保在订单真正完成前订单时可完成的才是最重要的。而不是，自己塞给服务器一大堆订单，发现百分之五十的订单属于超额范围，那就算你服务器不down，一样骂的你狼心狗肺。

小结

写了那么多，我小结一下：

0）无论你怎么设计，你的系统一定要能容易地水平扩展。也就是说，你的整个数据流中，所有的环节都要能够水平扩展。这样，当你的系统有性能问题时，“加3倍的服务器”才不会被人讥笑。

1）上述的技术不是一朝一夕能搞定的，没有长期的积累，基本无望。我们可以看到，无论你用哪种都会引发一些复杂性。

2）集中式的卖票很难搞定，使用上述的技术可以让订票系统能有几佰倍的性能提升。而在各个省市建分站，分开卖票，是能让现有系统性能有质的提升的最好方法。

3）春运前夕抢票且票量供远小于求这种业务模式是相当变态的，让几千万甚至上亿的人在某个早晨的8点钟同时登录同时抢票的这种业务模式是变态中的变态。业务形态的变态决定了无论他们怎么办干一定会被骂。

4）为了那么一两个星期而搞那么大的系统，而其它时间都在闲着，有些可惜了，这也就是铁路才干得出来这样的事了。

编者注：

0) 无论怎么设计，都需要很长期的维护与再开发。没有所谓的一步到位。

1) 没有一种理论是适用于你现在所处理的问题，只有一种一种的试过才能找到你所需要的真理。当然这需要你有能力承受很大代价。

2) 这是矛。如果上述技术能够让订票系统几百倍的提升。那么现在的系统就是一个优化后连一万的需求都处理不了的垃圾。在各个省市建分站分开卖票只是解决了不用走路去北京卖云南到拉萨的往返票的难题。当然这已经在投入使用了（详见各省市的火车票代售点）

3) 这是盾。如果有第2条，要这第三条干啥？

4) 这大嘴巴是谁抽的？抽谁？

编者最后总结：人们对12306.cn的怨声载道，一是：买不到票（很多人以为12306.cn是为了解决买票难回家难的问题才上线的），二是：在一大批程序员难赚钱，消费上涨的大前提下，12306.cn项目依旧能够给出国内经济环境依旧利好的信号，十足让人一半在水里一半在火里，水深火热啊。单纯扯技术还是不错的，但是一旦扯上12306.cn，责任大则压力越大，本文没有给出很好解答。

原文地址：http://coolshell.cn/articles/6470.html/

 

转载于:https://www.cnblogs.com/klvk/archive/2012/09/20/2696185.html