12306:分布式内存数据技术为查询提速75倍 - 开源中国社区
Float_left Icon_close
12306:分布式内存数据技术为查询提速75倍
自由的开源 2013年12月30日

12306:分布式内存数据技术为查询提速75倍

自由的开源 自由的开源 发布于2013年12月30日 收藏 112

阿里云高性能云服务器,2折起! >>> >>>  

  背景和需求

  中国铁路客户服务中心网站(www.12306.cn)是世界规模最大的实时交易系统之一,媲美Amazon.com,节假日尤其是春节的访问 高峰,网站压力巨大。据统计, 在2012年初的春运高峰期间,每天有2000万人访问该网站,日点击量最高达到14亿。大量同时涌入的网络访问造成12306几近瘫痪。 中国铁道科学院电子计算技术研究所作为12306互联网购票系统的承建单位,急需寻求办法解决问题。

  成功解决:速度提高75倍以上

  2012年3月开始,铁路总公司(原铁道部)开始调研、改造12306。2012年6月选择了Pivotal GemFire分布式内存计算平台(Distributed In-memory computing)改造12306,由铁科院项目小组负责人王明哲主任和资拓宏宇(IISI)信息科技有限公司在铁科院主管朱建生所长领导下提供技术实 施。一期先改造12306的主要瓶颈——余票查询系统。9月份完成代码改造,系统上线。2012年国庆,又是网上订票高峰期间,大家可以显著发现,可以登录12306,虽然还是很难订票,但是查询余票很快。2012年10月份,二期用GemFire改造订单查询系统(客户查询自己的订单记录)。2013年春节,又是网上订票高峰期间,大家可以显著发现,可以登录12306,虽然还是很难订票,但是查询余票很快,而且查询自己的订票和下订单也很快。

  根据系统运行数据记录,技术改造之后,在只采用10几台X86服务器实现了以前数十台小型机的余票计算和查询能力,单次查询的最长时间从之前的15秒左右下降到0.2秒以下,缩短了75倍以上。2012年春运的极端高流量并发情况下,系统几近瘫痪。而在改造之后,支持每秒上万次的并发查询,高峰期间达到2.6万个查询/秒吞吐量,整个系统效率显著提高。如上图所示。

  订单查询系统改造,在改造之前的系统运行模式下,每秒只能支持300-400个查询/秒的吞吐量,高流量的并发查询只能通过分库来实现。改造之后,可以实现高达上万个查询/秒的吞吐量,而且查询速度可以保障在20毫秒左右。

  新的技术架构可以按需弹性动态扩展,并发量增加时,还可以通过动态增加X86服务器来应对,保持毫秒级的响应时间。

  梦里寻它:技术革命一步跨越三代

  12306能够取得这样翻天覆地的效果,靠技术上的小修小补是不可能的,必须有全新的思路,能够给性能提升带来杠杆式的作用。12306发现GemFire分布式内存数据平台就是这样一种技术。

  GemFire分布式内存数据平台的技术原理如上图所示:通过云计算平台虚拟化技术,将若干X86服务器的 内存集中起来,组成最高可达数十TB的内存资源池,将全部数据加载到内存中,进行内存计算。计算过程本身不需要读写磁盘,只是定期将数据同步或异步方式写 到磁盘。GemFire在分布式集群中保存了多份数据,任何一台机器故障,其它机器上还有备份数据,因此通常不用担心数据丢失,而且有磁盘数据作为备份。 GemFire支持把内存数据持久化到各种传统的关系数据库、Hadoop库和其它文件系统中。

  大家知道,当前计算架构的瓶颈在存储,处理器的速度按照摩尔定律翻番增长,而磁盘存储的速度增长很缓慢,由此造成巨大高达10万倍的差距(如上图)。这样就很好理解GemFire为什么能够大幅提高系统性能了。

  按照计算与存储的关系,我们可以将计算架构分为四代:

  第一代,基于磁盘的单一系统:计算过程中需要从磁盘读取数据。小型机、大型机是其中的佼佼者,将单一系统的性能做到极致。

  第二代,基于磁盘的分布式集群系统:计算过程中需要从磁盘读取数据,但通过分布系统将数据分散到不同的服务器磁盘上,提高整个系统的处理能力。目前很多大型互联网和电子商务公司采用基于X86服务器的分布式集群系统,依靠海量的X86服务器部署解决高流量并发的问题。

  第三代,基于内存的单一系统:将整个数据库放在内存中,计算过程不需要从磁盘读取数据。整个系统的性能取决于单一系统的性能。传统的内存数据库就是这样的系统,对于企业级的应用可以很好地解决访问速度的问题,但面对海量数据或是海量并发访问的扩展性问题就无能为力。

  第四代,基于内存的分布式集群系统:GemFire就是这样的系统,并行计算是其关键技术之一,因而可以通过增加服务器部署规模,在内存计算的基础上,线性扩展性能。

  12306之前采用Unix小型机架构,采用GemFire技术改造成Linux/X86服务器集群架构,就意味着一下跨越三代。从小型机到大内存X86服务器集群,不仅让性能提升了一个数量级,而且成本也要低得多。

  GemFire是Pivotal企业级大数据PaaS平台的一部分。Pivotal公司的企业级大数据PaaS平台主要有三个层次:云基础架构 层Cloud Fabric、大数据基础架构层Data Fabric、应用开发基础架构层Application Fabric。GemFire属于大数据基础架构层,此外,Greenplum数据库也属于这一层;云基础架构层的技术是Cloud Foundry;应用开发基础架构层的技术是Spring Framework和RabbitMQ等。

  对于此次引入GemFire技术的改造,中国铁道科学研究院电子计算技术研究所副所长朱建生表示:“通过技术改造解决了困扰我们多时的尖峰高流 量并发问题,让全国人民不再因为技术原因而抱怨,我们终于舒了一口气。Pivotal GemFire分布式集群内存数据技术对整个技术改造发挥了关键的作用。同时,感谢Pivotal公司及其实施方项目团队的努力,在技术开改造过程中确保 旧系统顺畅运行、旧系统到新系统平滑迁移,快速实现新系统的上线。”

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:12306:分布式内存数据技术为查询提速75倍
分享
评论(173)
最新评论
0

