假如我是铁路订票系统架构师系列 - 系统目标，整体架构，用例 - 异步处理方案

在对业务需求和场景进行一定的调研分析之后，架构师设计满足用户需要的系统目标，架构和主要用例作为系统整体架构设计。 这是从业务需求到系统设计的核心步骤。 在得到确认后，以此为依据进行处理逻辑，数据和运行环境架构的设计，进行详细的设备和开发，测试工作估计。

系统整体架构设计需要架构师向领导和业务与开发，运维部门进行介绍， 明确其如何实现业务要求，对各个部门的影响，得到各方认可。 领导和每个部门需要评估其对自身部门的要求，影响提出相关改进意见。

对订票系统，可以有很多种方案，笔者认为比较灵活的一个方案如下。 以后介绍其他方案供讨论。

1。系统目标

铁路订票系统设计满足未来5年铁路客运售票要求。 系统可以满足每天1万车次，1千万张票的出售要求。提供5天到一年的预售期。 系统提供提供专业售票点和自助售票设备。 提供10万售票点和10万台自助终端。 可以在一小时内销售120万张票， 在10小时内销售1500万张票。 售票操作响应时间在5秒之内。售票设备只提供中文界面，考虑多语言购票要求。

在网上提供公开的票源和票价查询，支持各种互联网设备查询。 数据与实际销售可以有1-5分钟的延迟。（选择）支持用户对自己所购票的确认和车次状态查询。 销售状态

系统支持固定价格售票。考虑对指定（同时不超过1000）车次支持指定，投标，拍卖等其他交易方式。

安全型：系统用物理和口令双重认证所有交易终端，对所有购票交易记录记录完整数据，并保持一年。 系统不会因单点故障影响运行，系统容量保证当单点故障时，性能仍然满足要求。 故障包括设备损坏，停电，维护，自然灾害等计划内和意外事件。

2。系统架构

系统采用分布和异步处理架构。 在各个省建立多个终端服务器，分别服务各种范围内的查询，和专门的订单处理。 各省服务器根据本省售票终端和网络访问要求设计容量。订单通过消息队列，提交至交易处理服务器。 考虑每个车次建立一个队列， 由多个交易服务器选择处理。单个交易服务器可以完成每小时60万张票的处理。交易服务器访问存储票源数据的数据库服务器集群。 各个车次的售票统计通过数据库增量同步至各个省的服务器进行查询。

3。主要用例及处理流程

用例的描述用来说明各个场景如何在这个架构下实现。 一般用sequence图表现。 通过处理序列确认该架构满足各个使用场景的功能和性能要求。

4。主要问题的处理

a) 紧俏车票快速销售完产生的不满情绪：提供各个车次售票过程曲线，在需要时提供详细售票过程清单。

b) 由于切换预售期等原因在特定时段产生大量售票请求：建议预售期改变不超过5天，按小时释放票源，针对特别车次，区域临时增加前端，队列和交易服务器数量。

c) 保证公开网络服务性能并且不影响交易性能： 采用多级数据库同步，但可能产生更多地数据延迟。

d) 如何保证售票设备的响应速度：

票源查询速度：建立票源数据库的镜像数据库专门用于售票查询。

提交：保证售票服务器与队列服务器的通信带宽， 通过调度交易服务器保证，各个队列的排队时间小于10s。

方案优点：扩展性好，理论上可以无限扩充票量和售票点。

方案可能问题：系统中机器数量随数据量增加，管理配置复杂。 系统交易服务器配置不好时，售票时提交订单到确定出票时间可能较长，需要仔细调整。