陶小菘 　 王俊修 　 楊珍

1. 公安部第一研究所　 2. 警務(wù)物聯(lián)網(wǎng)應(yīng)用技術(shù)公安部重點(diǎn)實(shí)驗(yàn)室

引言

隨著信息化和大數(shù)據(jù)技術(shù)的快速發(fā)展，數(shù)據(jù)的重要性不言而喻，我們通過(guò)對(duì)數(shù)據(jù)進(jìn)行匯總和分析使得數(shù)據(jù)的價(jià)值得以體現(xiàn)。然而多數(shù)情況下，存在著數(shù)據(jù)多源性、類型多樣性等特點(diǎn)，為使數(shù)據(jù)分析結(jié)果準(zhǔn)確，就需要數(shù)據(jù)采集交換的完備性和及時(shí)性作為保證。因此，數(shù)據(jù)采集交換的穩(wěn)定性和可靠性顯得尤為重要。本文利用大數(shù)據(jù)技術(shù)解決警用裝備管理中業(yè)務(wù)數(shù)據(jù)采集和交換過(guò)程中的可靠性問(wèn)題，保障警用裝備管理工作的順利開(kāi)展和平穩(wěn)運(yùn)行。

一、警用裝備管理單點(diǎn)數(shù)據(jù)交換模式及問(wèn)題

（一）當(dāng)前警用裝備管理數(shù)據(jù)交換的模式

近年來(lái)由于警用裝備管理規(guī)模不斷擴(kuò)大，業(yè)務(wù)模式和需求不斷升級(jí)，管理手段存在多樣性等特點(diǎn)，因此公安部第一研究所結(jié)合一線實(shí)際管理需求開(kāi)發(fā)了兼容各類管理模式的警用裝備物聯(lián)網(wǎng)系統(tǒng)以滿足不同業(yè)務(wù)的需要，但系統(tǒng)存在著分布式部署以及不同業(yè)務(wù)場(chǎng)景下數(shù)據(jù)類型多樣等特點(diǎn)，給警用裝備信息數(shù)據(jù)的集中化管理帶來(lái)了一定難度。

因此，我們基于現(xiàn)有系統(tǒng)架構(gòu)模式開(kāi)發(fā)了業(yè)務(wù)數(shù)據(jù)集中采集和交換服務(wù)系統(tǒng)，以單點(diǎn)部署的方式實(shí)現(xiàn)了所有管理信息的匯總和業(yè)務(wù)系統(tǒng)間數(shù)據(jù)的同步，服務(wù)框架如圖1所示。

但是，由于采集數(shù)據(jù)的來(lái)源多樣性，部分類型數(shù)據(jù)更新頻率較快且需要同步的數(shù)據(jù)量龐大。因此，這對(duì)數(shù)據(jù)同步服務(wù)性能和穩(wěn)定性提出了更高的要求，一旦出現(xiàn)服務(wù)器單點(diǎn)故障且故障解決不夠及時(shí)，就會(huì)因數(shù)據(jù)同步延時(shí)影響業(yè)務(wù)系統(tǒng)對(duì)數(shù)據(jù)處理和分析結(jié)果的準(zhǔn)確性和實(shí)時(shí)性。

（二）解決方案

針對(duì)上述問(wèn)題，在架構(gòu)設(shè)計(jì)上采用了分布式設(shè)計(jì)思想，總體架構(gòu)如圖2所示。

利用5臺(tái)數(shù)據(jù)交換服務(wù)器作為集群替代之前單點(diǎn)式的設(shè)計(jì)架構(gòu)，通過(guò)用戶配置使每臺(tái)服務(wù)器上的服務(wù)分別采集不同系統(tǒng)上的交換任務(wù)數(shù)據(jù)，形成5臺(tái)服務(wù)器同時(shí)采集數(shù)據(jù)的并發(fā)模式，大大提高了數(shù)據(jù)的交換效率，同時(shí)減輕了單臺(tái)交換服務(wù)器的負(fù)載壓力。若分布式集群中出現(xiàn)單臺(tái)故障，就臨時(shí)由其它服務(wù)器進(jìn)行接管繼續(xù)提供交換服務(wù)，從而保障服務(wù)的可靠性。目前利用Zookeeper組件可以很好地實(shí)現(xiàn)上述功能。

