Redis內(nèi)存數(shù)據(jù)庫(kù)在智慧消防系統(tǒng)設(shè)計(jì)中的應(yīng)用

◆孫 超

Redis內(nèi)存數(shù)據(jù)庫(kù)在智慧消防系統(tǒng)設(shè)計(jì)中的應(yīng)用

◆孫 超

(公安部沈陽(yáng)消防研究所 遼寧 110034)

智慧消防系統(tǒng)是一種將GPS(全球衛(wèi)星定位系統(tǒng))、GIS(地理信息系統(tǒng))、GSM(無(wú)線移動(dòng)通信系統(tǒng))和計(jì)算機(jī)、物聯(lián)網(wǎng)及大數(shù)據(jù)等技術(shù)集于一體的智能消防無(wú)線報(bào)警網(wǎng)絡(luò)服務(wù)系統(tǒng)。將Redis內(nèi)存數(shù)據(jù)庫(kù)應(yīng)用于智慧消防系統(tǒng)的設(shè)計(jì)中，可以使智慧消防數(shù)據(jù)查詢滿足高訪問量、操作方便的現(xiàn)實(shí)需求，為智慧消防的大數(shù)據(jù)存儲(chǔ)設(shè)計(jì)提供了有效的參考。

智慧消防；物聯(lián)網(wǎng)；大數(shù)據(jù)；Redis內(nèi)存數(shù)據(jù)庫(kù)

0 引言

智慧消防系統(tǒng)[1]是一種將GPS(全球衛(wèi)星定位系統(tǒng))、GIS(地理信息系統(tǒng))、GSM(無(wú)線移動(dòng)通信系統(tǒng))和計(jì)算機(jī)、物聯(lián)網(wǎng)和大數(shù)據(jù)[2]等技術(shù)集于一體的智能消防無(wú)線報(bào)警網(wǎng)絡(luò)服務(wù)系統(tǒng)。隨著信息技術(shù)的深度發(fā)展，人類已進(jìn)入大數(shù)據(jù)時(shí)代，消防行業(yè)面臨著前所未有的巨大挑戰(zhàn)與機(jī)遇，傳統(tǒng)消防系統(tǒng)工作方式與新形勢(shì)、新任務(wù)不相適應(yīng)的矛盾日益凸顯。在物聯(lián)網(wǎng)產(chǎn)業(yè)迅猛發(fā)展的大背景下，必須主動(dòng)運(yùn)用大數(shù)據(jù)來解決了電信、建筑、供電、交通等公共設(shè)施建設(shè)協(xié)調(diào)發(fā)展的問題。在智慧消防系統(tǒng)中，消防指揮中心與用戶單位聯(lián)網(wǎng)，改變了過去傳統(tǒng)、落后和被動(dòng)的報(bào)警、接警、處警方式，實(shí)現(xiàn)了報(bào)警自動(dòng)化、接警智能化、處警預(yù)案化、管理網(wǎng)絡(luò)化、服務(wù)專業(yè)化、科技現(xiàn)代化，大大減少了中間環(huán)節(jié)，極大地提高了處警速度，真正做到了方便、快捷、安全、可靠，使人民生命、財(cái)產(chǎn)的安全以及警員生命的安全得到最大限度的保護(hù)。

Redis[3](Ｒemote dictionary server) 是一款開源的、網(wǎng)絡(luò)化的、基于內(nèi)存的、可進(jìn)行數(shù)據(jù)持久化的 Key-Value[4]存儲(chǔ)系統(tǒng)。它的數(shù)據(jù)模型建立在外層，類似于其他結(jié)構(gòu)化存儲(chǔ)系統(tǒng)，是通過Key映射Value的方式來建立字典以保存數(shù)據(jù)，有別于其他結(jié)構(gòu)化存儲(chǔ)系統(tǒng)的是，它支持多種數(shù)據(jù)類型的存儲(chǔ)：字符串(string)、鏈表(list)、集合(set)、有序集合(zset) 和哈希類型 (hash)，并且各種類型都支持豐富的操作，其中大多都支持原子操作。為了保證數(shù)據(jù)存取的效率，數(shù)據(jù)都保存在內(nèi)存中。Ｒedis還提供了對(duì)持久化的支持[5]，它可以定期將更新的數(shù)據(jù)異步寫入磁盤，同時(shí)不影響繼續(xù)提供服務(wù)。在此基礎(chǔ)上，還實(shí)現(xiàn)了主從復(fù)制，這對(duì)預(yù)防單點(diǎn)故障和提高負(fù)載能力有很大幫助。在操作方面，Redis 基于TCP協(xié)議的特性使得它可以通過管道的方式進(jìn)行數(shù)據(jù)操作[6]。Redis 本身提供了一個(gè)可連接Server 的客戶端，通過客戶端可方便地進(jìn)行數(shù)據(jù)存取操作。

