基于Redis與SSM的大型設備數據運用系統設計

熊肖磊，王春偉，趙 炯，周奇才

(同濟大學機械與能源工程學院，上海201804)

0 引言

對于大型設備運行數據采集并加以處理運用，進而實現設備生命周期管理是目前設備管理的研究重點，而本文以盾構設備為例，探討其數據處理運用系統設計方案與實現。隨著地鐵隧道掘進技術的逐漸發展完善，一條隧道的掘進過程往往伴隨著多臺盾構機施工，如此會出現多臺盾構分散施工而管理維護困難的問題，于是在管理成本的制約下，需要建立某種系統對盾構設備及施工進程數據進行有效運用，從而實現對盾構有效的監控管理。對此，國內外的盾構生產商，諸如鐵建、海瑞克和小松等，都對自家盾構配置了數據采集系統，但大多數無法滿足多盾構數據處理運用，多用戶訪問的情況。文獻[1]利用方便開發的組態軟件實現監控管理，但不利于后期擴展，其系統需要特定運行環境。文獻[5]以C/S結構實現了多臺盾構的集中監控與數據運用，并成功應用在大連地鐵103和201標項目，但隨數據量增大，會使數據庫訪問壓力增大。文獻[8]實現了網絡化盾構自動監控系統，并未滿足集中監控目的。文中給出了一種嵌入式網絡化盾構自動監控及報表系統，著重闡述了硬件結構與網絡協議移植，并未滿足多盾構監控目的。

基于B/S架構來構建盾構監控與數據運用系統既可實現多臺盾構集中監控，數據處理，分析等工作，且無需安裝專用客戶端，只需通過瀏覽器即可訪問，實現了多盾構多用戶的互聯網監控管理目的[2]。因此本文則采用B/S模式構建盾構機的數據處理運用系統，以SSM(Spring MVC、Spring、Mybatis)框架作為B/S實現的基礎與開發輔助。同時考慮到數據量快速增長，采用數據緩存技術實現較快速的數據處理能力，同時提供快速的并發訪問。本文利用Redis作為內存數據庫進行盾構實時數據緩存，并以MySQL進行數據同步，將盾構歷史數據與固有信息持久化，并且圍繞SSM框架技術，以分層方式設計系統，實現多盾構快速高效的數據處理運用。

1 相關技術介紹

Redis作為一種NoSQL類型的數據庫，具備了NoSQL靈活的數據模型；可存儲處理非結構化及半結構化數據；良好的可擴展性；快速的讀寫能力和低廉的成本等特點[3]。NoSQL(Not Only SQL)泛指非關系型數據庫，常用于超大規模和高并發的數據存儲處理場景中，其根據數據庫存儲類型分為鍵值(Key-Value)存儲數據庫、列式存儲數據庫、文檔性數據庫和圖形數據庫[3]。而Redis作為一種開源的Key-Value數據存儲系統，支持存儲的Value類型包括了字符串、鏈表、集合及哈希等類型，并且均支持push/pop、add/remove及取交集并集和差集等操作，同時Redis會周期性地把更新的數據寫入磁盤或者把修改操作寫入追加的記錄文件，并且在此基礎上實現Master-Slave同步[4，10]。

SSM(Spring+SpringMVC+Mybatis)框架集由Spring、SpringMVC、Mybatis三個開源框架整合而成，常作為數據源較為簡單的web項目的開發框架[6，9]。其中SpringMVC分離了控制器、模型對象、分派器以及處理器程序對象的角色，使其更容易進行定制；Spring是一個輕量級的控制反轉(IoC)和面向切面(AOP)的容器框架，供表現層調用，充當了表現層與持久層間的接口；而Mybatis則進行數據的持久化操作，支持普通SQL查詢、存儲過程和高級映射，通過對象關系映射將Java對象與數據庫中的數據記錄相互轉換。通過在開源框架配置文件中的引用與項目中依賴包的導入，即可將三個框架整合起來，實現完整的前后端通信流程[6]。

2 系統結構設計