ZooKeeper是一個(gè)開(kāi)源的分布式協(xié)調(diào)服務(wù)組件，實(shí)現(xiàn)自動(dòng)化集群管理、分布式協(xié)調(diào)、配置維護(hù)、域名服務(wù)等功能，保證分布式集群的一致性?？梢杂涗浄?wù)節(jié)點(diǎn)的元數(shù)據(jù)和狀態(tài)信息，建立針對(duì)某服務(wù)節(jié)點(diǎn)工作狀態(tài)的事件監(jiān)聽(tīng)，提供統(tǒng)一命名、分布式鎖等基礎(chǔ)服務(wù)。另外通過(guò)自有的ZAB協(xié)議來(lái)保證分布式應(yīng)用之間存儲(chǔ)數(shù)據(jù)的一致性。ZooKeeper采用了服務(wù)端/客戶端架構(gòu)設(shè)計(jì)，系統(tǒng)中ZooKeeper架構(gòu)系統(tǒng)如圖3所示。

客戶端主動(dòng)與服務(wù)端建立Session會(huì)話連接，通過(guò)心跳檢測(cè)與服務(wù)端保持有效的會(huì)話，同時(shí)ZooKeeper支持發(fā)布/訂閱模式客戶端可以建立服務(wù)端的監(jiān)聽(tīng)事件，對(duì)服務(wù)端的狀態(tài)進(jìn)行監(jiān)聽(tīng)。另外客戶端在建立會(huì)話連接后需要向ZooKeeper的Recipes注冊(cè)服務(wù)節(jié)點(diǎn)信息。這樣ZooKeeper能夠監(jiān)控客戶端與服務(wù)端的活動(dòng)行為，在異常情況下對(duì)服務(wù)進(jìn)行協(xié)調(diào)管理，保障無(wú)間斷交換服務(wù)。ZooKeeper服務(wù)端內(nèi)的各個(gè)節(jié)點(diǎn)相互進(jìn)行通信，實(shí)時(shí)掌握各節(jié)點(diǎn)的工作狀態(tài)，保證分布式服務(wù)的一致性。

ZooKeeper具有主從架構(gòu)即存在主節(jié)點(diǎn)和從節(jié)點(diǎn)，主節(jié)點(diǎn)負(fù)責(zé)跟蹤從節(jié)點(diǎn)的狀態(tài)，并分配任務(wù)到從節(jié)點(diǎn)。對(duì)于主從節(jié)點(diǎn)的確定，ZooKeeper采用選舉投票機(jī)制，選舉原則是Quorum（過(guò)半機(jī)器數(shù)），即n/2+1，其中n代表集群中機(jī)器的數(shù)量。為保證交換服務(wù)的絕對(duì)穩(wěn)定，綜合考慮后本系統(tǒng)將使用5臺(tái)機(jī)器作為集群。

Leader選舉過(guò)程示例如圖4所示。

在服務(wù)第一次啟動(dòng)時(shí)，ZooKeeper服務(wù)端的每臺(tái)機(jī)器會(huì)自動(dòng)發(fā)出一個(gè)投票，并推選自己作為L(zhǎng)eader，每次投票包含的信息包括自己的myid和ZXID。在接收到來(lái)自其它服務(wù)器的投票后，針對(duì)每一個(gè)投票，服務(wù)器需要與接收到的其它投票進(jìn)行比較，ZXID數(shù)值大優(yōu)先作為L(zhǎng)eader，在ZXID相同的情況下，繼續(xù)比較myid的數(shù)值，數(shù)值較大的一方作為L(zhǎng)eader，并將投票結(jié)果廣播給其它服務(wù)器，進(jìn)行下一次投票。當(dāng)服務(wù)器統(tǒng)計(jì)已有過(guò)半機(jī)器接收到相同的投票結(jié)果，即該結(jié)果對(duì)應(yīng)的服務(wù)器作為L(zhǎng)eader。一旦確定Leader，每個(gè)服務(wù)器就會(huì)更新自己的狀態(tài)：如果是Follower，就變更為FOLLOWING；如果是Leader，那么永久變更為L(zhǎng)EADING。

綜上所述，本文的核心是如何實(shí)現(xiàn)ZooKeeper的功能。下面對(duì)具體實(shí)現(xiàn)過(guò)程進(jìn)行介紹。

二、ZooKeeper在本文中的實(shí)現(xiàn)

ZooKeeper在運(yùn)行時(shí)主要關(guān)注三種狀態(tài)：服務(wù)啟動(dòng)時(shí)、服務(wù)運(yùn)行中、服務(wù)故障時(shí)。在服務(wù)器的不同狀態(tài)下，它的任務(wù)和功能不盡相同，但主要都是通過(guò)調(diào)用API來(lái)實(shí)現(xiàn)。

（一）服務(wù)啟動(dòng)時(shí)

1. 建立各部署系統(tǒng)/交換服務(wù)之間的會(huì)話

在ZooKeeper服務(wù)建立時(shí)，客戶端通過(guò)創(chuàng)建一個(gè)Session會(huì)話與服務(wù)端建立連接，客戶端的同步任務(wù)從圖3可知，本文中我們將各部署系統(tǒng)作為ZooKeeper客戶端，而交換服務(wù)作為服務(wù)端。其中創(chuàng)建會(huì)話必需的三個(gè)參數(shù)如表1所示。