在智慧消防底層數(shù)據(jù)庫(kù)設(shè)計(jì)中，完全可以應(yīng)用Redis數(shù)據(jù)存儲(chǔ)系統(tǒng)，以滿足高訪問量與操作方便的需求[7]。在操作方面，應(yīng)用Redis的管道通訊方式進(jìn)行數(shù)據(jù)操作，通過Redis 本身的客戶端，可以同時(shí)連接Server服務(wù)器，方便地進(jìn)行數(shù)據(jù)存取操作。常用的消防產(chǎn)品信息如：產(chǎn)品的生產(chǎn)企業(yè)、型號(hào)、證書編號(hào)、地理位置信息與應(yīng)急救援指示信息等較復(fù)雜的信息等信息可以以字符串的格式存儲(chǔ)在Redis的底層數(shù)據(jù)結(jié)構(gòu)中。通過hash結(jié)構(gòu)存儲(chǔ)，并通過可以唯一標(biāo)識(shí)產(chǎn)品信息的主鍵建立不同數(shù)據(jù)表中各條產(chǎn)品信息的聯(lián)系，構(gòu)建底層信息字典。利用Redis 底層數(shù)據(jù)結(jié)構(gòu)對(duì)字符串和字典數(shù)據(jù)的高效支持，可以達(dá)到快速查詢的目的。

在字符串?dāng)?shù)據(jù)的實(shí)現(xiàn)中，采用SDS(Simple Dynamic String，簡(jiǎn)單動(dòng)態(tài)字符串)取代了功能單一，抽象層次低，并且不高效的char*類型字符串。在字典數(shù)據(jù)的實(shí)現(xiàn)中，為了兼顧高效和簡(jiǎn)單性，使用了哈希表。在實(shí)現(xiàn)哈希表時(shí)，有一個(gè)問題就是采用何種策略來解決碰撞問題。對(duì)于使用鏈地址法來解決碰撞問題的哈希表來說，哈希表的性能取決于哈希表大小與保存節(jié)點(diǎn)數(shù)量之間的比率。RDB 將數(shù)據(jù)庫(kù)的快照以二進(jìn)制的方式保存到磁盤中。在Redis運(yùn)行時(shí)，RDB程序?qū)?dāng)前內(nèi)存中的數(shù)據(jù)庫(kù)快照保存到磁盤文件中，在Redis重啟動(dòng)時(shí)，RDB程序可以通過載入RDB文件來還原數(shù)據(jù)庫(kù)的狀態(tài)。AOF則以協(xié)議文本的方式，將所有對(duì)數(shù)據(jù)庫(kù)進(jìn)行過寫入的命令(及其參數(shù))記錄到AOF文件，以此達(dá)到記錄數(shù)據(jù)庫(kù)狀態(tài)的目的。AOF更像是歷史記錄，記錄所有運(yùn)行過的命令。但是AOF文件就會(huì)隨著時(shí)間持續(xù)增長(zhǎng)，進(jìn)而占據(jù)整個(gè)磁盤。為此，Redis 設(shè)計(jì)了AOF 重寫機(jī)制，通過開啟新線程，掃描數(shù)據(jù)庫(kù)數(shù)據(jù)，將其轉(zhuǎn)化為Redis命令，存入臨時(shí)的AOF文件。當(dāng)掃描完后，用臨時(shí)文件代替AOF文件。這樣一來，AOF 文件中記錄的命令就是最簡(jiǎn)潔的，因而不會(huì)占據(jù)很多空間。

