基于區(qū)塊鏈的村鎮(zhèn)污水處理監(jiān)測系統(tǒng)設(shè)計(jì)

張?jiān)铺?/p>

（青島理工大學(xué)信息與控制工程學(xué)院 山東省青島市 266525）

1 概述

村鎮(zhèn)污水處理監(jiān)測系統(tǒng)與技術(shù)行業(yè)關(guān)聯(lián)密切，長期以來，云計(jì)算、大數(shù)據(jù)等創(chuàng)新技術(shù)為其帶來了更高的可用性與實(shí)時(shí)性。傳統(tǒng)系統(tǒng)[1-2]利用物聯(lián)網(wǎng)(IoT)[3]技術(shù)采集設(shè)備監(jiān)測數(shù)據(jù)上傳存儲至中心服務(wù)器,基于應(yīng)用程序?qū)崿F(xiàn)可視化監(jiān)測。如張效葦[4]等設(shè)計(jì)的村鎮(zhèn)污水處理遠(yuǎn)程采集與監(jiān)測系統(tǒng)；Rezwan Sifat[5]等搭建的IoT 傳輸污水處理站數(shù)據(jù)極簡模型。然而傳統(tǒng)系統(tǒng)依賴中心數(shù)據(jù)庫，面臨數(shù)據(jù)篡改風(fēng)險(xiǎn)，這對需要在多種參與者之間共享IoT 數(shù)據(jù)的村鎮(zhèn)污水處理監(jiān)測場景危害極大。

在村鎮(zhèn)污水處理監(jiān)測場景中，數(shù)據(jù)共享主要涉及三方，污水處理站管理人員、監(jiān)管機(jī)構(gòu)以及公眾。通過系統(tǒng)，污水處理站管理人員實(shí)時(shí)了解站點(diǎn)運(yùn)行情況，監(jiān)管機(jī)構(gòu)履行政務(wù)監(jiān)管，公眾進(jìn)行第三方監(jiān)督。惡意的村鎮(zhèn)污水處理監(jiān)測數(shù)據(jù)篡改可能會造成經(jīng)濟(jì)損失、環(huán)境污染、監(jiān)管失職等不利后果，甚至危害到人身健康。如美國弗林特市水污染事件[6]中水質(zhì)數(shù)據(jù)被惡意篡改造成的市民飲用污染水中毒事件。

區(qū)塊鏈技術(shù)[7]的出現(xiàn)，為保護(hù)村鎮(zhèn)污水處理監(jiān)測系統(tǒng)數(shù)據(jù)安全帶來新思路，區(qū)塊鏈?zhǔn)且环N分布式的存儲方案，具有安全不可變的數(shù)據(jù)存儲模型，可以使數(shù)據(jù)具有不可篡改性從而保護(hù)數(shù)據(jù)安全，因此區(qū)塊鏈與村鎮(zhèn)污水處理監(jiān)測系統(tǒng)的結(jié)合具有重要的現(xiàn)實(shí)意義。

事實(shí)上，區(qū)塊鏈技術(shù)與IoT 監(jiān)測場景的結(jié)合已經(jīng)被研究[8-10]。如曾雋芳[11]等針對能耗監(jiān)測中數(shù)據(jù)安全問題，構(gòu)建的基于區(qū)塊鏈能耗監(jiān)測平臺；胡忠啟[12]等針對大壩監(jiān)控?cái)?shù)據(jù)存在的安全性與可靠性隱患問題,提出的基于區(qū)塊鏈的大壩監(jiān)控系統(tǒng)架構(gòu)。但村鎮(zhèn)污水處理監(jiān)測場景客觀存在著高并發(fā)的監(jiān)測數(shù)據(jù)存儲和監(jiān)測數(shù)據(jù)查詢，區(qū)塊鏈的存儲效率和查詢效率都較低，直接應(yīng)用會出現(xiàn)存儲受限、高查詢時(shí)延的問題。

