专家观点   

看社区专家们的12306体验

时间:2013-02-06 10:49:00

由于春运,铁道部官方订票网站12306流量暴增,其Alexa排名一度进入前200,网友戏称,12306已经成为“全球最大、最牛的电商网站”。由于流量激增,12306系统频频瘫痪,一度出现登不上去、登上去抢不了票、抢到票需排队、排队后出票失败等局面。系统的用户体验、性能遭到用户大量的不满。 

我们邀请了几位系统架构方面的专家,请他们从技术的角度为你剖析12306(我们会陆续增加其他几位专家的回复)。同时我们还从论坛活动中选取了一些精彩回复。

 

您是否在春节/国庆期间在12306上买过票?谈谈该系统的用户体验!


范凯   写道
春运和国庆期间没有买过。但去年夏天在12306上面买过票,结果没有买到票,改买了飞机票。 

我只用过一次,体验不深。感觉系统不太稳定,我访问的时候看到过Java出错抛出的错误堆栈信息。


陈雄华   写道
有。界面很象是企业MIS,显得很粗糙,交互性,体验性都感觉很次。


runfriends(来自论坛回复) 写道
我知道它很难用,所以我从来没用它买过票。去年国庆节查询个票,慢的要命。 

从sql的拼写到页面优化,从程序架构到服务器架构都需要全面重构。居然不是参数化查询sql,而是查询参数拼到sql里的,完全是一群业余选手的习作。  

应该采用js、css、图片、html都应该启用gzip压缩,所有css应减少到一个,js文件该合并的合并,能重用的重用,页面背景图应尽量合并成一个文件。尽量减少http请求数。

12306在去年国庆之前进行了改版,加入了排队系统,您认为加入排队系统的目的是什么?缓解了哪些问题?

范凯    写道
对具体情况我不太了解。我猜测,实时购票是一个高并发的在线事务处理系统,需要通过排队系统来缓解事务并发造成的锁定吧。


陈雄华    写道
排队是缓解资源并发的一次不错的策略,可以在后端资源不足时,将客户端请求暂存在池中,方便系统资源的调度。


runfriends(来自论坛回复) 写道
刚开始的时候看到网上很多人说它有一个巨大的事务。后来又加入了排队系统。至于为什么个人猜测可能是为了降低数据库压力。 

而实际上,用户并发量并没有变化,排队导致大量访问不能尽快返回,占用了大量系统资源。实际上这样做降低了系统吞吐量。数据库压力有没有降低先不说,系统吞吐量肯定会降低。


czwlucky(来自论坛回复) 写道
我认为增加这个功能的意义在于,当你不能立即买上票时,不用再不停的反复刷新提交了,相当于银行里发给你一个“号码”,等叫你时你过来买票就是了,不用站那儿傻等。一方面增强了用户体验感,另一方面也能节约反复请求带来的压力。 

但我认为买票难根本原因不在于这个,12306网站的压力自然是大的,但这表面的背后却隐藏着更多的问题,为什么一票难求? 我们问自己一个问题:究竟一列火车有多少张票可卖? 你会发现没有答案! 如果真的没有答案,那即便你把12306刷到爆,也无济于事。 

所以我认为,在系统设计上不是问题,像淘宝、天猫一样有大量的访问者,解决方案也不是就一个。 问题还是在于业务的设计上,只有把出票规则定合理了,系统才能更好的为大家服务,我们也不用去刷网站了,压力自然也会因此而小一些。 

无论是从新闻上了解的,还是我亲身经历的,都证明从始点站开始买票会相对容易些,因为开始出票时,票数还是较多的(虽然也不是很多,大家都似懂非懂的),但从中间站点开始买票,票数少的可怜,甚至是0(网络延迟造成的)。这里面有一个二次售票的概念,怎么把这个二次售票的问题解决了才可能改善购票难问题。 

二次售票我相信有它存在的理由。 但问题时它存在的理由真的注定它只能是现在这样的方式存在吗? 我也相信这个业务规则一定有改进的地方。 

