铁道部新客票系统设计(一)

标签: 铁道部 新客 系统 | 发表时间:2012-09-17 09:20 | 作者:爱公司的程序员
出处:http://www.cnblogs.com/

这几天正好看到一条新闻  铁道部:新客票系统2015年建成  ,正好最近想整理和总结一下这几年的工作中的收获,正好可以借这个机会,尝试设计一下铁路客票系统,把自己所学全部用到这个系统中去,顺便也希望各位猿们拍砖,一起探讨一下设计,技术吗,讨论讨论总是有点收获的,总比一个人在那里看书好。

非功能性要求

废话不说,这里先脱离系统的整体架构,后续在不断完善整体架构,这里首先讨论的是数据库层面的设计,因为对于整个架构系统来说,数据库的设计是最为关键重要的,数据库的设计好与坏,决定了整个系统的性能,可用性,扩展性。在考虑数据库的设计之前,我们可以先抛开非业务功能的需求,先看看非功能性需求,主要包括

1 数据库的类型选择

目前市场上数据库主要有:关系型数据库(Oracle,DB2,Mysql),NOSQL类型数据库(MogonDB),对象数据库(不是很了解),面向文档的数据库(apache couchBD),面向统计的数据库(HBASE)

根据客票系统的类型,应该是属于OLTP类型的系统,但是考虑到商业上分析需求,也属于OLAP型系统,由于本次讨论OLTP系统的设计,优先选择Oracle。为啥,用的公司多,市场上相关的技术工程师多,DBA管理员多,安全性和性能都不错。就是有点贵,不过考虑到是铁道部,完全忽略。对于部分客票系统非关键性业务也不重要的,这一部分数据可以考虑使用Mysql。至于NOSQL,没有用过,这个主要是面向web2.0的,对于事务要求高的系统,不太适合。

2 多数据中心

在金融行业,都必须部署多个数据中心,避免在一个数据库机房故障之后,全部数据都不可用。比如假如某地地震,数据库所在机房宕机了,如果这个时候检票或者买票,就sb了,所以需要尽快恢复。这样必须马上启动另外一个数据库机房配置。

除去灾备情况,考虑到铁路售票系统数据库的巨大访问量,2011年的铁道部的旅客发送量--- 2011年全国铁路运输目标:旅客发送量19亿人次,根据这个,初略估计一下一年估计要20亿张票,这个只是2011年的量,按照未来的几年的增长,按照目标值100亿人次估计,相当于一天有2700W独立UV,1亿PV。考虑到春节这个变态的高峰期,瞬间的并发量比平时会高上千倍。如果只在一个数据库只有一台,数据库就会存在单点,一旦数据库挂掉了,需要尽快的恢复。这个时候不太可能启用灾备数据库,因为灾备是异地备份,备份数据库同步数据比较慢(网络延迟),所以必须必须在同一个城市在部署一套数据库。这样在单点数据库故障的时候,可以马上切到备份数据库。

下面两幅图主要介绍异地灾备以及同城异机房备份的实现原理。

  • 同城备份

   数据一次写一份,日志写两份。由于日志文件实时同步,A服务器写完B服务器的日志文件,B服务器马上就写自己的数据文件。这样不会丢失数据。当A服务器故障,应用马上就可以切换到B服务器。不会存在单点故障。但是考虑特殊情况,北京地震,A,B机房同时故障,整个数据都丢失了。所以必须由异地灾备的数据中心。不过还有其他的方式,这里就不做叙述了。总之是要做好去除单点。

  • 异地备份

 

   这个架构和同城备份有一点区别,就是A服务器只会写A机房的日志文件,然后A异步同步日志到B机房的日志文件。这里面会有几分钟的网络延迟。这里不实时写B机房的日志文件,主要是性能。如果实时写B机房的数据,一次更新操作,就会至少有一次网络延迟(上海到北京的网络传输时间)。会影响数据库的性能。而同城市通过光纤连接,传输速率快,可以忽略网络延迟。如果A机房故障(灾难性的故障,比如地震,机房被恐怖分析袭击),就会丢失一部分数据,丢失的数据就是网络延迟同步的数据。对于购票业务来说,数据丢失几分钟的,是可以接受的,大不了我铁道部亏一点,这几分钟丢失的数据我全部免票。也可以做一次好的营销。但是对于金融行业来说,数据是不能丢失的,这里的异地备份就不符合金融业的要求。用性能换取可用性。就像atm取钱一样,一次交易涉及几分钟。你的交易数据银行至少会备份2份,一份同城的,一份异地的。