近年來，國家政策的鼓勵(lì)，促使村鎮(zhèn)污水處理站數(shù)量大幅增長，如張效葦?shù)缺O(jiān)測的村鎮(zhèn)具有高達(dá)760 個(gè)污水處理站點(diǎn)。這使村鎮(zhèn)污水處理監(jiān)測系統(tǒng)面臨著巨大的并發(fā)存儲壓力。根據(jù)廣東省某縣現(xiàn)場調(diào)研結(jié)果，目前常規(guī)村鎮(zhèn)污水處理場景每秒鐘需存儲約160 條監(jiān)測數(shù)據(jù)。目前區(qū)塊鏈體系中存儲效率處于前列的，基于Raft 共識的fabric，經(jīng)測試每秒可存儲約100 條監(jiān)測數(shù)據(jù)，存儲效率無法支撐實(shí)際應(yīng)用需求，應(yīng)用時(shí)易出現(xiàn)監(jiān)測數(shù)據(jù)存儲受限。

針對此問題，本文引入了可實(shí)現(xiàn)高吞吐的哈希圖[13](Hashgraph)高效異步共識，在使用fabric 架構(gòu)的基礎(chǔ)上，使用Hashgraph 取代fabric 原生的Raft 共識。Hashgraph 是由Hedera 公司首席技術(shù)官Leemon 設(shè)計(jì)提出的高速異步共識算法，它基于gossip 與虛擬投票完成排序共識過程，相對于Raft 共識, Hashgraph 強(qiáng)調(diào)最終一致性而非強(qiáng)一致性，大量減少了節(jié)點(diǎn)一致性通信和投票簽名的消耗，以大幅提高存儲效率，可以有效解決村鎮(zhèn)污水處理監(jiān)測場景下應(yīng)用區(qū)塊鏈出現(xiàn)的存儲受限問題。

此外村鎮(zhèn)污水處理監(jiān)測場景還存在著高并發(fā)的監(jiān)測數(shù)據(jù)查詢。經(jīng)估算單用戶請求單站點(diǎn)監(jiān)測數(shù)據(jù)時(shí)，平均每秒約產(chǎn)生20 次以上的監(jiān)測數(shù)據(jù)查詢。查詢效率同樣位于前列的fabric 在常規(guī)配置下每秒僅可完成約10 次，應(yīng)用時(shí)易產(chǎn)生較高的查詢時(shí)延。

針對此問題，本文基于余濤[14]等面向交易系統(tǒng)的高效鏈下查詢方案，改進(jìn)提出了一種面向IoT 監(jiān)測的監(jiān)測數(shù)據(jù)鏈下查詢方案，可以有效降低監(jiān)測數(shù)據(jù)查詢時(shí)延。本文提出的監(jiān)測數(shù)據(jù)鏈下查詢方案對比余濤等人的方案，主要貢獻(xiàn)如下：

（1）針對監(jiān)測數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)特征，鏈下數(shù)據(jù)庫改用OpenTSDB 時(shí)序數(shù)據(jù)庫，OpenTSDB 時(shí)序數(shù)據(jù)庫是一種主要用于處理帶時(shí)間標(biāo)簽的數(shù)據(jù)的非關(guān)系型數(shù)據(jù)庫，相對于原方案使用的關(guān)系型數(shù)據(jù)庫它的存儲空間減半，具有優(yōu)越的時(shí)間序列函數(shù)，查詢效率具有明顯優(yōu)勢，因?yàn)镺penTSDB 時(shí)序數(shù)據(jù)庫僅能存儲double 類型數(shù)據(jù)而不能存儲字符串，所以本文方案設(shè)計(jì)了全新的加密算法。

（2）針對監(jiān)測數(shù)據(jù)具有低關(guān)聯(lián)性，方案摒棄了原方案使用的中心鏈下數(shù)據(jù)庫，同步策略改用邊緣存儲，使每一個(gè)污水處理站節(jié)點(diǎn)擁有獨(dú)立的鏈下數(shù)據(jù)庫，僅存儲本站的監(jiān)測數(shù)據(jù)。

（3）針對IoT 監(jiān)測系統(tǒng)實(shí)時(shí)性要求，提供了原方案未提供的鏈下數(shù)據(jù)篡改應(yīng)對機(jī)制，通過將鏈下數(shù)據(jù)庫區(qū)塊化，使監(jiān)測數(shù)據(jù)篡改后可以得到修復(fù)，并確保查詢服務(wù)的持續(xù)。

