基于推送的煤礦WEB實時監(jiān)測技術(shù)

摘 要：推送技術(shù)以其實時性高和資源占用小等諸多優(yōu)點，逐漸得到應(yīng)用。首先介紹了煤礦Web實時監(jiān)測系統(tǒng)發(fā)展現(xiàn)狀，并分析了這一實時系統(tǒng)的主要特點；其次，對比了輪詢和推送兩種實時監(jiān)測技術(shù)的工作原理及其優(yōu)缺點；最后，介紹了推送技術(shù)的主要實現(xiàn)方式。

關(guān)鍵詞：推送；實時；監(jiān)測系統(tǒng)；輪詢

中圖分類號：TP391

近年來，煤礦各種安全事故頻發(fā)，為保障煤礦安全生產(chǎn)和職工人身安全，防止煤礦事故，2006年底，國家安監(jiān)總局發(fā)布的《關(guān)于修改〈煤礦安全規(guī)程〉第六十八條和第一百五十八條的決定》中明確指出：所有礦井必須裝備礦井安全監(jiān)控系統(tǒng)[1]。隨后，越來越多的煤礦企業(yè)配備安裝了各種安全監(jiān)控監(jiān)測設(shè)備，這大大提升了煤礦安全生產(chǎn)水平，降低了事故發(fā)生率。伴隨著硬件裝備的不斷升級，與之配套的實時監(jiān)測系統(tǒng)也得到了較快發(fā)展，尤其是基于B/S架構(gòu)的Web實時監(jiān)測系統(tǒng)，以其使用方便、易于維護(hù)、信息資料共享程度高等優(yōu)點，被廣泛應(yīng)用于煤礦實時監(jiān)測系統(tǒng)中。一些新的信息交互技術(shù)被應(yīng)用于系統(tǒng)中，使得系統(tǒng)的實時性、友好性等方面都有了較大提升。目前，廣泛采用輪詢方式實現(xiàn)信息的實時展示，但這種效率低下的方式已經(jīng)逐漸無法滿足不斷提升的煤礦Web系統(tǒng)的實時性要求，并且對網(wǎng)絡(luò)帶寬和服務(wù)端資源都造成了很大的壓力。

針對上述情況，本文介紹了目前新興的實時信息交互技術(shù)-推送技術(shù)，這一技術(shù)不僅為監(jiān)測系統(tǒng)帶來了更高的實時性，也極大的降低了服務(wù)器資源和網(wǎng)絡(luò)帶寬的壓力，提升了煤礦安全生產(chǎn)管理的信息化水平。

1 實時監(jiān)測系統(tǒng)的信息交互模式

煤礦實時監(jiān)測系統(tǒng)，要求將監(jiān)測到的最新數(shù)據(jù)在第一時間顯示到系統(tǒng)中，以便監(jiān)控人員及時根據(jù)信息做出響應(yīng)。根據(jù)煤礦監(jiān)測的特點，其監(jiān)測的數(shù)據(jù)變化時間不定，有些數(shù)據(jù)的實時性很強，比如風(fēng)速或瓦斯?jié)舛鹊?；另有一些?shù)據(jù)，例如風(fēng)門設(shè)備的開停狀態(tài)，變化頻率就很低。對于這種要求實時性高卻數(shù)據(jù)更新周期不定的系統(tǒng)，就需要有一個數(shù)據(jù)交互機制來滿足這類實時監(jiān)測的要求。傳統(tǒng)模式和基于推送技術(shù)的模式都可實現(xiàn)這類需求，但有截然不同的工作原理。

1.1 傳統(tǒng)的實時監(jiān)測模式

理想的實時監(jiān)測系統(tǒng)應(yīng)該是當(dāng)服務(wù)端識別到數(shù)據(jù)發(fā)生變化時，立刻主動將數(shù)據(jù)發(fā)送給客戶端。然而，HTTP作為客戶端-服務(wù)器通信的標(biāo)準(zhǔn)協(xié)議，它是無狀態(tài)的，而且在某種意義上來說，也是一種單向的協(xié)議。HTTP場景中所有通信都必須由客戶端發(fā)起，至服務(wù)器結(jié)束，服務(wù)器端僅是被動等待客戶端發(fā)出請求之后將數(shù)據(jù)傳送給客戶端。這與實時監(jiān)測系統(tǒng)的場景要求恰好相反。為了實現(xiàn)數(shù)據(jù)更新，Web開發(fā)人員采用一種稱為輪詢的方式，客戶端會以固定的時間間隔與服務(wù)器聯(lián)系，查找是否有新數(shù)據(jù)可用，如圖1所示，為輪詢的工作原理。但這實際上是一種偽實時場景，數(shù)據(jù)雖然被以一定頻率顯示到客戶端，但無法與數(shù)據(jù)更新頻率完全一致，這種更新機制不是真正意義上的實時更新。

圖1 輪詢工作原理

從圖1例子可知，這段時間內(nèi)客戶端以固定間隔請求服務(wù)器5次，服務(wù)器響應(yīng)了5次，其中僅有2次響應(yīng)包含了最新數(shù)據(jù)，且最新數(shù)據(jù)只是在數(shù)據(jù)更新之后的最近一次輪詢響應(yīng)后才發(fā)送到客戶端。