公交车,火车,长途汽车,在售票方式与运输距离,输送量上有很大差别,但运输本质没有差异。我们是不是能参考公交运输中的一些优点呢?比如是不是有可能增加同一线路的车次? 如果不能增加车次,是不是可以考虑沿途换乘方案?

在去年国庆之前12306进行了改版,加入了排队系统,您认为加入排队系统的目的是什么?缓解了哪些问题?

 

范凯    写道
对具体情况我不太了解。我猜测,实时购票是一个高并发的在线事务处理系统,需要通过排队系统来缓解事务并发造成的锁定吧。


陈雄华    写道
排队是缓解资源并发的一次不错的策略,可以在后端资源不足时,将客户端请求暂存在池中,方便系统资源的调度。


runfriends(来自论坛回复) 写道
刚开始的时候看到网上很多人说它有一个巨大的事务。后来又加入了排队系统。至于为什么个人猜测可能是为了降低数据库压力。 

而实际上,用户并发量并没有变化,排队导致大量访问不能尽快返回,占用了大量系统资源。实际上这样做降低了系统吞吐量。数据库压力有没有降低先不说,系统吞吐量肯定会降低。


czwlucky(来自论坛回复) 写道
我认为增加这个功能的意义在于,当你不能立即买上票时,不用再不停的反复刷新提交了,相当于银行里发给你一个“号码”,等叫你时你过来买票就是了,不用站那儿傻等。一方面增强了用户体验感,另一方面也能节约反复请求带来的压力。 

但我认为买票难根本原因不在于这个,12306网站的压力自然是大的,但这表面的背后却隐藏着更多的问题,为什么一票难求? 我们问自己一个问题:究竟一列火车有多少张票可卖? 你会发现没有答案! 如果真的没有答案,那即便你把12306刷到爆,也无济于事。 

所以我认为,在系统设计上不是问题,像淘宝、天猫一样有大量的访问者,解决方案也不是就一个。 问题还是在于业务的设计上,只有把出票规则定合理了,系统才能更好的为大家服务,我们也不用去刷网站了,压力自然也会因此而小一些。 

无论是从新闻上了解的,还是我亲身经历的,都证明从始点站开始买票会相对容易些,因为开始出票时,票数还是较多的(虽然也不是很多,大家都似懂非懂的),但从中间站点开始买票,票数少的可怜,甚至是0(网络延迟造成的)。这里面有一个二次售票的概念,怎么把这个二次售票的问题解决了才可能改善购票难问题。 

二次售票我相信有它存在的理由。 但问题时它存在的理由真的注定它只能是现在这样的方式存在吗? 我也相信这个业务规则一定有改进的地方。 

公交车,火车,长途汽车,在售票方式与运输距离,输送量上有很大差别,但运输本质没有差异。我们是不是能参考公交运输中的一些优点呢?比如是不是有可能增加同一线路的车次? 如果不能增加车次,是不是可以考虑沿途换乘方案?

春运购票,与淘宝、天猫在双11期间的促销有什么异同之处?

 

范凯    写道
相同之处应该都是高并发的在线事务处理系统,我猜测主要不同之处在于12306背后的票务系统可能不是一个集中式的系统,而可能连接各个铁路局票务系统,数据同步的实时性和一致性可能更复杂一些。当然这些都仅仅是猜测,可能很不靠谱。


陈雄华    写道
淘宝一天就处理了1亿零580万,而12306一天处理的交易仅仅166万条 ,如果从并发性上来说,淘宝的并发量远比12306大,但天猫的商品信息,促销数据都可以做缓存,做CDN,而12306的“商品”是一个个座位,这些座位必须通过后端数据库即时查询出来,状态的一致性要求很高。 

从这点上看,12306的商品信息很难利用到缓存,因此12306查看“商品”的代价是比较大的,涉及到一系列的后端数据库操作,从这个角度讲,12306的复杂度是高于天猫的。

淘宝、天猫是如何应对这种超大规模并发的?如何hold住暴增的流量?

 

范凯    写道
这个我确实不知道,需要请阿里系的专家来解读。 

