12306的问题是技术难题吗
本文转自爱活网，原地址如下：
http://www.evolife.cn/html/2014/75094_4.html
这篇文章对12306面临的技术问题看来还是比较了解的，本人对数据库方面不太了解，不能确定他讲是12306是不是真的就是世纪难题，连谷歌都无法解决。但有一点是确定的，关键还是总体运力不足，无论怎么优化，也无法解决这个问题，结果页就是让你的失望来的更早一些。最终还是国家要区域平衡发展，但是在能看到的一段时期内买票难肯定还会一直存在。
每年的春节是中国人的传统节日，大多数中国人都会在这一天选择回家团聚。然而，历年春节假期，巨大的访问请求都让中国铁路客户服务中心网站（www.12306.cn）陷入“万劫不复”。根据新浪的调查，去年春节，有近90%的网友表示12306网站缓慢、页面崩溃，严重影响正常购票。
世界级的人口迁徙带来了一个世界级的难题：要如何通过网络，把火车票及时卖给有需要的人？
中国人回家 世界级难题
铁道部在线车票发售网站12306基本不存在大量图片、视频这些占带宽资源的东西，所面临的主要问题就是数据库的高并发量——用中国的人口基数来算，这是一个极为恐怖的并发量，在车票发售的高峰时间点，向12306发起的并发请求数量大得就像一场国家规模的DDOS攻击。
中国铁路客户服务中心网站（www.12306.cn）是世界规模最大的实时交易系统之一，媲美Amazon.com，节假日尤其是春节的访问高峰，网站压力巨大。据统计，在2012年初的春运高峰期间，每天有2000万人访问该网站，日点击量最高达到14亿。
而到了去年春节期间，12306的网站订票系统系统峰值负载达2.6万QPS（每秒钟2.6万次访问请求）或11万TPS（TPS指每秒服务器处理、传输的事物处理个数，一条消息输入、一条消息输出、一次数据库访问，均可以折算成TPS），与去年淘宝双11活动峰值负载基本相当。然而，12306面临比淘宝更严重的问题——数据关联度。
淘宝的“双11秒杀”活动数据关联度本质上并不大，因为订单之间本身并不存在多少关联，淘宝可以用离散度较大的分布式计算架构，把负载一点点分离出去。
铁路票务系统的负载与普通B2C网站有着本质的不同，整条线路上每个车站、座位之间是密切关联的
但12306不同，售票系统每出一张票都要对全线路做数据更新（因为一条线路存在多个站点），车票数据之间存在互相关联，“牵一发而动全身”，系统的负载集中很多，直接搬运淘宝的分布式计算方案难以解决问题。
将问题放大到全球，答案也是一样的：谷歌拥有独步天下的分布式计算技术，但它同样是一个离散的架构，分布于全球各地的“谷歌服务器农场”的数据库每天仅需要同步2～3次数据，直接搬到12306来用，恐怕也是败走麦城。
放眼世界，还没有哪一家网站面临12306这样的窘境：访问请求大，I/O负载重，时间段分布不均衡。12306要解决问题，必然无法照搬现有的成功经验。
为解决12306网站的主要瓶颈——余票查询系统，从2012年中开始，中国铁道科学院电子计算技术研究所找来IBM、阿里巴巴等大企业寻求解决方案，给出的条件是资金管够但是问题得解决，但几大企业最后都拒绝了。
几番折腾之后，铁道部发现市面上可以买到的成套解决方案都不足以应付春运购票负载，所以只好开始尝试自行改进现有数据库来解决问题。
问题解决了一半：车票查询速度提高75倍以上
2012年3月开始，铁路总公司(原铁道部)开始调研、改造12306。2012年6月选择了Pivotal GemFire分布式内存计算平台（Distributed In-memory computing）改造12306，由铁科院项目小组负责人王明哲主任和资拓宏宇（IISI）信息科技有限公司在铁科院主管朱建生所长领导下提供技术实施。按照计划，一期工程最先改造的是12306的主要瓶颈——余票查询系统。
12306的老系统所使用的是HP Superdome小型机，使用UNIX操作系统，Sybase ASE数据库，在历届春运期间被发现性能严重不足，遂改用x86系统+linux平台。
2012年9月份，12306完成代码改造，系统上线。2012年国庆，又是网上订票高峰期间，很多人发现，登录12306变得容易了，虽然还是很难订票，但是查询余票很快。2012年10月份，二期用GemFire改造订单查询系统（客户查询自己的订单记录）上线。2013年春节，又是网上订票高峰期间，大家发现登陆12306查票简单多了——虽然还是很难订到票，但是查询余票很快，而且查询自己的订票和下订单也很快。
据介绍，12306目前最核心系统用了十几个节点的多路Xeon E7服务器，每个节点配1TB内存，将数据库全部放到内存中运行。根据系统运行数据记录，技术改造之后，12306只用十几台x86服务器就实现了以前数十台小型机的余票计算和查询能力，单次查询的最长时间从之前的15秒左右下降到0.2秒以下，缩短了75倍以上。在改造之后，支持每秒上万次的并发查询，高峰期间达到2.6万个查询/秒吞吐量，整个系统效率显著提高。
订单查询系统改造，在改造之前的系统运行模式下，每秒只能支持300-400个查询/秒的吞吐量，高流量的并发查询只能通过分库来实现。改造之后，可以实现高达上万个查询/秒的吞吐量，而且查询速度可以保障在20毫秒左右。
并且，新的技术架构可以按需弹性动态扩展，并发量增加时，还可以通过动态增加X86服务器来应对，保持毫秒级的响应时间。
至此，虽然高峰期买票还是难，但你可以认为，12306的技术问题已经解决了一半。
技术一步跨越三代：GemFire是如何搞定麻烦的？
12306能够取得这样翻天覆地的效果，靠技术上的小修小补是不可能的，必须有全新的思路，能够给性能提升带来杠杆式的作用，GemFire分布式内存数据平台就是这样一种技术。
GemFire分布式内存数据平台的技术原理如上图所示：通过云计算平台虚拟化技术，将若干x86服务器的内存集中起来，组成最高可达数十TB的内存资源池，将全部数据加载到内存中，进行内存计算。
这样改造后，整个数据库的访问过程本身不需要读写磁盘，只是定期将数据同步或异步方式写到磁盘，最大程度利用了DRAM内存速度快、吞吐大的优势。
GemFire在分布式集群中保存了多份数据，任何一台机器故障，其它机器上还有备份数据，因此通常不用担心数据丢失，而且有磁盘数据作为备份。GemFire支持把内存数据持久化到各种传统的关系数据库、Hadoop库和其它文件系统中。
大家知道，当前计算架构的瓶颈在存储，处理器的速度按照摩尔定律翻番增长，而磁盘存储的速度增长很缓慢，由此造成巨大高达10万倍的差距（如下图），数据库在内存中运行和在磁盘中运行，性能差距可达上万倍。用通俗的话来说，GemFire分布式计算实际上是用内存打造了一个超大的“硬盘池”，来运行数据库，这样你就能很好理解为什么性能差距是如此之大了。
按照Pivotal官方的说法，计算与存储的关系，可以简单划分为四代：
第一代，基于磁盘的单一系统：计算过程中需要从磁盘读取数据。小型机、大型机是其中的佼佼者，将单一系统的性能做到极致。
第二代，基于磁盘的分布式集群系统：计算过程中需要从磁盘读取数据，但通过分布系统将数据分散到不同的服务器磁盘上，提高整个系统的处理能力。目前很多大型互联网和电子商务公司采用基于X86服务器的分布式集群系统，依靠海量的X86服务器部署解决高流量并发的问题。
第三代，基于内存的单一系统：将整个数据库放在内存中，计算过程不需要从磁盘读取数据。整个系统的性能取决于单一系统的性能。传统的内存数据库就是这样的系统，对于企业级的应用可以很好地解决访问速度的问题，但面对海量数据或是海量并发访问的扩展性问题就无能为力。
第四代，基于内存的分布式集群系统：GemFire就是这样的系统，并行计算是其关键技术之一，因而可以通过增加服务器部署规模，在内存计算的基础上，线性扩展性能。
12306之前采用Unix小型机架构，采用GemFire技术改造成Linux/X86服务器集群架构，就意味着一下跨越三代。从小型机到大内存X86服务器集群，不仅让性能提升了一个数量级，而且成本也要低得多。
中国铁道科学研究院电子计算技术研究所副所长朱建生表示，“通过技术改造解决了困扰我们多时的尖峰高流量并发问题，让全国人民不再因为技术原因而抱怨，我们终于舒了一口气。Pivotal GemFire分布式集群内存数据技术对整个技术改造发挥了关键的作用。”
“买票依旧难”，问题的另一半何时能解？
让我们回到最初的问题。2013年春节，依然有近90%的网友表示12306网站缓慢、页面崩溃，严重影响正常购票。这是为何？GemFire分布式计算技术没有起效吗？答案是否定的。
恰恰相反，网友依然不满12306的原因是GemFire还做得不够。事实上，GemFire改造的仅仅是12306的后台数据库系统，网站的前端和UI（被网友反映崩溃最多的罪魁祸首）依然臃肿陈旧，这些被诟病的问题并未得到及时解决。这就是我们写下“问题只解决了一半”的原因所在。
另外，网络购票，铁道部的订单系统也是瓶颈所在（反映到购票流程里就是“出票”这个过程）。车票也是一种商品，购买行为是要发生支付关系的，这就牵涉到更加复杂的支付渠道和财务结算问题，远远超出了GemFire一个票务数据库的“管辖范围”之内。
我们在这里先提出一个假设：假定12306的数据库、前端、UI、出票流程全部都用现代化技术完成改造，这样就能拯救归心似箭的我们吗？很可惜答案依然是否定的。
这样的结果只有一个——用户原本需要花几小时断断续续刷网站的体验，变成“秒杀”——没错，假设系统能力变成无限大，足以实时响应春运时全部用户的全部鼠标点击，绝不崩溃，后果就是车票瞬间抢空。你看到的，将是一个到达放票时间后，迅速告诉你“没票”的网站。
“买票难”问题的本质是春运期间铁路运力的整体不足，作为一个客户服务网站，12306的性能无论怎样优化，用户买到票的概率都不会提升。所以，即使技术强大到12306永不崩溃，也无法保证让所有网友都按时坐上回家的火车。
要解决“买票难”，合理规划城镇化进程、科学统筹交通等基础设施建设、着重解决区域经济发展不平衡等，都是需要考虑的问题。而这些，就不属于本文讨论的范畴之内了。
12306的问题是技术难题吗相关推荐
- 显示12306服务器处理中正在排队,12306称能够解决技术问题 不与企业合作
[IT168 资讯]近两天,多名网友上传截屏图,显示在12306网站从登录到预订.排队.处理等各个环节都遭遇卡壳. 昨日起,铁路部门通过网络和电话开始发售9月30日"中秋节"的车票 ...
- 电商平台-“秒杀”系统技术难题及解决方案
电商平台-"秒杀"系统技术方案 文章目录 电商平台-"秒杀"系统技术方案 前言 一.什么是秒杀? 二.秒杀的技术难点? 1.避免对现有网站的冲击 2.高效解决网 ...
- 20个！中国科协发布2020年重大科学问题和工程技术难题
来源: 中国科学报 作者 | 高雅丽 8月15日,中国科协在第二十二届中国科协年会闭幕式上发布了 10个对科学发展具有导向作用的科学问题和10个对技术和产业具有关键作用的工程难题. 10个前沿科学问题 ...
- 关于征集2020重大科学问题和工程技术难题的通知
来源:中国指挥与控制学会 学会全体会员: 为研判未来科技发展趋势.前瞻谋划和布局前沿科技领域与方向,瞄准世界科技前沿,推进世界科技强国建设,根据<中国科协办公厅关于征集2020重大科学问题和工程 ...
- 中国科协发布20个重大科学问题和工程技术难题
来源:晓艳的科技坊 6月30日,中国科协在第二十一届中国科协年会闭幕式上发布了2019年20个对科学发展具有导向作用.对技术和产业创新具有关键作用的前沿科学问题和工程技术难题. 中国科学院院士.中国 ...
- Mysql系列七：分库分表技术难题之分布式全局唯一id解决方案
Mysql系列七:分库分表技术难题之分布式全局唯一id解决方案 参考文章: (1)Mysql系列七:分库分表技术难题之分布式全局唯一id解决方案 (2)https://www.cnblogs.com/ ...
- 破解世界性技术难题！ GTS让分布式事务简单高效
近日,2017云栖大会·深圳峰会如期举行,多项阿里云新产品对外发布.在企业级互联网架构分会场,来自阿里中间件(Aliware)的技术专家及合作伙伴,为现场参会嘉宾带来最新的传统IT架构到企业级互联网架 ...
- 重磅福利！《Apache Flink 十大技术难点实战》发布，帮你从容应对生产环境中的技术难题...
精选30+云产品,助力企业轻松上云!>>> 简介: 总结生产环境十大常见难点,10篇技术实战文章帮你完成故障识别.问题定位.性能优化等全链路过程,实现从基础概念的准确理解到上手实操的 ...
- 比特币一种点对点的电子现金系统是哪一年诞生的_驭凡学堂 中本聪创造比特币的原因是为了解决技术难题...
在创造比特币的过程中,中本聪发明了区块链技术,区块链是源自比特币的底层技术.那么,他为什么要创造比特币?他想解决什么难题? 现在,比特币常被称为一种"加密数字货币",人们常很关注其 ...
- 项目遇到技术难题，领导让我假招聘套取解决方案，我没有照做，结果15天后蒙了
导读:一般说来,很多技术人员在面试过程中都会有这样一个环节,那就是会问你许多技术问题,或者面试官给一个难题给你,让你把这个难题解答出来.但是在这个解决技术难题的过程中,有可能是面试官的一个" ...
最新文章
- 技术以外的功夫 ----作者：李天平
- 零基础学Python：自定义序列类的详细教程
- weekend110（Hadoop）的 第二天笔记
- php集合与数组的区别,java集合与数组的区别
- windows docker redis 集群部署
- Windows Server 2008 R2之活动目录回收站
- UI设计中的弹窗设计素材，技巧快get起来
- php的弹出窗口,弹出窗口 PHP
- poj4001 Xiangqi
- 做一个项目的详细步骤
- 中国涂料工业协会：世界十大涂料品牌2011年度报告
- TO B销售谈判经验 TO B销售技巧分享
- 面对疫情，健身俱乐部管理者最应该做的6件事
- 柱状图折线图混合使用
- 百元降噪耳机推荐有哪些品牌？适合学生党使用的降噪蓝牙耳机分享
- License Code of Jigloo序列号、注册码,可能是通用的呵呵
- Linux下安装mysql完整教程
- 3DMAX入门需要什么基础？中英文版本？
- linux 磁盘4k对齐方法及查看方法
- html文字加描边效果,怎么用css给文字加描边？