輪詢方式已經(jīng)廣泛用于煤礦Web監(jiān)測系統(tǒng)中，其主要優(yōu)點是實現(xiàn)簡單。這種方式只要客戶端加入定時獲取數(shù)據(jù)的少量腳本代碼，即可實現(xiàn)數(shù)據(jù)的持續(xù)更新。一些成熟的技術(shù)如Ajax，是目前最廣泛的實現(xiàn)方式。

然而，輪詢也存在著較大問題，主要有以下兩方面：（1）資源消耗大。在大多數(shù)時候，輪詢純粹是浪費，因而服務(wù)器沒有任何更新。這種方法不是沒有代價的，它有兩大問題。一方面，這種方法極度浪費網(wǎng)絡(luò)資源。每一個輪詢請求都會創(chuàng)建一個TCP套接字連接，套接字連接本身代價極高，需要服務(wù)器更多的CPU和內(nèi)存資源；另一方面，每次請求都要在網(wǎng)絡(luò)上傳輸一些數(shù)據(jù)，如果請求未在服務(wù)器上發(fā)現(xiàn)任何更新，那么這樣的數(shù)據(jù)傳輸就是浪費帶寬資源。（2）實時性差?？紤]到輪詢的頻率，這樣的更新并不是實時的。例如，輪詢方式采用固定的時間間隔請求數(shù)據(jù)，如果在下一個請求周期到來之前，數(shù)據(jù)發(fā)生多次變化，用戶將只能看到最后一次的新數(shù)據(jù)而錯過某些數(shù)據(jù)，無法實時看到所有變化。這就要求請求的時間間隔與數(shù)據(jù)更新時間完全匹配，這對于數(shù)據(jù)更新周期不定的系統(tǒng)來說，是不可能的。對于需要以盡可能實時方式運行的應(yīng)用程序來說，這樣的等待也是不可接受的?？紤]到如上兩大問題，對于需要關(guān)鍵、實時的服務(wù)器端更新的企業(yè)應(yīng)用程序而言，輪詢并非最佳方案。

1.2 基于推送技術(shù)的實時監(jiān)測模式

為解決輪詢方式資源占用大和實時性差等問題，開發(fā)人員采用了一種稱為推送的方式，實現(xiàn)了更為有效的Web實時監(jiān)測系統(tǒng)。推送是一種主動從Web服務(wù)器發(fā)送數(shù)據(jù)到瀏覽器的機制。雖然HTTP協(xié)議并無相關(guān)配置來直接實現(xiàn)此機制，開發(fā)人員使用各種獨創(chuàng)方法來繞過這些問題，從而使得推送得以實現(xiàn)。如圖2所示，為推送的工作原理。

圖2 推送工作原理

從圖2中例子可知，這段時間內(nèi)客戶端僅在首次建立了請求連接，之后沒有請求。服務(wù)端響應(yīng)了2次，這2次都包含了最新數(shù)據(jù)，最新數(shù)據(jù)在到達(dá)服務(wù)器第一時間發(fā)送到客戶端，沒有延遲。

推送技術(shù)主要有如下優(yōu)點：（1）實時性強。推送正是為了滿足Web系統(tǒng)更高實時性的要求應(yīng)運而生的。服務(wù)器端完全能夠控制更新數(shù)據(jù)的時間和頻率，與傳統(tǒng)輪詢請求更新的模式相比，實現(xiàn)了真正意義上的實時更新。（2）資源消耗少。推送技術(shù)由于一直保持連接，不像輪詢每次都要進(jìn)行重新建立連接和發(fā)送完整而冗余的信息，這對于網(wǎng)絡(luò)帶寬的占用和服務(wù)器CPU資源及內(nèi)存消耗都較小。當(dāng)然，由于始終保持連接，即使無數(shù)據(jù)傳輸時也如此，因此服務(wù)器必須為每個推送鏈接分配并讓其一直占用一個TCP套接字連接，這對于TCP/IP端口數(shù)有限的服務(wù)器是一個必須關(guān)注的問題。只要將推送技術(shù)主要用于實時性要求強的核心模塊，這一資源消耗是可以忽略了。

推送技術(shù)目前存在的主要不足是實現(xiàn)方式較為復(fù)雜。由于HTTP協(xié)議在底層不直接提供對推送的支持，因此實現(xiàn)推送的方式并不容易。另外，開發(fā)人員固有的研發(fā)思路和開發(fā)模式，也使得對推送這一新技術(shù)的學(xué)習(xí)曲線較為陡峭。隨著對推送技術(shù)的深入研究和廣泛應(yīng)用，其學(xué)習(xí)難度在逐漸下降，實現(xiàn)方式也在不斷簡化和完善。

2 推送技術(shù)的實現(xiàn)方式

推送技術(shù)在應(yīng)用中已有不少解決方案，主要分為兩類：一類采用瀏覽器插件技術(shù)（ActiveX、Applet、Flash），基于套接口傳送信息，或是使用RMI、CORBA進(jìn)行遠(yuǎn)程調(diào)用[2]；另一類則無需安裝插件，基于HTTP長鏈接或最新的HTTP5標(biāo)準(zhǔn)。以下介紹幾種常見的推送實現(xiàn)技術(shù)。

