基于Redis的ATS緩存系統設計與實現

程遠瑤 王昕怡 陳 逸 郭 佳

(通號城市軌道交通技術有限公司 北京 100070)

0 引 言

信號系統是城市軌道交通列車控制的神經中樞,列車自動監控系統(ATS)是整個城市軌道交通信號系統的運營核心,負責監視和控制線路中所有列車的運行狀態,是城軌信息化體系建設中的重要一環[1-2]。城軌線路地域分布廣,對實時性要求高,車站節點需要具備獨立運行的能力,并由中心集中控制所屬車站[3-4]。因此ATS一般設計為分布自律、中心集中控制的系統,且系統關鍵設備及網絡結構采用冗余的方式部署,保證系統具有高度的可靠性和可用性。

全自動運行系統是城軌列車控制自動化發展的新階段[5],ATS系統需要接入更多其他專業的數據,增加與其他系統聯動。現有的ATS存儲系統無法滿足日益增長的數據交互需求,因此迫切需要一套實時強、可靠性高、靈活易擴展、支持分區容錯的緩存系統。目前常用的分布式緩存架構多以內存數據庫Memcache、Redis為存儲核心搭建集群[6-8],緩存熱點數據、提高系統訪問的并發量,具備極高的讀寫性能和可靠性,但系統中各節點對緩存數據的訪問會因網絡傳輸距離增加帶來整體響應時延的增加,不適合地域分布廣、對實時性要求高的應用場景。

為解決上述問題及挑戰,本文基于Redis強大的性能優勢和靈活的數據結構,根據ATS的特點,設計了適用于ATS的緩存系統,提供實時性強、可靠性高的數據服務。

1 系統設計方案

分布式系統遵循CAP(Consistency,Availability,Partition Tolerance)定理進行設計,即在構建分布式系統時,一致性(Consistency)、可用性(Availability)、分區容錯性(Partition tolerance)這三個要素最多只能同時實現兩點,不可能三者兼顧。由于軌道交通信號系統領域對系統性能有高安全性、高可靠性的需求,高可用性、高分區可用性是更系統更核心的設計目標,對一致性的要求只需保證在系統數據收斂后,對系統的所有訪問都將返回相同的結果,滿足最終一致性即可。因此在ATS分布式緩存業務場景中,以滿足可用性、分區容忍性、最終一致性為目標,以保證系統穩定可靠地運行。

由于城軌線路長度一般在十幾公里到上百公里,地域延伸廣,為保證系統穩定可靠及實時性,ATS系統采用分布自律系統,車站分機提供車次跟蹤、進路選排等業務服務,中心服務器提供全線監視、控制等服務,區域故障,不影響系統提供基本服務。基于以上ATS業務場景,本文設計緩存系統采用混合分割式和復制式的拓撲結構,系統設計方案如圖1所示。基于Redis的ATS分布式緩存系統采用Redis作為實時信息的緩存數據庫。為快速服務實時響應,避免遠距離站間網絡通信帶來的時延影響,本文方案將Redis模塊與其他業務模塊置于同一物理節點中,各節點緩存獨立信息,為本節點提供數據服務,節點間數據通過同步達到數據最終一致性。每個緩存節點設立一個或多個緩存數據的備份,用于保障數據的可靠性。在本文中,不失一般性地建模為一個中心三個車站緩存數據庫,中心緩存數據庫對應三個備機,各車站各對應一個備機。本分布式緩存系統由中心和車站的緩存數據庫構成,中心緩存數據庫通過主主同步的方式從各車站緩存數據庫同步數據,各緩存備機通過主從同步的方式實現與緩存數據庫的數據同步。

圖1 基于Redis的ATS緩存系統整體方案

1.1 系統結構詳細設計

本文基于開源組件Redis設計實現了滿足業務場景需求的高可靠性、高實時性的ATS分布式緩存系統。為保證系統具有高度的可靠性和可用性,系統關鍵設備及網絡結構采用冗余的方式。

單物理節點的ATS分布式緩存系統詳細設計如圖2所示。Redis作為緩存主程序,直接與ATS系統業務組件進行數據交互,存儲實時數據,提供查詢、存儲、修改等服務;與高可用模塊交互信息,負責物理節點Redis冗余設備的維護、切換、設備主從狀態發布。Redis管理組件負責監控與管理Redis狀態信息,包括Redis主從狀態、運行狀態等;與網絡組件交互數據,實現網絡冗余控制;與數據同步模塊交互信息,實現不同節點數據同步。

圖2 ATS分布式緩存系統結構詳細設計

1.2 系統功能詳細設計

1.2.1緩存數據結構設計

ATS系統中唯一物理設備對應多個屬性,包括列車信息、軌道、道岔、信號機等狀態信息、ZC狀態信息等,數據結構具有明顯的樹狀結構特點,與Redis提供的鍵值對形式的Hash數據結構特點類似。使用Hash結構存儲可以使業務組件輕松訪問到具體設備目標屬性的狀態值,避免非必要的冗余信息訪問。

