Ausführlich guter Artikel-Vortrag über die Architektur und Leistungsoptimierung großer Websites ab 12306.cn.

12306.cn-website ist down，Von Leuten im ganzen Land gescholten。Ich habe diese zwei Tage darüber nachgedacht，Ich möchte diese Angelegenheit nutzen, um mit Ihnen die Leistungsfähigkeit der Website grob zu besprechen.。Wegen Eile，Und basiert ausschließlich auf meiner begrenzten Erfahrung und meinem Verständnis，und so，Bei Fragen bitte gemeinsam diskutieren und korrigieren。(Dies ist ein weiterer langer Artikel，Besprechen Sie nur Leistungsprobleme，Diskutieren Sie nicht über diese Benutzeroberfläche，Benutzererfahrung，或是是否把支付和购票下单环节分开的功能性的东西）

业务

任何技术都离不开业务需求，und so，Zur Veranschaulichung von Leistungsproblemen，Zuerst möchte ich zuerst über das Geschäftsproblem sprechen。

• Einer，Jemand könnte dieses Ding mit QQ oder Online-Spielen vergleichen。Aber ich denke die beiden sind unterschiedlich，Online-Spiele und QQ online oder beim Einloggen auf weitere eigene Daten des Nutzers zugreifen，Das Ticketbuchungssystem greift auf die Ticketvolumendaten des Centers zu，Es ist nicht das gleiche。Glauben Sie nicht, dass Online-Spiele oder QQ funktionieren können, Sie denken nur, dass es dasselbe ist。Im Vergleich zu E-Commerce-Systemen ist die Backend-Last von Online-Spielen und QQ immer noch einfach。

• Sekunde，Manche Leute sagen, dass die Buchung eines Zuges während des Frühlingsfestes wie eine Spitzenaktivität auf der Website ist。Wirklich sehr ähnlich，Aber wenn dein Denken nicht an der Oberfläche ist，Sie werden feststellen, dass dies auch ein wenig anders ist。Zugtickets，Einerseits wird es von einer Vielzahl von Abfrageoperationen begleitet，Darüber hinaus gibt es bei BT viele konsistente Operationen auf der Datenbank, wenn eine Bestellung aufgegeben wird.，Einerseits die Konsistenz jedes Segmenttickets vom Startpunkt bis zum Endpunkt，auf der anderen Seite，Käuferroute、Zugnummer、Es gibt viele Zeitoptionen，Wird die Art und Weise der Auftragserteilung ständig ändern。Und Spike，Töte es einfach direkt，Es gibt nicht so viele Abfragen und Konsistenzprobleme。Außerdem，Über Spike，Es kann eingestellt werden, dass nur die Anfragen der ersten N Benutzer akzeptiert werden (keine Daten im Backend betreiben， Einfach den Bestellvorgang des Benutzers protokollieren)，Diese Art von Geschäft，Sie müssen nur die Anzahl der Spikes in den Speichercache setzen，Sie können die Daten auch verteilen，100Fan-Shop，10Jeder Server stellt 10，Keine Notwendigkeit, zu diesem Zeitpunkt eine Datenbank zu betreiben。Sie können genug bestellen，Spitze stoppen，Dann stapelweise in die Datenbank schreiben。Und es gibt nicht viele Produkte im Spike。Das Zugticket ist nicht so einfach wie ein Spike，Zeit des Frühlingsfestes，Fast alle Tickets sind heiße Tickets，Und fast alle Menschen des ganzen Landes sind hier，Und es gibt auch ein Transfergeschäft，Multi-Line-Inventar muss transaktionale Vorgänge sein，Denk darüber nach，Wie schwer ist das。(Taobaos Double Eleven hat 3 Millionen Nutzer，而火车票瞬时有千万级别甚至是亿级别的）（更新：201411. Januar：Nach der Ankunft in Taobao，Verstehe das System von Taobao，Taobaos Spitzenaktivität，Im Wesentlichen verwendet es den Verifizierungscode, um Benutzer direkt auf dem CDN herauszufiltern，zum Beispiel：1Dutzende Millionen Nutzer werden herausgefiltert, es bleiben nur noch 20.000 Nutzer，这样数据库就顶得住了）

• 其三，Jemand vergleicht dieses System mit dem olympischen Ticketsystem。Ich denke es ist immer noch anders。Obwohl das olympische Ticketsystem gleich nach seiner Einführung abgeschafft wurde。Aber die Olympischen Spiele verwenden eine Lotterieziehung，Mit anderen Worten, es gibt keinen Wer zuerst kommt, mahlt zuerst，und，Ist ein nachträglicher Gedanke，Muss nur vorher Informationen erhalten，Keine vorherige Sicherstellung der Datenkonsistenz，Kein Schloss，Einfach horizontal skalieren。

• Vierte，Das Buchungssystem sollte dem E-Commerce-Bestellsystem sehr ähnlich sein，Alle müssen Inventur durchführen：1) Inventar besetzen，2) Zahlung (optional)，3) Der Vorgang des Abzugs von Inventar。Dies muss auf Konsistenz geprüft werden，Das heißt, die Daten müssen während der Parallelität gesperrt werden。B2C-E-Commerce wird dies grundsätzlich asynchron tun，Mit anderen Worten，Ihre Bestellung wird nicht sofort bearbeitet，Aber verzögerte Bearbeitung，Nur erfolgreich bearbeitet，Das System sendet Ihnen eine Bestätigungs-E-Mail mit der Bestätigung, dass die Bestellung erfolgreich war。Ich glaube, viele Freunde haben erfolglose E-Mails erhalten。Dies bedeutet, dass，Datenkonsistenz ist ein Engpass bei Parallelität。

