0引言

隨著光纖保護系統在通信領域的廣泛運用，建立一整套軟、硬齊全的光層保護監控系統尤其重要。系統通過數據采集服務可以實時快速地獲得各個光保護設備的及時數據，然后交給上層進行相應的處理。

數據采集服務是惟一面向光纖設備的接口服務層，每秒有相當大的數據吞吐量，因此數據采集服務的設計尤為關鍵，必須兼顧考慮設計的合理性、高效性和一致性。面對大量的數據交流，采集服務分多個模塊，主要采用多點采集多線程的模式構建方式。各個模塊分別完成不同的功能，通過由主線程創建許多與子模塊對應的子線程，由單獨的一個線程來分發數據給各個子線程，實現數據的同步處理，提高系統的效率和網元容量。

1 TCP／IP，UDP協議

數據采集服務需要大量的數據處理工作，從光設備中采集數據以及將數據轉交給上層服務都需要一定的協議來完成。根據TCP和UDP不同的特點，選取可靠的TCP／IP通信方式連接采集服務與上層服務；選取效率較高的UDP通信方式連接采集服務及下層設備。以UDP為例，UDP通信模塊在發送的時候，只是需要從UDP發送隊列獲取數據發給設備，而在接收的時候，將設備數據存放到UDP接收隊列。

數據的發送和接收分別由兩個不同的線程來完成。此外，還有一個單獨的線程對接收隊列的數據進行解包和分發，并根據返回的UDP命令代碼或索引（track）的不同將數據分別放置到數據輪詢返回隊列、閾值輪詢返回隊列和讀寫設備返回隊列，其模塊結構如圖1所示。

2數據輪詢

由于光保護設備都是非智能的設備，只能被動地采集性能數據，不會主動地上報性能變化給管理軟件，基于此，在軟件設計中采用了數據輪詢機制，獨立出一個輪詢模塊來捕捉網絡中的性能變化，彌補了設備的不足。在這個模塊中要進行處理，去掉一些重復的數據，以減少與上層服務通信的數據量。在輪詢過程中，要進行超時控制，對于超時的請求需要補叫。因此，對于所有的輪詢都需要有緩沖列表存儲，只有當得到回應后才刪除請求。

數據輪詢模塊包括數據輪詢線程、數據輪詢返回處理線程、閾值輪詢返回處理線程和切換命令超時處理線程。數據輪詢模塊結構圖如圖2所示。

2.1數據輪詢線程

數據輪詢線程是負責對設備進行輪詢的線程。通過定時地發出讀數據和讀閾值命令來采集設備的性能、狀態、告警和閾值信息，因此，輪詢時間間隔必須很小，而且對性能和閾值輪詢的周期要求有所不同，因為閾值的變化較少。該線程在輪詢模塊啟動后，判斷是否獲得配置信息樹的初始信息，如果是就開始輪詢。

2.2閾值輪詢返回處理線程

數據輪詢線程按照閾值輪詢的周期定期發送讀光保護設備閾值的命令，設備在收到命令包后定期返回設備的閾值，這些閾值通過UDP模塊的數據分發線程發送到閾值輪詢返回隊列，等待閾值輪詢返回處理線程來處理。

閾值輪詢返回處理線程則接收這些返回的閾值，通過比較全局配置信息樹的前次輪詢結果與當前返回結果來捕捉閾值的變化，并將這些變化寫入告警隊列，通過性能和告警模塊將閾值變化事件發送到上層服務器。

2.3數據輪詢返回處理線程

與閾值的輪詢相似，數據輪詢線程按照系統設定的輪詢周期定期發送讀光保護設備數據的命令，輪詢周期一般為500 ms或1 s。設備在收到讀數據的命令包后定期返回設備數據，這些數據通過UDP模塊的數據分發線程發送到數據輪詢返回隊列，等待數據輪詢返回處理線程來處理。數據輪詢返回處理線程在接收到這些返回的數據后，通過比較全局配置信息樹的前次輪詢結果與當前返回結果來捕捉告警信息、狀態變化事件及其他信息，并將這些變化寫入告警隊列，通過性能和告警模塊將告警和事件發送到上層服務器。

在該線程中，對線路切換的處理比較特殊，由于發生線路切換時用戶需要察看切換前整個過程中性能值的變化情況，并且需要該信息盡快返回到用戶界面，因此，當發生線路切換時需要立即發送8個數據包讀取40幀切換過程的性能信息，通過數據分析后取出最近一次切換前的性能信息作為切換事件的附加數據添加到告警隊列。

2.4讀切換命令超時處理線程

在數據輪詢線程中讀切換信息命令發生工作模式改變（即發生線路切換）時，連續發送8個數據包（即8個讀切換命令）讀取40幀與線路切換相關的性能數據，每個命令讀取5幀數據。返回的40幀數據通過索引號來判別數據的先后關系，與數據幀的位置無關。在實際過程中可能還需要反復發送數據包才能完整地獲得40幀數據。因此，在讀切換命令超時處理線程中，在命令超時之前還要對未返回的數據包反復發送取切換命令，直到完全獲得全部40幀數據才能分析處理。