Redis 兼具內(nèi)存數(shù)據(jù)庫(kù)隨機(jī)訪問的優(yōu)勢(shì)和Key-Value數(shù)據(jù)模型簡(jiǎn)單高效的特點(diǎn)，因此，其 I/O性能非常優(yōu)異，支持高并發(fā)性，豐富的數(shù)據(jù)結(jié)構(gòu)適合存儲(chǔ)何種復(fù)雜的數(shù)據(jù)?？紤]到社會(huì)對(duì)智慧消防數(shù)據(jù)服務(wù)的實(shí)時(shí)響應(yīng)、高并發(fā)、高吞吐量提出了更高的需求，且大多數(shù)消防產(chǎn)品信息數(shù)據(jù)服務(wù)后臺(tái)數(shù)據(jù)量并不大，大容量、低價(jià)格的內(nèi)存使得以內(nèi)存數(shù)據(jù)庫(kù)的輕量級(jí)空間數(shù)據(jù)應(yīng)用成為可能。本文以內(nèi)存數(shù)據(jù)庫(kù)Redis為平臺(tái)，利用其響應(yīng)速度快、并發(fā)性高、數(shù)據(jù)結(jié)構(gòu)豐富的優(yōu)勢(shì)，研究了Redis的輕量級(jí)數(shù)據(jù)的高效組織和索引方法，提升高并發(fā)訪問下消防產(chǎn)品信息數(shù)據(jù)服務(wù)的響應(yīng)速度和查詢性能。

1 Redis數(shù)據(jù)模型

1.1 數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)

Redis本身存儲(chǔ)是一個(gè)巨大的Hash表，為了模仿關(guān)系型數(shù)據(jù)庫(kù)的表，通常使用分隔符分隔“表名”以及“字段”，本文使用”：”作為分隔符。例如存儲(chǔ)一個(gè)消防產(chǎn)品的屬性信息，可以表示為Product：ProductID作為key，并用hash結(jié)構(gòu)存儲(chǔ)消防產(chǎn)品屬性信息。field域包括：產(chǎn)品名稱(ProductName)、產(chǎn)品型號(hào)(ProductType)、出廠日期(Date of Product)、技術(shù)參數(shù)(TechnicalParameters)、證書編號(hào)(CertificateNumber)、安裝位置(InstallationSite)和報(bào)警記錄(AlarmRecord)等字段。value域包含實(shí)際的存儲(chǔ)信息。在每一個(gè)消防產(chǎn)品投入到智慧消防云平臺(tái)前，系統(tǒng)會(huì)為其賦予唯一的產(chǎn)品編號(hào)ProductID，因此該key是唯一的。

表1 Redis中hash數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)示例

1.2 系統(tǒng)配置

本文采用主從方式進(jìn)行系統(tǒng)配置，共有3個(gè)主(master)節(jié)點(diǎn)，3個(gè)從(slave)節(jié)點(diǎn)，采用全雙工通信方式，最大客戶端連接數(shù)設(shè)置為10000，系統(tǒng)為每個(gè)節(jié)點(diǎn)分配的最大內(nèi)存為1000MB。采用Java虛擬機(jī)環(huán)境， Jvm主處理單元配置為4核Intel(R) Xeon(R) CPU E7-4830 v2 @ 2.20GHz，內(nèi)存31GB，操作系統(tǒng)選擇NeoKylin Linux Advanced Server release 6.0。緩存集群服務(wù)器主處理器配置為4核Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz，內(nèi)存5.5GB，操作系統(tǒng)選擇Red Hat Enterprise Linux Server release 6.3。

2 實(shí)驗(yàn)與分析

2.1 大批量操作緩存測(cè)試

智慧消防是一個(gè)全新的概念和理念，目前尚處于發(fā)展階段，還沒有權(quán)威和統(tǒng)一的定義和標(biāo)準(zhǔn)。根據(jù)智慧消防模型設(shè)計(jì)的理念[8]，模擬出能夠體現(xiàn)消防產(chǎn)品信息，消防產(chǎn)品安裝位置信息和消防產(chǎn)品地理位置信息等數(shù)據(jù)，根據(jù)這些信息生成智慧消防系統(tǒng)的模擬數(shù)據(jù)。在消防產(chǎn)品入網(wǎng)前，為每一個(gè)產(chǎn)品分配唯一的ProductID，以作為該產(chǎn)品在系統(tǒng)中唯一的標(biāo)識(shí)。考慮到消防數(shù)據(jù)的復(fù)雜與多樣性[9]，在模擬數(shù)據(jù)時(shí)，盡可能地選擇了多的可能體現(xiàn)消防產(chǎn)品信息的數(shù)據(jù)，考慮到不同的表中要素的個(gè)數(shù)不同，共生成了2個(gè)數(shù)據(jù)表Ka100和Ac001，其中Ka100中數(shù)據(jù)盡可能多地體現(xiàn)了產(chǎn)品的信息，表中所含要素個(gè)數(shù)為27891個(gè)，Ac001盡可能多地體現(xiàn)了產(chǎn)品的位置信息，表中所含要素個(gè)數(shù)為46254個(gè)，2張表格中分別具有消防產(chǎn)品信息數(shù)據(jù)10萬(wàn)條。