2 監(jiān)測數(shù)據(jù)存取方案

圖1為本文設(shè)計(jì)系統(tǒng)的監(jiān)測數(shù)據(jù)存取方案模型，圖中左上為通過網(wǎng)絡(luò)連接的部署于各污水處理站的服務(wù)器組成的集群，服務(wù)器負(fù)責(zé)本站監(jiān)測數(shù)據(jù)的處理和響應(yīng)本站監(jiān)測數(shù)據(jù)查詢。右上為任意物理位置的瀏覽器，負(fù)責(zé)為用戶提供可視化查詢?nèi)肟?。圖1示例了虛線框所示的某個(gè)污水處理站的服務(wù)器對該站監(jiān)測數(shù)據(jù)的處理過程。圖中連線序號標(biāo)識了步驟順序。

圖1：監(jiān)測數(shù)據(jù)存取方案模型

步驟（1）：監(jiān)測數(shù)據(jù)采集器將監(jiān)測數(shù)據(jù)上傳至服務(wù)器。監(jiān)測數(shù)據(jù)是一個(gè)結(jié)構(gòu)體，主要包含時(shí)間戳、監(jiān)測項(xiàng)、監(jiān)測數(shù)值三類信息，例如{ 1612109100，一號機(jī)器電壓，5}，表示2021年02月01日00 時(shí)05 分，一號機(jī)器電壓為5V。

步驟（2）：服務(wù)器將監(jiān)測數(shù)據(jù)存儲到本站fabric 賬本中。

步驟（3）：fabric 賬本進(jìn)行存儲時(shí)，會基于Hashgraph 共識機(jī)制將存儲內(nèi)容廣播至其他站點(diǎn)的fabric 賬本中，使所有站點(diǎn)完成相同的存儲。Hashgraph 共識過程如圖2所示。

圖2：Hashgraph 共識過程

服務(wù)器向fabric 賬本發(fā)起監(jiān)測數(shù)據(jù)存儲后，會被封裝為一條交易轉(zhuǎn)發(fā)往fabric 排序節(jié)點(diǎn)，由fabric 排序節(jié)點(diǎn)轉(zhuǎn)發(fā)至Hashgraph 網(wǎng)絡(luò)進(jìn)行排序共識，被Hashgraph 排好順序的交易由鏡像節(jié)點(diǎn)收集并返回給fabric 排序節(jié)點(diǎn)，fabric 排序節(jié)點(diǎn)將一段時(shí)間內(nèi)的有序交易封裝為區(qū)塊后，通過主節(jié)點(diǎn)將區(qū)塊廣播給所有站點(diǎn)的fabric 賬本。

采用共識機(jī)制后，任意站點(diǎn)的fabric 賬本都存儲了完整的、全部站點(diǎn)的監(jiān)測數(shù)據(jù)。圖2最下方的虛線框示例了賬本區(qū)塊內(nèi)的交易鏈片段，其中CouchDB 為fabric 內(nèi)置的用于的索引鍵值對數(shù)據(jù)庫，存儲鍵key 由站點(diǎn)唯一序列號、小時(shí)時(shí)間戳、監(jiān)測項(xiàng)組成，示例的兩個(gè)key 含義為N62586 號和C74247 號處理站在2021年02月02日00 時(shí)至01 時(shí)對一號機(jī)器電壓的監(jiān)測數(shù)值。存儲值value 指向若干交易，指向方式有歷史與最新兩種，示例的第一條交易為第一個(gè)key 的歷史交易，其內(nèi)容由時(shí)間戳和監(jiān)測數(shù)值組成，含義為2021年02月02日00 時(shí)05 分的監(jiān)測數(shù)值為3。若站點(diǎn)每5min 上傳一次監(jiān)測數(shù)據(jù)，則一個(gè)value 至多指向11 條歷史交易，1 條最新交易。fabric 賬本中每一條交易都包含根據(jù)自身生成的Hash，以此有效察覺fabric 賬本中數(shù)據(jù)篡改，并以其他站點(diǎn)fabric 賬本作為數(shù)據(jù)源得到修復(fù)，確保數(shù)據(jù)的安全。