(小编:阿里专家正在路上,Coming Soon!敬请期待!)


陈雄华    写道
这是一个系统性的功能,简而言之就是:分布式和缓存。

 

您认为这些经验中哪些可以应用到12306?

 

范凯    写道
据我个人了解的八卦,去年春运12306宕机之后,曾经求教过阿里,当时阿里派出了一支技术团队去了解情况和提供建议。 实事求是的说,12306相比一年前还是有所进步的,不知道是不是背后有阿里系专家的贡献。

在系统、业务设计上,12306还存在哪些挑战?

范凯    写道
我觉得12306面临的主要挑战就是两个方面: 

  • 一、实时高并发在线事务处理;
  • 二、如何和各个铁路分局票务系统对接,保证数据同步的实时性和一致性。

陈雄华    写道
淘宝的商品相对独立,而12306商品之间的关联性很大,由于CAP定律限制,如果其商品的一致性要求过高,必然对可用性和分区容错性造成影响。 

因此,业务设计上,如果找到一条降低一致性要求时,还能保证业务的正确性的业务分拆之路。举个例子,火车票查询时,不要显示多少张,而是显示“有”或“无”,或者显示>100张,50~100,小于50等,这样就可以减小状态的更新频率,充分使用缓存数据。


czwlucky(来自论坛回复) 写道
12306网站的技术问题或许有多种解决方案(虽然可能并不完美),但最难解决的是业务问题! 

一列火车总共有多少张票?恐怕这个就难回答,即使是铁道上的人也不见得能回答的十分清楚。 

火车跟公交有几分相似,都有固定站点,每个站点都可能有人上下。不同的是,公交车可以先上车后买票,火车只能先买票后上车。我想这才是问题的根本。公交上去了就上去了,上不去可以等下一趟。火车得先有票才能上车,可是卖票规则却成了难解之题。

您认为高性能并发系统架构应该如何设计?关键是什么?

 

范凯    写道
高性能并发系统其实分很多种类,是并发读,并发写,并发长连接,还是并发事务?不同类型的架构设计是不同的。具体到12306就是并发事务,在这个领域,我个人没有什么经验。

陈雄华    写道
1)  优化前端网页 

  • 充分利用CDN,使JS、图片等静态资源的请求能够就近访问(顺便说一下,如果12306订票插件能从google提供的http://cdnjs.com中引用JS,而不去直接引用github的JS,就不会把github搞瘫了)。
  • 将JS、CSS合并,最小化请求数。将JS和CSS压缩,最小化数据传输
  • 启用gzip压缩网页。

2)  群集分发和调度 

据说12306是采用集中式构架的,集中式构架很难应对高并发,也很难水平扩容,分布式不是仅仅将调度服务器,应用服务器,缓存服务器,数据库服务器分开就行,应该进行更细的服务级划分,对业务进行服务细分,做成一个个松散耦合的服务,然后把这些服务独立分布式部署。 

3)  采用分布式会话 

为了可以进行灵活的请求调度,不应采用weblogic、websphere这些应用服务器自身的session管理用户会话,而应该自己管理会话,如将会话保存在独立的集群memcached服务器中,这样每个应用服务就都无状态了,会话的请求可以随意分发给不同的服务器。这也是我的ROP开源项目没有使用HttpSession,而专门抽象出一个SessionManager接口的原因,开发者应该自己去实现这个接口实现分布式会话管理。 

4)  关于数据库设计优化 

数据库往往是系统瓶颈所在,首先应该对数据库进行分库设计,可采用两级水平切割,如首先切割成几个物理库,然后在物理库内部再采用表分割,一般是通过某个业务ID进行取模切割,降低单库及单表的并发性,提高TPS。 

合理采用读写分离技术,做到读写分离,可以一写多读,有效降低数据库的负载,数据的同步可以视情况采取应用层同步写,读取数据库日志更新或直接使用mysql读写分离技术等。 

此外,业务服务化、服务解耦化是关键。


runfriends(来自论坛回复) 写道
个人认为针对不同的系统要有不同的设计方案。 