引用来自“merlinjn”的评论

用一台服务器就可以实现26000次/秒的余票查询,何必用那十多台?12306不是已达技术瓶颈,可提升空间还是蛮大的。
你指的是什么查询啊?查单表啊?你不知道查票还需要大量的运算啊。osc喷子是多,高级黑也不少。你是只做过jee项目吧。
0
用一台服务器就可以实现26000次/秒的余票查询,何必用那十多台?12306不是已达技术瓶颈,可提升空间还是蛮大的。
0

引用来自“fork()”的评论

@红薯 ,感觉无论打开哪个文章,评论都是清一色喷子。12306做得不好这些喷子来试试新的技术和架构?编译器漏洞评论清一色的不屑,难道这里面都是这么高的神?那么多漏洞这些神们为什么不去挖两个来卖卖?动动手指头就能拿到钱啊!我就不信神们都这么清高。。。该白帽子在我的群里,做事为人低调,他只会汇编,表示对高级语言有无限向往。但是他的能力,更这些喷子相比(至少是大多数),我就不说了。

能在OSC看到大神的回复,小生真是三生有辛~现在的OSC 怎么会有这么多喷子。@红薯 能不能好好管一下,不然OSC就是喷子的集中营!
0

引用来自“wolfy123”的评论

问一个问题,为什么12306的证书总是不安全的?求解

那证书不用也没有关系 !支付的时候它的证书是买的。
0

引用来自“zerosky_zerolook”的评论

我感觉最近的网上购票更难!我记得上年还能抢到,但今年一到高峰期,直接就打不开或者没有反应。然后我打开购票的源代码,发现了一个不起眼的大问题:购票页居然出现很多html注释(<!-- -->)。一个并发量要求那么高的页面你给我来这么多注释!!!占用网站出口带宽虽然不是问题,但对服务器造成的压力也是不少的。大家都在抢票,一个人的一张票也有n台电脑在抢。

去年买票真的很容易。虽然说也有很多插件才搞鬼。但那也是5秒刷新一次。乌云上这个漏洞没有修复
http://www.wooyun.org/bugs/wooyun-2010-042062
毫秒级别的刷新频率!再者就是还有数字,球球,百毒,金山等公司推出的**助手。疯狂识别验证码!还有android,ios两个平台的推出,并发不知道有多大!而去年这些是没有的!去年来回都抢到了卧铺。今年是苦逼的站票。。。
0

引用来自“DavidYun”的评论

引用来自“君陌”的评论

「虽然还是很难订票,但是……」
「虽然还是很难订票,但是……」
数据定期刷到硬盘?机房得摆满各国神仙祈祷别断电吧

笑尿了,你不知道机房都有备用电么

网吧主机都有备用UPS(这个不是物流:))!一个备用UPS 可以用两个小时。完全足够了。
0

引用来自“max_sun”的评论

为什么不能用车次建库呢?
前面几个说的,没想明白。举个例子
现在明显是用归属局区分的。