步驟（4）：服務(wù)器將監(jiān)測數(shù)據(jù)存儲入fabric 賬本后，將監(jiān)測數(shù)據(jù)同步存儲至鏈下OpenTSDB 時(shí)序數(shù)據(jù)庫中。因?yàn)殒溝翺penTSDB時(shí)序數(shù)據(jù)庫中數(shù)據(jù)并不安全，所以存儲時(shí)仿照fabric 賬本，對鏈下OpenTSDB 時(shí)序數(shù)據(jù)庫進(jìn)行區(qū)塊化加密存儲。由于OpenTSDB 規(guī)定了行鍵必須由小時(shí)時(shí)間戳、監(jiān)測項(xiàng)、標(biāo)簽值組成，規(guī)定了列族必須由1 至3600 共3600 個(gè)數(shù)字構(gòu)成，代表小時(shí)內(nèi)3600 秒且僅允許存儲double 數(shù)值，因此方案設(shè)計(jì)將兩行記錄視為一個(gè)邏輯區(qū)塊，把兩行記錄中相同列族的兩個(gè)值視為一條邏輯交易。區(qū)塊化加密存儲過程如圖3所示：

（1）將圖3所示監(jiān)測數(shù)據(jù)結(jié)構(gòu)體解析，獲取其中的監(jiān)測數(shù)值8。

圖3：OpenTSDB 區(qū)塊化加密存儲

（2）根據(jù)監(jiān)測數(shù)據(jù)結(jié)構(gòu)體的時(shí)間戳和監(jiān)測項(xiàng)尋找目標(biāo)行列位置進(jìn)行存儲，圖3中監(jiān)測數(shù)據(jù)結(jié)構(gòu)體時(shí)間戳為1612109100，因此存儲行鍵的小時(shí)時(shí)間戳應(yīng)為1612108800，存儲列族應(yīng)為300，存儲行鍵的監(jiān)測項(xiàng)為一號機(jī)器電壓，方案規(guī)定監(jiān)測數(shù)值存儲標(biāo)簽值為tagkey=1。

（3）根據(jù)監(jiān)測數(shù)據(jù)結(jié)構(gòu)體生成一個(gè)加密數(shù)值5，生成加密數(shù)值偽代碼如圖4所示。

圖4：生成加密數(shù)值偽代碼

（4）重復(fù)（2）過程但存儲標(biāo)簽值選擇為tagkey=2。

對生成加密數(shù)值偽代碼解釋如下：

（1）中 pre_encryptValue 為加密數(shù)值目標(biāo)存儲行列的上一個(gè)非空列族值；如圖3中標(biāo)識的上一條加密數(shù)值4，此處假設(shè)了存儲頻率為5min 一次，因此列族300 的上一個(gè)非空列族為列族1。

（2）判斷是否找不到這樣一個(gè)列族值，即目標(biāo)存儲行列會成為該行記錄中的第一個(gè)非空列族值，則令pre_encryptValue 為startEncrypt，startEncrypt 是一個(gè)固定數(shù)值。

（3）將value 與pre_encryptValue 兩個(gè)double 數(shù)值轉(zhuǎn)化為8位byte 數(shù)組。對兩個(gè)轉(zhuǎn)化后的8 位byte 數(shù)組進(jìn)行異或操作后，可得到一個(gè)新的8 位byte 數(shù)組，并再次轉(zhuǎn)化為一個(gè)double 類型數(shù)據(jù)midEncryptValue。

（4）使用加鹽MD5 將midEncryptValue 加密為32 位字符串并拆解為32 位byte 數(shù)組midEncryptBytes，其中key 是加密秘鑰，salt 為加密鹽。

（5）將midEncryptBytes 分割為四個(gè)8 位byte 數(shù)組并由第一個(gè)8 位byte 數(shù)組逐一對其他三個(gè)8 位byte 數(shù)組進(jìn)行異或操作獲得一個(gè)新的8 位byte 數(shù)組encryptBytes。

（6）將encryptBytes 轉(zhuǎn)化為一個(gè)double 數(shù)字作為輸出的加密數(shù)值encryptValue，即圖3中的加密數(shù)值5。

