升级的核心是余票查询的升级,余票查询使用存储过程,sybase数据库,结果悲剧了,业务并发性高时,不能横向扩展.
[url=http://www.csdn.net/article/2015-04-29/2824589]揭秘12306技术改造(三):传统框架云化迁移到内存数据平台[/url]
2012年 改造前的余票计算/查询子系统架构描述
1. 路局“实时”提供售票记录
火车票的席位销售是由每个路局规划和调控(铁路总公司共有18个路局), 而12306与每个路局是共享同一个“票库”。 换句话说,“线上”的12306是与“线下”的火车站点售票窗口,电话售票,和各地的售票点抢票。每个路局将每张票的销售记录都“实时“传送到12306在铁总数据中心“主数据库服务器”做汇总。
2. 数据库复制到余票集群:
在铁总的数据中心 - 余票计算服务器集群是由“主数据库服务器”和72部Unix小型机组成;主数据库服务器汇总各个路局传输过来的数据后,利用数据库复制的机制,实时将数据“复制“到72部Unix小型机。
3. 并行处理余票计算: 其中8部小型机做售票预处理,再将预处理结果送到64部小型机,64部小型机“同时并行”处理余票计算。
4. 应用缓存服务器: 64部小型机将余票计算后的结果汇总产生余票表,将余票表放置在前端的应用缓存服务器集群;此举是要解决在高并发的情况下,缓存服务器提供更快速的余票查询服务。
5. CDN(Content Delivery Network)服务器:12306最外围部署CDN网络,其目的是使用户可就近取得所需信息,将用户的请求重新导向离用户最近的服务节点解决 Internet网络拥挤的状况,还有调整负载均衡的功能,提高用户访问的响应速度。
6. 余票信息更新机制:余票信息更新是以“车次“为基准,每隔10分钟更新一次。当用户提交“区间站点”的余票查询时,先从CDN服务器查询资料,假如CDN的资料已超过10分钟,会从应用缓存服务器索取最新的数据。同理,当应用缓存服务器的资料超过时效,会触发余票计算流程,重新计算余票产生余票表, 提交给应用缓存服务器。每隔10分钟更新的参数是可调整的。
12306改造原则和目标
(1)设定性能指标:
以余票计算子系统为例,Gemfire集群的余票计算性能指标需要达到10,000 TPS以上, 并可以随着业务成长做弹性扩展。配合应用缓存服务器集群和最前端的CDN负载均衡服务器集群,预估12306可以支持每秒达百万次的余票查询。此部分的系统性能是与服务器CPU类型, 内存大小,Gemfire节点数和x86服务器数量都有关联。
(2)余票计算处理能力可随着虚机的增加而线性增加
余票查询是要反映最新的余票情况,作为购票的依据。 在上篇文章已谈到余票计算的复杂度,需要很强大的CPU处理能力为后盾来计算每个区间站点的余票量;将计算结果放置到缓存数据服务器和CDN服务器。余票计算是利用Gemfire Data Grid和Map Reduce的技术提供巨大CPU处理能力。
(3)在不改变原有的体系框架上增加Gemfire集群, 新旧两套系统并行运算
为确保12306生产环境的稳定性和平稳过渡,新旧两套系统必须同时运行,由最前端的CDN服务器控制访问流量,逐渐将需要余票计算的请求加压到Gemfire集群,测试Gemfire的承载能力,检验可扩展的功能。
(4)系统高可用性(High Availability)
Gemfire的数据节点都有其它节点的备份数据, 也可以将内存数据持久化到硬盘或是同步/异步写到数据库。
(5)x86服务器
考虑未来多数据中心和混合云的部署,必须使用x86服务器为生产机。
根据12306改造设计原则在不改变原有的体系框架上增加Gemfire集群, 在过渡期间,新旧两套系统并行运算,在过渡期后,以Gemfire集群为主。 所以此步的改造是针对上述”改造前的余票计算/查询子系统架构”的第2项和第3项进行分析和改造。
12306改造步骤:
(1)系统架构改造和数据上载
为确保12306生产系统的稳定运行和平稳过渡,在不改变原有的体系框架上增加Gemfire集群, 新旧两套系统并行运算。那就必须考虑如何将数据从数据库实时同步到Gemfire集群做余票计算。
A.数据库复制服务器 :增加一部数据库服务器,将铁总数据中心“主数据库服务器”汇总的数据实时复制到此部数据库服务器。
B.实时同步机制和SQL解析服务器 : 此步骤是从数据库取出Log数据并解析SOL语句,因为原来代码是用Stored Procedure开发的。
C.Rabbit MQ服务器 :同步机制服务器将解析过的SQL语句透过Rabbit MQ传输给Gemfire集群做余票计算。
D.Gemfire集群将余票计算结果汇总后,提交给前端的应用缓存服务器提供余票快速查询。
(2)系统数据结构分析
数据结构分析和设计是在改造过程中最关键的一步,影响到后续性能的提升; 利用“数据网格Share Nothing”的特性, 将数据切割, 把 “数据关联性强”的数据放在同一个Gemfire 数据节点,再配合业务逻辑的设计,降低节点之间数据交换的延迟,提高系统处理能力。
(3)Benchmark (基准点)测试
进行Benchmark测试, 评估每部Gemfire服务器的TPS和余票计算反应时间
-验证Gemfire集群性能可随着x86虚机的增加而线性增加
测试“实时同步”机制, 量测数据同步到Gemfire集群的稳定性,延迟和吞吐量
(4)系统稳定性, 安全性和HA设计
在Gemfire的数据节点都有其它节点的备份数据来达到HA的目的,也可以将内存数据持久化到硬盘或是数据库。
使用Gemfire改造的实施流程:
1. 需求分析阶段:
需求调研,确定改造方案、
分析数据表结构、样本数据、数据量及应用访问特性信息
2. 架构设计:
设计Region结构,确定分区方式,和 设计二级索引
数据切割(partition)放在Gemfire的节点, 每个节点数据量大小是根据物理机内存来决定。例如, 在阿里云的节点一般是30G左右,在铁总数据中心的节点是60G-120G左右。 从项目经验来说,Gemfire数据节点以不超过128G可得到最佳效果。
利用Data Grid和Map Reduce的分布式技术提供强大的CPU处理能力。
使用到的Gemfire功能参考下列描述
3. 编码和单元测试:
12306是采用Stored Procedure开发,必须将Stored Procedure解析, 采用Java开发和编码,并将业务逻辑代码和数据都放在Gemfire节点, 此举可以达到最高的系统性能
单元测试
4. 集成测试/准确度测试/性能调优:
在集群环境下进行准确度测试
在集群环境下进行性能及压力测试
依据测试结果进行性能调优
性能调优可能需要调整细部架构的重新设计
5. HA和热部署测试
6. 线上运维:
创建Release版本并纳入管理
配置部署生产环境并进行持续监控
主要的Gemfire功能特性:
在12306改造过程中,使用到下列Gemfire的功能特性:
Rich Objects: 以objects的形式体现和编码,自己定义数据结构
Elastic Growth w/o pausing : 弹性扩展和热部署
Partitioned Active Data : 根据数据属性,例如:客户,订单,车次,站名,做合理的数据切割,放在不同的数据节点。
Redundancy for instant FT:HA的设置
Colocated Active Data: share nothing的概念,将关联性强的数据放在同一个Gemfire 数据节点, 例如,车次,站名
Replicated Master Data: 数据量不大的常用数据,例如:站名字典和席位类别等,在每个Gemfire节点都有一份拷贝,此举是要减少数据的交换。
Server-side Event Listeners: 当数据在Server端产生变化时,会触发相应的操作
Client-side Durable Subscriptions:当Server端满足客户端订阅的某些条件时,会推送信息
Parallel Map-Reduce Function Execution: 车次余票在每个Gemfire 节点并行运算,再汇总运算结果
Parallel OQL Queries
Continuous Queries
LRU Overflow to disk in native format for fast retrieval
Parallel, Shared Nothing Persistence to disk w/ online backup
Asynchronous Write Behind, Write Through or Read Through
[url=http://geode.incubator.apache.org/]geode Gemfire的开源版本[/url]
[url=http://www.csdn.net/article/2015-04-29/2824589]揭秘12306技术改造(三):传统框架云化迁移到内存数据平台[/url]
2012年 改造前的余票计算/查询子系统架构描述
1. 路局“实时”提供售票记录
火车票的席位销售是由每个路局规划和调控(铁路总公司共有18个路局), 而12306与每个路局是共享同一个“票库”。 换句话说,“线上”的12306是与“线下”的火车站点售票窗口,电话售票,和各地的售票点抢票。每个路局将每张票的销售记录都“实时“传送到12306在铁总数据中心“主数据库服务器”做汇总。
2. 数据库复制到余票集群:
在铁总的数据中心 - 余票计算服务器集群是由“主数据库服务器”和72部Unix小型机组成;主数据库服务器汇总各个路局传输过来的数据后,利用数据库复制的机制,实时将数据“复制“到72部Unix小型机。
3. 并行处理余票计算: 其中8部小型机做售票预处理,再将预处理结果送到64部小型机,64部小型机“同时并行”处理余票计算。
4. 应用缓存服务器: 64部小型机将余票计算后的结果汇总产生余票表,将余票表放置在前端的应用缓存服务器集群;此举是要解决在高并发的情况下,缓存服务器提供更快速的余票查询服务。
5. CDN(Content Delivery Network)服务器:12306最外围部署CDN网络,其目的是使用户可就近取得所需信息,将用户的请求重新导向离用户最近的服务节点解决 Internet网络拥挤的状况,还有调整负载均衡的功能,提高用户访问的响应速度。
6. 余票信息更新机制:余票信息更新是以“车次“为基准,每隔10分钟更新一次。当用户提交“区间站点”的余票查询时,先从CDN服务器查询资料,假如CDN的资料已超过10分钟,会从应用缓存服务器索取最新的数据。同理,当应用缓存服务器的资料超过时效,会触发余票计算流程,重新计算余票产生余票表, 提交给应用缓存服务器。每隔10分钟更新的参数是可调整的。
12306改造原则和目标
(1)设定性能指标:
以余票计算子系统为例,Gemfire集群的余票计算性能指标需要达到10,000 TPS以上, 并可以随着业务成长做弹性扩展。配合应用缓存服务器集群和最前端的CDN负载均衡服务器集群,预估12306可以支持每秒达百万次的余票查询。此部分的系统性能是与服务器CPU类型, 内存大小,Gemfire节点数和x86服务器数量都有关联。
(2)余票计算处理能力可随着虚机的增加而线性增加
余票查询是要反映最新的余票情况,作为购票的依据。 在上篇文章已谈到余票计算的复杂度,需要很强大的CPU处理能力为后盾来计算每个区间站点的余票量;将计算结果放置到缓存数据服务器和CDN服务器。余票计算是利用Gemfire Data Grid和Map Reduce的技术提供巨大CPU处理能力。
(3)在不改变原有的体系框架上增加Gemfire集群, 新旧两套系统并行运算
为确保12306生产环境的稳定性和平稳过渡,新旧两套系统必须同时运行,由最前端的CDN服务器控制访问流量,逐渐将需要余票计算的请求加压到Gemfire集群,测试Gemfire的承载能力,检验可扩展的功能。
(4)系统高可用性(High Availability)
Gemfire的数据节点都有其它节点的备份数据, 也可以将内存数据持久化到硬盘或是同步/异步写到数据库。
(5)x86服务器
考虑未来多数据中心和混合云的部署,必须使用x86服务器为生产机。
根据12306改造设计原则在不改变原有的体系框架上增加Gemfire集群, 在过渡期间,新旧两套系统并行运算,在过渡期后,以Gemfire集群为主。 所以此步的改造是针对上述”改造前的余票计算/查询子系统架构”的第2项和第3项进行分析和改造。
12306改造步骤:
(1)系统架构改造和数据上载
为确保12306生产系统的稳定运行和平稳过渡,在不改变原有的体系框架上增加Gemfire集群, 新旧两套系统并行运算。那就必须考虑如何将数据从数据库实时同步到Gemfire集群做余票计算。
A.数据库复制服务器 :增加一部数据库服务器,将铁总数据中心“主数据库服务器”汇总的数据实时复制到此部数据库服务器。
B.实时同步机制和SQL解析服务器 : 此步骤是从数据库取出Log数据并解析SOL语句,因为原来代码是用Stored Procedure开发的。
C.Rabbit MQ服务器 :同步机制服务器将解析过的SQL语句透过Rabbit MQ传输给Gemfire集群做余票计算。
D.Gemfire集群将余票计算结果汇总后,提交给前端的应用缓存服务器提供余票快速查询。
(2)系统数据结构分析
数据结构分析和设计是在改造过程中最关键的一步,影响到后续性能的提升; 利用“数据网格Share Nothing”的特性, 将数据切割, 把 “数据关联性强”的数据放在同一个Gemfire 数据节点,再配合业务逻辑的设计,降低节点之间数据交换的延迟,提高系统处理能力。
(3)Benchmark (基准点)测试
进行Benchmark测试, 评估每部Gemfire服务器的TPS和余票计算反应时间
-验证Gemfire集群性能可随着x86虚机的增加而线性增加
测试“实时同步”机制, 量测数据同步到Gemfire集群的稳定性,延迟和吞吐量
(4)系统稳定性, 安全性和HA设计
在Gemfire的数据节点都有其它节点的备份数据来达到HA的目的,也可以将内存数据持久化到硬盘或是数据库。
使用Gemfire改造的实施流程:
1. 需求分析阶段:
需求调研,确定改造方案、
分析数据表结构、样本数据、数据量及应用访问特性信息
2. 架构设计:
设计Region结构,确定分区方式,和 设计二级索引
数据切割(partition)放在Gemfire的节点, 每个节点数据量大小是根据物理机内存来决定。例如, 在阿里云的节点一般是30G左右,在铁总数据中心的节点是60G-120G左右。 从项目经验来说,Gemfire数据节点以不超过128G可得到最佳效果。
利用Data Grid和Map Reduce的分布式技术提供强大的CPU处理能力。
使用到的Gemfire功能参考下列描述
3. 编码和单元测试:
12306是采用Stored Procedure开发,必须将Stored Procedure解析, 采用Java开发和编码,并将业务逻辑代码和数据都放在Gemfire节点, 此举可以达到最高的系统性能
单元测试
4. 集成测试/准确度测试/性能调优:
在集群环境下进行准确度测试
在集群环境下进行性能及压力测试
依据测试结果进行性能调优
性能调优可能需要调整细部架构的重新设计
5. HA和热部署测试
6. 线上运维:
创建Release版本并纳入管理
配置部署生产环境并进行持续监控
主要的Gemfire功能特性:
在12306改造过程中,使用到下列Gemfire的功能特性:
Rich Objects: 以objects的形式体现和编码,自己定义数据结构
Elastic Growth w/o pausing : 弹性扩展和热部署
Partitioned Active Data : 根据数据属性,例如:客户,订单,车次,站名,做合理的数据切割,放在不同的数据节点。
Redundancy for instant FT:HA的设置
Colocated Active Data: share nothing的概念,将关联性强的数据放在同一个Gemfire 数据节点, 例如,车次,站名
Replicated Master Data: 数据量不大的常用数据,例如:站名字典和席位类别等,在每个Gemfire节点都有一份拷贝,此举是要减少数据的交换。
Server-side Event Listeners: 当数据在Server端产生变化时,会触发相应的操作
Client-side Durable Subscriptions:当Server端满足客户端订阅的某些条件时,会推送信息
Parallel Map-Reduce Function Execution: 车次余票在每个Gemfire 节点并行运算,再汇总运算结果
Parallel OQL Queries
Continuous Queries
LRU Overflow to disk in native format for fast retrieval
Parallel, Shared Nothing Persistence to disk w/ online backup
Asynchronous Write Behind, Write Through or Read Through
[url=http://geode.incubator.apache.org/]geode Gemfire的开源版本[/url]