3 硬件配置

这一块不是很熟悉,交给dba专业的人去做吧。小机 + 存储(SAS)。不过对于铁道部有钱,上大机即可。不过我们还是按照互联网方式去分析设计系统,使用普通的存储以及服务器。

功能性分析

1 业务流程分析

先简单的了解一下购票系统的业务流程:旅客到互联网(也可能是其他渠道)登录,根据出发日期,起始站,终点站查询车票,确定车次和座位,预定车票,然后进行支付,支付成功之后,发短信,之后客户到线下去取票。一个简单的流程就结束了。

从上面的流程可以看出,整个业务流程中有几个以下几个实体以及实体的重要属性信息

1 旅客信息:假设都是实名的,至少有三个重要信息 姓名,身份证,手机号

2 车次信息:车次,起始站,终点站,类型,发车时间,到达时间

3 车次停靠信息:车次,停靠站,达到时间,停靠时间

4 余票信息:车次,起始站,终点站,发车日期,剩余座票,剩余卧铺。。。

5 车票信息:车次,起始站,终点站,发车日期,购票日期,旅客姓名,身份证,手机号,状态,购票渠道,支付日期

6 支付信息:金额,支付日期,支付银行,支付金额,支付方式

7 短信信息:车票信息,验证码,短信内容

 

整个购票过程包括以上几个重要的实体,其他的几个字段可以先不管。我们可以假设一下每一个实体的数据规模

实体 数据量 日增量
旅客信息 上限-中国人口数 16亿                   这个真不好估计
车次信息                             比较少,假设10万 日增应该也不会超过10
车次停靠信息 车次信息 ×200 == 200W 日增应该也不会超过100
车票信息 巨大,目前年增20亿,未来年曾100亿 自己换算一下,不过不会很平均,春节几天会暴增
支付信息 和车票信息同数量级 和车票信息一样
短信信息 少于车票信息,毕竟只有网络订票才会有短信,线下购票不会有 未知,假设100W
余票信息 一年交易量 365×车次信息 == 5000W 日增数据量 和 车次信息数量一致 假设10W

 

从数据量来看 车票信息 > 支付信息 > 短信信息 > 余票信息 > 旅客信息 > 车次停靠信息 > 车次信息

从如此数据量来看,必须进行分库分表。所以分库分表就在设计库的时候就显的非常重要。

 

2 简单分库策略

旅客信息相关的信息单独分在一个库,这些数据相对来说是读多写少,并且可以大量进行缓存,是基础相数据。

车次相关的信息,比如车次,车次停靠可以单独放在一个标里面,这个标是保存原数据信息,数据量不大,数据完全可以缓存。可以考虑和余票库放在一次。

剩下就是四大的实体信息,余票信息,车票信息,支付信息,短信通知信息,首先短信通知信息相对来说比较通用的,可能未来很多业务都会涉及到短信通知,所以短信相关的信息放在一个库

在剩下就是考虑业务上比较耦合的三个实体:余票,车票,支付。

余票查询频繁,没出一张票,就会更新余票数

车票数据量巨大,有查询和更新需求

支付信息:单笔查询和更新需求

考虑到车票和支付信息在数据量级上远远高于余票信息,余票信息单独一个库,而车票信息和支付信息业务上差异比较大,也单独分出来。

根据以上的分析,可以分出来5个逻辑库:旅客库,车票库,短信库,车次库(车次信息,余票信息),支付库。

继续往下分析,在5个逻辑库里面,由于旅客库数据量有上线,只需要分配一个实体库即可。 车次库增长有限,也暂时分配一个实体库里面。而车库票,支付库,短信库数据量比较大,分配一个实体库显然不够。下面单独分析这三个逻辑库的分库策略

