12306网站架构设想

我的公众号「码农之屋」(id: Spider1818) ，分享的内容包括但不限于 Linux、网络、云计算虚拟化、容器Docker、OpenStack、Kubernetes、SDN、OVS、DPDK、Go、Python、C/C++编程技术等内容，欢迎大家关注。

---

1.背景介绍

2012年春节，铁道部推出12306网站，进行网络实名购票。每一个返乡人原以为不用再忍冻排队，就能买着一张回家的火车票，但结果还是大失所望。7天内，12306网站访问用户已占全球互联网用户的0.902%，每天点击量高达10亿人次；系统一度支撑不住如此庞大的访问量而陷入崩溃。针对12306的责难也不绝于耳。最近几年IT业内很热火，云计算、大数据以及Hadoop等概念铺天盖地袭来。针对12306遇到的难题，也就有诸如淘宝、人人网、即刻搜索以及Facebook等许多率先实践Hadoop的技术人员来分享应用经验。从表面看来，类似12306的高性能高并发系统与Facebook、微博以及淘宝节假日抢购活动非常类似，并且，淘宝、新浪以及Facebook等都在这一块做得非常的好。那么他们的经验是否可以借鉴呢?

以国际上非常流行的Facebook为例，Facebook的瞬间并发最大的特点就是写操作非常频繁，而Facebook的解决之道则在于通过利用HBase写速度快的特点来构建数据库，并对整个架构进行优化来达到缩短时间的目的，微博跟Facebook在本质上差不太多。而对于12306而言，其实质上应当属于频繁的混合读写操作，而且是小随机频繁读写，这在业内是公认的难题。与网游或QQ的后端负载相比，12306购票系统的压力显然要大得多。因为网游和QQ在线或是登录时访问的更多的是用户自己的数据，而订票系统访问的是中心的票量数据，这是不一样的。

12306互联网售票系统应该是一个高性能、高伸缩性、高可靠性的系统，可以在高峰期(例如春运时刻)增加机器能够应对高峰期的峰值用户群。而目前的传统做法是用一大堆好机器来做数据库集群和应用服务器集群，把用J2EE架构做出来的功能部署在应用服务器集群上，而把大部分压力都放在数据库上。传统的做法并不特别关注高性能、高可靠性、高伸缩性的应用架构设计、数据架构的设计和相应的代码质量。而这也正是12306系统所缺失的地方。

2.面临难题

通过公开数据可以看到铁路在春运期间是2.3亿人次，再按照出行高峰期来看也就是20天，也就是说每天的火车票数量可以近似的认为是近1000万张。如果我们的12306 系统是非常强悍（快、高效、稳定）的话，12306系统将会售出的票数为大部分（例如700万张），这样的话700万张票如果一放出来会被在几分钟内全部被抢完（如果按照人的习惯的话买一张票最好所费的时间是10分钟）。也就是说12306系统的处理能力是每秒能处理卖出（700万/(10分钟*60）=1.17万）张票，反映到事务的话更加恐怖。这种XTP（极限事务处理）处理能力如果按照一天八小时高峰运转的话就是3.36亿笔/天。所以，系统要具备高性能。

除了整个系统需要满足高性能需求之外，还得同时具备高可扩展性(高可伸缩性)。因为从历年来的经验来看，铁道部的并发高峰通常是在节假日发生，如五一、十一长假等，春运则是最大的一个并发高峰。而目前的情况看来，12306在线购票系统虽然不能应对春运高峰，但在平时售票却还是没有问题。这就使得这个系统必须具备高可伸缩性，在并发高峰来临之前，能够通过简单的加机器或者与新浪、淘宝、腾讯等大型互联网公司合作来共同应对这些并发高峰。

在具备上述两个特点的同时，还得具备高可靠性。这么大的并发单靠一台机器是不可能实现，必须采用集群来分散压力。而在集群中，必须防备机器故障，单台机器故障之后不能影响其他机器的正常运转，并且还必须在短时而将故障修复。

除了上述三大必备性能之外，如果想拥有更好的用户体验，那么还得具备一些其他的特点。目前移动互联网正飞速向前发展，各种智能移动终端(如智能手机、平板电脑)层出不穷，作为一个方便可行的系统，那么还应该对这些移动终端提供支持。另外，从现今角度除外，铁道部所售出的总票数是远远小于想要买票的人数的，供小于求，必然导致投机分子的存在，如“黄牛”，那么这个系统就还得作出一些措施来防范利用脚本、程序进行刷票的行为。刷票也是增加并发的一个因素之一，防止刷票也从另一个方面减少了并发，提高整个系统的可用性。

3.数据库设计

从用户操作角度来看，这个业务流程是非常清晰的。主要几个功能点就是：注册用户、查询余票信息、确认订票、支付票款、安全控制、取票。除了取票操作由用户到售票点/取票机器完成的话，其它的功能都在12306 互联网售票系统中实现。12306大致购票流程如图1所示。根据这些功能设计出来的12306系统的功能模块相对来说还是比较少的，然而就是由于功能逻辑上简单让很多实现人员对它比较轻视，使用传统的设计理念来应对，却没有预料到他在春运高峰期间所面临的并发压力是如此吓人，这种并发压力如此吓人到让应用系统性能急剧退化，导致现有的12306系统的问题。当然，功能模块的简单也给我们解决这么吓人的并发能力提供了可能。

其实，高并发性系统的瓶颈很大程度上决定于数据库的设计。目前购票系统的瓶颈，在于ACID的实现关键：锁。由于锁具有一定程