列车在线订票系统的业务逻辑比较简单,不用多说。可能的瓶颈有两个,一个是车次和剩余票量的查询,一个是下单。在设计软件架构之前,需要先研究产品需求、软硬件条件、网络环境以及关联系统的接口,但这些资料无从获得,所以只能做几点分析和假设,做为设计的前提条件。
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网站崩溃并不算太丢人,但需要好好考虑架构优化方案,明年春运不能再倒了:)
分享到:
相关推荐
然而,在2012年春运期间,由于访问量超出设计预期,12306网站在高峰期出现了一系列问题,如页面打开缓慢、查询和下单报错、后台系统过载、用户体验不佳等。 主要问题的根因分析包括: * 请求高峰响应迟缓:放票时...
《2021 Java互联网架构师...以上知识点构成了一条完整的Java互联网架构师学习路径,通过深入理解和实践这些内容,开发者可以提升在分布式系统设计、性能优化和高并发处理等方面的能力,从而胜任互联网架构师的角色。
系统改造中的困局表现在架构师需要不断“缝缝补补”,架构的包袱问题以及对架构师而言长期的约束和挑战。 造成这种状况的原因之一是架构师们通常面对需求驱动的项目,往往只能做到最小化修改,而无法从全局的角度...
《2014大数据架构师峰会》是一次聚焦大数据领域的重要会议,汇聚了业界的顶尖专家和架构师,共同探讨大数据技术的最新进展和实际应用。本次峰会的议题广泛,涵盖了大数据的各个方面,包括但不限于数据分析、存储解决...
秒杀系统之所以难以设计和实现,主要是因为其特殊的需求特性:在短时间内,大量用户会同时尝试获取极其有限的商品库存。例如,小米手机的秒杀活动,可能仅有1万部手机,但却会有数百甚至上千万的用户在同一时间涌入...
### 架构师2013年2月刊...通过以上分析可以看出,《架构师》2013年2月刊不仅关注软件开发过程中的效率提升和资源优化,同时也聚焦于新兴技术(如Go语言)的应用和发展趋势,为读者提供了丰富的技术知识和实践经验分享。
从描述“12306.zip”来看,我们可以推测这个压缩包可能包含了与12306网站设计或开发相关的文件。 标签为空,这意味着我们没有额外的信息来指导对压缩包内容的理解,我们将基于文件名来推测其内容。 文件名称列表...
而架构师和开发人员则会关注更深层次的性能因素,如应用架构合理性、代码效率、内存管理、线程同步和锁机制等。运维工程师则需要监控服务器资源利用率、数据库性能、SQL执行效率以及系统的稳定性和高可用性。 性能...
总的来说,2013年中国数据库大会-11的演讲中,童家旺深入探讨了CAP定理的理论和实践,分析了其在不同场景下的应用,并提出了分布式系统设计时的重要考量因素,为数据库开发者和架构师提供了宝贵的参考。
而Java的学习路径,从初级到高级,涵盖了前端开发、后端接口对接、数据库操作、网络编程、设计模式、微服务、大数据处理等多个层面,使得学习者能够逐步成长为精通Java的架构师。 云和数据的Java大数据课程,特别...
以上内容涉及了旅游市场分析、投资建议、数据分析、行业动态和风险管理等多方面的知识点,不仅为行业分析师和投资者提供了信息参考,也对社会服务行业的整体市场环境和具体公司的表现进行了深入探讨。