3 车票库分库策略

对于车票信息的分库策略,需要考虑到以下几个因素

      1. 功能需求

   查询需求:按照购票日期 + 旅客信息 + 状态 或者 旅客 +  发车日期 + 状态 

   统计需求:按发车日期统计购票总数量和金额 或者其他几个维度

   交易需求:创建车票信息,更新车票状态,创建关联支付信息

   对账需求:(假设不考虑退票需求)按照支付日期统计支付流水总金额 以及 统计 支付成功的车票信息总金额

        2. 负载均衡

     按照数据库处理实时要求进行分析,响应要求高的请求和耗时类请求分开,优先保证能够卖出票,支付车票。同时不能所有的请求都指向一个库。

        3  高可用性

        避免单点,否则购票功能就不可用。所以数据库至少有备份机制。

        4 数据均匀

        避免大多数据都在同一个库,否则遇到大数据查询数据库负载会很高,进而影响系统整体的可用性。因为大多数请求都会排队,导致系统资源耗尽。

  5 可扩展性

   当数据增长过快时候,能够很灵活的添加数据库而整个应用不需要做太大的修改

 

根据以上几个因素考虑,每一张车票生成一个全局的唯一性id,根据id最后一位数字/N平均把数据分配到N个数据库中,这样每张车票库最多可以分成10个库,可扩展性不强。也可以考虑一致性hash算法进行分库,但是这个比较复杂。还有一种方式就是随机分库,好处是可以无限扩展数据库,但是会给查询带来很大的影响。考虑到查询需求,太多的库可能导致查询复杂,甚至在有限时间内无法查询出来。这里采用最后数字/N的方式进行分库,N为数据库的个数。在这个基础上,在增加一个库,就是历史库,暂时只需要一个即可,把完结的历史数据迁移到这个库,一个季度之前的数据不需要在进行操作,一般只是查询需求,就迁移到这个库里面,减少交易库的压力。

这里分10个线上库,一个历史库。一共11个库。能够支持年100亿的交易规模。不过对于对账的需求,可以考虑另外的方式来实现。这里以后在说。

下面一幅图展示了分库的模型:

通过以上的分库策略,如果某一个库宕机了,会影响1/10的购票用户。

4 余票库分库策略

余票库虽然数据量没有车票库数大,但是查询和更新需求远比车票库频繁。而且是整个业务的关键路径。在考虑这个库的只需要保持一个月的数据即可,一个月前的数据可以迁移走,不需要所有的数据。而在春运期间,这个库的瞬间访问量会飙升,相当于淘宝的秒杀,要求实时性比较高,所以不太可能读写分离。综合考虑,可以分为两个库, 线上库和历史库。历史库用来做分析。这个后续是设计的重点。

5 支付库分库策略

支付信息和车票信息这两个库有点类似,只是用户查询相对来说比较少。这个支付库分库策略和车票库的策略可以一样。

 

6 短信库分库策略

由于短信通知是全站业务,这个完全可以独立与购票业务。消息量大,但非关键业务,非系统关键路径,对实时行要求不高,所以简单分成两个库即可。

 

在分库之后,数据一致性要求就会比较高,涉及到分布式事务 ,后续会重点讨论分布式事务的设计。

先写到这里吧,下一篇 会分析表结构以及分表策略和索引。

 

 

本文链接

相关 [铁道部 新客 系统] 推荐:

铁道部新客票系统设计(一)

- - 博客园_首页
这几天正好看到一条新闻  铁道部:新客票系统2015年建成  ,正好最近想整理和总结一下这几年的工作中的收获,正好可以借这个机会,尝试设计一下铁路客票系统,把自己所学全部用到这个系统中去,顺便也希望各位猿们拍砖,一起探讨一下设计,技术吗,讨论讨论总是有点收获的,总比一个人在那里看书好. 废话不说,这里先脱离系统的整体架构,后续在不断完善整体架构,这里首先讨论的是数据库层面的设计,因为对于整个架构系统来说,数据库的设计是最为关键重要的,数据库的设计好与坏,决定了整个系统的性能,可用性,扩展性.

