簡婷
韦德1946网址 上海嘉定201801
摘要：智慧消防係統是一種將GPS(全球衛星定位係統)、GIS(地理信息係統)、GSM(無線移動通信係統)和計算機、物聯網及大數據等技術集於(yu) 一體(ti) 的智能消防無線報警網絡服務係統Redis內(nei) 存數據庫應用於(yu) 智慧消防係統的設計中，可以使智慧消防數據查詢滿足高訪問量、操作方便的現實需求，為(wei) 智慧消防的大數據存儲(chu) 設計提供了有效的參考。
關(guan) 鍵詞：智慧消防；物聯網；大數據；Redis內(nei) 存數據庫
0引言
智慧消防係統山是一種將GPS(全球衛星定位係統)、GIS(地理信息係統)、GSM(無線移動通信係統)和計算機、物聯網和大數據⑵等技術集於(yu) 一體(ti) 的智能消防無線報警網絡服務係統。隨著信息技術的深度發展，人類已進入大數據時代，消防行業(ye) 麵臨(lin) 著巨大挑戰與(yu) 機遇，傳(chuan) 統消防係統工作方式與(yu) 新形勢、新任務不相適應的矛盾日益凸顯,在物聯網產(chan) 業(ye) 迅猛發展的大背景下，主動運用大數據來解決(jue) 了電信、建築、供電、交通等公共設施建設協調發展的問題，在智慧消防係統中，消防指揮與(yu) 用戶單位聯網，改變了過去傳(chuan) 統、落後和被動的報警、接警、處警方式，實現了報警自動化、接警智能化、處警預案化、管理網絡化、服務專(zhuan) 業(ye) 化、科技現代化，大大減少了中間環節，提高了處警速度，做到了方便、快捷、可靠，使人民生命、財產(chan) 的以及警員生命的得到保護Redis*Remotedictionaiyserver)是一款開源的、網絡化的、基於(yu) 內(nei) 存的、可進行數據持久化的Key-Vah/存儲(chu) 係統。它的數據模型建立在外層，類似於(yu) 其他結構化存儲(chu) 係統，是通過Key映射Value的方式來建立字典以保存數據，有別於(yu) 其他結構化存儲(chu) 係統的是，它支持多種數據類型的存儲(chu) ：字符串(string)、鏈表(list)、集合(set)、有序集合(zset)和哈希類型(hash),並且各種類型都支持豐(feng) 富的操作，其中大多都支持原子操作。為(wei) 了保證數據存取的效率，數據都保存在內(nei) 存中Redis還提供了對持久化的支持%它可以定期將更新的數據異步寫(xie) 入磁盤，同時不影響繼續提供服務。在此基礎上，還實現了主從(cong) 複製，這對預防單點故障和提高負載能力有很大幫助。在操作方麵，Redis基於(yu) TCP協議的特性使得它可以通過管道的方式進行數據操作閩。Redis本身提供了一個(ge) 可連接Server的客戶端，通過客戶端可方便地進行數據存取操作。
在智慧消防底層數據庫設計中，*可以應用Redis數據存儲(chu) 係統，以滿足高訪問量與(yu) 操作方便的需求氣在操作方麵，應用Redis的管道通訊方式進行數據操作，通過Redis本身的客戶端，可以同時連接Server服務器，方便地進行數據存取操作常用的消防產(chan) 品信息如：產(chan) 品的生產(chan) 企業(ye) 、型號、證書(shu) 編號、地理位置信息與(yu) 應急救援指示信息等較複雜的信息等信息可以以字符串的格式存儲(chu) 在Redis的底層數據結構中、通過hash結構存儲(chu) ，並通過可以標識產(chan) 品信息的主鍵建立不同數據表中各條產(chan) 品信息的聯係，構建底層信息字典利用Redis底層數據結構對字符串和字典數據的支持，可以達到快速査詢的目的。
在字符串數據的實現中，采用SDS(SimpleDynamicString,簡單動態字符串)取代了功能單一，抽象層次低，並且不的char*類型字符串。在字典數據的實現中，為(wei) 了兼顧簡單性,使用了哈希表。在實現哈希表時，有一個(ge) 問題就是釆用何種策略來解決(jue) 碰撞問題。對於(yu) 使用鏈地址法來解決(jue) 碰撞問題的哈希表來說.哈希表的性能取決(jue) 於(yu) 哈希表大小與(yu) 保存節點數量之間的比率、RDB將數據庫的快照以二進製的方式保存到磁盤中在Redis運行時，RDB程序將當前內(nei) 存中的數據庫快照保存到磁盤文件中，在Redis重啟動時，RDB程序可以通過載入RDB文件來還原數據庫的狀態。AOF則以協議文本的方式，將所有對數據庫進行過寫(xie) 入的命令(及其參數)記錄到AOF文件，以此達到記錄數據庫狀態的目的。AOF更像是曆史記錄，記錄所有運行過的命令。但是AOF文件就會(hui) 隨著時間持續增長，進而占據整個(ge) 磁盤為(wei) 此，Redis設計了AOF重寫(xie) 機製，通過開啟新線程，掃描數據庫數據，將其轉化為(wei) Redis命令，存入臨(lin) 時的AQF文件當掃描完後，用臨(lin) 時文件代替AOF文件。這樣一來，AOF文件中記錄的命令，因而不會(hui) 占據很多空間。
Redis兼具內(nei) 存數據庫隨機訪問的優(you) 勢和Key-Value數據模型簡單特點，因此，其I/O性能非常優(you) 異，支持高並發性，豐(feng) 富的數據結構適合存儲(chu) 何種複雜的數據。考慮到社會(hui) 對智慧消防數據服務的實時響應、高並發、高吞吐量提出了更高的需求，且大多數消防產(chan) 品信息數據服務後台數據量並不大，大容量、低價(jia) 格的內(nei) 存使得以內(nei) 存數據庫的輕量級空間數據應用成為(wei) 可能。本文以內(nei) 存數據庫Redis為(wei) 平台，利用其響應速度快、並發性高、數據結構豐(feng) 富的優(you) 勢，研究了Redis的輕量級數據的組織和索引方法，提升髙並發訪問下消防產(chan) 品信息數據服務的響應速度和査詢性能。
1 Redis數據模型
1.1數據結構設計
Redis本身存儲(chu) 是一個(ge) 巨大的Hash表，為(wei) 了模仿關(guan) 係型數據庫的表，通常使用分隔符分隔“表名”以及“字段”，本文使用”：”作為(wei) 分隔符例如存儲(chu) 一個(ge) 消防產(chan) 品的屬性信息，可以表示為(wei) Product：ProductID作為(wei) key,並用hash結構存儲(chu) 消防產(chan) 品屬性信息field域包括：產(chan) 品名稱(ProductName)、產(chan) 品型號(ProductType)、出廠日期(DateofProduct)、技術參數(TechnicalParameters)、證書(shu) 編號(CertificateNumber)、安裝位置(InstallationSite)和報警記錄(AlarmRecord)等字段。value域包含實際的存儲(chu) 信息。在每一個(ge) 消防產(chan) 品投入到智慧消防雲(yun) 平台前，係統會(hui) 為(wei) 其賦予的產(chan) 品編號PmductlD,因此該key。
表1Redis中hash數據結構設計示例
1.2係統配置
本文采用主從(cong) 方式進行係統配置，共有3個(ge) 主(master)節點，3個(ge) 從(cong) (slave)節點，采用全雙工通信方式，客戶端連接數設置為(wei) 10000,係統為(wei) 每個(ge) 節點分配的內(nei) 存為(wei) 1000MB。采用Java虛擬機環境，Jvm主處理單元配置為(wei) 4核Intel(R)Xeon(R)CPUE7-4830v2@2.20GHz,內(nei) 存31GB,操作係統選擇NeoKylinLinuxAdvancedServerrelease6.0o緩存集群服務器主處理器配置為(wei) 4核Intel(R)Core(TM)i3-2120CPU@3.30GHz,內(nei) 存5.5GB,操作係統選擇RedHatEnterpriseLinuxServerrelease6.3o
2實驗與(yu) 分析
2.1大批量操作緩存測試
智慧消防是一個(ge) 全新的概念和理念，目前尚處於(yu) 發展階段，還沒有權和統一的定義(yi) 和標準。根據智慧消防模型設計的理念圓，模擬出能夠體(ti) 現消防產(chan) 品信息，消防產(chan) 品安裝位置信息和消防產(chan) 品地理位置信息等數據，根據這些信息生成智慧消防係統的模擬數據。在消防產(chan) 品入網前，為(wei) 每一個(ge) 產(chan) 品分配的ProductID,以作為(wei) 該產(chan) 品在係統中的標識。考慮到消防數據的複雜與(yu) 多樣性性在模擬數據時，盡可能地選擇了多的可能體(ti) 現消防產(chan) 品信息的數據，考慮到不同的表中要素的個(ge) 數不同，共生成了2個(ge) 數據表KalOO和AcOOl,其中KalOO中數據盡可能多地體(ti) 現了產(chan) 品的信息，表中所含要素個(ge) 數為(wei) 27891個(ge) ，AcOOl盡可能多地體(ti) 現了產(chan) 品的位置信息,表中所含要素個(ge) 數為(wei) 46254個(ge) ,2張表格中分別具消防產(chan) 品信息數據10萬(wan) 條。
2.2寫(xie) 緩存測試
考慮到智慧消防係統在實際應用中，寫(xie) 緩存業(ye) 務單次不會(hui) 超過5萬(wan) 條，因此將測試的數據量上限設為(wei) 5萬(wan) 。當緩存服務器宕機或其他因素導致緩存不可用時，程序會(hui) 將單次上傳(chuan) 的所有數據存入一條zzOl的blob(binarylargeobject)類型字段中，其中blob的容量為(wei) 2GB。下麵本文對寫(xie) 緩存成功的時間，寫(xie) 緩存失敗的時間以及緩存失敗時存入blob的數據量進行了測試。測試結果如下圖1、圖2。
通過對測試結果進行分析，可以看出緩存同步時間隨著數據量的增加基本呈現線性增長的趨勢，當數據量達到5萬(wan) 條時,AcOOl大小為(wei) 18.6MB,KalOO大小為(wei) 18MB,而blob可以容納2GB,不會(hui) 發生溢出。這樣的結果說明，Redis寫(xie) 緩存的實現過程*可以滿足智慧消防係統實際應用中大數據量同時寫(xie) 入緩存的需求。
2.3數據査詢測試
本文中共使用2個(ge) 數據表KalOO和AcOOl,其中KalOO中數據盡可能多的體(ti) 現了產(chan) 品的信息，表中所含要素個(ge) 數為(wei) 27891個(ge) ,AcOOl盡可能多地體(ti) 現了產(chan) 品的位置信息，表中所含要素個(ge) 數為(wei) 46254個(ge) ，2張表格中分別具有消防產(chan) 品信息數據10萬(wan) 條。在Redis環境和普通數據庫環境下，分別對兩(liang) 張表中不同條數的數據進行了査詢，測試結果取5次測試的平均值，計算出平均査詢時間。
如上圖3、圖4,從(cong) 測試結果中可以看出，無論什麽(me) 數據，Redis環境都比Oracle環境下耗時少得多。因為(wei) Oracle使用的是R樹空間索引，而Redis使用的是網格索引，通常來講，R樹空間索引的效率要高於(yu) 網格索引的效率，但Redis在網格索引的支持下，效率仍然高於(yu) Oracle,說明Redis在智慧消防數據的査詢上，效率更高。另外，Redis作為(wei) 內(nei) 存型數據庫，數據存放在內(nei) 存中，數據査詢可以得到快速響應，而傳(chuan) 統的關(guan) 係型數據庫Oracle,需要將數據存放在硬盤中，需要先傳(chuan) 輸到內(nei) 存中，才能得到響應，受製於(yu) I/O傳(chuan) 輸瓶頸，査詢效率明顯低於(yu) Redis數據庫。
3 安科瑞智慧消防監控雲(yun) 平台介紹與(yu) 選型
3.1平台簡介
安科瑞智慧消防綜合管理雲(yun) 平台基於(yu) 物聯網、大數據、雲(yun) 計算等現代信息技術，將分散的火災自動報警設備、電氣火災監控設備、智慧煙感探測器、智慧消防用水等設備連接形成網絡，並對這些設備的狀態進行智能化感知、識別、定位，實時動態采集消防信息，通過雲(yun) 平台進行數據分析、挖掘和趨勢分析，幫助實現科學預警火災、網格化管理、落實多元責任監管等目標。填補原先針對“九小場所”和危化品生產(chan) 企業(ye) 無法有效監控的空白，適應於(yu) 所有公建和民建，實現了無人化值守智慧消防，實現智慧消防“自動化”、“智能化”、“係統化”、用電管理的實際需求。
從(cong) 火災預防，到火情報警，再到控製聯動，在統一的係統大平台內(nei) 運行，用戶、安保人員、監管單位都能夠通過平台直觀地看到每一棟建築物中各類消防設備和傳(chuan) 感器的運行狀況，並能夠在出現細節隱患、發生火情等緊急和非緊急情況下，在幾秒時間內(nei) ，相關(guan) 報警和事件信息通過手機短信、語音電話、郵件提醒和APP推送等手段，就迅速能夠迅速通知到達相關(guan) 人員。同時，通過自動消防滅火控製裝置啟動自動滅火設備和消防聯動控製設備，有效解決(jue) 用電單位電氣線纜老舊，小微企業(ye) 無專(zhuan) 業(ye) 電工、肉眼無法直觀係統即時排查電氣隱患、隱蔽工程隱患檢查難等難題，及時排除隱患，安科瑞智慧消防監控雲(yun) 平台結構如下圖所示：
3.2平台功能
(1)平台登陸
用戶登錄成功之後進入頁，如圖所示。主要展示的內(nei) 容有：項目概況、設備狀態、設備分類、設備報警信息、報警分類、報警統計、設備台賬信息等。其中百地圖可以選配成BIM建築模型，任何傳(chuan) 感器報警時可以在BIM模型中預警顯示。
(2)實時監控
智慧用電子係統可接入電氣火災、故障電弧、電氣火災主機、滅弧式保護器探測和母排無線測溫探測等等各類子係統，實現對相關(guan) 消防係統設備的信息實時監控，一且發現監測數劇超過風險閾值，APP、電話報警統統上陣，通過設備的標簽、地理位置定位，快速通知，快速處置
(3)隱患管理
隱患管理包括隱患巡查、隱患處理、和隱患記錄，隱患巡查的目的是為(wei) 了係統在產(chan) 生報警或隱患後，係統可以針對工程人員派發工單，處理完以後工程人員能夠在係統中填寫(xie) 相關(guan) 工單任務記錄，以供曆史查詢。隱患統計支持對項目進行日、月、季、年的維度查詢，並能夠自定義(yi) 時間查詢，將項目下隱患以曲線，圖表的形式展現
(4)統計分析
統計分析包括數據匯總和分析報告，數據匯總以曲線和表格形式顯示各個(ge) 月份的報警和故障記錄，同時顯示控製日誌，支持按照控製類和參數設置類分別顯示，也可以按照操作是否成功分別顯示，包括此次控製的操作情況，項目名稱，設備信息以及對應的操作時間等；分析報告包括總體(ti) 概況和設備回路特征分析。
(5)運維管理
根據運維調度管理的需要，智能調度技術人員可以分為(wei) 不同角色，係統支持指巡檢計劃和巡檢日曆，可支持巡檢人員使用手機NFC芯片巡檢打卡的功能。
(6)手機APP功能
手機APP軟件具有ioses版本和安卓版本，並與(yu) 電腦終端係統的數據同步，能展示剩餘(yu) 電流、溫度、電壓、電流等電氣參數的實時監測數據及變化曲線、曆史數據與(yu) 變化曲線；短路、斷線、漏電、超溫、過壓、欠壓、過流等電氣故障實時報警數據等；能實時顯示項目地理位置、未排除隱患數、未處理巡檢數等；通過APP消息推送的方式提醒用戶實時報警信息；可以實現遠程複位、遠程分閘功能；可以對所有現場探測器進行遠程參數設定及修改；可以對所有現場探測器的遠程控製記錄進行查詢； 硬件配置清單：(如申請阿裏雲(yun) 可忽略)
3.4係統現場硬件配置清單：
注：以下配置為(wei) 針對1個(ge) 回路選型，其中剩餘(yu) 電流互感器應根據現場回路電流大
3.5產(chan) 品選型
電氣火災監控探測器
4 結論
消防物聯網的技術發展，將給消防事業(ye) 帶來全新的方法與(yu) 途徑，將改變消防產(chan) 品生產(chan) 與(yu) 消防監管模式四。智慧消防的發展乃是大勢所趨，它是社會(hui) 發展和人們(men) 生活水平提高到一定程度後的必然需求叫。但智慧消防的實現，不僅(jin) 需要消防從(cong) 業(ye) 人員的努力，同時需要與(yu) 物聯網和大數據等技術進一步結合四。本文提出的Redis在智慧消防係統設計中的設計，實現了智慧消防數據庫係統的Redis模型的建立。試驗結果表明，Redis數據模型在智慧消防數據查詢的響應效率，較傳(chuan) 統的Oracle數據模型有較大的優(you) 勢，可以滿足智慧消防係統實際應用中高訪問量、高並發和計時響應的現實需求。
然而，Redis作為(wei) 一個(ge) 內(nei) 存型數據庫，其數據存儲(chu) 容量有限，需要在和大數據結合上更做進一步的研究；智慧消防的設計尚處於(yu) 理論階段，雲(yun) 平台和模型細節仍在研究過程中，因此如何將Redis模型更好地應用於(yu) 智慧消防係統的建設中，還需要研究與(yu) 探索，但隻要全社會(hui) 共同努力，相信智慧消防很快來到我們(men) 身邊。讓我們(men) 共同期待智慧消防早日到來！
參考文獻：
[1]孫超.Redis內(nei) 存數據庫在智慧消防係統設計中的應用.
[2]丁宏軍(jun) .基於(yu) 物聯網技術的智慧消防建設[J].消防技術與(yu) 產(chan) 品信息，2017.
[3]嚴(yan) 霄鳳，張德馨.大數據研究山.計算機技術與(yu) 發展，2013.
[4]安科瑞企業(ye) 微電網設計與(yu) 應用手冊(ce) ，2020.06版.
作者簡介：簡婷,女,韦德1946网址，主要從(cong) 事智慧消防監控係統，
郵箱：2885080326@qq.com
地址：上海市嘉定區育綠路253號