?

實(shí)現(xiàn)核心代碼如圖5所示。

2. 注冊(cè)節(jié)點(diǎn)

在會(huì)話創(chuàng)建后下一步就需要向ZooKeeper注冊(cè)節(jié)點(diǎn)信息。注冊(cè)節(jié)點(diǎn)的目的是使ZooKeeper了解每個(gè)交換服務(wù)的基本信息和任務(wù)信息，以便某個(gè)交換服務(wù)發(fā)生異常情況時(shí)，通知其它交換服務(wù)進(jìn)行接管操作。ZooKeeper的視圖結(jié)構(gòu)使用的數(shù)據(jù)節(jié)點(diǎn)方式稱為ZNode，文件系統(tǒng)層級(jí)樹(shù)狀結(jié)構(gòu)，用來(lái)存儲(chǔ)交換服務(wù)各節(jié)點(diǎn)的地址信息以及數(shù)據(jù)交換任務(wù)的執(zhí)行位置和狀態(tài)。ZNode數(shù)據(jù)結(jié)構(gòu)如圖6所示。

從圖4可以看到ZooKeeper的數(shù)據(jù)結(jié)構(gòu)中的ZNode節(jié)點(diǎn)有 4種： Leader、Follower、Task、Assign，分別指主節(jié)點(diǎn)、從節(jié)點(diǎn)、任務(wù)和任務(wù)的分派情況等信息，其中Task和Assign節(jié)點(diǎn)是在生成任務(wù)時(shí)才進(jìn)行寫(xiě)入的。通過(guò)集中管理主從成員的任務(wù)執(zhí)行情況，實(shí)現(xiàn)了分布式集群服務(wù)一致性的可靠保障。創(chuàng)建節(jié)點(diǎn)的方法如表2所示。

?

以注冊(cè)從節(jié)點(diǎn)為例具體實(shí)現(xiàn)代碼如圖7所示。

3. 建立監(jiān)聽(tīng)事件

在ZooKeeper中，Watcher機(jī)制實(shí)現(xiàn)了訂閱發(fā)布模式的分布式通知功能，即ZooKeeper客戶端向服務(wù)端進(jìn)行通知訂閱，服務(wù)端會(huì)根據(jù)客戶端訂閱的內(nèi)容在更新時(shí)進(jìn)行通知。本文中一旦服務(wù)端某個(gè)交換服務(wù)中斷，在Session超時(shí)后，會(huì)向客戶端發(fā)送Watcher事件，告知由哪個(gè)交換服務(wù)來(lái)進(jìn)行接管。

當(dāng)ZooKeeper服務(wù)端向客戶端發(fā)送一個(gè)watchers事件通知時(shí)，客戶端就會(huì)對(duì)相應(yīng)的process方法進(jìn)行回調(diào)，從而實(shí)現(xiàn)對(duì)事件的處理。process的定義如表3所示。

?

WatchedEvent 包含了每一個(gè)時(shí)間的三個(gè)基本屬性：通知狀態(tài)（keeperState），事件類型（eventType）和節(jié)點(diǎn)路徑（path），如圖8所示。ZooKeeper使用WatchEvent對(duì)象來(lái)封裝服務(wù)端事件并傳遞給Watcher，從而方便回調(diào)方法process對(duì)服務(wù)端事件進(jìn)行處理。

部署系統(tǒng)接收Watcher響應(yīng)事件代碼如圖9所示。

（二）服務(wù)運(yùn)行中

如果有新交換任務(wù)需要交換服務(wù)來(lái)進(jìn)行同步，客戶端調(diào)用數(shù)據(jù)更新API向ZooKeeper Recipes更新任務(wù)信息。這樣作為L(zhǎng)eader的交換服務(wù)，通過(guò)查詢Recipes會(huì)調(diào)度指定的Follower來(lái)執(zhí)行同步操作。

節(jié)點(diǎn)數(shù)據(jù)更新方法如表4所示。

?

節(jié)點(diǎn)數(shù)據(jù)更新方法如圖10所示。

其中，mission代表每次數(shù)據(jù)交換任務(wù)的結(jié)構(gòu)體信息。

（三）服務(wù)故障時(shí)

1. 超時(shí)重新進(jìn)行選舉

當(dāng)Leader交換服務(wù)在Session超時(shí)時(shí)間內(nèi)未能重新建立與客戶端的連接，該Leader便失去了服務(wù)的控制權(quán)，其它的Follower交換服務(wù)將Session狀態(tài)變?yōu)長(zhǎng)OOKING，然后開(kāi)始進(jìn)入選舉。選舉過(guò)程與服務(wù)第一次啟動(dòng)時(shí)的選舉過(guò)程一致。

