《铁路客票系统关系型数据库的困境和出路研究》由会员分享，可在线阅读，更多相关《铁路客票系统关系型数据库的困境和出路研究（7页珍藏版）》请在金锄头文库上搜索。
1、铁路客票系统关系型数据库的困境和出路研究 李杨 阎志远 朱建军 戴琳琳 中铁程科技有限责任公司 中国铁道科学研究院电子计算技术研究所 摘 要： 介绍铁路客票系统中应用关系型数据库的现状, 以及面临的成本高、可扩展性差等方面挑战和客票系统业务特征带来的瓶颈。结合客票业务特点和场景, 以及数据库未来的发展趋势和需求, 提出了客票系统多种数据库综合运用、云服务化、业务改造等一系列的改进思路和建议。关键词： 客票系统; 关系型数据库; 困境和出路; 作者简介：李杨, 助理研究员;作者简介：阎志远, 副研究员。收稿日期：2017-06-26基金：中国铁路总公司科技研究开发计划项目 (2015X003-A
2、) Predicament and solution for relational database of railway ticketing and reservation systemLI Yang YAN Zhiyuan ZHU Jianjun DAI Linlin China Rails Travel Technology Co.Ltd.; Institute of Computing Technologies, China Academy of Railway Sciences; Abstract： This article introduced the present situat
3、ion of relational database of railway ticketing and reservation system (TRS) , the challenges of high cost and poor scalability, bottleneck brought by the business characteristics of TRS. Combining the business characteristics of TRS and scene with the future development trend and demand of the data
4、base, the article proposed a series of ideas and suggestions for improvement such as comprehensive use of a variety of database, cloud service, business transformation, etc.Keyword： ticketing and reservation system (TRS) ; relational database; predicament and solution; Received： 2017-06-26中国铁路新一代客票系
5、统支撑全路 5 000 多个车站的客运业务。2016 年全年售票量超过 32 亿张, 其中 12306 网站和手机 APP 售票量占比 61%;平均日售票量近 800 多万张, 高峰日售票量超过 1 000 万张。客票系统由中国铁路总公司数据中心, 地区数据中心和所辖车站系统组成, 采用分布与集中相结合的多级分层系统架构1。客户端采用 PB、C#及 H5 等前端展示技术, 运行在 Windows、Android、IOS 等多种操作系统上;应用层使用了如CTMS、DBCS 等自主研发的中间件, 以及 JBoss、Nginx 等商业和开源中间件产品;数据层包括数据库、数据复制、集中存储和分布式存储
6、等技术。目前, 数据库支撑着客票系统的核心交易与运营统计、分析业务, 类型包括关系型数据库、数据仓库、内存数据库和分布式数据库等。其中, 数据仓库占比较少, 大部分使用商用关系型数据库产品。1 客票系统关系型数据库困境随着高速铁路的飞速发展, 旅客对出行乘坐体验的要求越来越高, 其中最引人关注的就是客票系统, 其安全稳定运行直接关系到老百姓购票体验, 提高客票系统高效、稳定、可持续发展已经成为共识2。多年来客票系统不断迭代、完善以适应业务需求, 随着业务种类快速扩充, 线上线下售票量的迅速增长, 生产业务相关数据类型和存储量越来越多, 关系型数据库在客票系统中的应用遇到了多种挑战。1.1 成本
7、高传统商用关系型数据库对运行环境要求较高, 为保障业务系统的性能和高可用性, 多数提供高端服务器加存储的解决方案。另一方面, 需要昂贵的授权及技术支持费用。目前, 客票系统的核心交易业务使用的商用关系型数据库, 一定程度上对客票系统的发展形成了经济制约。1.2 性能挑战为分离查询业务对交易业务的影响, 客票系统中各铁路局基本都已设置专用的查询数据库, 目前存在业务高峰期请求响应超时的问题。除硬件配置和性能因素外, 更多与关系型数据库的保证数据完整性、一致性和持久性的设计特点相关。传统关系型数据库不适用于密集型查询业务场景, 相比之下, 12306 互联网售票的余票查询采用了运行在 PC 服务器
8、的集群内存数据库, 支撑了日均几十亿次的查询量3。铁路局级营销系统使用的关系型数据库, 在大数据量的分组、排序、聚合及多表连接等复杂操作场景下, 数据库负荷持续较高, 性能瓶颈明显。铁路总公司营销系统采用了基于列存储的关系型数据仓库, 可进行全路营销数据统计分析, 相对铁路局级系统性能有所提升, 但更适用于中等数据规模的应用场景, 对大数据处理力有不逮。同时, 传统关系型数据库在结构化数据的复杂运算上存在性能瓶颈。现有部分客票业务的数据模型复杂, 如在内容管理、日志监控等方面, 使用支持 JSON 格式的数据库或者其他非结构化数据库处理相对比较方便和高效。1.3 可扩展性差可扩展性的目标有两点
9、:突破性能瓶颈和实现高可用。目前客票关系型数据库常用的有两种高可用方案:双活模式和双机热备模式。商业关系型数据库的可扩展性本质上还是一种单机扩展, 即通过在系统中引入处理能力更强, 可靠性更高, 但是价格也更昂贵的软硬件设备, 以解决系统的可靠性和扩展性问题, 或者通过负载均衡实现有限的水平扩展。由此可见传统的关系型数据库扩展性非常有限, 在性能和高可用方面都存在很大的瓶颈。1.4 业务和数据库紧耦合由于历史原因, 客票核心交易业务基于数据库的存储过程实现。这种实现方式可简化业务逻辑, 减少网络开销4, 但这也导致客票系统业务层和数据层紧耦合。随着客票系统的发展, 这种紧耦合不但限制了业务层的
10、通用性, 而且使客票系统绑定在特定的商业数据库产品上, 限制了数据库的迁移切换, 制约了业务发展, 也间接增加了运维成本。1.5 大数据处理困难铁路客票系统的快速发展积累了大量的系统运行、业务生产、旅客出行等数据5, 截止到 2016 年底, 12306 网站注册用户量已超过 2.8 亿, 节假日期间每天登陆用户超过 1 500 万, 每天产生的访问日志数据多达 10 T, 如何高效地从这些海量数据中分析、挖掘、生成更高层次的决策支持信息, 提高铁路运营动态监测、指挥协调、服务监管、异常行为预警和辅助决策能力, 对于客票系统传统关系型数据库来说是个巨大的挑战。2 客票系统关系型数据库出路客票系
11、统关系型数据库面临困境的原因错综复杂、相互影响。业务和数据库的紧耦合, 以及商业关系型数据库特点导致可扩展性差;可扩展性差又导致数据库性能瓶颈、高可用能力弱;为了提高可扩展性, 客票系统维护了大量复杂的数据库复制和同步;同时, 系统可用性和性能又需要更稳定和更昂贵的服务器支撑。2.1 走出困境技术路线对客票系统关系型数据库的出路研究是一个系统工程, 我们采用从简单场景到复杂业务, 从外围应用到核心系统, 从局部模块到总体架构的方式, 循序渐进地探索、改造关系型数据库在客票系统中的应用。伴随铁路客票系统交易量和业务量的快速增长, 客票系统技术团队通过对铁路客票系统不断的升级和改造, 对关系型数据
12、库的应用进行了大量的探索、应用研究以及实践总结, 形成了突破关系型数据库困境的基本思路:(1) 通过细化客票系统应用场景, 从关系型数据库中剥离非交易型业务, 逐步迁移至业务场景适合的数据库中。(2) 提出关系型数据库的发展趋势及应用策略:硬件平民化、开源产品化、分布式、云服务化, 如图 1 所示。2.2 细化数据库应用场景数据库产品种类繁多, 百花齐放6, 针对不同业务场景各具优势, 有适用于事务处理应用的 Old SQL、适用于数据分析应用的 New SQL 和适用于互联网应用、大数据处理的 No SQL。通过细化客票系统业务场景, 剥离非交易型业务, 如查询, 统计分析等业务, 采用更擅
13、长此方面的数据库产品能够更好地突破限制。客票系统数据库应用业务场景细化图如图 2 所示。图 1 关系型数据库发展趋势 下载原图图 2 客票系统数据库应用场景细化图 下载原图细分业务场景的基本策略是对于核心交易部分仍采用 Sybase ASE 关系型数据库, 并探索研究 Postgre SQL、My SQL 等开源关系型数据库的使用;非交易的场景采用其他类型的数据库, 如高速查询采用内存数据库 Gemfire、Redis、Memcache;文档文件存储方面使用 Mongo DB、Ceph 等, 大数据存储可以仍然采用 Sybase IQ, 部分场合可以采用 Cassandra、H B a s e
14、;统计分析、数据仓库采用 H i v e、N e w S Q L 数据库 Clustrix, 或者 MPP 数据库代表 Greenplum 等;数据挖掘采用 NLTK 等。针对不同场景多种数据库综合运用上, 客票系统中一些非核心、非交易的场景已经开始用其他类型数据库进行替换。如表 1 所示。2.3 硬件平民化随着硬件发展, PC 服务器在稳定性和可靠性上均有很大提升, PC 服务器和小型机的差距也在缩小, 虽然有些应用场景下, PC 服务器还无法完全替代小型机, 但是随着云计算、分布式、集群等高可用技术的发展, PC 服务器的适用范围将更加广泛。表 1 客票系统中多种数据库综合运用研究列表 下
15、载原表 客票系统在 12306 和手机售票系统中已经在大量使用 PC 服务器, 通过集群化提供高可用、高性能、可扩展的服务, 应用效果良好。2.4 拥抱开源开源关系型数据库拥有成熟的技术和广泛的市场, 根据 2017 年 4 月 DB-Engines 数据库流行度排名, 数据库前 10 名中开源关系型数据库就有 3 款。开源关系型数据库不管是在对 SQL 标准的支持、存储管理和网络管理, 还是在开发、管理和监控工具等方面都能媲美主流商业数据库, 并且在集群支持、数据库复制和分区等高级功能方面, 开源数据库都能够提供完善的支持。开源关系型数据库在单机性能上也不输商业数据库, 并且开源关系型数据库
16、通过众多的扩展分布式和高可用中间件, 借此突破关系型数据库在扩展性和单机性能瓶颈的困境, 能够有效降低原有数据库的商业授权费用, 实现数据库的安全可控。客票系统核心业务原关系型数据库多采用“双活”模式, 两台主机能够同时处理业务, 并通过主-主复制保持数据同步, 当一个节点宕机不影响整体对外提供服务7。目前, 客票系统在多个系统中研究和采用了分布式开源中间件, 突破原数据库有限扩展的瓶颈。常见的开源分布式中间件如表 2 所示。2.5 云服务化客票系统对数据库处理能力需求具有规律性, 在节假日售票高峰时, 需求最为紧迫, 而在非节假日, 需求并不那么突出8, 通过将数据库部署在云资源上, 提供数据库云服务, 在高峰时, 动态伸展, 满足应用需要;在非高峰时, 可以部署其他应用, 提高资源利用率。采用公有云服务还可以降低基础建设和维护费用, 通过支付月租费实现基础设施扩展, 减少运维人员和运维工作量。表 2 开源分布式中间件列表 下载原表 铁路客票系统在国庆和春运高峰期间已经采用云服
