【IT168 评论】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 台服务器，每台服务器上有 100 个库存，这就好像 B2C 的仓库一样。
