本文深入分析12306订票系统面临的挑战与解决方案，包括车次查询、下单处理及系统架构设计等内容。面对春运高峰期间的巨大访问量，文章探讨了如何通过前端缓存、数据库查询优化及异步处理等方式提高系统稳定性和用户体验。
列车在线订票系统的业务逻辑比较简单，不用多说。可能的瓶颈有两个，一个是车次和剩余票量的查询，一个是下单。在设计软件架构之前，需要先研究产品需求、软硬件条件、网络环境以及关联系统的接口，但这些资料无从获得，所以只能做几点分析和假设，做为设计的前提条件。
1、2012年铁路春运是2.35亿人次，去程售票的那几天应该是订票的最高峰点，假设是3天内订出1.2亿张票，那么每天是4000万张。由于还有车站窗口、电话、代售点等渠道，所以每天通过网站售出的票应该小于4000万张，这里假设2000万张是由网站售出的。
2、如果2000万张票是在一天内均匀地订出，那么每秒钟大约是230张。中国排名前100位的网站应该都会超过这个事务量，不会有什么难题。问题是，订票网站是在一个固定时刻（早上6：00）开始放票，考虑一个极端的情况：早已守候在电脑前的2000万用户在准点开始按下按钮下单，并且都在1分钟时间内订到了票，那么系统需要每秒33万的事务处理能力，这至少需要上千台服务器的集群才能按时处理完。（按照网上有关12306建设资金的报道来看，服务器投入肯定远远不到这个数。）实际情况当然不会这么极端，但必须保证整个系统有非常好的横向扩展能力，以便在必要的时候添加设备扩展服务能力。车站窗口、代售点和电话售票之所以不会产生这样的峰值，原因是这些渠道都是有人工受理，效率足够低，低到用户需要排几个小时的队来等候，自然就把峰值给抹平了。
3、前面还不是最大的问题。铁道部应该还有个核心数据库，保存最权威的票务数据，网络订票系统、电话订票系统和代售点必须与这个数据库对接以提交订单记录和获得准确的车票余量信息。至于这个接口有多少条连接，每秒允许多少次事务，那就不得而知了。这里我们假定接口要么足够宽，宽到不会成为瓶颈，要么在事先已有固定数量的车票分配给了网络订票系统，这样网络订票系统就可以根据这个固定数量自主地接受订单，然后在后台慢慢地把订单数据传给核心数据库。否则，就好像8车道的马路一下变成了2车道，无论如何也不可能让用户畅通无阻地订到票。
有了上面的分析和假设，可以考虑以下设计方案。
1、车次和剩余票量的查询。考虑到车次查询量可能是订单数量的数倍至数十倍，不能让用户提交查询请求时直接去主数据库检索数据，而应该采用前端+缓存+检索+数据库的多层逻辑结构。数据库存放持久化的权威数据并保证数据的一致性；缓存层负责把车次、余量等数据放到内存中以保证最好的查询性能，并有比较好的横向扩展性；检索机负责定时（例如每5秒一次）去数据库检索所有车次信息并主动更新缓存机上的数据；前端负责响应来自用户的web请求。这个架构无法保证用户看到的车票余量是实时准确的（比如有数秒的滞后），但由于用户从看到车票余量到完成订单之间肯定是有时间间隔的，在订票高峰期和票量较少时本来就无法保证“在看到有票的情况下一定能订到票”（技术上能够实现这一点，但代价非常大），所以这个缺陷并不明显，是个很划得来的折中。注意是检索机负责将车票数据抓出来并更新到缓存机上，这是保护数据库并使缓存层能够线性扩展的关键方法。另外查询页面需要采取防频繁刷新的措施，这个在前端机上设置web server策略即可。
2、下单部分由于要更新车票余量，必须保证数据的一致性，扩展性不可能很好，因此是整个系统中最为脆弱的一环。实现的方法分同步处理和异步处理两种。同步处理就是用户选择完车次正式下单订票后，立即锁住车票记录并检查车票真实余量，如果大于1，那么余量减1，解除锁定并回复用户订票成功进入支付流程，否则解除锁定回复订票失败请用户选择其它车次。这是订票系统的标准流程，无论用户量大还是小，处理流程都是一样的。为了支撑春运这种极端情况下的高访问量，需要提高订单处理的并发吞吐量和单个事务的处理速度。提高吞吐量可以将不同车次的车票数据分拆到不同的物理服务器上，提高订单处理速度可以考虑取消关系数据库，将车次数据放到内存中并用原生语言实现订单处理逻辑。有一个比较值得考虑的措施是在用户下单前用图片或者短信的方式要求用户二次验证，这既可以防止刷页面，也可以使峰值变得更平缓。异步处理就是在用户提交订单时并不立即告诉用户订票成功或者失败，只是将订票请求放入队列里排队，订单成功处理后再通知用户。处理优先级上采用时间排序或者抽签都可以，不过抽签适合在非常时期采用，并不适合作为一个标准策略，这多少增加了系统开发的复杂度。采用异步的方式将会在最大程度上避免用户下单高峰造成的冲击，缺点是用户不知道什么时候能有结果，是否应该尝试其它车次，这对用户体验有一定程度的损伤。
硬件架构方面，负载均衡设备是必须采用的，除了扩展负载能力，也需要扛住DoS攻击。服务器用普通PC服务器就可以了。网络架构方面，内网应该设计成无阻塞的，外网引入三大运营商的BGP带宽，不要用静态带宽。
最后说一句，几千万用户同时下订单，即使是三大互联网巨头的系统，也不一定撑得住，12306网站崩溃并不算太丢人，但需要好好考虑架构优化方案，明年春运不能再倒了：）
1、2012年铁路春运是2.35亿人次，去程售票的那几天应该是订票的最高峰点，假设是3天内订出1.2亿张票，那么每天是4000万张。由于还有车站窗口、电话、代售点等渠道，所以每天通过网站售出的票应该小于4000万张，这里假设2000万张是由网站售出的。
2、如果2000万张票是在一天内均匀地订出，那么每秒钟大约是230张。中国排名前100位的网站应该都会超过这个事务量，不会有什么难题。问题是，订票网站是在一个固定时刻（早上6：00）开始放票，考虑一个极端的情况：早已守候在电脑前的2000万用户在准点开始按下按钮下单，并且都在1分钟时间内订到了票，那么系统需要每秒33万的事务处理能力，这至少需要上千台服务器的集群才能按时处理完。（按照网上有关12306建设资金的报道来看，服务器投入肯定远远不到这个数。）实际情况当然不会这么极端，但必须保证整个系统有非常好的横向扩展能力，以便在必要的时候添加设备扩展服务能力。车站窗口、代售点和电话售票之所以不会产生这样的峰值，原因是这些渠道都是有人工受理，效率足够低，低到用户需要排几个小时的队来等候，自然就把峰值给抹平了。
3、前面还不是最大的问题。铁道部应该还有个核心数据库，保存最权威的票务数据，网络订票系统、电话订票系统和代售点必须与这个数据库对接以提交订单记录和获得准确的车票余量信息。至于这个接口有多少条连接，每秒允许多少次事务，那就不得而知了。这里我们假定接口要么足够宽，宽到不会成为瓶颈，要么在事先已有固定数量的车票分配给了网络订票系统，这样网络订票系统就可以根据这个固定数量自主地接受订单，然后在后台慢慢地把订单数据传给核心数据库。否则，就好像8车道的马路一下变成了2车道，无论如何也不可能让用户畅通无阻地订到票。
有了上面的分析和假设，可以考虑以下设计方案。
1、车次和剩余票量的查询。考虑到车次查询量可能是订单数量的数倍至数十倍，不能让用户提交查询请求时直接去主数据库检索数据，而应该采用前端+缓存+检索+数据库的多层逻辑结构。数据库存放持久化的权威数据并保证数据的一致性；缓存层负责把车次、余量等数据放到内存中以保证最好的查询性能，并有比较好的横向扩展性；检索机负责定时（例如每5秒一次）去数据库检索所有车次信息并主动更新缓存机上的数据；前端负责响应来自用户的web请求。这个架构无法保证用户看到的车票余量是实时准确的（比如有数秒的滞后），但由于用户从看到车票余量到完成订单之间肯定是有时间间隔的，在订票高峰期和票量较少时本来就无法保证“在看到有票的情况下一定能订到票”（技术上能够实现这一点，但代价非常大），所以这个缺陷并不明显，是个很划得来的折中。注意是检索机负责将车票数据抓出来并更新到缓存机上，这是保护数据库并使缓存层能够线性扩展的关键方法。另外查询页面需要采取防频繁刷新的措施，这个在前端机上设置web server策略即可。
2、下单部分由于要更新车票余量，必须保证数据的一致性，扩展性不可能很好，因此是整个系统中最为脆弱的一环。实现的方法分同步处理和异步处理两种。同步处理就是用户选择完车次正式下单订票后，立即锁住车票记录并检查车票真实余量，如果大于1，那么余量减1，解除锁定并回复用户订票成功进入支付流程，否则解除锁定回复订票失败请用户选择其它车次。这是订票系统的标准流程，无论用户量大还是小，处理流程都是一样的。为了支撑春运这种极端情况下的高访问量，需要提高订单处理的并发吞吐量和单个事务的处理速度。提高吞吐量可以将不同车次的车票数据分拆到不同的物理服务器上，提高订单处理速度可以考虑取消关系数据库，将车次数据放到内存中并用原生语言实现订单处理逻辑。有一个比较值得考虑的措施是在用户下单前用图片或者短信的方式要求用户二次验证，这既可以防止刷页面，也可以使峰值变得更平缓。异步处理就是在用户提交订单时并不立即告诉用户订票成功或者失败，只是将订票请求放入队列里排队，订单成功处理后再通知用户。处理优先级上采用时间排序或者抽签都可以，不过抽签适合在非常时期采用，并不适合作为一个标准策略，这多少增加了系统开发的复杂度。采用异步的方式将会在最大程度上避免用户下单高峰造成的冲击，缺点是用户不知道什么时候能有结果，是否应该尝试其它车次，这对用户体验有一定程度的损伤。
硬件架构方面，负载均衡设备是必须采用的，除了扩展负载能力，也需要扛住DoS攻击。服务器用普通PC服务器就可以了。网络架构方面，内网应该设计成无阻塞的，外网引入三大运营商的BGP带宽，不要用静态带宽。
最后说一句，几千万用户同时下订单，即使是三大互联网巨头的系统，也不一定撑得住，12306网站崩溃并不算太丢人，但需要好好考虑架构优化方案，明年春运不能再倒了：）
扫一扫
737
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
