2012年春节，铁道部推出12306网站，进行网络实名购票。每一个返乡人原以为能买着一张回家的火车票，但结果还是大失所望。7天内，12306网站访问用户已占全球互联网用户的0.902%，每天点击量高达10亿人次;系统一度支撑不住如此庞大的访问量而陷入崩溃。针对12306的责难也不绝于耳。

　　对此，中国铁路客户服务中心透露，目前，铁道部已启动了新一代客票系统的规划和设计。考虑采用云计算架构，对现有的客票系统进行全面的优化和改造。IT168企业计算群组特启动“支招12306 大型高并发高性能网站架构经验大家谈”特别专题，针对大型高并发高性能网站架构广泛征集意见，为12306网站提出优化建议，并对更多有需要构建大型高并发高性能网站的用户提供参考。本期采访的嘉宾叶萌，曾任天涯社区CIO，现在从事云计算相关的创业工作。

　　在采访中，叶萌表示，虽然大家对12306网站有所指责，但是站在纯技术指标的角度，从公开的一些数据看，我个人觉得它做得还蛮不错，应该给铁道部一点鼓励。他认为，12306网站归根结底可以归结为在线交易型网站，并谈到了在线交易型网站在前端设计和后端设计方面的一些原则，在线交易型网站最大的难点就是要结合自己的业务特点，把这些设计原则融合到网站设计中去。

　　问题一：12306网站需求分析 与其他网站有何不同?

　　叶萌：这种大型的服务网站，包括淘宝、京东等电商的网站，还有这类订票的网站，服务的可用性以及响应的时间是刚性的需求，但是不同的网站由于业务不同会导致需求有所不同，同时还有网站的访问压力也同网站的需求有关，压力包括用户的访问压力以及业务流程的复杂度和要处理的数据量的压力。

　　京东、新浪、淘宝、12306等等这些大型的网站，需求方面最主要的区别就在于并发的访问量、业务逻辑的不同、以及数据量的大小。

　　问题二： 12306网站系统的设计存在的问题分析？

　　叶萌：不管是京东也好，淘宝也好，还是12306也好，都可以归结为一种在线交易系统。这种系统大致地可以分前端和后端两大部分。后端再细分一点，可以分业务逻辑的部分和数据处理的部分。

　　前端的设计要在满足功能需求的前提之下做得比较轻，所谓轻就包括前端的格式和数据量，每下载一个页面所需要的数据量以及打开同一个页面上建立的http的连接数要尽可能地少。反之，如果网页比较重的话，每下载一个网页从服务器传出来的东西就会比较多，当访问量很大时，对系统的带宽会有极大的挑战。

　　12306前端设计比较重，主要表现几个方面：第一，把CSS的表和网页混在一块下载。第二，打开一个网页需要建立的http连接数都很多。很多关键的网页包括订票的网页、查询的网页，打开一个网页需要建立的http连接数都很多，有人分析过打开一个网页超过70个http连接数。每一台服务器建立的http连接数是有一个上限，如果大家都去并发访问的时候，服务器的连接数很快就不够用了。

　　在这里我想补充一点：多浏览器的兼容性问题。12306目前好象使只能使用IE浏览器，用google的Chrome的浏览就不能并发的用，所以这也是一个需要注意的问题。

　　后端可以分成两块：一个是业务逻辑，一个是数据处理。

　　从业务逻辑角度来讲，火车票的查询从A地到B地有多少趟车，这个查询的逻辑比电商的要复杂。电商无非是到一个库里看还有没有货，结果要么就是有要么就是没有，不会有第三种。但是对于火车票来讲，从A地到B地可能有多种选择，可能有几趟车可以选择。

　　这个比电商要复杂，因为它做的事要很多，计算就比较多，或者要做好几个查询，才能把信息汇总起来。如果涉及到关联订票的情况就更复杂了，但是目前12306还没有实现关联订票。

　　后端的还有一块——数据处理方面。这个跟订票有关系，订票以后需要做一个事务，就是要从下单到完成订票是一个完整的事务，这个事务和电商下单的时候有一定的相似性，直到付款这一步之前都跟电商就很像。这个部分的问题在哪里?12306采取的一个做法就是同步的响应，同步做法是大家比较喜欢的一种做法，就是下了单马上能看到买到票没有。但是同步的做法对系统的挑战比较高，有很多电商的网站实际已经从业务逻辑的调整为一个异步，就是把订票这个事务变成异步操作来完成。

　　事务的处理有一个最大的挑战是数据一致性的问题，就是一定要保证后端在任何一个时间点它是一致的，伸缩性不管是纵向扩展还是横向扩展，尤其是横向扩展比较难的地方就在于数据的一致性的问题。

　　问题三：基于上述问题，如何设计一个高并发的交易型网站?需要从哪些方面考虑?