2. 重新建立會(huì)話

當(dāng)客戶端與交換服務(wù)網(wǎng)絡(luò)中斷時(shí)，客戶端會(huì)自動(dòng)向其它節(jié)點(diǎn)進(jìn)行重連，如果在有效時(shí)間重連成功，則繼續(xù)由該節(jié)點(diǎn)提供交換服務(wù)；如果出現(xiàn)重連異常，會(huì)出現(xiàn)兩種情況：C O N N E C T I O N_L O S S（連接斷開(kāi)）和SESSION_EXPIRED（會(huì)話過(guò)期），如果連接斷開(kāi)則客戶端會(huì)向其它節(jié)點(diǎn)進(jìn)行重連，若所有節(jié)點(diǎn)都無(wú)法連接成功，則當(dāng)前無(wú)可用交換服務(wù)；如果在有效時(shí)間之外重新連接成功雖然連接建立，但會(huì)話已失效，這時(shí)需要客戶端重新實(shí)例化ZooKeeper對(duì)象并恢復(fù)臨時(shí)數(shù)據(jù)。

三、系統(tǒng)運(yùn)行監(jiān)控及系統(tǒng)分布式與單點(diǎn)式對(duì)比

（一）系統(tǒng)運(yùn)行監(jiān)控

系統(tǒng)部署啟動(dòng)后，利用Zookeeper的相關(guān)命令可以了解各服務(wù)端的運(yùn)行情況，包括數(shù)據(jù)的發(fā)送與接收、服務(wù)節(jié)點(diǎn)的身份情況（比如Leader或者Follower）、當(dāng)前活動(dòng)的節(jié)點(diǎn)數(shù)據(jù)量等信息。圖11、圖12分別是查看Leader服務(wù)器與Follower服務(wù)器的運(yùn)行情況。

（二）本系統(tǒng)分布式架構(gòu)與單點(diǎn)式架構(gòu)對(duì)比

通過(guò)對(duì)比可以看到，分布式數(shù)據(jù)交換系統(tǒng)的最大優(yōu)勢(shì)就是服務(wù)的可靠性和穩(wěn)定性得到很好保障；另外分布式數(shù)據(jù)交換方式使得集群中各服務(wù)按照不同分工并行進(jìn)行數(shù)據(jù)采集和傳輸，較單點(diǎn)式系統(tǒng)大大降低了單個(gè)服務(wù)器的負(fù)載，使得數(shù)據(jù)交換服務(wù)的運(yùn)行壓力得以分擔(dān)；最后分布式數(shù)據(jù)交換系統(tǒng)將集群中任務(wù)執(zhí)行位置和狀態(tài)等信息存儲(chǔ)在Zookeeper各服務(wù)端，相互之間通過(guò)廣播通信保證上述信息的同步，保證了即使當(dāng)前服務(wù)器網(wǎng)絡(luò)中斷，上次任務(wù)的執(zhí)行信息也不會(huì)丟失，這樣在被服務(wù)器托管或者本服務(wù)器恢復(fù)后，仍然可以繼續(xù)執(zhí)行數(shù)據(jù)交換任務(wù)。

?

四、結(jié)語(yǔ)

分布式的數(shù)據(jù)交換系統(tǒng)極大提高了數(shù)據(jù)交換的效率，減輕了負(fù)載壓力。同時(shí)，利用ZooKeeper實(shí)現(xiàn)分布式集群之間的協(xié)調(diào)管理保障了服務(wù)的可靠性和穩(wěn)定性，其優(yōu)勢(shì)顯而易見(jiàn)。目前ZooKeeper技術(shù)已廣泛應(yīng)用在各類大數(shù)據(jù)開(kāi)源系統(tǒng)中，用來(lái)解決諸如配置管理、分布式通知/協(xié)調(diào)、集群管理和主從選舉等一系列分布式問(wèn)題，保障系統(tǒng)的穩(wěn)定運(yùn)行。

在大數(shù)據(jù)技術(shù)逐漸滲透到警用裝備管理的今天，通過(guò)對(duì)歷史數(shù)據(jù)的有效分析進(jìn)行災(zāi)難預(yù)判和環(huán)境感知的監(jiān)控，可防止危險(xiǎn)的發(fā)生，而這一切都需要數(shù)據(jù)資源的準(zhǔn)確性、及時(shí)性、完備性作為保障。我們相信隨著警用裝備業(yè)務(wù)管理的不斷豐富，采集和交換的數(shù)據(jù)量會(huì)不斷增長(zhǎng)，數(shù)據(jù)交換服務(wù)的穩(wěn)定性和可靠性作為非常重要的業(yè)務(wù)要求將會(huì)持續(xù)受到管理部門(mén)的高度關(guān)注。