本文旨在利用數據緩存Redis和SSM集成框架搭建一種適用于盾構機數據處理運用的系統，對此在盾構機數據采集的基礎上對系統進行結構的分層設計。整個系統基于B/S模式進行開發，而盾構數據通過機載的數據采集器用PLC采集得來，需要解包、轉換、緩存和持久化。因此整個系統的工作流程是先將機載系統采集的數據解析后進入Redis，然后按照前端請求進行實時的數據請求響應，同時將盾構固有數據和實時數據同步存儲到MySQL中，為后續的故障預測、數據分析等大量數據運用處理過程事務提供數據源。所以根據數據流動和功能劃分，本文將整個系統軟件結構分為數據層、應用層和表示層[9]，如圖1。

圖1 系統框架結構圖

如圖1所示，數據層將底層盾構機載系統采集的數據在傳輸到數據中心的服務器后進行解析和存儲，提供更加結構化的數據源；應用層則是利用數據庫中存儲的數據進行模塊化的功能處理，諸如狀態監測顯示、設備關系、故障分析預測等，并使用SSM框架進行設計解耦，獨立封裝各模塊功能，對客戶端的數據請求給予正確響應；而表示層通過瀏覽器頁面對盾構數據的諸多處理運用結果進行可視化的顯示。

3 數據層

在前面提到數據層主要對后續應用層功能表現提供數據支持，即數據層是系統的基礎環節，該層通過對底層機載系統采集傳輸的數據進行解析和存儲，并在存儲之前做一定程度的預處理，使存儲的數據更具有結構性。本文將數據層實現分為兩個部分：Redis實時緩存與MySQL持久化，以分別應對實時監測與大數據量分析運用的功能實現。

3.1 Redis實時數據解析緩存

盾構機在掘進隧道的過程中，需要將采集監測的量按類型分為數字量和模擬量。其中數字量對應某個限位開關的開閉或者千斤頂的伸縮，而模擬量則對應千斤頂壓力、電機電壓、旋轉速度以及注漿壓力等具有數值意義的量。同時數據遵循一定的協議格式傳輸，因此接收到數據之后，同樣按照此種協議格式進行解析，通過數據包的起始地址加上偏移量的方法，得出各個測點或者數據量的真實數據，解析過程如圖2。

圖2 源數據解析流程

源數據進行解析后按照是否超過上下限進行緩存，對于實時數據的存儲則按照測點配置表中的信息進行對號入座，根據底層數據采集的約定協議生成各個測點的配置表，如表1與圖3。

表1 各測點的偏移量對應關系

圖3 測點信息配置表

如表1所列測點偏移量對應關系，解析程序即按此進行數據包解析，同時生成一項測點信息的配置表存儲在數據庫中，便于之后作為某臺盾構的特征信息查看。在生成測點信息配置表過程中，以各測點所屬盾構機子系統分組，如此在后續對盾構機子系統部件進行分析時提供便利，如圖3。

如此實時數據經解析之后便可以進行Redis緩存了，在Redis緩存中以Key-Value的數據形式存儲[10]，對于實時數據而言，每一個時刻的數據均是有區別的，這種區別存在于每一個傳輸的數據包上帶有的時間戳(TIMESTAMP)，于是對于兩個實時數據包即可通過TIMESTAMP進行區分，并可作為Key來標識緩存中的Value。結合Key-Value存儲無表概念的特點，實時數據的存儲時，以盾構ID為Key，以hash作為Value存儲此臺盾構的數據，如此便可以Key區分不同盾構的數據。對于Value部分的hash，以TIMESTAMP作為Key，以數據list作為Value，如此便可區分同一盾構不同時刻的數據，在數據list中，以Key-Value的形式存儲各個測點的名稱及對應的數值[4]。因此存儲結構如表2所示。從表2中可以看出，根據盾構的標識ID及某個時刻的TIMESTAMP即可以唯一的確定某臺盾構某一時刻的各個測點的實時數據，根據底層數據發送的時間間隔進行實時數據的解析緩存，并將一段時間內的舊數據同步至MySQL中，而后刪除，保證內存不被占滿。

表2 實時數據緩存結構

3.2 MySQL數據持久化

通過前面內容所述，盾構實時數據在經過Redis緩存之后，同步持久化至MySQL中，用于后續的數據分析工作，而且盾構機的某些固有特征數據也要存儲到數據庫中，由于這些數據一般是結構化數據，所以可直接利用MySQL存儲。對于盾構機特征數據和故障記錄等并不會由底層數據采集系統傳輸，而是訪問特定的接口得到，而此種訪問是以JSON字符串作為數據傳輸的格式，因此在訪問特定接口獲得盾構機特征數據和故障記錄信息的處理流程如圖4。

