0引言
隨著光纖保護(hù)系統(tǒng)在通信領(lǐng)域的廣泛運(yùn)用,建立一整套軟、硬齊全的光層保護(hù)監(jiān)控系統(tǒng)尤其重要。系統(tǒng)通過數(shù)據(jù)采集服務(wù)可以實(shí)時快速地獲得各個光保護(hù)設(shè)備的及時數(shù)據(jù),然后交給上層進(jìn)行相應(yīng)的處理。
數(shù)據(jù)采集服務(wù)是惟一面向光纖設(shè)備的接口服務(wù)層,每秒有相當(dāng)大的數(shù)據(jù)吞吐量,因此數(shù)據(jù)采集服務(wù)的設(shè)計(jì)尤為關(guān)鍵,必須兼顧考慮設(shè)計(jì)的合理性、高效性和一致性。面對大量的數(shù)據(jù)交流,采集服務(wù)分多個模塊,主要采用多點(diǎn)采集多線程的模式構(gòu)建方式。各個模塊分別完成不同的功能,通過由主線程創(chuàng)建許多與子模塊對應(yīng)的子線程,由單獨(dú)的一個線程來分發(fā)數(shù)據(jù)給各個子線程,實(shí)現(xiàn)數(shù)據(jù)的同步處理,提高系統(tǒng)的效率和網(wǎng)元容量。
1 TCP/IP,UDP協(xié)議
數(shù)據(jù)采集服務(wù)需要大量的數(shù)據(jù)處理工作,從光設(shè)備中采集數(shù)據(jù)以及將數(shù)據(jù)轉(zhuǎn)交給上層服務(wù)都需要一定的協(xié)議來完成。根據(jù)TCP和UDP不同的特點(diǎn),選取可靠的TCP/IP通信方式連接采集服務(wù)與上層服務(wù);選取效率較高的UDP通信方式連接采集服務(wù)及下層設(shè)備。以UDP為例,UDP通信模塊在發(fā)送的時候,只是需要從UDP發(fā)送隊(duì)列獲取數(shù)據(jù)發(fā)給設(shè)備,而在接收的時候,將設(shè)備數(shù)據(jù)存放到UDP接收隊(duì)列。
數(shù)據(jù)的發(fā)送和接收分別由兩個不同的線程來完成。此外,還有一個單獨(dú)的線程對接收隊(duì)列的數(shù)據(jù)進(jìn)行解包和分發(fā),并根據(jù)返回的UDP命令代碼或索引(track)的不同將數(shù)據(jù)分別放置到數(shù)據(jù)輪詢返回隊(duì)列、閾值輪詢返回隊(duì)列和讀寫設(shè)備返回隊(duì)列,其模塊結(jié)構(gòu)如圖1所示。
2數(shù)據(jù)輪詢
由于光保護(hù)設(shè)備都是非智能的設(shè)備,只能被動地采集性能數(shù)據(jù),不會主動地上報(bào)性能變化給管理軟件,基于此,在軟件設(shè)計(jì)中采用了數(shù)據(jù)輪詢機(jī)制,獨(dú)立出一個輪詢模塊來捕捉網(wǎng)絡(luò)中的性能變化,彌補(bǔ)了設(shè)備的不足。在這個模塊中要進(jìn)行處理,去掉一些重復(fù)的數(shù)據(jù),以減少與上層服務(wù)通信的數(shù)據(jù)量。在輪詢過程中,要進(jìn)行超時控制,對于超時的請求需要補(bǔ)叫。因此,對于所有的輪詢都需要有緩沖列表存儲,只有當(dāng)?shù)玫交貞?yīng)后才刪除請求。
數(shù)據(jù)輪詢模塊包括數(shù)據(jù)輪詢線程、數(shù)據(jù)輪詢返回處理線程、閾值輪詢返回處理線程和切換命令超時處理線程。數(shù)據(jù)輪詢模塊結(jié)構(gòu)圖如圖2所示。
2.1數(shù)據(jù)輪詢線程
數(shù)據(jù)輪詢線程是負(fù)責(zé)對設(shè)備進(jìn)行輪詢的線程。通過定時地發(fā)出讀數(shù)據(jù)和讀閾值命令來采集設(shè)備的性能、狀態(tài)、告警和閾值信息,因此,輪詢時間間隔必須很小,而且對性能和閾值輪詢的周期要求有所不同,因?yàn)殚撝档淖兓^少。該線程在輪詢模塊啟動后,判斷是否獲得配置信息樹的初始信息,如果是就開始輪詢。
2.2閾值輪詢返回處理線程
數(shù)據(jù)輪詢線程按照閾值輪詢的周期定期發(fā)送讀光保護(hù)設(shè)備閾值的命令,設(shè)備在收到命令包后定期返回設(shè)備的閾值,這些閾值通過UDP模塊的數(shù)據(jù)分發(fā)線程發(fā)送到閾值輪詢返回隊(duì)列,等待閾值輪詢返回處理線程來處理。
閾值輪詢返回處理線程則接收這些返回的閾值,通過比較全局配置信息樹的前次輪詢結(jié)果與當(dāng)前返回結(jié)果來捕捉閾值的變化,并將這些變化寫入告警隊(duì)列,通過性能和告警模塊將閾值變化事件發(fā)送到上層服務(wù)器。
2.3數(shù)據(jù)輪詢返回處理線程
與閾值的輪詢相似,數(shù)據(jù)輪詢線程按照系統(tǒng)設(shè)定的輪詢周期定期發(fā)送讀光保護(hù)設(shè)備數(shù)據(jù)的命令,輪詢周期一般為500 ms或1 s。設(shè)備在收到讀數(shù)據(jù)的命令包后定期返回設(shè)備數(shù)據(jù),這些數(shù)據(jù)通過UDP模塊的數(shù)據(jù)分發(fā)線程發(fā)送到數(shù)據(jù)輪詢返回隊(duì)列,等待數(shù)據(jù)輪詢返回處理線程來處理。數(shù)據(jù)輪詢返回處理線程在接收到這些返回的數(shù)據(jù)后,通過比較全局配置信息樹的前次輪詢結(jié)果與當(dāng)前返回結(jié)果來捕捉告警信息、狀態(tài)變化事件及其他信息,并將這些變化寫入告警隊(duì)列,通過性能和告警模塊將告警和事件發(fā)送到上層服務(wù)器。
在該線程中,對線路切換的處理比較特殊,由于發(fā)生線路切換時用戶需要察看切換前整個過程中性能值的變化情況,并且需要該信息盡快返回到用戶界面,因此,當(dāng)發(fā)生線路切換時需要立即發(fā)送8個數(shù)據(jù)包讀取40幀切換過程的性能信息,通過數(shù)據(jù)分析后取出最近一次切換前的性能信息作為切換事件的附加數(shù)據(jù)添加到告警隊(duì)列。
2.4讀切換命令超時處理線程
在數(shù)據(jù)輪詢線程中讀切換信息命令發(fā)生工作模式改變(即發(fā)生線路切換)時,連續(xù)發(fā)送8個數(shù)據(jù)包(即8個讀切換命令)讀取40幀與線路切換相關(guān)的性能數(shù)據(jù),每個命令讀取5幀數(shù)據(jù)。返回的40幀數(shù)據(jù)通過索引號來判別數(shù)據(jù)的先后關(guān)系,與數(shù)據(jù)幀的位置無關(guān)。在實(shí)際過程中可能還需要反復(fù)發(fā)送數(shù)據(jù)包才能完整地獲得40幀數(shù)據(jù)。因此,在讀切換命令超時處理線程中,在命令超時之前還要對未返回的數(shù)據(jù)包反復(fù)發(fā)送取切換命令,直到完全獲得全部40幀數(shù)據(jù)才能分析處理。
讀切換命令超時時間設(shè)置為5 s,5 s內(nèi)反復(fù)讀取切換信息直到全部40幀數(shù)據(jù)返回或者超時,如果超時則僅向告警隊(duì)列添加切換事件而不附帶性能數(shù)據(jù)。
在返回?cái)?shù)據(jù)的分析處理中,首先找到40幀數(shù)據(jù)中4個索引號的最大值,并在索引號最大的一組(共10個)數(shù)據(jù)中找到剛發(fā)生切換之前的性能數(shù)據(jù)——即找到這組數(shù)據(jù)中工作模式與切換后的當(dāng)前工作模式相同的一幀數(shù)據(jù),這幀數(shù)據(jù)的前一幀數(shù)據(jù)就是剛剛發(fā)生切換之前的性能數(shù)據(jù),將這些性能數(shù)據(jù)作為切換事件的附帶數(shù)據(jù),和切換事件一起寫入告警隊(duì)列,發(fā)往性能和告警模塊,等待處理并發(fā)送到上層服務(wù)器。
3多線程的應(yīng)用
數(shù)據(jù)輪詢模塊自身就屬于一個單獨(dú)的線程,用來完成數(shù)據(jù)采集模塊中的性能和告警數(shù)據(jù)主動采集功能,為了保證對眾多網(wǎng)元設(shè)備的快速采集,數(shù)據(jù)輪詢模塊內(nèi)部又用了多個子線程分工協(xié)作。
雖然多個線程同時工作,可以在不占用大量CPU資源的情況下提高模塊的執(zhí)行效率,但是模塊也存在著一個隱患,它有一個潛在問題,即數(shù)據(jù)采集服務(wù)中有許多共享資源,可能在某個時刻,某一個線程修改某一個信息,正好第二個線程的時間片也到了,也試圖去修改同一個信息,此刻就發(fā)生了數(shù)據(jù)沖突,那么后果比較嚴(yán)重。
上述問題的出現(xiàn)主要是兩個線程同時訪問了一個共享的變量,為了避免這種問題的發(fā)生,要求在多個線程之間進(jìn)行同步處理,保證一個線程訪問共享資源時,其他線程不能訪問該資源。為了達(dá)到該目的,這里最初使用Sleep函數(shù),讓線程睡眠片刻,避免多個線程同時訪問同一資源,但經(jīng)過實(shí)踐發(fā)現(xiàn),這樣不僅浪費(fèi)時間,依然沒有解決同步的問題。
為了實(shí)現(xiàn)這種同步,系統(tǒng)采用了同步隊(duì)列技術(shù),即構(gòu)造了一個隊(duì)列,讓多個線程分別向其中存人數(shù)據(jù)和取出數(shù)據(jù)。例如,通過數(shù)據(jù)輪詢從下層設(shè)備得到多種性能數(shù)據(jù),這是UDP接收線程的工作。該線程將接收到的UDP包添加到同步隊(duì)列的隊(duì)尾,然后再去接收新的數(shù)據(jù),反復(fù)做同樣的操作。存放在同步隊(duì)列中的數(shù)據(jù)等待命令處理線程將其一一取出并加以分析,然后分派到各個模塊類。
命令處理線程每次從隊(duì)列頭部取出數(shù)據(jù),一次只能取出一個數(shù)據(jù)。同一時刻,只能有一個線程對同步隊(duì)列進(jìn)行操作。否則會出現(xiàn)操作不同步的問題,影響數(shù)據(jù)獲得的正確性。例如,當(dāng)接收線程向隊(duì)尾寫數(shù)據(jù)時,處理線程也從隊(duì)頭取數(shù)據(jù),可能取出的數(shù)據(jù)正好是接收線程當(dāng)前所寫入的,這樣得到的數(shù)據(jù)不但不完整,也破壞了原始得到的性能數(shù)據(jù)。解決的方法就是給同步隊(duì)列設(shè)置一個互斥量(mutex),當(dāng)某個線程對同步隊(duì)列進(jìn)行操作時,就設(shè)置互斥。
這樣,其他線程想要使用隊(duì)列資源時就會因?yàn)榛コ饬恳驯辉O(shè)置而處于等待中,直到共享資源得到釋放。另外,同步隊(duì)列還采用了生產(chǎn)者一消費(fèi)者模型,保證向同步隊(duì)列添加新數(shù)據(jù)時,隊(duì)列有空間;向隊(duì)列取數(shù)據(jù)時,隊(duì)列中有數(shù)據(jù),避免產(chǎn)生內(nèi)存泄露等問題。實(shí)現(xiàn)方式是在隊(duì)列中添加信號量spProducer和spConsumer,每當(dāng)向隊(duì)列添加數(shù)據(jù)時,調(diào)用spConsumer-》post();取出數(shù)據(jù)的時候,調(diào)用spProducer-》post()。
同步隊(duì)列定義了一個基類CMosSynQueue,里面封裝了同步互斥的基本操作。在采集服務(wù)中各個模塊都運(yùn)用了多線程,所以每個模塊都定義了一個同步隊(duì)列,全部派生于CMosSynQueue。
4跨平臺的實(shí)現(xiàn)
為了加強(qiáng)系統(tǒng)的通用性,系統(tǒng)將平臺的相關(guān)性轉(zhuǎn)變?yōu)闊o關(guān)性。利用stlport庫的可移植性,封裝了普通類,使所有類都能夠跨平臺使用。這些類包括CMosDirec-tory,CMosSynQueue,CMosEvent,CMosFile,CMos-MutexLock,CMosRunThread,CMosReadWriteLock,CMosSemaphore,CMosSimpleLock,CMosThread,CMosTimedMutex,CMosTryMurex。
每個類中,通過宏來選擇程序運(yùn)行在哪個操作平臺,例如,#if defined(_MoS_WIN32_)則在Windows操作系統(tǒng)中使用,#elif defined(_MOS_POSIX_)則表示在Linux系統(tǒng)中使用。經(jīng)過封裝,系統(tǒng)中所有的類都派生自這些類,這樣就可以在多個平臺上使用了。
5結(jié)語
數(shù)據(jù)采集模塊在整個網(wǎng)絡(luò)管理系統(tǒng)中占據(jù)著十分重要的地位。這里主要介紹了采集模塊中一個很重要的模塊,即數(shù)據(jù)輪詢模塊。輪詢模塊采用了多線程,針對多線程,提出了一種同步的方式,采用同步隊(duì)列。為了使軟件更具有移植性,系統(tǒng)主要采用了stlport類庫,實(shí)現(xiàn)了跨平臺。該模塊已在實(shí)際的網(wǎng)管系統(tǒng)中得到了應(yīng)用,取得了較好的效果。
編輯:jq
-
cpu
+關(guān)注
關(guān)注
68文章
10780瀏覽量
210493 -
UDP
+關(guān)注
關(guān)注
0文章
318瀏覽量
33837
發(fā)布評論請先 登錄
相關(guān)推薦
評論