内存数据库在互联网余票查询中的应用

梅巧玲，王明哲，张志强，杨立鹏

（中国铁道科学研究院 电子计算技术研究所，北京 100081）

互联网售票系统上线以来，以其便捷性迅速得到认可，越来越多的旅客通过互联网进行购票，互联网售票量呈大幅增长的态势，高峰期的大并发请求对互联网售票系统的压力更是屡创新高。互联网售票系统在为旅客提供极大便利的同时，也必须确保在大并发访问时稳定高效运行，尤其是订票过程中需要高频度访问的功能。

互联网余票查询是互联网售票系统的频繁访问的功能之一，是旅客购票关注的焦点，在节假日期间，系统的访问量会急剧增加，导致整个系统后台数据库压力过大，响应速度变慢，用户的体验度降低。余票查询业务是具有很多动态逻辑规则的实时运算系统，数据变化频繁，运算量较多，提高余票查询的效率显得尤为重要。在提升查询效率和并发性能方面，原有基于关系型数据库存储过程编写的业务逻辑已经做了接近数据库处理极限的优化，但对于互联网高并发的访问量来说，仍然远远不能满足系统的需求。内存数据库技术为互联网余票查询业务提供了较为合适可行的解决方案。

1 内存数据库与磁盘数据库

磁盘数据库是把数据存放在磁盘上进行管理，需要频繁的访问磁盘来进行数据的操作，强调维护数据的完整性、一致性和系统的高吞吐量，当数据量很大时，由于磁盘存取、内外存的数据传递、缓冲区管理、排队等待及锁的延迟等使得事务实际平均执行时间与估算的最坏情况执行时间相差很大，数据的读写性能会下降很多，数据的实时性和处理性能也不是很高。

相对于磁盘而言，内存使得每个事务在执行过程中没有I/O，数据的读写速度要高出几个数量级，将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。内存数据库抛弃了磁盘数据管理的传统方式，基于全部数据都存储在内存中，重新设计了体系结构，数据以Key-Value形式存储，并且在数据缓存、快速算法、并发控制与恢复的算法方面也进行了相应的改进，可提供高速访问和动态扩展。内存数据库的最大特点是其“主拷贝”或“工作版本”常驻内存，即活动事务只与实时内存数据库的内存拷贝打交道。它所处理的数据通常是有一定的有效时间，实时产生新的数据，过期的数据会被定期清理掉。分布式内存数据库是将海量数据基于特定算法分散在多个服务器节点上，当进行计算时，多个节点可并发执行数据运算任务，大大缩短运算时间。内存数据库与磁盘数据库的差异如表1。

表1 内存数据库与磁盘数据库的差异

由表1可以看出，内存数据库可以提供比磁盘数据库好得多的响应时间、事务吞吐量和查询性能，这对那些要求事务在特定期限内完成的实时应用尤为重要，非常适合处理互联网售票系统中实时性强、高并发、响应快的余票查询业务。

2 技术方案

2.1 实时数据同步

内存数据库对于互联网售票系统来说，并不是产生数据的源点，如何把在传统数据库中产生的业务数据也就是余票等数据同步到内存数据库中，需要采用中间件技术、复制技术、消息队列机制来实现。分布式内存数据同步流程如图1所示。

当关系型数据库中的数据发生变化时，中间件服务将侦听到的日志变化所影响的的数据变化，发送到Message Queue Server服务器上，再由接收端Receiver将MQ Server中的消息发送到内存数据库中，实现数据的同步。

由于接收端 Receiver依赖的库多并且复杂，采用直接调用的方式会导致异构系统之间的耦合度太紧密，一旦Client端发生变化，还需要同时修改接收端的代码，造成系统的可维护性差。使用Message Queue Server作为异构系统之间的中转，关系型数据库和内存数据库的客户端Client并不直接通信，双方只和Message Queue Server建立连接，这种松耦合的设计，带来了互相依赖性小，可维护性高的好处。

在系统初始化时先将全量数据导入到内存中，建立索引缓存，之后在数据修改时，通过listener监控触发与之相关的小范围内的索引重建，保证数据的及时性。

实时同步的数据包括两类：基础数据和业务数据。基础数据变化不频繁，数据量小，包括车次数据、停靠站数据、票价数据、调令数据等；业务数据变化频繁，数据量大，主要是余票相关数据。

图1 分布式内存数据库数据同步流程

图2 分布式内存数据库调用模式

2.2 查询请求

互联网查询客户端和内存数据库服务器之间也是采用松耦合的方式，只需配置服务器地址和端口号，任何服务器端的改动都不会影响到客户端。Client收到查询请求后将其划分为多个子任务，将任务分配到多个节点Server上进行并行运算，运算完成后，将结果进行汇总并返回。分布式内存数据库调用模式，如图2所示。

3 关键技术及解决方案

3.1 数据切分

互联网余票查询的逻辑运算能力的提高仅仅基于内存的架构是不能满足需求的，充分发挥CPU的计算能力也是必须的。一个复杂的余票查询，如上海至南京的车次有300多列，其中一些K字头的车，还要处理复杂的共用定义逻辑，循环次数非常多。在逻辑算法已经优化的情况下，一次查询所要进行的运算量无论存储计算还是基于内存计算其实是相当的。