為避免Redis緩存中鍵沖突問題,需要設計設備的唯一標識為鍵,屬性值為對應的設備具備的屬性或者車站下特定設備標識。以聯鎖表示信息為例,緩存的數據結構設計如表1所示,Hash key為線路碼+站碼;Field為設備類型和設備ID的組合;Value為設備的狀態色碼值。Hash key與Field可以表征某線路某站的某個特定設備,具備全局唯一性。

表1 聯鎖緩存標識信息數據結構

1.2.2網絡冗余功能設計

網絡冗余是工業網絡的一項保障策略。作為快速反應備份系統,網絡冗余的目的是減輕意外中斷的風險,通過即時響應保證生產連續,從而降低關鍵數據流上任意一點失效所帶來的影響。

ATS系統涉及安全相關,為保證系統的可靠性、實時性,在運輸層采用雙網冗余設計,在雙網的情況下,即使某一單網連接故障也不應該影響正常的通信,從而保證傳輸的可靠性。

雙網需要實現數據的冗余傳輸功能,發送方要將一個數據包發送到兩個單網連接上,兩個同樣的數據包先后從兩個單網連接到達接收方,接收方取先到的數據包,丟棄后到的數據包。為了實現該功能,通過設計雙網協議對單網連接進行封裝,增加雙網序列號用于唯一標識在兩個單網上傳輸的數據包,如表2所示。雙網的序列號為8字節(64位)整數,假設傳輸速度為每微秒發送一個數據包,該序列號發生溢出需要50多萬年的時間,因此理論上可以保證該序列號永遠都不會重復,實現對數據包的唯一標識。

表2 雙網協議包格式

1.2.3數據同步功能設計

為保證數據的一致性,需要通過設計適配ATS系統的分布式緩存同步策略,保證車站、中心各節點數據的統一。ATS分布式緩存系統中的數據同步分為:節點主從同步、數據冗余備份即車站節點、中心緩存節點主機與熱備從機的同步;節點主主同步,多主機節點間的數據同步即車站節點主機之間、車站節點主機與中心節點主機間的數據同步。

1) 節點主從同步方案。本文通過在ATS節點對應的Redis服務設定主從角色,建立緩存主從角色與ATS系統服務器主備機的對應關系。Redis客戶端通過IP和端口標識相應節點的Redis實例并設置主從關系。車站和中心緩存節點均采用冗余備份機制,且緩存主從節點間采用全量同步結合增量同步的方式實時備份緩存數據。節點主從初始化連接狀態后,進行全量同步,將主節點緩存中所有數據復制一份,寫入從節點;全同步結束后,進行增量同步,將主節點的寫操作同步到從服務器上。

基于Redis的ATS分布式緩存主從同步方案具體如下:

(1) 初始化ATS分布式集群,各節點服務器的初始化主備狀態均為主機,各節點Redis緩存的初始化主從狀態均為主機。

(2) 各節點服務器通過加權競爭算法判斷并切換自身主備狀態。

(3) 緩存的主從狀態隨服務器主備狀態進行自適應的切換:當服務器為主機,通過Redis客戶端將對應Redis設為主機;當服務器為備機,將對應Redis設為主服務器對應Redis的從機。

(4) 服務器通過心跳信息維護Redis主從狀態,當緩存狀態異常,如緩存重啟、網絡連接異常、與其他緩存連接異常等,服務器將標記Redis異常狀態信息,改變相應競爭因子,實現故障自動識別與切換。

當ATS系統服務器主備機狀態發生切換,或緩存的網絡連接等狀態信息發生故障,分布式緩存系統的主從狀態需要進行切換。Redis主從復制功能雖然內置了基于故障檢測的主從切換策略[9-10],但ATS系統的主備切換需要根據集群機器的網卡狀態、接口狀態、主要進程狀態和集群設備間心跳連接狀態進行判斷,Redis內置的主從切策略不能滿足ATS系統的業務場景需求。

本文提出一種加權競爭算法,根據影響主備切換的系統狀態條件建立狀態矩陣,經過配置的加權參數矩陣的處理,將節點的狀態量化為競爭因子,通過比較競爭因子的大小確定集群各節點的主備狀態。

定義關于離散時間的競爭因子函數如式(1)所示。

m(Tk)=λP(Tk)

(1)

式中:m(Tk)為節點在Tk時刻的競爭因子;P(Tk)為影響主備切換的系統狀態矩陣關于離散時間Tk的函數;λ為各類狀態的影響因子矩陣。

其中,影響主備切換的系統狀態矩陣如式(2)所示,矩陣元素pi(Tk)為網卡狀態、聯鎖接口狀態、ZC限速通道狀態、ZC列車通道狀態、ZCATO通道狀態、TWC接口狀態、主要進程狀態、集群設備間心跳連接狀態等節點相關的狀態信息關于離散時間Tk的抽象模型,當pi(Tk)=1時表示狀態正常,pi(Tk)=0時表示狀態異常。

各類狀態的影響因子矩陣如式(3)所示,矩陣元素λi為各節點狀態信息的權重表示各狀態信息對節點能否正常運行的影響程度,可以根據實際情況進行靈活配置。