虽然12306可以归类为电商领域,但是跟通常意义上的B2C还是有巨大的差异。所以单纯从12306上面讨论高性能并发系统架构并没有通用意义。 

不过,有一个思想应该贯彻。那就是所有访问力求分散到不同的服务器处理,不同类型的资源要坚持使用不同的集群服务。动静分离、读写分离,减少一次页面访问的请求数和数据库访问次数,保持小事务粒度,注意线程安全,避免大数据量的查询,建立索引(多表联合、union、非参数化sql、笛卡儿积计算、返回大数据集等数据库操作应该避免)。 

对于变化较小的查询操作可将查询工作交给专门的索引服务器完成。不过个人感觉像12306这样的业务,引入索引的意义不大也没有必要。 

12306的业务需求乍一看似乎都是同一类型的资源,但是我们可能根据车次、卧、软、硬、站、时段、线路等信息将车票这个12306要处理的惟一类型的资源分成若干子类,不同的子类请求由不同的集群处理。

有人提议12306采用NoSQL存储,您认为是否可行?

 

范凯    写道
NoSQL的优势在于海量无模式数据存储和查询,12306的挑战在于并发事务处理,所以用NoSQL无助于解决12306面临的问题。


陈雄华    写道
纯用NoSQL个人认为现在还不成熟,毕竟NoSQL的状态一致性不好。一条可行的路子是MySQL+NoSQL,通过nosql缓解后端MySQL的压力。 

当然这涉及到很多业务流程的优化设计,降低数据一致性要求后才能合理使用NoSQL。


runfriends(来自论坛回复) 写道
事务的粒度应做到购买行为是原子性的,即保证两个人不会买到相同的票即可。每个票种的优先级是一样的,应不同的查询条件保证能尽快的返回。 

实际上每天出售的票种总和远达不到海量的程度。但是每年有几个时段并发量特别大。如果使用大量nosql数据库集群,票量一致性恐怕难以保证;如果使用单台nosql,恐怕吞吐量和实时响应也会像mysql一样难以做到。 

不论什么数据库,都难以完成这么少的数据量却要完成这么大并发量的情况。 

个人认为还是把不同票种分散在不同票池服务器中,完全由程序操作内存完成查询和购买更合适一些,虽然数据结构可能要复杂很多。 

最后根据每个票种的余票量要限制每个票种的查询和购买并发量。超过的就拒绝访问,以节省资源。早死早超生,而不是所有人都耗在买票这个事上。

12306 如果使用开源来实现,您有什么建议?

 

其实用WebLogic应用服务器,Oracle数据库,SSH框架和C3P0连接池都是OK的,但要解决12306面临的并发事务问题,需要系统在基础设施和架构上做很多专门的调整和开发的工作,  这些才是解决问题的关键,和用什么软件和框架关系不大。


陈雄华    写道
预算很大一部分都要来买weblogic、oracle的授权了,好钢用在了刀背上。完全可以用jboss代替weblogic,用mysql代替oracle,把这些省下的钱请技术专家,远比买这些东西好用。 

另外,这种高并发的互联网的应用不建议使用Hibernate,建议直接使用Spring JDBC,毕竟Hibernater操作数据库往往不够细粒度。另外还建议使用Spring MVC替代Struts,Spring MVC比Struts更高效性,页面尽量使用客户端的技术而不要使用服务端的技术实现,如使用客户端的requirejs+underscore客户端模块就比使用服务端的JSP或Freemarker要好,毕竟这样就让客户机来负责页面渲染了,且可以有效地使用CDN。

从目前来看,您认为12306需要着重改善哪些方面?如果让您来设计,您会如何做?

 

12306从前端页面上来看用户体验就比较差,至少从页面设计和前端JS代码上来说就有巨大的改进空间了。后台架构上需要解决高并发事务处理,和分布式数据同步的实时性和一致性问题,在这两个问题上,我个人也没有太多相关实践经验,有一些个人的想法,但还是不误人子弟了,这些方面可以请阿里系的专家来解答。