• Nr. 5，Das Geschäft mit Bahntickets ist anormal，Es verwendet plötzliche Ticketfreigabe，Und manche Stimmen reichen bei weitem nicht für alle，und so，Jeder wird die Praxis haben, Tickets für ein Geschäft mit chinesischen Merkmalen zu ergattern。Also wenn das Ticket freigegeben ist，Millionen oder sogar Dutzende von Millionen werden getötet，Anfragen，Eine Bestellung aufgeben。Innerhalb von zehn Minuten，Eine Website kann zig Millionen Besuche erhalten，Das ist eine schreckliche Sache。Es wird gesagt, dass der Spitzenbesuch von 12306 1 Milliarde PV . beträgt，Konzentrieren Sie sich auf 8 bis 10 Uhr，Zig Millionen PV pro Sekunde in der Spitze。

Sag noch ein paar Worte：

• Inventar ist ein B2C-Albtraum，Bestandsverwaltung ist ziemlich kompliziert。Misstrauen，Sie können alle traditionellen und Elektrohandelsunternehmen fragen，Sehen Sie, wie schwierig es für sie ist, das Inventar zu verwalten。Andernfalls，Es wird nicht so viele Leute geben, die nach Vancls Inventar fragen。(Sie können sich auch "Berufsbiografie" ansehen，Du weißt, warum Tim das Amt des CEO von Apple übernommen hat，最主要的原因是他搞定了苹果的库存周期问题）

• 对于一个网站来说，Die hohe Belastung beim Surfen im Web ist einfach zu handhaben，Die Last der Abfrage hat einen gewissen Schwierigkeitsgrad zu bewältigen，Aber es kann immer noch durch Zwischenspeichern der Abfrageergebnisse erfolgen，Das Schwierigste ist die Ladung der Bestellung。Weil ich auf das Inventar zugreifen muss，Für eine Bestellung，Grundsätzlich erfolgt es asynchron。Doppel 11 letztes Jahr，Taobaos Bestellungen pro Stunde liegen bei etwa 600.000，Jingdong kann nur 400.000 an einem Tag unterstützen (es ist schlimmer als 12306)，Amazon konnte vor 5 Jahren 700.000 Bestellungen in einer Stunde unterstützen。sichtbar，Die Auftragserteilung ist nicht so hoch wie bei uns。

• Taobao ist viel einfacher als eine B2C-Website，Weil es kein Lager gibt，und so，Es gibt keine Operation wie B2C, die N Lager hat, um denselben Produktbestand zu aktualisieren und abzufragen。Bei Auftragserteilung，Die B2C-Website wird ein Lager finden，Wieder nah am Nutzer，Wieder Inventar，Dies erfordert viele Berechnungen。Stell dir vor，Du hast ein Buch in Peking gekauft，Das Lager in Peking ist vergriffen，Muss aus dem umliegenden Lager umgeladen werden，Dann schau, ob das Lager in Shenyang oder Xi'an auf Lager ist，wenn nicht，Ich muss mir das Lager in Jiangsu ansehen，und viele mehr。Taobao hat nicht so viele Dinge，Jeder Händler hat sein eigenes Inventar，Inventar ist eine Zahl，Und das Inventar wird dem Händler zugeteilt，Es ist förderlich für die Leistungserweiterung。

• Datenkonsistenz ist der wahre Leistungsengpass。Einige Leute sagen, dass nginx 100.000 statische Anfragen pro Sekunde verarbeiten kann，Ich zweifle nicht。Aber das ist nur eine statische Anfrage，Theoretischer Wert，Solange die Bandbreite、E/A ist stark genug，Server-Rechenleistung reicht aus，Und die Anzahl der unterstützten gleichzeitigen Verbindungen kann dem Aufbau von 100.000 TCP-Links standhalten，Das ist kein Problem。Aber angesichts der Datenkonsistenz，Diese 100.000 sind völlig zu einem unerreichbaren theoretischen Wert geworden。

Ich habe so viel gesagt，Ich möchte nur allen vom Geschäft erzählen，Wir müssen die Anomalien des Ticketbuchungsgeschäfts der Spring Festival Railway aus der Branche wirklich verstehen.。

前端性能优化技术

要解决性能的问题，Es gibt viele gängige Methoden，Ich werde unten auflisten，Ich glaube, dass die 12306-Website, die die folgenden Technologien verwendet, ihre Leistung zu einem qualitativen Sprung machen wird。

einer、前端负载均衡

通过DNS的负载均衡器（一般在路由器上根据路由的负载重定向）可以把用户的访问均匀地分散在多个Web服务器上。Dies kann die Anforderungslast des Webservers reduzieren。Weil http-Anfragen kurze Jobs sind，und so，Diese Funktion kann durch einen sehr einfachen Load Balancer erreicht werden。Es ist am besten, ein CDN-Netzwerk zu haben, damit Benutzer eine Verbindung zum nächstgelegenen Server herstellen können (CDN wird normalerweise von verteiltem Speicher begleitet).。（关于负载均衡更为详细的说明见“后端的负载均衡”）

zwei、Reduzieren Sie die Anzahl der Frontend-Links

我看了一下12306.cn，打开主页需要建60多个HTTP连接，车票预订页面则有70多个HTTP请求，现在的浏览器都是并发请求的（当然，浏览器的一个页面的并发数是有限的，但是你挡不住用户开多个页面，und，后端服务器TCP链接在前端断开始，还不会马上释放或重要）。und so，只要有100万个用户，就有可能会有6000万个链接（访问第一次后有了浏览器端的cache，这个数会下来，就算只有20%也是百万级的链接数），太多了。一个登录查询页面就好了。把js打成一个文件，把css也打成一个文件，把图标也打成一个文件，用css分块展示。把链接数减到最低。

三、减少网页大小增加带宽

这个世界不是哪个公司都敢做图片服务的，因为图片太耗带宽了。现在宽带时代很难有人能体会到当拨号时代做个图页都不敢用图片的情形（现在在手机端浏览也是这个情形）。我查看了一下12306首页的需要下载的总文件大小大约在900KB左右，如果你访问过了，浏览器会帮你缓存很多，只需下载10K左右的文件。但是我们可以想像一个极端一点的案例，1百万用户同时访问，且都是第一次访问，每人下载量需要1M，如果需要在120秒内返回，那么就需要，1M. * 1M. /120 * 8 = 66Gbps的带宽。很惊人吧。und so，我估计在当天，12306的阻塞基本上应该是网络带宽，und so，你可能看到的是没有响应。后面随着浏览器的缓存帮助12306减少很多带宽占用，于是负载一下就到了后端，后端的数据处理瓶颈一下就出来。于是你会看到很多http 500之类的错误。这说明后端服务器垮了。

四、前端页面静态化

静态化一些不常变的页面和数据，并gzip一下。还有一个变态的方法是把这些静态页面放在/dev/shm下，这个目录就是内存，直接从内存中把文件读出来返回，这样可以减少昂贵的磁盘I/O。使用nginx的sendfile功能可以让这些静态文件直接在内核心态交换，可以极大增加性能。

五、优化查询

很多人查询都是在查一样的，完全可以用反向代理合并这些并发的相同的查询。这样的技术主要用查询结果缓存来实现，第一次查询走数据库获得数据，并把数据放到缓存，后面的查询统统直接访问高速缓存。为每个查询做Hash，使用NoSQL的技术可以完成这个优化。（这个技术也可以用做静态页面）

对于火车票量的查询，个人觉得不要显示数字，就显示一个“有”或“无”就好了，这样可以大大简化系统复杂度，并提升性能。把查询对数据库的负载分出去，从而让数据库可以更好地为下单的人服务。

六、缓存的问题

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

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

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

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

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

后端性能优化技术

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

einer、数据冗余

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

zwei、数据镜像

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

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

三、数据分区

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

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

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

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

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

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

四、后端系统负载均衡

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

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

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

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

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

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

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

五、异步、 throttle 和 批量处理

异步、throttle（节流阀） 和批量处理都需要对并发请求数做队列处理的。

• 异步在业务上一般来说就是收集请求，然后延时处理。在技术上就是可以把各个处理程序做成并行的，也就可以水平扩展了。但是异步的技术问题大概有这些，a）被调用方的结果返回，会涉及进程线程间通信的问题。b）如果程序需要回滚，回滚会有点复杂。c）异步通常都会伴随多线程多进程，并发的控制也相对麻烦一些。d）很多异步系统都用消息机制，消息的丢失和乱序也会是比较复杂的问题。

• throttle 技术其实并不提升性能，这个技术主要是防止系统被超过自己不能处理的流量给搞垮了，这其实是个保护机制。使用throttle技术一般来说是对于一些自己无法控制的系统，zum Beispiel，和你网站对接的银行系统。

• 批量处理的技术，是把一堆基本相同的请求批量处理。zum Beispiel，大家同时购买同一个商品，没有必要你买一个我就写一次数据库，完全可以收集到一定数量的请求，一次操作。这个技术可以用作很多方面。比如节省网络带宽，我们都知道网络上的MTU（最大传输单元），以态网是1500字节，光纤可以达到4000多个字节，如果你的一个网络包没有放满这个MTU，那就是在浪费网络带宽，因为网卡的驱动程序只有一块一块地读效率才会高。deshalb，网络发包时，我们需要收集到足够多的信息后再做网络I/O，这也是一种批量处理的方式。批量处理的敌人是流量低，und so，批量处理的系统一般都会设置上两个阀值，一个是作业量，另一个是timeout，只要有一个条件满足，就会开始提交处理。

und so，只要是异步，一般都会有throttle机制，一般都会有队列来排队，有队列，就会有持久化，而系统一般都会使用批量的方式来处理。

云风同学设计的“排队系统” 就是这个技术。这和电子商务的订单系统很相似，就是说，我的系统收到了你的购票下单请求，但是我还没有真正处理，我的系统会跟据我自己的处理能力来throttle住这些大量的请求，并一点一点地处理。一旦处理完成，我就可以发邮件或短信告诉用户你来可以真正购票了。

在这里，我想通过业务和用户需求方面讨论一下云风同学的这个排队系统，因为其从技术上看似解决了这个问题，但是从业务和用户需求上来说可能还是有一些值得我们去深入思考的地方：

1）队列的DoS攻击。Erste，我们思考一下，这个队是个单纯地排队的吗？这样做还不够好，因为这样我们不能杜绝黄牛，而且单纯的ticket_id很容易发生DoS攻击，zum Beispiel，我发起N个 ticket_id，进入购票流程后，我不买，我就耗你半个小时，很容易我就可以让想买票的人几天都买不到票。有人说，用户应该要用身份证来排队， 这样在购买里就必需要用这个身份证来买，但这也还不能杜绝黄牛排队或是号贩子。因为他们可以注册N个帐号来排队，但就是不买。黄牛这些人这个时候只需要干一个事，把网站搞得正常人不能访问，让用户只能通过他们来买。

2）对列的一致性？对这个队列的操作是不是需要锁？只要有锁，性能一定上不去。Stell dir vor，100万个人同时要求你来分配位置号，这个队列将会成为性能瓶颈。你一定没有数据库实现得性能好，und so，可能比现在还差。抢数据库和抢队列本质上是一样的。

3）队列的等待时间。购票时间半小时够不够？多不多？要是那时用户正好不能上网呢？如果时间短了，用户不够时间操作也会抱怨，如果时间长了，后面在排队的那些人也会抱怨。这个方法可能在实际操作上会有很多问题。Außerdem，半个小时太长了，这完全不现实，我们用15分钟来举例：有1千万用户，每一个时刻只能放进去1万个，这1万个用户需要15分钟完成所有操作，So，这1千万用户全部处理完，需要1000*15m = 250小时，10天半，火车早开了。（我并非信口开河，根据铁道部专家的说明：这几天，平均一天下单100万，und so，处理1000万的用户需要十天。这个计算可能有点简单了，我只是想说，在这样低负载的系统下用排队可能都不能解决业务问题）

4）队列的分布式。这个排队系统只有一个队列好吗？还不足够好。因为，如果你放进去的可以购票的人如果在买同一个车次的同样的类型的票（比如某动车卧铺），还是等于在抢票，也就是说系统的负载还是会有可能集中到其中某台服务器上。deshalb，最好的方法是根据用户的需求——提供出发地和目的地，来对用户进行排队。而这样一来，队列也就可以是多个，只要是多个队列，就可以水平扩展了。这样可以解决性能问题，但是没有解决用户长时间排队的问题。

我觉得完全可以向网上购物学习。在排队（下单）的时候，收集好用户的信息和想要买的票，并允许用户设置购票的优先级，zum Beispiel，A车次卧铺买 不到就买 B车次的卧铺，如果还买不到就买硬座等等，然后用户把所需的钱先充值好，接下来就是系统完全自动地异步处理订单。成功不成功都发短信或邮件通知用户。eine solche，系统不仅可以省去那半个小时的用户交互时间，自动化加快处理，还可以合并相同购票请求的人，进行批处理（减少数据库的操作次数）。这种方法最妙的事是可以知道这些排队用户的需求，不但可以优化用户的队列，把用户分布到不同的队列，还可以像亚马逊的心愿单一样，通过一些计算就可以让铁道部做车次统筹安排和调整（最后，排队系统（下单系统）还是要保存在数据库里的或做持久化，不能只放在内存中，不然机器一down，就等着被骂吧）。

小结

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

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

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

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

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

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

更新2012年9月27日

Alexa 统计的12306的PV （注：Alexa的PV定义是：一个用户在一天内对一个页面的多次点击只算一次）

（本文转载时请注明作者和出处，请勿于记商业目的）

转自：http://coolshell.cn/articles/6470.html