区块链相关技术在铁路客票系统中的应用研究

戴琳琳，贾成强，苗 凡，杨海峰

（1.中国铁道科学研究院集团有限公司，北京 100081；2.中国铁路南昌局集团有限公司，南昌 330000）

区块链（blockchain）已经成为当下炙手可热的新兴技术，是基于分布式存储、共识机制、点对点传输、加密算法等计算机技术的新型应用模式。基于区块链技术的分布式系统是完全去中心化的节点自组织、自验证的可靠系统。运用该技术衍生出大量应用，例如比特币（BitCoin）、Tezos 智能合约系统、Synereo 分布式社交网络等。

目前，铁路客票系统部分业务系统的应急工作模式如图1 所示，中国国家铁路集团有限公司（简称：国铁集团）级系统与铁路局集团公司级（简称：铁路局级）某单点服务器进行定期数据同步，如果国铁集团级系统出现故障，可以降级到铁路局级的该台服务器上进行应急期间数据查询和业务操作，车站应急也类似。即在铁路局或车站应急期间，分布式的客票系统会降级为集中式的单点模式。因此迫切需要剖析区块链的关键技术细节，将其在客票系统中进行创新应用。

图1 客票系统现有业务系统应急模式示意图

本文在目前业务模型框架下利用区块链相关技术改进现有集中式应急系统模型，设计分布式的智能应急模型，实现应急数据的智能同步。

1 分布式系统同步算法分析

分布式系统具有节点动态调整和系统容错性强的特点，该系统的难点是数据同步，根据同步模式可分为始终一致（Always Consistent）和最终一致（Eventually Consistent）2 种，其中始终一致同步模式，是强同步模式，要求分布式系统的大多数节点数据在任何时刻都保持一致，代表算法有Paxos算法，代表应用有ZooKeeper 等[1-2]；最终一致同步是松耦合同步，分布式系统的各节点保持自己的数据，通过消息交互逐渐达成一致，代表算法有区块链共识算法[3-5]、DHT 算法[6-8]等，代表应用有比特币和电驴等。

1.1 Paxos同步算法

Basic Paxos 算法中节点有提议者、接受者和观察者3 种角色。由提议者提出一个同步准备请求，过半的接受者同意后，提议者发出真正同步请求，过半的接受者接受后，实现节点间同步。为了防止活锁（2 个提议者轮流提议而导致节点间长时间达不成一致），提议者在发现有更高编号的提议时，该提议者静默一段时间后再进行下一轮提议。但每次数据同步都使用这一流程，效率比较低，因此在实际应用中都采用有领导者模式的Multi-Paxos 算法，即各个提议者节点自主选择出一个领导者节点，这个节点负责数据同步的提议，大家追随它进行同步，如果该节点出现故障，需要重新选择领导节点。由于算法在多节点情况下同步效率较低，一般应用中不会超过20 个节点。

1.2 区块链共识算法

区块链共识算法是区块链技术中创造性的价值体现之一，比特币是区块链最成功的应用实例，本文以比特币实现作为区块链机制的主要参考。截至2018 年5 月7 日，比特币区块链上有10 450 个节点。每个节点都保存着一份关于它对整个区块链理解的区块链数据。通过不停地监听新块产生的消息，验证新块数据正确，自主维护区块链。

由于新块产生和广播的速度不一致，比特币区块链每个节点上的区块链数据在某个时刻不都是一致的，在特定时刻还可能出现区块链分支的情况，但是比特币区块链的共识算法，通过工作量证明的难度设计和全网节点间接投票决定（最长区块链策略）的方法，可以保证经过一段时间后，全网大多数节点会达成一致，这种同步机制是完全自主实现的，对于节点数没有限制。

2 智能应急系统设计

2.1 系统需求

本文设计的客票智能应急系统，需要满足以下需求：（1）充分利用现有客票系统已有服务器、终端设备的计算和存储能力；（2）应急存储客票数据具有可追溯的逻辑链条；（3）应急节点动态调整，数据智能分布，在应急状态下减少人工干预环节，允许部分（最新）数据不一致。

2.2 系统架构

智能应急系统由应急数据私链和应急交易私链组成，如图2 所示。在业务正常运行时，各业务系统同步业务数据到应急数据私链上，应急数据私链是基于区块链技术实现的分布式数据存储层，允许有一定的数据同步延时。而应急交易私链则是一个典型的分布式交易集群。

业务系统在进入应急模式后，与应急交易私链进行应急期间交易，例如，若国铁集团级业务系统发生故障，铁路局级业务系统就调用应急交易私链继续进行国铁集团级业务数据交易，应急交易私链支持快速应用交易，并且使用应急数据私链存储应急交易数据。

应急结束后，业务系统查询应急数据私链，寻找属于自己的、最新的应急数据，进行应急数据恢复，例如，国铁集团级业务系统一直在监听应急数据私链上关于本级系统的应急数据是否有变化，然后提取数据并进行处理，存储于原系统中。