圖4 接口數據處理存儲流程

對于實時數據的持久化存儲時需要考慮盾構機組成特點和系統的功能需求，然后設計存儲的表結構。盾構機是一種集機械、電氣和液壓系統與一體的大型設備，其結構復雜，系統眾多，每個大的部件或者子系統中包含諸多零部件，并且零部件之間存在某種父子關系。所以在設計表結構時考慮零部件的父子關系將其按照樹形結構存儲，即一臺設備包含多個子系統，一個子系統包含多個部件，一個部件包含多個零件或測點，即它們之間是1∶n的關系；同時考慮到多臺盾構的集中監控與數據運用，所有數據存儲在一張數據表中會因為記錄太多導致查詢某臺盾構的運行數據時緩慢，因此采用單盾構單表的形式，即單張數據表中只存儲一臺盾構的運行數據，并使用配置表維護，使各臺盾構名稱與數據表名關聯起來，從而將多臺盾構的運行數據分散到多張表中存儲，減輕了單張表存儲記錄過多的壓力。于是綜合信息后得出其中的關聯如圖5。

圖5 盾構運行數據存儲表關聯示意

如圖5(a)，通過配置表中表名字段與盾構數據表名關聯，實現數據分散至多表存儲，而圖5(b)則是對某臺盾構而言的設備、部件、測點和數據的關聯示意，如此則實現了樹形存儲。

4 應用層

應用層主要是以數據層為基礎，通過調用數據層向上提供的接口，對該層提供的盾構運行數據和特征數據進行對應的加工處理，實現相應的業務邏輯，并向表示層提供接口，將實現的業務邏輯通過表示層可視化表現。如此處于系統中間層的應用層是系統核心，起著承上啟下的作用，系統的功能實現則主要在這層實現。

對于盾構機而言，其在運行過程中積累大量的工程數據，包括關鍵部件測點的監測參數、掘進隧道的地質數據、設備故障信息和維護信息等，這些數據是監測管理盾構的重要依據。因此對于盾構管理而言，應該是全周期的，即對盾構施工前期、施工中期和施工后期的信息都需要進行管理。而盾構機工作環境較為惡劣，如果出現零件損壞，則勢必會影響整個盾構的運行，因此對于盾構數據的處理運用包含了實時數據監測、測點歷史統計、故障信息記錄以及基于歷史運行數據的故障預測與診斷等，便可以時刻關注盾構的健康狀態，使得在零部件出現損壞前給出預警，及時更換，從而不會影響整個系統的正常運行。在這些功能的實現上，利用SSM框架進行應用系統解耦，以模塊獨立化的方式開發，簡化了開發流程，達到在模塊內部可以更加專注于邏輯實現，高度內聚，而在模塊之間專注于接口調用，低度耦合的目的。應用層結構如圖6。

圖6 應用層結構示意圖

如圖6，應用層中包含多個功能模塊，并且各模塊之間相互獨立，通過Spring MVC向表示層提供統一的訪問接口，在接收到表示層請求之后，根據Spring MVC的控制器分發請求，直接調用對應的模塊進行其中的業務邏輯處理，同時這一過程有著Spring的管理與Mybatis對象關系映射，從而能夠完成接收請求，分發請求，業務處理，訪問數據源，模型生成，視圖填充以及給予響應的完整過程[9]。

在過程實現中，Spring整合Mybatis，進行數據通道、映射與事務的管理，通過在Spring容器中注冊DataSource、SqlSessionFactory和MapperScannerConfigurer的實例bean，將數據源屬性文件載入，從而加載數據通道和關系映射原則，并制定Mapper接口的掃描路徑，使得在訪問數據庫時自動掃描Mapper接口進行數據的持久化操作，把Java對象與數據表記錄映射起來，從而完成在應用層中的對象傳遞。而Spring MVC則主要加載了請求映射器和適配器的驅動，配置了基于注解@Controller的控制器掃描路徑，使得Spring MVC在攔截請求之后，根據攔截路徑，自動掃描@Controller類，匹配攔截路徑，從而可以執行對應的業務邏輯，調用對應的接口方法，訪問對應的數據庫表[6]。