2.1 Comet

Comet是基于HTTP長連接的推送技術(shù)，有流方式和長輪詢方式。其工作原理是：用戶發(fā)起請求后就掛起，等待服務(wù)器返回數(shù)據(jù)，在此期間不會斷開連接。流和長輪詢方式的區(qū)別是：前者在客戶端發(fā)起連接就不會斷開連接，并由服務(wù)器端進(jìn)行控制。當(dāng)服務(wù)器端有更新時，刷新數(shù)據(jù)，客戶端進(jìn)行更新；而后者是當(dāng)服務(wù)器端有更新返回，客戶端先斷開連接，進(jìn)行處理，然后重新發(fā)起連接。

Comet雖然可達(dá)到雙向通信，但依然需要發(fā)出請求，而且會大量消耗服務(wù)器帶寬和資源。

2.2 WebSocket

WebSocket是HTML5標(biāo)準(zhǔn)中的一種新協(xié)議，它支持瀏覽器與服務(wù)器的雙向通信[3]，只需要一個握手動作，瀏覽器和服務(wù)器之間就形成了一條快速通道以便互相傳送數(shù)據(jù)。這一技術(shù)的出現(xiàn)第一次從底層支持推送，而無需開發(fā)人員采用變通方法實現(xiàn)推送，大大提高了推送效率，降低了資源消耗。然而，目前這一技術(shù)存在的不足在于其需要瀏覽器內(nèi)核的支持，目前現(xiàn)代瀏覽器如Firefox 4、Chrome 4、IE10及以上版本等，都已經(jīng)支持WebSocket標(biāo)準(zhǔn)。但對于IE9及以下版本，無法直接支持WebSocket。

2.3 SignalR

以上介紹了幾種常見的推送實現(xiàn)方式，由于不同方式需要的支撐環(huán)境不同，需要瀏覽器、插件、運行平臺等方面的支持，這給開發(fā)人員提出了較高要求。目前，已經(jīng)出現(xiàn)幾種較好的解決方案，屏蔽了以上這些技術(shù)細(xì)節(jié)，讓開發(fā)人員專注于業(yè)務(wù)領(lǐng)域的開發(fā)，大大簡化了推送功能的實現(xiàn)，SignalR就是其中較有代表性的方案之一。

SignalR是一個微軟.NET框架庫和jQuery插件，是集成的客戶端與服務(wù)器庫，基于瀏覽器的客戶端和基于ASP.NET的服務(wù)器組件可以借助它進(jìn)行雙向多步對話。該對話不受限制地進(jìn)行單個無狀態(tài)請求/響應(yīng)數(shù)據(jù)交換；它將繼續(xù)直到明確關(guān)閉。對話通過永久連接進(jìn)行，允許客戶端向服務(wù)器發(fā)送多個消息，并允許服務(wù)器做出相應(yīng)答復(fù)，值得注意的是，還允許服務(wù)器向客戶端發(fā)送異步消息。它是基于現(xiàn)有技術(shù)的復(fù)合體。SignalR屏蔽了底層具體的推送實現(xiàn)細(xì)節(jié)，一般情況下，它會使用Comet進(jìn)行推送，如果瀏覽器支持WebSocket，它就采用WebSocket方式。

3 結(jié)論

本文通過對推送技術(shù)的工作原理和實現(xiàn)方式進(jìn)行介紹，了解了推送技術(shù)的主要工作機制及適用領(lǐng)域，其高實時性和資源占用小等優(yōu)點，非常適合煤礦Web實時監(jiān)測系統(tǒng)。雖然目前在這一領(lǐng)域尚未廣泛應(yīng)用推送技術(shù)，但可以預(yù)知，這將是實現(xiàn)下一代煤礦實時監(jiān)測系統(tǒng)的重要技術(shù)之一。

參考文獻(xiàn)：

[1]國家安全生產(chǎn)監(jiān)督管理總局.關(guān)于修改〈煤礦安全規(guī)程〉第六十八條和第一百五十八條的決定[Z].2006，10（25）.

[2]孫清國.Web應(yīng)用中的服務(wù)器推送技術(shù)研究綜述[J].計算機系統(tǒng)應(yīng)用，2008，11.

[3]尹西杰.基于智能Agent的Web信息自動推送系統(tǒng)[J].網(wǎng)絡(luò)通訊與安全，2012，8（16）.

作者簡介：柳波（1982.9-），男，北京人，碩士，助理工程師，現(xiàn)主要從事煤炭行業(yè)安全信息化軟件的研發(fā)工作。

作者單位：煤炭科學(xué)研究總院北京分院，北京 100083

基金項目：“十二五”國家科技支撐計劃課題：礦井動目標(biāo)監(jiān)測技術(shù)及在用設(shè)備智能管控技術(shù)平臺與裝備（基于物聯(lián)網(wǎng)安全管控技術(shù)）。課題編號：2013BAK06B05。