[铁道部信息化管理]核心业务需求及逻辑架构分析

• 12306的已知信息、数据及问题
• 需求分析（一）—— 售票系统领域知识（区间票、订票、预留票）
• 需求分析（二）—— 涉众、用户体验
• 核心业务需求及逻辑架构分析
• 需求分析（三）—— 票仓
• 票仓设计（一）—— 预生成车票方案的优缺点
• 票仓设计（二）—— 区间二进制方案的优缺点
• 票仓设计（三）—— 平衡方案的优缺点
• 票务并发冲突处理原则设计（基于平衡方案）
• 缓存逻辑架构设计
• 数据库逻辑设计
• 灾难备份与恢复

 

快要太监了 :-(

因为各类我的缘由, 铁道部的这个博文系列停止了好久。最近终于连本身都很差意思了。因此仍是继续完成它吧，估计1-2周一篇的节奏。

 

感受不先划分一下大的系统架构总会让你们感受有点头晕, 不过没能力对整个12306进行设计，这个货太大了。只是借这个机会谈谈本身对系统结构分析的一些感想

 

朴素的面向对象分析

面向对象是一个万金油，可是听说真正懂的人很少是吧？

我对面向对象的感受就是: 他本质上是对现实世界的抽象，其表面现象是不断细分对象的粒度，提高对象的抽象度。最终造成一种用有限数量的独立的对象“积木”构造整个需求不断变化的系统的目标。

而系统级别的分析也大体如此，咱们能够借鉴类分析中的不少概念，不断划小系统规模，剥离职责，抽出依赖性。

 

通常系统结构

这里只是一个简单模型，用以表达我对多数项目的结构分析。

配置数据服务：系统运行所须要的动态配置信息
资产数据服务：全部实际或虚拟的“物”的管理（CRUD），甚至能够包括人。
业务数据服务：该企业实际经营的业务产生的数据。超市的收银记录，企业的销售记录，铁道部的售票记录
报表数据服务：各种统计报表须要的

其中业务系统和业务数据服务应该是最核心的部分。

通常而言，那些配置和资产管理的部分不会形成严重的性能问题。只要在实现CRUD的时候多考虑考虑相关的业务需求，努力作到任何资产的属性变更时，确保相关的业务完整性就好（出租公司管理系统里，一辆出租车今天还在运营，后台系统绝对不该该能够轻松地把它标记成报废车辆，连软删除都是不合理的作法）。

12306之因此能招全国人民围观，我以为主要仍是花的钱和你们的感觉之间有落差。而我阴暗的觉得这个问题的核心部分就在票务处理的部分。

因此我后续的几篇博文都会围绕票务处理里面的内容展开。

另外，我要你们了解的是，我是要设计一个合理的区间票售票系统核心。而不是实现铁道部的需求。本质上我认为铁道部不会说清楚他本身的需求，而太极公司的需求分析有能够进一步深挖的可能。

 

12306核心需求及模块分析

总体架构无法子设计，太大了。有兴趣的能够参考

中国铁路客票发售和预订系统5_0版的研究与实现
国铁路客票发售和预订系统5.0版本(TRSv5.0)售票与经由维护操做说明

目前我专一的是用于订票的部分。我感受这个是最重要的部分。

12306最大的问题，就是如何在订票的时候高效率得而且适当优化得找到须要数量的车票。而且要能完全保证一张票不会被两个请求同时处理成功。

只要这个问题没法完全解决，任何分布式处理，最终都会卡在这个问题上。

我会涉及到的模块

 

12306票务处理功能模块分析

假想完整网络订票流程图

这里实际的用户和系统的交互有4种类型。

一、车次和余额查询

二、订票

三、取消订票

四、确认订票

 

这里但愿广大围观群众都来评估一下这个假设的订票流程及其参数是否是都合理？若是这个流程自己不合理，则我后续的分析都要重写了。不熟悉售票流程的，能够看看我以前的分析文章。

而后咱们继续来细化一下

 

车次和余额查询

输入：起始站，终到站，日期，座位类型集合

输出：车次，对应座位类型可售余额

做用：最终用户根据查询结果选择须要出行的车次，并进一步进入订票操做。可是系统不保证显示为有票的车次在下一步操做中必然有票。

这里其实涉及到两个类型的查询

一、哪些车次符合用户的查询结果，能够经过一个基本固定不变的数据源来提供。而该数据源能够实现分布式缓存以缓解查询压力，甚至能够考虑客户端部分结果缓存。
输入：起始站，终到站，日期
输出 :车次列表，

二、特定车次，特定座位类型的可售票数量。这个数据的来源应该和第一个查询不一样。
输入：起始站，终到站，车次，日期
输出：数量

订票(我喜欢称它为锁票)

输入：起始站，终到站，日期，座位类型，须要车票数量，用户ID

输出：实际到的获取车票数量

做用：最终用户经过订票操做，顺利锁定须要数量的车票。系统保证用户在规定的时间段内对这几张车票具备优先订购权利，且其余人不得购买这些车票。

目前我感受留给用户10-15分钟时间继续后续操做，以进入支付环节（固然，这必须是在系统自己性能良好条件下。不然点个按钮就要等10分钟，那就不对了。）
同时若是超时，则系统会在后续订票操做中忽视该锁定状态。

取消订票

输入：起始站，终到站，日期，座位类型，数量，用户ID

输出：成功标志

做用：用户放弃已经得到的被锁定的售票权利，系统恢复对应的数据为可售。

确认订票（确认支付）

输入：起始站，终到站，日期，座位类型，数量，用户ID，支付相关信息

输出：成功标志/确认失败（恰好锁定超时，且被他人订走）

做用：最终确认售票，系统向第三方支付服务提交确认请求。