基于有限状态机机制的双机热备系统研究

杨 坤 李 夏 王 勇 都书刚

（ 煤炭科学技术研究院有限公司，北京100013）

1 概述

为实现人员定位管理系统的可靠性, 煤炭行业监管部门制定的相关行业标准要求： 煤矿井下作业人员管理系统应具有双机切换功能, 并且从工作主机故障到备用主机投入正常工作时间应不大于5min。 因此,井下作业人员管理系统必须具有稳定、可靠的双机热备解决方案。基于煤矿生产场景的实际,目前的煤矿井下人员定位系统主要是采用纯软件的方式实现。 纯软件的双机热备系统具有节约成本与部署方便的优点, 但现有的纯软件的双机热备系统也存在着一些缺陷：(1) 监控服务状态的流程复杂,造成可靠性差;(2)数据同步采用通信程序分发机制,易造成数据混乱;(3)界面复杂,操作困难。 针对现有纯软件方式实现的双机热备存在的问题, 笔者设计了一套基于有限状态机的双机热备系统,能够同时监测PostgreSQL、Redis 与通讯服务的工作状态,形成一个稳定的解决方案,提高了双机热备的可靠性。

2 有限状态机基本原理

2.1 数学模型

有限状态机是指系统中的有限个状态以及状态之间的迁移移活动,并通过状态、条件、动作与次态四个要素构建对应的数学模型。 状态：系统具有一组状态,并且系统可以在这些状态之间切换;但是,系统在某一时刻只能处于一个状态。 条件：触发系统进行状态切换的事件;当系统处于某一个稳定状态时,发生能够触发系统进行状态切换的事件, 系统去执行具体的动作来完成状态的切换。

动作：系统状态变更需要执行的具体的操作。

次态：系统完成变更后的状态。

综合上述表示,有限状态机可以表示为五元数学符号：

2.2 表示方法

在进行理论研究时, 有限状态机一般以数学表达式的方式抽象出来。 此外,有限状态机还具有状态转移图、转移表和状态转移矩阵三种直观的表示方法。 本文中主要采用状态转移图的表示方法。如图1 所示,圆圈表示状态,有向弧线表示状态变迁过程,弧线上的字符表示条件,具有开始箭头标注的圆圈表示初始状态,双圆圈表示最终状态。该表示方法可以直观的表示系统的状态集合、状态切换过程以及切换条件。

图1 有限状态机状态转移图

3 双机热备系统设计

3.1 总体架构

基于有限状态机的双机热备系统的总体架构如图2 所示,在两台机器中分别运行一套控制系统, 包括UI 界面、 应用服务、PostgreSQL、Redis、通讯服务与热备服务。 其中,UI 界面主要是展示展示各模块的状态与操作按钮; 应用服务主要是用来获取PostgreSQL 数据库、Redis 数据库、 通讯服务以及热备服务的各模块的状态; 热备服务主要是用来监测各服务的状态与控制A机和B 机的状态切换。

图2 系统架构图

3.2 内部架构

热备服务的内部架构设计为4 个单元与3 个外围受控组件,通过4 个单元与组件构成了完整的热备服务。

3.2.1 通信单元

通信单元的设计主要是实现A 机与B 机的状态信息的交换。 状态信息的交换主要是通过keepalived 的vrrp 协议的报文处理实现。

3.2.2 PostgreSQL

PostgreSQL 是实现终端数据与配置数据的持久化存储的数据库系统。

3.2.3 Redis

Redis 是为减轻PostgreSQL 数据库的访问压力,存放常用读取数据的数据库系统。

3.2.4 通讯服务

通讯服务主要是接收终端的数据, 并保存至PostgreSQL 数据库,其中工作状态包含“ 主模式”与“ 备模式”。

3.2.5 监控单元

监控单元主要监控A 机与B 机的状态,并根据A 机与B 机的状态进行工作状态的迁移, 其中机器的工作状态包含通讯服务的工作状态、PostgreSQL 的工作状态与Redis 的工作状态。 机器的状态转移,包含迁移状态与终态,其中,迁移状态包含：待协商、待确认、尝试进入主模式、尝试进入备模式、尝试提升为主模式,终态包括：主模式与备模式。 为进一步说明状态迁移的流程,如图3 所示,为A 机机器启动的完整工作流程：