九问铁道部

- Harbeth - 2可器的电线杆:世界的另一面
(以上两截图,未经证实,求辟谣). 事情到了这个时候这个地步,铁道部的相关人员也应该走到台前给公众的疑问一个合理有序的解释了吧. 问题一:高铁列车究竟是正牌儿国产还是由日本国进口. 如果是从日本进口,请告知公众是哪家公司(株式会社或企业)所造. 当初买来的时候,究竟是否将全套设备及技术(如控制系统、预警系统、安全设施等主次设备及技术)完整采购来华.

铁道部 你赢了

- 什么原因 - 特推资讯
@这里是厦门:【铁道部,你赢了. 】王惠女士证实:前天下午,两名铁道部善后人员相互间“大声聊天”,说其先生郑杭征的遗体未冷冻,而是冷藏,“都有苍蝇了”. 这句话让王惠听到,她“瞬间懵了”,决定不再追究任何问题,同意签协议. 与其他遇难者一样,赔偿金是91.5万元. 行为上全无羞耻 口头上牌坊林立.

[贴图] 铁道部赢了!!

- iBeyond - 水木社区 今日十大热门话题
发信人: jhli (一剑封喉), 信区: Picture. 发信站: 水木社区 (Fri Aug 5 06:59:52 2011), 站内. ※ 修改:·jhli 于 Aug 5 07:00:29 2011 修改本文·[FROM: 117.79.73.*]. ※ 来源:·水木社区 http://newsmth.net·[FROM: 117.79.73.*].

铁道部埋车真相揭秘

- way - 天朝娱乐 | 每天开心一下!
感谢 p民求真相 投递给天朝娱乐. 猜您喜欢: 2011年最感动人心的民谣:流川枫与苍井空. 十六岁的男生高山 (Clay Garner) – 梦. 这个夏天,以网友的身份去看望药家鑫父母. 保姆虐婴 看得人心都揪起来了,简直不是人.

铁道部VS民航总局(@谭笑_

- nethibernate - 微博段子
铁道部VS民航总局(@谭笑_Derrick). 原文地址:http://www.tduanzi.com/tweets/12910.html.

铁道部,给你添麻烦了亲~~

- Taotao - 天朝娱乐 | 每天开心一下!
动车事故现场警戒解除,“我们就来看看,还有没有列车碎片,拿点儿回去卖卖. ”拾荒为生的张师傅说,“反正在地里埋着也是埋着嘛. 据说现场有个记者看到有用的残骸就买下,已经花了好几千块. 记者和全路通信信号研究设计院精彩对白. 铁道部开发布会,却只让cctv与新华社的进. 铁道部,红十字,公安部等中央单位为我党生日献礼.

铁道部为什么这么骄横?

- dousei - 牛博国际
(原发于7/29凤凰网《冰眼》专栏 http://news.ifeng.com/opinion/zhuanlan/yutianren/detail_2011_07/29/8036817_0.shtml).  这几天在全世界的电视上都能看到这么几个发生在温州动车事故救援现场的镜头:. 几台挖掘机在同时捣毁事故动车的车头,然后把它埋了起来.

我们委屈铁道部了阿!!!

- yuling - 天朝娱乐 | 每天开心一下!
据说,铁道部因为抗不住舆论压力,让部分工作人员从香格里拉搬到了国贸酒店. 铁道部赔偿遇难者斤斤计较,住宿还挺阔气.

铁道部发言人被撤职

- 音乐天堂 - 月光微博客
  据新华网英文消息,中国铁道部8月16日表示,铁道部新闻发言人王勇平被停职.   王勇平在温州列车相撞事故的记者会上多次失言,并创造了“高铁体”爆红网络. 他解释掩埋列车残骸,是为方便救援时,表示“至于你们信不信,反正我信了”. 当被质疑为何停止搜救后,拆卸车体时有发现一个活着的小女孩,王勇平称“这是一个奇迹”.