在生成加密數(shù)值的過程中，引用了目標(biāo)存儲行的上一條加密數(shù)值，因此該行記錄形成一條短鏈，若視該行記錄中每一個(gè)列族值為一個(gè)交易頭，則可視存儲對應(yīng)監(jiān)測數(shù)值的一行記錄中每一個(gè)列族值為一個(gè)交易體，交易頭與交易體所在的兩行記錄的行鍵僅tagkey 不同。因此圖3中圓圈所示的兩個(gè)列族值可視為一條邏輯交易，圖3中虛線框所示兩行記錄可以視為一個(gè)邏輯區(qū)塊。

至此區(qū)塊化加密存儲過程完畢，不同于fabric 賬本，鏈下OpenTSDB 時(shí)序數(shù)據(jù)庫不會廣播存儲內(nèi)容至其他站點(diǎn)，因此僅存儲本站監(jiān)測數(shù)據(jù)，這符合邊緣存儲策略。由于高增量的數(shù)據(jù)將顯著降低列數(shù)據(jù)庫的條件查詢效率，方案令鏈下OpenTSDB 時(shí)序數(shù)據(jù)庫的數(shù)據(jù)增量與站點(diǎn)數(shù)量無關(guān)，從而使查詢性能穩(wěn)定。

步驟（5）：進(jìn)入數(shù)據(jù)查詢階段，當(dāng)用戶需要監(jiān)測站點(diǎn)時(shí)，可通過瀏覽器向服務(wù)器發(fā)起請求。請求主要包含時(shí)間戳、監(jiān)測項(xiàng)兩類信息，例如{ 1612108800，二號機(jī)器水位}，即請求本站2021年02月01日00 時(shí)00 分的二號機(jī)器水位的監(jiān)測數(shù)值，根據(jù)邊緣存儲策略，當(dāng)用戶請求其他站點(diǎn)數(shù)據(jù)時(shí)，請求將被發(fā)送至其他站點(diǎn)服務(wù)器，形成負(fù)載均衡。

步驟（6）：服務(wù)器接到瀏覽器請求后，向鏈下OpenTSDB 時(shí)序數(shù)據(jù)庫查詢符合請求的監(jiān)測數(shù)值和加密數(shù)值，并生成加密數(shù)值進(jìn)行校驗(yàn)。若輸入請求的監(jiān)測項(xiàng)、請求的時(shí)間戳、查詢獲得的監(jiān)測數(shù)值，輸出查詢獲得的加密數(shù)值，則通過校驗(yàn)，判斷被請求監(jiān)測數(shù)值及其相關(guān)數(shù)值（對應(yīng)加密數(shù)值、上一條加密數(shù)值）未被篡改，這是因?yàn)閷Ρ徽埱蟊O(jiān)測數(shù)值及其相關(guān)數(shù)值的篡改一定會使校驗(yàn)結(jié)果有誤。當(dāng)校驗(yàn)未通過時(shí)，判斷被請求監(jiān)測數(shù)值及其相關(guān)數(shù)值被篡改，啟動(dòng)篡改應(yīng)對機(jī)制，模型如圖5所示。

圖5：篡改應(yīng)對機(jī)制模型