陈雄华    写道
  • web前端要大笔优化,采用requirejs+jquery+backbone+underscore框架,web应用要进行部署优化js合并,js压缩;
  • 所有业务SOA化,以便可以将业务分布式部署;
  • 数据库分库,二级切分,实现读写分离,从业务流程调整上降低对数据一致性的要求;
  • 充分使用nosql技术,通过流程优化和调整,使nosql承担大量的数据访问请求,使nosql成为保卫后端mysql的一道坚强的保障。


runfriends(来自论坛回复) 写道
铁道部应该对每节车厢、每个车次要卖出多少站票、软座、硬座、卧铺有一个规划。购买同一车次和票种的人不会造成太高的并发。因此关键在于查询和买票服务器集群的设计和实现。 

设计一个票池系统,按照车次、线路、区域划分票池,按照车次、站、软、硬、卧分类不同票种,将每个票种分配到票池集群的某台服务器上。买票时肯定已经确定了票种,通过一致性哈希准确定位指定票种所在的服务器。票池系统完全采用内存储存预售票票种、票量信息。 

查询、购买分开不同的集群,两个集群之间实现余票量同步。保证每个操作迅速返回,不必保证查询和购买实时同步,也不必保证查到的票在购买的时候一定能买到。

庄表伟:与12306相关的一些思考

 

铁路购票的12306网站,我也在上面购买过火车票,虽然的确存在着各种各样的问题,但是最终确实成功的买到了票,而且也顺利的坐上了火车。也许因为不是在春运期间购买的缘故,说实话,我对它的印象没有那么糟糕。 

当然,如果我们看看网络上的新闻,搜索微博里的各种人对12306的批评、责骂与嘲讽...是的,他们做得糟透了。 
但是,在我看来,痛骂他们的技术如何垃圾,并没有追踪到问题的本质,本文试着继续深入的追究下去。 

一、不要外包 

分布式系统的第一原则是:不要分布式!而外包系统的第一原则是:不要外包!前一句,有很多高人说过,后面这一句,是我杜撰的。而我之所以会提到这个问题,是因为网络上有很多类似的观点,似乎是因为这次的外包开发没有找好,如果将这个活包给淘宝、支付包、京东、亚马逊之类的大型成熟电商来做,就万事大吉了。事实上,这些成熟电商之所以成熟,恰恰是经过了长期的改进完善之后的结果,而且,一定是他们自己的开发团队完成的。另一个近在眼前的例子,想想苏宁易购吧。直接一点说,如果这事外包给淘宝来做,就算淘宝有人有时间也愿意接这个活,也肯定干不好。 

为什么外包通常搞不好呢?因为他们不是自己人,他们没有跟着一个企业同步成长的体会。因为他们希望获得整理明白后的一本“需求汇总”,他们害怕反复不断变动的需求。当然,我这个观点,可能存在着某种偏见,但是,越是变动复杂,极其核心,影响巨大的系统,我都强烈的不建议交给外包来完成。 

二、循序渐进 

一个非常庞大的电商网站,都不是一天建成的,淘宝不是一天建成的,亚马逊、京东也不是一天建成的。我们怎么能够希望12306在第一次推出的时候,就能够支撑春运购票这样变态的需求呢? 

为了限制需求,其实可以有很多种办法:比如限制特定的班次(只卖高铁票、卧铺票、只卖从起点到终点的票等等)、比如网络购票加价,比如只在平时提供使用而不是在春运期间投入使用。总之,不需要一开始就服务所有的用户,选定一个较小的范围,先服务好,再循序渐进,逐步扩大服务的范围、提升服务的效率与质量,才是较为稳妥的办法。 

三、排队系统 

在12306网站推出之前,我们的购票体验同样糟糕,客观的说,只怕更糟。但是为什么反而没有什么人来骂呢?很多人在说,因为12306的用户体验做得不够好,但是我想要反其道而谈之。如果网站的用户体验能够像当初的实际购票一样差,只怕反而更加好一些。 