讀切換命令超時時間設置為5 s，5 s內反復讀取切換信息直到全部40幀數據返回或者超時，如果超時則僅向告警隊列添加切換事件而不附帶性能數據。

在返回數據的分析處理中，首先找到40幀數據中4個索引號的最大值，并在索引號最大的一組（共10個）數據中找到剛發生切換之前的性能數據——即找到這組數據中工作模式與切換后的當前工作模式相同的一幀數據，這幀數據的前一幀數據就是剛剛發生切換之前的性能數據，將這些性能數據作為切換事件的附帶數據，和切換事件一起寫入告警隊列，發往性能和告警模塊，等待處理并發送到上層服務器。

3多線程的應用

數據輪詢模塊自身就屬于一個單獨的線程，用來完成數據采集模塊中的性能和告警數據主動采集功能，為了保證對眾多網元設備的快速采集，數據輪詢模塊內部又用了多個子線程分工協作。

雖然多個線程同時工作，可以在不占用大量CPU資源的情況下提高模塊的執行效率，但是模塊也存在著一個隱患，它有一個潛在問題，即數據采集服務中有許多共享資源，可能在某個時刻，某一個線程修改某一個信息，正好第二個線程的時間片也到了，也試圖去修改同一個信息，此刻就發生了數據沖突，那么后果比較嚴重。

上述問題的出現主要是兩個線程同時訪問了一個共享的變量，為了避免這種問題的發生，要求在多個線程之間進行同步處理，保證一個線程訪問共享資源時，其他線程不能訪問該資源。為了達到該目的，這里最初使用Sleep函數，讓線程睡眠片刻，避免多個線程同時訪問同一資源，但經過實踐發現，這樣不僅浪費時間，依然沒有解決同步的問題。

為了實現這種同步，系統采用了同步隊列技術，即構造了一個隊列，讓多個線程分別向其中存人數據和取出數據。例如，通過數據輪詢從下層設備得到多種性能數據，這是UDP接收線程的工作。該線程將接收到的UDP包添加到同步隊列的隊尾，然后再去接收新的數據，反復做同樣的操作。存放在同步隊列中的數據等待命令處理線程將其一一取出并加以分析，然后分派到各個模塊類。

命令處理線程每次從隊列頭部取出數據，一次只能取出一個數據。同一時刻，只能有一個線程對同步隊列進行操作。否則會出現操作不同步的問題，影響數據獲得的正確性。例如，當接收線程向隊尾寫數據時，處理線程也從隊頭取數據，可能取出的數據正好是接收線程當前所寫入的，這樣得到的數據不但不完整，也破壞了原始得到的性能數據。解決的方法就是給同步隊列設置一個互斥量（mutex），當某個線程對同步隊列進行操作時，就設置互斥。

這樣，其他線程想要使用隊列資源時就會因為互斥量已被設置而處于等待中，直到共享資源得到釋放。另外，同步隊列還采用了生產者一消費者模型，保證向同步隊列添加新數據時，隊列有空間；向隊列取數據時，隊列中有數據，避免產生內存泄露等問題。實現方式是在隊列中添加信號量spProducer和spConsumer，每當向隊列添加數據時，調用spConsumer-》post（）；取出數據的時候，調用spProducer-》post（）。

同步隊列定義了一個基類CMosSynQueue，里面封裝了同步互斥的基本操作。在采集服務中各個模塊都運用了多線程，所以每個模塊都定義了一個同步隊列，全部派生于CMosSynQueue。

4跨平臺的實現

為了加強系統的通用性，系統將平臺的相關性轉變為無關性。利用stlport庫的可移植性，封裝了普通類，使所有類都能夠跨平臺使用。這些類包括CMosDirec-tory，CMosSynQueue，CMosEvent，CMosFile，CMos-MutexLock，CMosRunThread，CMosReadWriteLock，CMosSemaphore，CMosSimpleLock，CMosThread，CMosTimedMutex，CMosTryMurex。

每個類中，通過宏來選擇程序運行在哪個操作平臺，例如，#if defined（_MoS_WIN32_）則在Windows操作系統中使用，#elif defined（_MOS_POSIX_）則表示在Linux系統中使用。經過封裝，系統中所有的類都派生自這些類，這樣就可以在多個平臺上使用了。

5結語

數據采集模塊在整個網絡管理系統中占據著十分重要的地位。這里主要介紹了采集模塊中一個很重要的模塊，即數據輪詢模塊。輪詢模塊采用了多線程，針對多線程，提出了一種同步的方式，采用同步隊列。為了使軟件更具有移植性，系統主要采用了stlport類庫，實現了跨平臺。該模塊已在實際的網管系統中得到了應用，取得了較好的效果。

編輯：jq