首先鏈下OpenTSDB 時(shí)序數(shù)據(jù)庫會立刻通知服務(wù)器被篡改監(jiān)測數(shù)值所在邏輯區(qū)塊，不單獨(dú)修復(fù)被篡改的監(jiān)測數(shù)值及其相關(guān)數(shù)值是因?yàn)檫壿媴^(qū)塊內(nèi)交易頭是迭代生成的，必須對整個(gè)邏輯區(qū)塊進(jìn)行修復(fù)。服務(wù)器得到通知后會將邏輯區(qū)塊以隊(duì)列元素形式存儲入修復(fù)隊(duì)列中，隊(duì)列元素應(yīng)由小時(shí)時(shí)間戳、監(jiān)測項(xiàng)組成，例如{1612285200，三號機(jī)器電流}，可唯一指定鏈下OpenTSDB 時(shí)序數(shù)據(jù)庫中的兩行記錄形成的邏輯區(qū)塊。接下來服務(wù)器會向fabric 賬本查詢待修復(fù)的邏輯區(qū)塊所需監(jiān)測數(shù)值，并重新生成兩行記錄，覆蓋至鏈下OpenTSDB 時(shí)序數(shù)據(jù)庫完成邏輯區(qū)塊的修復(fù)。修復(fù)完成后，服務(wù)器將已修復(fù)邏輯區(qū)塊移除修復(fù)隊(duì)列。圖5中最后的步驟（6.6）并非最后執(zhí)行，而是與步驟（6.1）異步執(zhí)行。由于IoT 監(jiān)測場景的特殊性，不允許數(shù)據(jù)查詢服務(wù)因等待修復(fù)而停止，因此需要進(jìn)行數(shù)據(jù)源的切換：數(shù)據(jù)篡改被發(fā)現(xiàn)的當(dāng)次查詢會返回fabric 賬本的監(jiān)測數(shù)值查詢結(jié)果，且當(dāng)用戶再次通過瀏覽器向服務(wù)器查詢監(jiān)測數(shù)值時(shí)，會首先判斷待查詢監(jiān)測數(shù)值所在邏輯區(qū)塊是否存在于修復(fù)隊(duì)列中，若不存在，則向鏈下OpenTSDB 時(shí)序數(shù)據(jù)庫查詢，否則向fabric 賬本查詢。完整的監(jiān)測數(shù)值查詢偽代碼如圖6所示。

圖6：監(jiān)測數(shù)值查詢偽代碼

對監(jiān)測數(shù)值查詢偽代碼解釋如下：（1）判斷待查詢監(jiān)測數(shù)值是否存在于修復(fù)隊(duì)列repairQueue 中，若存在則執(zhí)行（2），從本站fabric 賬本中獲取待查詢監(jiān)測數(shù)值并定義為結(jié)果aimValue。其中serial 指污水處理站的唯一序列號;若不存則執(zhí)行（3）、（4）、（5），從本站鏈下OpenTSDB 時(shí)序數(shù)據(jù)庫獲取待查詢監(jiān)測數(shù)值value 與對應(yīng)加密數(shù)值encryptValue，生成加密數(shù)值進(jìn)行校驗(yàn)。若通過校驗(yàn)則執(zhí)行（6），定義value 為結(jié)果aimValue；若未通過則執(zhí)行（7），將待查詢監(jiān)測數(shù)值所在邏輯區(qū)塊添加至修復(fù)隊(duì)列，執(zhí)行（8）從fabric 賬本中獲取待查詢監(jiān)測數(shù)值定義為結(jié)果aimValue。與此同時(shí)啟動(dòng)異步修復(fù)線程，線程內(nèi)容包括（9）至（12），（9）到（11）完成邏輯區(qū)塊的修復(fù)。（12）完成將已修復(fù)的邏輯區(qū)塊從修復(fù)隊(duì)列移除。

步驟（7）：服務(wù)器返回給瀏覽器可視化結(jié)果，完成整個(gè)數(shù)據(jù)存取流程。

3 系統(tǒng)架構(gòu)

系統(tǒng)架構(gòu)如圖7所示，由用戶層、節(jié)點(diǎn)層、應(yīng)用層、合約/接口層、數(shù)據(jù)層、數(shù)據(jù)來源層組成。

圖7：系統(tǒng)架構(gòu)圖

其中用戶層為系統(tǒng)的使用人群，節(jié)點(diǎn)層為各污水處理站服務(wù)器集群；應(yīng)用層為服務(wù)器的Web 服務(wù)和數(shù)據(jù)處理服務(wù)部署的應(yīng)用；合約/接口層為服務(wù)器的fabric-sdk 服務(wù)部署的合約和OpenTSDBsdk 服務(wù)部署的合約與接口；數(shù)據(jù)層為系統(tǒng)數(shù)據(jù)的存儲工具；數(shù)據(jù)來源層為數(shù)據(jù)的具體來源。

4 系統(tǒng)協(xié)作

系統(tǒng)協(xié)作如圖8所示，過程共10 步：

圖8：系統(tǒng)協(xié)作圖

（1）數(shù)據(jù)采集器采集設(shè)備監(jiān)測數(shù)據(jù)。