回顾一下传统的购票流程吧:来到购票大厅,首先要选择一个窗口排队,运气不好的时候,自己选择的那一队恰恰是最慢的。经过几个小时甚至十几个小时的排队,我们来到了窗口前,遇到的是心烦意乱的售票员大妈,她们通常态度恶劣却动作迅速,到哪里?没有!卖完了!只有站票了,要不要?不要就换下一个!看清楚了吗?确认我就出票了。 

窗口前的购票者,在身后巨大的目光压力之下,在面前不耐烦的语言压力之下,做着迅速的购买决定。这种购票体验,真的是太烂了。唯一的好处是:当我们拿到了那张纸片,就放下心来,肯定能回家了。 

假设,我们一开始就把12306做成一个售票大厅的模式,总共就100个窗口,每个人都登录以后先排上10个小时的队,一旦排上了,轮到自己了,购票时间不会超过2分钟。那么,虽然是漫长的10小时的等待,却不需要时刻守在电脑前站着。这种体验,我想就足够了。 

从12306的角度而言,完全可以将系统按照每个城市一个售票大厅的方式来部署,一开始假设只有100个窗口,人再多也是这么排着。等到系统稳定了,能力上去了,再慢慢的增加窗口的数量,缩短排队的时间。痛骂的人,将会少很多很多。原因很简单,不要一开始就给用户一个很高的期待值,然后再让他们失望,而是基于现状,小步快跑的做着改进。反而会有较好的效果。 

这种做法,其实在网游行业是基本常识,随着用户数量的增加,新增一组一组的服务器,以容纳更多的玩家,而不是一开始就放开让所有的人进来玩。宁可不让他们进来,也不是让他们进来以后,在游戏场景里玩排队的游戏。 

四、代售机制 

火车票代售网点,其实在很多年前就已经出现了。我认为这个模式其实很不错,是一个分散客流提高效率的好办法。假设,我们不做12306的网站,而是开办成千上万,甚至上百万的火车票代售网店,情况会变成什么样子呢?假设,我们降低火车票代售点的准入门槛:交XX万押金,下载一个代售点客户端,自备电脑,自寻场地,自寻客源,自己去做生意。搞一个简单的审批流程,每年新增批准10万个个体户代售点。 

这样的好处是:每个企业,每个公司,每个街道办事处,都可以自己申请成为一个代售网点,然后解决身边人购票的难题。在最大限度内,减少集中排队的压力。另一方面,由于审批流程可以控制代售点的数量,同时也就保证了系统的压力始终以可控的方式增长。 

我在内心默默推理了一下,似乎是一个较为简单可行的办法。 

五、架构演进 

在网络上,我们常常能够看到很多给12306支招的方案,总之各种前卫,各种先进。但是,在我看来,越是复杂的系统,越是怕这种“革命”,哪怕过去的架构再不合理,也最好不要贸然引入过于激进的架构,在原有的架构下逐步演进,逐步扩展,逐步寻找小范围的、能够被改进的点来推进,才是较为合理的做法。 

我能够看到的很多对于12306的批评,常常是一直站着说话不腰疼的姿态,说实话,并不可取。就目前来看,我们最乐观的估计是,12306能够顶住压力,逐渐改进、完善,在3~5年之后,渐渐淡出人们的视线,成为一个普通的,日常必须使用的,生活服务类网站。 

六、抓大放小 

说起用户体验糟糕,每个人都可以滔滔不绝的说很多话。我们常常会看到这样一种言论:铁道部的官员,他们用12306吗?如果他们也用,难道不会更加促使12306网站更快的改进吗? 

其实,从技术人员的角度而言,怕的就是大老板亲自抓用户体验。当然,比这个更加糟糕的,则是每个领导,都对用户体验,说三道四。 

对于12306的改进,我想不必过于关注细节,追踪一些统计数据的变化情况就好。比如:平均购票等待时间;退票率与废票率;列车上座率等等。至于如何提高这些数据,领导们千万不要事无巨细的参与讨论,大家各自努力就好。有更多的事情得靠领导们努力:比如切实提高运力...

 

其他

 

 