(3)

在競選主機的判決中,m(Tk)越大表示被判斷為主機的可能性越大。通過式(1),集群中每個節點計算Tk時刻本節點的m(Tk),并將本節點競選因子廣播到集群。假設集群大小為n,Tk時刻集群中本節點接收到的競爭因子矩陣如式(4)所示。

本節點通過比較當前時刻m(Tk)與接收到的上一時刻競爭因子矩陣Mk-1,判斷本節點主備狀態。若?m∈Mk-1,mm(Tk+1),則本機為備機;若以上兩種情況均不符合,表示存在一個或多個主機與本機競爭因子相等且最大,則進一步比較相同競爭因子主機的唯一標識通用唯一識別碼(Universally Unique Identifier,UUID),UUID最大的節點當選主機。

2) 主主同步方案。中心節點緩存中的數據是所轄范圍內所有車站節點緩存的數據的集合。各車站節點除保存本車站緩存數據外,還需保存相鄰節點緩存數據。本文利用Redis的Stream數據結構,采用生產者消費者模式實現高可靠性、高實時性的緩存數據同步。基于Redis的ATS緩存系統主主同步方案如圖3所示,需要同步數據的節點作為生產者將數據以哈希鍵值對的形式寫入本節點時序消息隊列中,需求同步數據的節點作為消費者獲取生產節點消息隊列中數據。通過消息隊列的形式,將數據同步解耦為異步模式,節點將需要同步的數據以時序序列的形式緩存在節點內存中,消費節點主動檢測隊列中數據更新,讀取未消費數據,實現節點間數據同步。

圖3 主主同步方案

使用Redis中Stream結構存儲數據流,Stream是一個時序的、支持多播的可持久化的消息隊列。ATS系統中,各節點需要同步的數據都為實時狀態信息,將同步數據劃分為全體狀態信息和變化信息,當前狀態可通過過去一段時間內全體消息加上增量的變化信息恢復,在消息隊列中存儲全體信息和變化信息,將標識全體狀態信息的消息ID存儲在Redis中,消費者通過消息ID,獲取當前時間最近的全體信息,消費后續變化信息持續同步數據。全體消息ID失效時,發送請求包,生產者收到請求后,檢查一定時間段內是否處理過請求信息。若未處理過,則寫入全體信息,更新Redis中全體消息ID;若已處理,忽略請求。

2 性能評測

為保證業務系統的高效、穩定,ATS分布式緩存需要滿足極高實時性、可用性,系統響應速度是衡量這一系統性能的關鍵指標。此外,Redis中Stream的不同參數也對系統性能產生影響。因此,本文對基于Redis的ATS分布式緩存系統的響應速度、Stream響應性能進行測試與分析。

2.1 測試環境

搭建ATS集群環境,利用重慶五號線的生產環境數據進行功能和性能測試,本次測試環境中,集群由一個中心服務器與三個車站分機四個節點組成。

2.1.1硬件環境配置

物理節點性能指標均為CPU主頻2.30 GHz,內存2 GB,可用磁盤空間10 GB以上,網卡為2個100 Mbit/s以太網卡。

2.1.2軟件配置

測試環境操作系統版本采用RHEL6.5,內核版本2.6.32,Redis版本采用穩定版5.0.6,使用Redis Desktop Manager程序對Redis的存儲狀態及內存使用情況進行監控。

2.2 測試結果與分析

2.2.1響應速度性能

模擬實際場景中城市軌道交通信號系統的I/O負載,利用重慶五號線生產環境數據對ATS緩存進行性能測試。建立多個緩存客戶端連接,測試不同連接數下系統平均每秒的響應次數,測試結果如圖4所示,可以看出,在連接數為1到20時,隨著連接數的增加,系統響應速度性能會有一定提升;當連接數繼續增加,系統的響應速度性能會有一定程度的下降。ATS系統并發量一般在20～100,緩存系統的平均響應的請求數達100 000次/s以上,可以滿足系統對響應速度的需求。

圖4 實際業務場景中系統響應性能

2.2.2Stream響應性能

由于主主同步中Stream的消息隊列長度參數會對吞吐量產生影響,因此在Stream配置不同消息隊列截取長度參數、有無容忍長度誤差的情況下,對不同寫入次數的執行時間進行測試。在單連接場景下,系統的吞吐量性能如圖5所示。可以看出,執行時間與寫入次數呈線性關系;在消息隊列截取長度較大時,有容忍長度誤差時系統性能更優;相同容忍長度誤差情況下,截取長度較小的執行時間更短,性能更優。

圖5 單連接場景下Stream響應性能

3 結 語

本文提出基于Redis的分布自律的緩存系統設計,實現實時信息的增刪改查,基于工業信號系統需求,實現了雙網冗余、數據同步等功能,保證了系統的高可用性和數據的高一致性。以重慶五號線的實際業務場景為測試環境對本文所設計的系統進行性能測試,結果表明基于Redis的分布自律的緩存系統具有響應速度快、吞吐量大的性能,可以滿足信號系統高可用性、高數據一致性和高實時性的要求。