提高性能的关键在于大任务的合理分解，进行分布式运算，再进行结果的汇总。分布式处理的基本前提是避免分布，或者说尽可能少的网络交互，数据与处理逻辑在同一片内存区域，只有处理结果会输出到同一个点。以此为出发点，需要在余票查询所涉及的数据中找出一个合适的切分方式，使得相关数据能够很容易的切分开来而又具备独立的完整性。

通过分析现有数据的分布情况可以看到，余票数据、车次数据以及共用数据涉及复杂逻辑的数据表都是与车次相关的，因此最终选择以车次作为数据划分的标准。相同车次的数据会集在的一个服务节点上，所有的基础数据以全复制的方式存在于每一个服务节点上，每个服务节点上都可以独立运行查询逻辑。这样的处理方式，就可以得到一个可扩展的结构，通过增加服务节点数量，从而达到降低每个节点的车次数量，也即降低了单个节点的负荷，实现了查询性能和并发性能的可控性。

3.2 数据存储方式

在内存数据库中，每个表在逻辑上是以region的方式存放的，region有Partitioned、Replicated（distributed）、Distributed（not replicated）、Local（not distributed）4种类型。基础数据数据量小，因此采用全复制Replicated（distributed）的策略，也就是集群中每个节点都保留一份相同数据；而业务数据的数据量比较大，采用partition的方式，每个节点只保留和该节点上车次相关的数据。这种数据同步的策略确保了数据同步的高效和完整。对于一个写操作，如果该数据是Partitioned方式的，则会复制到其它节点上；对于一个读操作，就会被路由到某个节点上去读取。在同一个节点上的数据，每个不同的表之间是通过一种叫做Colocation的机制根据某个指定的属性关联起来。数据存储方式的关系图如3所示。

图3 数据存储方式关系图

3.3 数据传输

对于分布式系统来说，网络是数据传输需要考虑的一个极其重要的因素，也就是将对象转换成二进制流传输过去，到服务器上再将二进制流转换成对象进行计算，称之为序列化的损耗。对于局域网而言，200列车次数据的网络传输的消耗其实很小。序列化会发生在网络交互的过程中，客户端将Java对象序列化成字节流，通过网络发送到Server端，Server端将接收到的字节流再反序列化为Java对象。假设一个场景，200列车次，10个节点，通过负载平衡每个节点上分布了20个左右的车次，如果向每个节点都传递200列车次，序列化要做200×10，反序列化要做200×10；如果只传递每个节点需要的数据，序列化和反序列化只需做400次，即（200+200）次，有效减少了网络传输的次数。

如何向每个服务器只传递所需要的数据，系统的解决方案是采用client-server模式，服务端负载数据和运算逻辑，客户端比较轻量级，更多的用来处理与外部系统的接口工作。客户端还要负载向服务端发起运算请求，客户端发起请求有3种方式：要求与某个数据相关的服务器执行运算。这种调用方式是data-dependent的，即运算的请求在哪里执行会与数据分布有关。按车次将余票、共用定义等数据拆分成多个独立的计算单元，对余票查询中最耗时的共用定义部分做预先处理，生成查询缓存。

3.4 动态扩展及高可用性

分布式内存数据库具有良好的扩展及容错能力，集群支持弹性扩展，可通过动态增加节点应对变化的数据访问负载,数据库的计算性能呈线性增长，满足动态查询的需要。内存数据库集群可配置保存1～N份数据，将数据分布到不同的服务器节点上，保留的份数越多，数据丢失的可能性越小，但对系统带来的多个节点线性或并行写并保持数据的正确性就非常高。一般建议系统保留1份备份，和原始数据保存在不同的物理服务器上，当集群中某个节点发生故障时易引发的数据重新分配问题，导致雪崩效用，系统采用一致性hash（Consistent hashing）算法解决了节点变化时的数据迁移问题，增强了缓存平台的稳定性。

4 结束语

自2012年底上线以来，内存数据库在互联网售票系统中已经历一年半的时间，应用效果明显，相比之前在关系型数据库中的查询效率，响应时间有几十甚至几百倍的提升。目前，使用内存数据库的应用还有订单查询、常用联系人查询和实名制查询。由于分布式内存数据库的引入，为客票系统带来了极其深刻的影响，为在客票系统其它领域的应用提供了实践经验。当处理的数据量增加到海量级时，由于内存数据库管理的内存资源价格比较高，花费比较昂贵的内存介质来存储处理海量数据代价较大，需引入海量数据处理的数据仓库技术，内存数据库针对活动的实时数据，而数据仓库可以针对历史数据，把内存数据库和分布式数据仓库有机的结合起来，是形势所趋，处理大数据、高并发是我们未来研究的方向。

[1]杨 艳,李 炜，王 纯.内存数据库在高速缓存方面的应用[J].计算机科学技术，2011（12）.

[2] The Hardest Problems in Data Management[EB/OL].https://www. vmware.com/files/pdf/Gemfire-Hardest-Problems-Data-Management. pdf.

[3] HighPerformance,DistributedMain-Memoryand Events Platform[EB/OL]. https://www.vmware. com/files/pdf/vmware-vfabric-gemfire-distributed-main-memory-platform-WP.