（2）數(shù)據(jù)采集器推送監(jiān)測數(shù)據(jù)到數(shù)據(jù)處理服務(wù)中。

（3）數(shù)據(jù)處理服務(wù)通過新增鏈上監(jiān)測數(shù)據(jù)應(yīng)用，調(diào)用fabricsdk 服務(wù)的監(jiān)測數(shù)據(jù)增改合約，完成鏈上存儲監(jiān)測數(shù)據(jù)。

（4）數(shù)據(jù)處理服務(wù)通過新增鏈下監(jiān)測數(shù)據(jù)應(yīng)用，調(diào)用OpenTSDB-sdk 服務(wù)的監(jiān)測數(shù)值增改接口、加密數(shù)值增改接口，完成鏈下加密存儲監(jiān)測數(shù)據(jù)。

（5）用戶通過瀏覽器請求監(jiān)測某站點(diǎn)。

（6）瀏覽器向指定站點(diǎn)Web 服務(wù)發(fā)起請求。

（7）Web 服務(wù)通過查詢鏈下監(jiān)測數(shù)據(jù)應(yīng)用，調(diào)用OpenTSDB數(shù)據(jù)庫服務(wù)的監(jiān)測數(shù)據(jù)查詢接口、加密數(shù)值查詢接口獲得并校驗(yàn)監(jiān)測數(shù)值。

（8）若未通過校驗(yàn)，Web 服務(wù)調(diào)用fabric-sdk 服務(wù)的監(jiān)測數(shù)據(jù)查詢合約獲得監(jiān)測數(shù)值。

（9）Web 服務(wù)通過修復(fù)鏈下監(jiān)測數(shù)據(jù)應(yīng)用，調(diào)用fabric-sdk 服務(wù)的監(jiān)測數(shù)據(jù)查詢合約和OpenTSDB 時(shí)序數(shù)據(jù)庫的監(jiān)測數(shù)值增改合約、加密數(shù)值增改合約， 完成數(shù)據(jù)修復(fù)。

（10）Web 服務(wù)響應(yīng)瀏覽器。

5 性能實(shí)驗(yàn)

為驗(yàn)證系統(tǒng)性能符合村鎮(zhèn)污水處理監(jiān)測場景需求，進(jìn)行仿真環(huán)境實(shí)驗(yàn)，實(shí)驗(yàn)方案如下：部署四臺服務(wù)器，服務(wù)器硬件參數(shù)如表1所示。

表1：服務(wù)器硬件參數(shù)

在四臺服務(wù)器上均部署fabric 節(jié)點(diǎn)，每一個(gè)節(jié)點(diǎn)形成一個(gè)聯(lián)盟，背書策略為每一個(gè)聯(lián)盟至少有一個(gè)節(jié)點(diǎn)參與，共識配置為Hashgraph，目前Hashgraph 網(wǎng)絡(luò)僅可通過公網(wǎng)由Hedera 公司提供，分付費(fèi)版和免費(fèi)版，本文選擇的是免費(fèi)版，此外在每臺服務(wù)器部署鏈下OpenTSDB 時(shí)序數(shù)據(jù)庫。部署測試應(yīng)用后，模擬持續(xù)一天存儲100 個(gè)污水處理站點(diǎn)的8 種監(jiān)測數(shù)據(jù)，存儲頻率至5s 一次，使實(shí)際每秒監(jiān)測數(shù)據(jù)存儲量達(dá)到160。

圖9為測試應(yīng)用截圖，左上所示為全部站點(diǎn)均處于在線狀態(tài)，證明在該監(jiān)測數(shù)據(jù)并發(fā)量下，方案使用的基于Hashgraph 共識的fabric 集群可以穩(wěn)定的完成監(jiān)測數(shù)據(jù)的存儲。中央彈窗所示即為一個(gè)被觀察的站點(diǎn)，展示了其模擬存入的8 種監(jiān)測數(shù)據(jù)，測試應(yīng)用對受觀察站點(diǎn)的監(jiān)測數(shù)據(jù)的實(shí)時(shí)查詢正常。實(shí)驗(yàn)證明，本文設(shè)計(jì)系統(tǒng)可以良好的完成村鎮(zhèn)污水處理監(jiān)測場景的存儲與查詢需求。