图3 机器启动流程图

其中,条件a：返回的B 机状态未知或未获取到B 机的状态;条件b： 返回的B 机的状态属于状态集2; 条件c： A 机的PostgreSQL 以备模式启动、Redis 以备模式启动与通讯服务为备模式; 条件d：A 机的PostgreSQL 以主模式启动、Redis 以主模式启动与通讯服务为主模式;条件e：返回的B 机的状态属于状态集1;条件f：返回B 机的PostgreSQL 数据库状态(某表的数据量),确定A 机的优先级比B 机的优先级高; 条件g： 返回B 机的PostgreSQL 数据库状态(某表的数据量),确定A 机的优先级比B机的优先级低;条件h：A 机的优先级比B 机的优先级高;条件i：A 机的PostgreSQL 以主模式启动、Redis 以主模式启动与通讯服务为主模式;其中：状态集1 包含：“ 协商”与“ 确认”;状态集2 包含：“ 尝试进入主模式”、“ 切换为主模式”与“ 主模式”;状态集3 包含：“ 尝试进入备模式”与“ 备模式”;初始状态：“ 协商”;最终状态：“ 主模式”与“ 备模式”。

3.2.6 控制单元

控制单元主要是完成机器状态的切换与虚拟IP 的切换,其主要功能是基于keepalived 实现。 其中,机器状态的切换是通过在keepalived 中定义切换到相应模式时的执行脚本来实现,虚拟IP 的切换通过keepalived 的工作优先级来确定建立虚拟IP 的机器。

3.2.7 同步单元

同步的单元包含PostgreSQL 数据库与Redis 数据库的数据同步。 PostgreSQL 数据库的同步是基于异步流复制传递预写日志的方式来实现的。 A 机与B 机的PostgreSQL 数据库在使用流复制时, 只要处于主模式工作的机器的PostgreSQL 数据库一产生日志, 就会马上传递到处于备模式工作的机器的PostgreSQL数据库。 假设A 机器原来工作在主模式,当A 机的数据库工作异常或者被控制单元切换为备模式工作状态时, 机器B 上以主模式重启数据库,在数据库刚重启时,会重放B 机的数据库状态切换之前最后一个checkpoint 点之后的WAL 日志,把数据库推导到自动进入工作状态, 数据库在完成恢复后会自动进入正常状态,此时的A 机器在控制单元的协助下重新启动,以备模式启动,一直等待A 机的新的WAL 日志,如果有新的日志过来,则自定进行重放,直到A 机器工作异常,B 机以主模式状态工作,再让B 机的数据库进入主模式工作, 实现了A 机器上的数据库出故障时,B 机器的上的数据库能够接管的功能。

Redis 的数据同步分为全量同步与增量同步两个过程, 其中全量同步主要是指从模式的Redis 数据库启动的时候的初始化过程,增量同步指的是主模式的Redis 每执行一个写命令就像从模式的Redis 发送相同的写命令,从模式的Redis 接收并执行收到的写命令。 假设A 机的Redis 数据库以master 模式启动,B 机的Redis 数据库以slave 模式启动, 此时当B 机的Redis 数据库在启动的初始化阶段需要将A 机的Redis 数据库的数据全部复制一遍。 具体步骤如下：a. B 机的Redis 数据库连接A 机的Redis,并发送同步命令;b. A 机的Redis 接收到同步命令后,开始执行数据保存命令, 生成快照文件并使用缓冲区记录此后执行的所有写命令;c. A 机的Redis 数据库将快照文件发送至B 机的Redis 数据库, 并在发送期间记录被执行的写命令;d. B 机的Redis 数据库接收到快照文件后丢弃所有数据,载入收到的快照;e. A 机的Redis 发送完快照文件,继续向B 机的Redis 发送缓冲区的写命令;f. B 机的Redis 完成快照文件的载入后, 开始接收命令请求,并持续接收来自A 机的缓冲区的写命令。

4 结论

基于有限状态机机制的双机热备系统采用传软件的方式实现,具有节约成本与部署方便优点,并且对外提供了一系列的信息交互接口, 使得现有的人员定位系统的双机热备运行更加简单、稳定、可靠。