综上，由应急数据私链和应急交易私链构成了全网分布、适应于各级业务系统故障的智能应急系统，与客票分布式系统相比有更大优势。智能应急系统屏蔽了各级业务系统间的区别，使用统一的分布式数据链存储数据，统一的交易链处理交易，具有更强的通用性。

图2 智能应急系统架构图

2.3 应急交易私链拓扑

为了快速处理交易，应急交易私链是一个分组、分节点的传统分布式交易系统，每个组各节点一起承担处理应急业务交易工作，同一个交易业务ID（根据业务要求来定义，可以是铁路局码+ 车站码+ 售票处号+ 终端号，也可以是用户证件号+ 日期+ 车次）的交易是由同一组节点处理的，并且由每个组的领导者发布交易数据。

如图3 所示，在全路建立9 ～11 组的交易节点组（不同颜色虚线圈代表不同组），每个交易组内有5 ～9 个交易节点，每个交易组选出领导者节点，该节点负责将组内交易数据发布到应急数据链，全路领导者节点间同步应急交易分组规则。同一个业务操作产生的多条交易数据可以按照交易顺序统一由领导者节点提交到应急数据私链中，从而保障交易的原子性。

图3 应急交易私链拓扑图

2.4 应急数据私链拓扑

应急数据私链采用区块链技术，充分利用现有客票各个系统的计算和存储能力，并且考虑到各个系统的数据存储条件，其中，每个节点可根据能力和角色选择是否保持全量数据。

如图4 所示，国铁集团级和铁路局级参与应急数据私链的节点大多数是服务器，存储能力相对较强，可以将节点角色定位成全功能节点，存储全量数据；车站参与应急数据私链的节点一般能力有限，可将节点角色定位为部分功能节点或瘦客户端节点。全功能节点间通过区块链协议和数据组织结构进行数据同步和保存；部分功能节点和全功能节点组成局部网络，进行全区块链全数据的分片存储[9]；终端用瘦客户端节点接入系统，只查询数据，不存储数据。

图4 应急数据私链节点拓扑图

2.5 应急数据私链同步机制

比特币区块链通过工作量证明来限定新块的产生速度。工作量证明的实质是对新块块头执行哈希算法，通过调整新块块头里的一些可变字段，来改变哈希值，直到得到的哈希值小于难度目标值。为了控制新块产生时间在10 min 左右，难度目标值设定前几十个（70 左右）比特位都是0。

由于应急数据私链在客票专网运行，网络条件有保证，网络节点规模较小，可以适当缩短新块产生时间，因此该私链工作量证明的难度设置可以把前面比特位为0 的个数调小，设置为22 位左右，那么新块产生时间只需要13 s 左右，这个时间对于在专网进行数据传播和应急数据更新延时来说，都是可以接受的。

2.6 应急数据结构

2.6.1 区块链数据存储结构分析

比特币区块链实现了一个链条式的数据存储结构，如表1、表2 所示，区块链上的每个区块单向相连，存放父块的块ID（块ID 是块头的哈希值），形成一个账簿形式的数据结构。子节点保持父节点的哈希值，也是一种对父节点的校验，每个节点在区块链上增加新块时，都会对新块进行计算校验。

表1 比特币区块链块定义列表

表2 比特币区块链块头定义列表

在比特币区块链中，每个块内包含多个交易，交易是公开的，只是交易拥有者是匿名的，每个交易有若干个输入和输出定义，如表3、表4 所示，交易输入代表交易的来源点，交易输出代表交易的消费点，输入里包含交易哈希值，可通过一个交易追溯到该交易的全流程。

表3 交易输入定义列表

表4 交易输出定义列表

2.6.2 应急数据结构设计

在客票智能应急系统的应急数据私链设计中，参照2.6.1 中比特币区块链的数据存储结构。区块链中每个区块存放着若干客票业务操作数据，有些数据的来源点可以是空的，表明这个是一张新票存根数据；已有票的更改或其他延伸服务数据变化的输入点是原有票，输出点是客票变更业务数据。应急数据不考虑匿名消费机制。

区块链可以接收由正常业务系统产生的单条交易数据，也可以接收由应急交易私链产生的块交易数据，并且在交易中标识出应急标识，为应急结束后的应急数据恢复提供支撑。

区块链数据大小估算。每个客票交易数据大概200 B，每个区块存储1 000 条交易数据，大小在2 KB左右，以每天400 万条客票业务操作来计算，每天累计私链数据8 GB 左右。

3 结束语

本文讨论了分布式系统相关技术，包括Paxos 同步算法、区块链共识算法、比特币区块链数据组织等。通过分析算法和机制得出，区块链相关技术适用的交易系统具有分布式数据存储冗余性强，可容忍交易确认延时，数据透明可追溯及安全强校验等特点[10]，客票应急系统满足这些特点，因此本文设计了基于区块链相关技术的双链智能应急系统，对现有客票应急系统提供了相应的技术改造方案，该方案发挥了区块链技术完全去中心化、节点自组织和自验证的优势，将新兴技术在客票系统应用上做出大胆尝试。