基于有限狀態機機制的雙機熱備系統研究

楊 坤 李 夏 王 勇 都書剛

（ 煤炭科學技術研究院有限公司，北京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 結論

基于有限狀態機機制的雙機熱備系統采用傳軟件的方式實現,具有節約成本與部署方便優點,并且對外提供了一系列的信息交互接口, 使得現有的人員定位系統的雙機熱備運行更加簡單、穩定、可靠。