2.2 寫緩存測(cè)試

考慮到智慧消防系統(tǒng)在實(shí)際應(yīng)用中，寫緩存業(yè)務(wù)單次不會(huì)超過5萬(wàn)條，因此將測(cè)試的數(shù)據(jù)量上限設(shè)為5萬(wàn)。當(dāng)緩存服務(wù)器宕機(jī)或其他因素導(dǎo)致緩存不可用時(shí)，程序會(huì)將單次上傳的所有數(shù)據(jù)存入一條zz01的blob(binary large object)類型字段中，其中blob的最大容量為2GB。下面本文對(duì)寫緩存成功的時(shí)間，寫緩存失敗的時(shí)間以及緩存失敗時(shí)存入blob的數(shù)據(jù)量進(jìn)行了測(cè)試。測(cè)試結(jié)果如下圖1、圖2。

圖1 寫緩存數(shù)據(jù)時(shí)間測(cè)試

圖2 緩存失敗時(shí)存入blob的數(shù)據(jù)量測(cè)試

通過對(duì)測(cè)試結(jié)果進(jìn)行分析，可以看出緩存同步時(shí)間隨著數(shù)據(jù)量的增加基本呈現(xiàn)線性增長(zhǎng)的趨勢(shì)，當(dāng)數(shù)據(jù)量達(dá)到5萬(wàn)條時(shí)，Ac001大小為18.6MB，Ka100大小為18MB，而blob最大可以容納2GB，不會(huì)發(fā)生溢出。這樣的結(jié)果說明，Redis寫緩存的實(shí)現(xiàn)過程完全可以滿足智慧消防系統(tǒng)實(shí)際應(yīng)用中大數(shù)據(jù)量同時(shí)寫入緩存的需求。

2.3 數(shù)據(jù)查詢測(cè)試

本文中共使用2個(gè)數(shù)據(jù)表Ka100和Ac001，其中Ka100中數(shù)據(jù)盡可能多的體現(xiàn)了產(chǎn)品的信息，表中所含要素個(gè)數(shù)為27891個(gè)，Ac001盡可能多地體現(xiàn)了產(chǎn)品的位置信息，表中所含要素個(gè)數(shù)為46254個(gè)，2張表格中分別具有消防產(chǎn)品信息數(shù)據(jù)10萬(wàn)條。在Redis環(huán)境和普通數(shù)據(jù)庫(kù)環(huán)境下，分別對(duì)兩張表中不同條數(shù)的數(shù)據(jù)進(jìn)行了查詢，測(cè)試結(jié)果取5次測(cè)試的平均值，計(jì)算出平均查詢時(shí)間。

圖3 針對(duì)Ka100表的Redis和Oracle數(shù)據(jù)庫(kù)查詢響應(yīng)時(shí)間對(duì)比

圖4 針對(duì)Ac001表的Redis和Oracle數(shù)據(jù)庫(kù)查詢響應(yīng)時(shí)間對(duì)比

如上圖3、圖4，從測(cè)試結(jié)果中可以看出，無(wú)論什么數(shù)據(jù)，Redis環(huán)境都比Oracle環(huán)境下耗時(shí)少得多。因?yàn)镺racle使用的是R樹空間索引，而Redis使用的是網(wǎng)格索引，通常來講，R樹空間索引的效率要高于網(wǎng)格索引的效率，但Redis在網(wǎng)格索引的支持下，效率仍然高于Oracle，說明Redis在智慧消防數(shù)據(jù)的查詢上，效率更高。另外，Redis作為內(nèi)存型數(shù)據(jù)庫(kù)，數(shù)據(jù)存放在內(nèi)存中，數(shù)據(jù)查詢可以得到快速響應(yīng)，而傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)Oracle，需要將數(shù)據(jù)存放在硬盤中，需要先傳輸?shù)絻?nèi)存中，才能得到響應(yīng)，受制于I/O傳輸瓶頸，查詢效率明顯低于Redis數(shù)據(jù)庫(kù)。