之后則是在項目啟動文件中設置Spring及Spring MVC的入口文件，從而在系統啟動時，框架功能也隨之準備就緒，即在web.xml中設置Spring配置文件applicationContext.xml路徑以及Spring MVC的請求控制分發器DispatcherServlet和Spring-mvc.xml的路徑，并在web.xml中配置好請求攔截HTTP請求的基礎路徑[9]。

5 表示層

表示層作為系統頂層，主要是將盾構數據處理應用后的結果以某種方式呈現出來，即通過文字、圖片、表格和視頻等元素構成的網頁顯示在用戶的瀏覽器上，從而使用戶更加直觀的感受各種數據處理后的結果。對于表示層而言，其通過應用層取得業務邏輯處理后的結果數據，填充到經過HTML、CSS和JavaScript美化過的頁面中，形成最終的網頁。但是這樣在結果數據變化時，為了體現這種變化，前端表示頁面也需要不斷刷新載入，這對于實時數據監控顯示或者根據條件查詢的應用來說很不友好，每次整體頁面刷新不僅體驗不好，同時也對系統資源造成了浪費，所以就使用AJAX進行頁面的局部刷新。通過AJAX[7]向服務端請求數據時，一般有長輪詢和短輪詢兩種方式，其中長輪詢就是建立瀏覽器與服務器之間的鏈接持續保持下去，多次請求使用同一個連接，而短輪詢則是每次請求都會建立新的鏈接，請求結束后鏈接也隨之中斷；但由于長輪詢需要服務器維持鏈接，導致系統資源多余耗費，同時實時數據監控顯示間隔在秒級單位，因此本文采用短輪詢的方式請求數據。

對于實時監測數據顯示，每次AJAX請求為盾構機標識ID和當前時間戳TIMESTAMP，服務器端接收參數之后，從Redis數緩存中查詢出數據，并以AJAX請求中常用的JSON數據傳輸格式返回數據，對實時監測頁面進行局部的數據更新，從而達到盾構運行數據實時變化的目的。AJAX數據請求流程如圖7。

圖7 實時數據監測顯示頁面AJAX請求流程

如圖7所示，前端瀏覽器獲取盾構標識ID和當前時間戳TIMESTAMP之后作為參數發起AJAX請求，服務器接收AJAX請求后解析出盾構標識和時間戳參數，并按此查詢Redis數據緩存，并將查詢結果以JSON格式返回至瀏覽器，瀏覽器解析JSON數據，填充頁面實現局部刷新。而實現代碼如下[7]：

$.ajax({ type ： "POST"，url ： "xxx"，dataType ： "json"，

data ： {"shieldID" ： ID，"Timestamp" ： Timestamp}，

success ： function (data) { …//更新頁面部分}，

error ： function () { …//異常處理部分代碼}});

實時數據監測頁面示意如圖8，圖中通過純數據顯示方式將盾構各子系統關鍵參量的數據變化直接表示，包括了千斤頂系統、刀盤系統、螺旋機系統和注漿與泡沫系統，并結合折線圖和儀表板插件強調某些參量的變化趨勢與變動情況。

而對于盾構固有特征信息查詢或者統計分析、故障統計、地表沉降預測等結果顯示同樣是基于AJAX短輪詢實現，即通過不同業務邏輯處理或根據模塊配置即可同樣原理實現。諸如圖9所示的故障統計，通過柱狀圖顯示數量，表格顯示詳細記錄。

圖8 盾構運行數據實時監測顯示示意圖

圖9 盾構故障信息統計

6 結論

本文使用Redis數據緩存和MySQL持久化，對盾構運行數據和結構化特征數據進行存儲，并通過SSM框架搭建了基于B/S模式的盾構數據處理運用系統。系統總體結構分為三層，分別是數據層、應用層和結構層，在數據層中使用Redis對實時數據進行緩存，以滿足實時監控的要求，并且將歷史數據及時同步至MySQL中，對后續一系列的數據處理應用提供數據源。雖然目前可以實現多臺盾構的集中監控，但為了提供數據處理能力和系統交互能力，后續可進一步搭建Redis集群，以應對高并發系統訪問；同時在數據處理方面應用機器學習、數據挖掘等方法進一步增強對盾構數據的處理效果，從而能夠完整的實現盾構的全生命周期管理。