圖9：測試應(yīng)用截圖

為驗(yàn)證本文使用的Hashgraph 共識在吞吐量上的優(yōu)越性，進(jìn)行實(shí)驗(yàn)對比fabric 的原生Raft 共識和本文使用的Hashgraph 的污水處理監(jiān)測數(shù)據(jù)吞吐量。實(shí)驗(yàn)配置塊內(nèi)最大交易數(shù)為100，使用Caliper工具發(fā)起總共10000 條污水處理監(jiān)測數(shù)據(jù)，截取兩種共識在實(shí)驗(yàn)條件下的連續(xù)10 次穩(wěn)定出塊，給定編號1-10，獲取出塊時(shí)間、塊內(nèi)交易數(shù)，并計(jì)算其吞吐量（TPS），實(shí)驗(yàn)結(jié)果如圖10 所示。

圖10：監(jiān)測數(shù)據(jù)吞吐量對比

如圖10 所示，Hashgraph 具有更高的吞吐量，峰值可達(dá)550TPS，平均達(dá)到350 TPS 以上；而Raft 峰值可達(dá)200 TPS，平均達(dá)到130 TPS 以上，平均提高1.6 倍。實(shí)驗(yàn)結(jié)果證明，本文采用的Hashgraph 具有更高的監(jiān)測數(shù)據(jù)吞吐量，更適合村鎮(zhèn)污水處理監(jiān)測場景。

為驗(yàn)證本文設(shè)計(jì)系統(tǒng)對查詢時(shí)延的降低，使用控制臺在監(jiān)測數(shù)據(jù)總存入量的多階段分別進(jìn)行單條監(jiān)測數(shù)值查詢測試，為體現(xiàn)本文方案查詢時(shí)延降低的有效性，進(jìn)行對比試驗(yàn)，分別模擬鏈上查詢、FabricSQL 查詢、本文方案查詢，對以上三種查詢方案的查詢時(shí)延進(jìn)行對比，結(jié)果如圖11 所示，實(shí)驗(yàn)數(shù)據(jù)顯示，鏈上查詢具有最高時(shí)延，F(xiàn)abricSQL 次之，本文方案具有最低查詢時(shí)延。因此本文方案的查詢效率具有明顯優(yōu)勢，且隨著監(jiān)測數(shù)據(jù)總存入量的增加，查詢效率優(yōu)勢不斷增加。

圖11：三種方案查詢時(shí)延對比

在實(shí)際村鎮(zhèn)污水處理監(jiān)測生產(chǎn)環(huán)境中，監(jiān)測數(shù)據(jù)存入總量遠(yuǎn)大于實(shí)驗(yàn)環(huán)境，F(xiàn)abricSQL 的查詢時(shí)延將隨監(jiān)測數(shù)據(jù)存入總量的增加而明顯提高，將不再符合場景需求。在村鎮(zhèn)污水處理站數(shù)量爆發(fā)式增長的今后，本文設(shè)計(jì)系統(tǒng)將更具現(xiàn)實(shí)意義與實(shí)用價(jià)值。

6 結(jié)束語

本文針對傳統(tǒng)村鎮(zhèn)污水處理監(jiān)測系統(tǒng)存在的數(shù)據(jù)安全性低的問題，引入了區(qū)塊鏈技術(shù)。同時(shí)針對區(qū)塊鏈存儲與查詢性能較低，不滿足村鎮(zhèn)污水處理監(jiān)測場景客觀存在的高并發(fā)數(shù)據(jù)存儲與數(shù)據(jù)查詢帶來的性能需求的問題，引入了Hashgraph 共識，設(shè)計(jì)了基于時(shí)序數(shù)據(jù)庫的鏈下查詢方案。實(shí)驗(yàn)證明，本文設(shè)計(jì)系統(tǒng)有效解決了上述問題，具有重要的現(xiàn)實(shí)意義。接下來將進(jìn)一步研究監(jiān)測數(shù)據(jù)流向與監(jiān)測數(shù)據(jù)分析流程相關(guān)問題，期待有進(jìn)一步的突破。