3 結(jié)語(yǔ)

消防物聯(lián)網(wǎng)的技術(shù)發(fā)展，將給消防事業(yè)帶來全新的方法與途徑，將徹底改變消防產(chǎn)品生產(chǎn)與消防監(jiān)管模式[10]。智慧消防的發(fā)展乃是大勢(shì)所趨，它是社會(huì)發(fā)展和人們生活水平提高到一定程度后的必然需求[11]。但智慧消防的實(shí)現(xiàn)，不僅需要消防從業(yè)人員的努力，同時(shí)需要與物聯(lián)網(wǎng)和大數(shù)據(jù)等技術(shù)進(jìn)一步結(jié)合[12]。本文提出的Redis在智慧消防系統(tǒng)設(shè)計(jì)中的設(shè)計(jì)，實(shí)現(xiàn)了智慧消防數(shù)據(jù)庫(kù)系統(tǒng)的Redis模型的建立。試驗(yàn)結(jié)果表明，Redis數(shù)據(jù)模型在智慧消防數(shù)據(jù)查詢的響應(yīng)效率，較傳統(tǒng)的Oracle數(shù)據(jù)模型有較大的優(yōu)勢(shì)，可以滿足智慧消防系統(tǒng)實(shí)際應(yīng)用中高訪問量、高并發(fā)和計(jì)時(shí)響應(yīng)的現(xiàn)實(shí)需求。

然而，Redis作為一個(gè)內(nèi)存型數(shù)據(jù)庫(kù)，其數(shù)據(jù)存儲(chǔ)容量有限，需要在和大數(shù)據(jù)結(jié)合上更做進(jìn)一步的研究；智慧消防的設(shè)計(jì)尚處于理論階段，最終的云平臺(tái)和模型細(xì)節(jié)仍在研究過程中，因此如何將Redis模型更好地應(yīng)用于智慧消防系統(tǒng)的建設(shè)中，還需要更全面的研究與探索，但只要全社會(huì)共同努力，相信智慧消防很快來到我們身邊。讓我們共同期待智慧消防早日到來！

[1]丁宏軍.基于物聯(lián)網(wǎng)技術(shù)的智慧消防建設(shè)[J].消防技術(shù)與產(chǎn)品信息，2017.

[2]嚴(yán)霄鳳，張德馨.大數(shù)據(jù)研究[J].計(jì)算機(jī)技術(shù)與發(fā)展， 2013.

[3] Redis [EB/OL]. 2016-01-28. http: //redis.io.

[4]Key-Value stores: A practical overview[EB/OL].

[2013-07-25].http://blog.marc-seeger.de/assets/papers/Ul-tra_Large_Sites_SS09-Seeger_Key_Value_Stores.pdf.

[5]How fast is Redis[EB/OL]. 2013-08-20.http: //redis. io/topics/benchmarks.

[6]朱明倫，胡金初.Linux下基于B/S的高并發(fā)Web服務(wù)優(yōu)化研究[J].計(jì)算機(jī)技術(shù)與發(fā)展，2006.

[7]王珊，肖艷芹，劉大為等.內(nèi)存數(shù)據(jù)庫(kù)關(guān)鍵技術(shù)研究[J].計(jì)算機(jī)應(yīng)用，2007.

[8]丁祥郭.“智慧消防”建設(shè)與發(fā)展的思考[J].計(jì)算機(jī)安全， 2012.

[9]張景云.基于Redis的矢量數(shù)據(jù)組織研究[D].南京:南京師范大學(xué)，2013.

[10]曹盛華.關(guān)于“智慧消防”建設(shè)與發(fā)展的探討[J].數(shù)字化用戶，2017.

[11]丁曉春.云計(jì)算與上海市智慧消防[J].現(xiàn)代測(cè)繪，2013.

[12]葛儉輝.物聯(lián)網(wǎng)技術(shù)在“智慧消防”建設(shè)中的應(yīng)用初探[C].消防科技與經(jīng)濟(jì)發(fā)展—2014年浙江省消防學(xué)術(shù)論文優(yōu)秀獎(jiǎng)?wù)撐募?015.