车次建库?车次有L,K,T,Z,D,G,还有纯数字开头的,你算一下,共有多少个车次!还有买票的方式有很多种,比如直达的,半途的,半途后面再接着买的,还有中转的。一个站可以作为起始站,也可以做为中转站(过路站)。你考虑一下 用户要买不同类型的票 你这个逻辑怎么处理!还有扣票,多渠道实时同步问题!
0
吓尿了
0
@红薯 ,感觉无论打开哪个文章,评论都是清一色喷子。12306做得不好这些喷子来试试新的技术和架构?编译器漏洞评论清一色的不屑,难道这里面都是这么高的神?那么多漏洞这些神们为什么不去挖两个来卖卖?动动手指头就能拿到钱啊!我就不信神们都这么清高。。。该白帽子在我的群里,做事为人低调,他只会汇编,表示对高级语言有无限向往。但是他的能力,更这些喷子相比(至少是大多数),我就不说了。
0
问一个问题,为什么12306的证书总是不安全的?求解
0

引用来自“Jacle”的评论

引用来自“刘子玄”的评论

“中国铁路客户服务中心网站(www.12306.cn)是世界规模最大的实时交易系统之一,媲美Amazon.com”

放你麻痹的狗屁,光腾讯的垃圾QQ就能完爆这煞笔12306。还媲美Amazon.com?媲你麻的痹。

+10086

+10010
0
“虽然还是很难订票,但是查询余票很快。”哈哈哈哈……
0
我感觉最近的网上购票更难!我记得上年还能抢到,但今年一到高峰期,直接就打不开或者没有反应。然后我打开购票的源代码,发现了一个不起眼的大问题:购票页居然出现很多html注释(<!-- -->)。一个并发量要求那么高的页面你给我来这么多注释!!!占用网站出口带宽虽然不是问题,但对服务器造成的压力也是不少的。大家都在抢票,一个人的一张票也有n台电脑在抢。
0
购票体验依然很差,没看到有什么效果
0

引用来自“komelio”的评论

引用来自“FreeBlues”的评论

引用来自“白文”的评论

引用来自“CheckStyle”的评论

引用来自“白文”的评论

引用来自“LVAN”的评论

没有看出有什么特点的,革命尚未成功,同志还需努力的,
很奇怪的,为什么不与淘宝等具备大数据量处理公司进行合作的

业务不一样,怎么合作?铁总只能用集中式数据库,淘宝能用分布式的,没法比。

没办法的事情,业务决定了集中式数据库,这个阿里也没太大办法

阿里根本不会有几千万乃至上亿人去访问同一种商品,这是阿里不会跨的原因,不代表阿里技术有多高。

确实,客观地说,基本上没有哪个站点能达到铁路春运订票这种突发访问的量级。

秒杀应该比这个高

秒杀肯定不如他高的。
0

引用来自“自由的开源”的评论

引用来自“白文”的评论

引用来自“komelio”的评论

引用来自“FreeBlues”的评论

引用来自“白文”的评论

引用来自“CheckStyle”的评论

引用来自“白文”的评论

引用来自“LVAN”的评论

没有看出有什么特点的,革命尚未成功,同志还需努力的,
很奇怪的,为什么不与淘宝等具备大数据量处理公司进行合作的

业务不一样,怎么合作?铁总只能用集中式数据库,淘宝能用分布式的,没法比。

没办法的事情,业务决定了集中式数据库,这个阿里也没太大办法

阿里根本不会有几千万乃至上亿人去访问同一种商品,这是阿里不会跨的原因,不代表阿里技术有多高。

确实,客观地说,基本上没有哪个站点能达到铁路春运订票这种突发访问的量级。

秒杀应该比这个高

哪种商品的秒杀的人数和点击率超过12306?

是啊,啥商品能有上千万的人去抢呀,太疯狂了

回楼上 12306也不是这十几亿的人都在买同一趟列车的同一种票,一趟列车的一种票相当于一件商品,这样才能与淘宝比同一件商品的访问量
0
为喷而喷,没意思~
0
媲美这词用在12306上真不合适,不知道改造系统那拨人看不看这文章
0

引用来自“eechen”的评论

该网站的安全证书不受信任!
您尝试访问 kyfw.12306.cn,但服务器出示的证书却不是由您计算机操作系统信任的实体颁发的。这可能意味着该服务器已生成自己的安全凭据(Chrome 无法依据这些凭据确定身份信息),或者有攻击者尝试拦截您的通信。
您不应再继续,尤其是如果您以前从未在此网站看到这一警告信息,则更不应继续操作。

买个SSL证书真的会穷死铁路公司吗?

没回扣怎么买
0

引用来自“Jacle”的评论

引用来自“疲于奔命的傻逼”的评论

媲美亚马逊…笑尿

+1

+1
顶部