　　叶萌：做一个大型高并发的交易型网站不可能从一个技术点就能突破，它需要综合性的考虑，包括前端、后端，后端又包括业务逻辑和数据处理，都需要考虑到。业务逻辑需要特别强调，做任何网站最重要的一点就是它的业务逻辑本身以及这个业务逻辑的优化上。

　　首先讲前端，在做真正交易部分的前端的界面，要设计的尽可能地简单和轻。做这些页面不是为了炫而是为了做事，页面要非常简洁，简洁反映在数据量尽可能少，同时最好都在一个http连接或者很少在http连接就能把这个页面下载过来或者上传回去。

　　从后端业务逻辑上来讲，业务逻辑刚才讲了业务流程优化的一个问题，做这种大型的网站要多做横向扩展，就是大家说的scale-out。策略就几招：

　　第一招就是尽可能做划分。所谓划分就是有功能上的划分和数据上的划分。第一，查询的和交易等功能尽可能地划分，由不同的服务器来做相关的事情。第二，从数据上划分，如果是一个数据库，尽可能地要把一张很复杂的大表分给各种小表，尤其不相关的信息，尽可能拆分到不同的表里甚至不同的数据库里。举一个例子，像淘宝很简单的一个划分方法就是以网店为单位设计这个表，一个极端的例子就是每个网店是一张表，当然这个例子很极端，它肯定不是这么做的，一个网店一张表的话，表的数量肯定太多了。我查了一些资料，在春运的时间根据铁道部发布的全国列车运行图，在2012年春运期间好象开了2064对列车，来往算一对的话，总共开了2064对。如果把一对看成一个网店话，就是开了2064个网店，每一个网店里面每一条铁路线，实际就是任何每两点都应该可以买到票，理论上讲可以买到票，如果一条线上N个节点，应该是(28：09ncr)都可以买到票。这么一个组合，这个数字出来相当于网店里的商品数。这个量也不算太大，如果以每一对列车作为一个处理单元，可以把(28：37)分开的。

　　还有一招就是尽可能地把同步操作变成异步操作。所谓异步操作就是它不需要马上给你回复。举一个例子，大家都用过携程网，携程网订飞机票，大家知道在携程里选了以后就下单了，下单以后携程不会马上告诉你订票成功的，它会告诉你它会去处理，会把处理的结果给你，通过短信通知你。这样的流程带来什么好处?可以把收集订单，收集完以后用类似于批处理的方式，集中处理这些订单。在业务逻辑和业务流程上做一些调整，对大型网站的横向扩展是非常有好处。

　　我们稍微总结一下，大型的网站设计主要是要注意四个方面：第一，前端要尽量轻;第二，有一些静态的或者变化不怎么频繁的数据尽可能地使用缓存机制。包括像CDN、自己做的缓存等;第三，尽可能地把同步的交易异步化。第四，数据要尽可能划分开，系统的设计从功能上要尽可能地划分开，从数据上不关联的数据或者弱相关的数据尽可能分开，甚至强相关的数据也需要想一定的方法把它们分开，变成弱相关的数据，因为这样可以最好地做横向扩展，做并发处理。

　　问题四：对于未来的12306，有网友建议可以采用NOSQL，你是如何看待的?

　　叶萌：首先要搞清楚NOSQL是怎么来源的， NOSQL技术出现最主要的原因，就是随着互联网模式的发展，数据量日渐增大，这些数据量用数据库尤其是关系型数据库处理不过来，这是NOSQL发展的背景。

　　关系型数据库最大的问题就是对这个数据一致性的保障最好，因为它支持一些原子操作、事务处理这些东西，所以它对一致性处理是最好的。互联网上大量的数据对一致性的需求没有交易系统这么高，所以NOSQL的技术主要是在放松了对数据一致性要求的前提下发展起来的一种数据处理技术。所以NOSQL的一个特点，它放松了对数据一致性的需求，获得了性能的提升和吞吐量的提升。

　　从这个特点来看，要不要用这个NOSQL的技术，跟我们在做什么样的事情非常有关系。如果这些数据用来做一些分析等等，那用NOSQL技术固然很好，因为做这些东西首先它通常是线下做，而且前一秒和后一秒钟数据有一定的误差不会对你的统计结果产生很明确的干扰。

　　但是，据我知道，没有人用NOSQL的技术做交易系统。因为数据一致性对交易系统是第一位的需求，买到了就是买到了，买不到就是买不到，不能说在这一刻既可以买到又可以不买到，这个是大家不能接受的。所以对于交易型的系统用NOSQL技术来提高性能是有问题。

　　但是NOSQL的技术在类似12306的这种网站里不是不能用，它可以在做状态查询的时候用到，比如查有票没票，这时候数据一致性的需求没有那么高。