runfriends(来自论坛回复) 写道
第一:专业的事就应该找专家来做。不论招标也好,还是私下里寻找合作伙伴也好,都应该挑选有高并发、高吞吐量这方面的专家完成。而这样的人只存在于大型电商公司。铁道部花了那么多钱却没去找正确的人来做这件事。 

第二:关键在于目的是什么。目的是花钱,还是为了方便买票,还是其它目的? 

第三:关于抢票插件的问题。如果网站本身响应迅速,抢票插件也没什么市场了。关键在于要去考虑怎么改善用户体验,而不是要去禁抢票插件。上头意识从来都没有做正确的事。 

酷壳博主说,就为了一年那么几次,十几天的高访问量,花那么多钱开发一个购票网站,也就铁道部能做的出来了。 

个人觉的,更好的做法是。铁道部应该可以把购票api开放出来。让所有人都可以通过这些api开发购票网站。让这些网站之间形成竞争。 

这样访问压力分散到了不同公司的服务器,而铁道部就是做了一个平台。这样做的效果更好。就像现在很多类似携程这样的网站都可以在上面订飞机票一样。 

另外,通过云计算将根据一年中不同时段的压力弹性改变计算资源,也可以节省成本。
wangshu3000(来自论坛回复) 写道
问题瓶颈(Front to Backgroud): 

  • Web端,每天请求上亿,压力很大,包括html js css img等,需要占用大量带宽
  • 身份证认证,可能会用到第三方的认证,或者铁道部协议,获取到身份证信息,这个查询量也很大
  • 交易,银行性能应该不在瓶颈
  • 订票记录,采用按照车次分表,应该是集中控制集群,分表 分区 索引,速度不会太慢
  • 查询余票,每次交易成功,更新订票数据,更新量较大
分析: 

  • 网站的内容可以分布式部署,采用apache+xxx分发,后台多个镜像分担请求,进行冗余;图片、css、js、html、动态jsp、后台业务,分别部署;并且对web进行部分优化,压缩,合并,缓存等。
  • 每次订票数据流量在2M,每天1200w/8h/60min/60s,每秒420个订票请求,840M/s的网络流量,根据分布6种文件140M/s,一般光纤网络就可以了;每种文件下面分布几个cluster,性能足以支持,每秒70个请求。并不大
  • 身份证第三方只要支持每秒1k+的并发请求就足以支持订票了。很容易
  • 如果本地验证身份证,根据省份、建立表,根据城市建立分区表,速度也会非常快,用身份证做主键,一条身份证信息0.2k,全国13亿=260G的数据量,easy,做个RAC就足以支持这种压力了
  • 银行不考虑
  • 车次,订票记录,余票记录,每天7kw的记录,14G/天,保存20天,才280G
  • 订票业务按照省份分布,每个省份单独结算
  • 整体采用SOA架构,都是服务,每个服务专注自己的业务,优化自己的服务
  • 银行交易需要大量校对和核实业务,也许要一些投入,算成本;需要对仗,异常情况分析等,属于不是直接业务的处理,不能省略。
  • 硬件IO,视情况而定优化,EMC盘阵,RAID;数据分布存储,根据数据量划分group。
  • CPU,内存通过简单增加刀的CPU和内存来提高。
  • 网络,根据地点,业务分布到不同的节点进行购票,每个节点的网络吞吐可以控制,不会太高

 

来源:PHPchina

Notice: Constant RUNTIME already defined in /srv/html/srccn/news/config.php on line 15 Notice: Constant ROOTDIR already defined in /srv/html/srccn/news/config.php on line 16 Notice: Constant SITEDIR already defined in /srv/html/srccn/news/config.php on line 17 Notice: Constant DATAURL already defined in /srv/html/srccn/news/config.php on line 20 Notice: Constant VERSION already defined in /srv/html/srccn/news/system/kernel.php on line 17 Notice: Constant COREDIR already defined in /srv/html/srccn/news/system/kernel.php on line 18 Fatal error: require(): Cannot redeclare class mysql in /srv/html/srccn/news/system/kernel.php on line 22