宋四云，胡金炎，林 霖，喻德曠，王 濤

SONG Si-yun，HU Jin-yan，LIN Lin，YU De-kuang，WANG Tao

(南方醫(yī)科大學生物醫(yī)學工程學院，廣州 510515)

0 引言

無線射頻識別技術(Radio Frequency Identification,RFID)利用電磁波在閱讀器和帶標簽的物體或人之間進行非接觸雙向通信，它通過交換數據來達到自動識別被標識對象以及獲取被標識對象相關信息的目的[1]。相比傳統(tǒng)的條形碼技術，RFID技術具有實時性好、穿透能力強、數據量大及可重復使用等諸多優(yōu)點。近年來，RFID技術發(fā)展迅速，在交通、供應鏈管理、校園安全等領域得到廣泛使用[2～4]。利用RFID技術，加強醫(yī)院產科和新生兒科的安全，提高健康監(jiān)護管理水平，是隨著RFID技術的成熟和普及而產生的一個新的極具前景的應用領域。為此我們設計開發(fā)了一套基于RFID技術的母嬰安全監(jiān)護系統(tǒng)(Maternalinfant Safety and Surveillance,MISS）。

母嬰安全監(jiān)護系統(tǒng)應用于醫(yī)院，具有監(jiān)控新生嬰兒生命體征，防止嬰兒被盜及母嬰配對等功能[5]。系統(tǒng)的拓撲結構如圖1所示。它基于B/S架構，分為兩部分，前臺顯示部分和后臺服務軟件部分。標簽（Tag）佩戴在人體上，可通過傳感器接入設備，它集成兩個溫度傳感器和一個運動傳感器，以1.5Hz采樣率采集人體及周圍環(huán)境參數。標簽整合三個傳感器的信號及自身識別屬性形成66比特的字節(jié)數據，然后以射頻（RF）信號發(fā)送給閱讀器（Reader）。一個閱讀器可以接收多個標簽的數據并且內置防碰撞算法避免信號沖突。閱讀器是具有RF信號發(fā)射與接收模塊的微系統(tǒng)，將TCP/IP協議棧集成于微系統(tǒng)中，通過TCP協議與應用程序服務器雙向通信。應用程序服務器按照通信協議接收標簽的實時傳感數據，合理解釋引用之后過濾冗余信息將其存儲在數據庫中。用戶通過瀏覽器訪問系統(tǒng)，提取已經處理過的傳感器采樣數據，在頁面上呈現母嬰的實時狀況，同時在出現異常情況時控制聲光報警器與LED顯示器的開關，為醫(yī)護人員的決策提供支持。

圖1 母嬰安全監(jiān)護系統(tǒng)拓撲結構

通過對系統(tǒng)的測試可知，系統(tǒng)存在數據量大，數據采集速率快等特點。而后臺服務軟件在線程、數據庫連接對象的建立和數據邏輯運算上均比較耗時，數據處理消耗較大[6]。因而系統(tǒng)相對快速的數據采集過程與相對緩慢的數據處理過程的同步性得不到滿足。新生嬰兒作為母嬰安全監(jiān)護系統(tǒng)的主要應用對象，其佩帶的標簽將采集到的生命體征信息和位置狀態(tài)信息傳遞給應用程序服務器，而應用程序服務器需經過一系列對原始數據的解析、回調以及事件處理后以應用數據作為媒介為我們提供嬰兒安全監(jiān)控。在標簽采集信息具有高度時域性的情況下，系統(tǒng)對實時處理的要求高，當有標簽信息丟失、漏報或者延時較大的情況發(fā)生時，應用程序服務器因不能及時處理并解讀出此異?，F象而會造成系統(tǒng)功能上的錯誤。

在當前研究中，解決數據實時處理一般有兩種方法。一種為硬件拓撲結構的改進，通過使用服務器集群、數據庫集群，增加硬件處理能力，利用負載平衡技術來避免系統(tǒng)負載過重；另一種為軟件設計方法，通過建立一個適合于大量數據實時處理訪問的模型，提高程序的并行處理能力以達到系統(tǒng)應用要求[7,8]。本文所研究開發(fā)的系統(tǒng)，考慮到實施成本及實際的負載強度等情況，選擇使用軟件設計方法。

基于以上考慮，提出了一種基于多線程及緩存技術的數據實時處理方法，把數據處理過程劃分為兩個階段：數據采集階段和數據處理階段。階段內以流水線進行數據操作，建立多線程，每個線程為數據處理的基本粒子；階段間建立緩存容器，異步傳輸數據，消除階段間的數據同步。實踐證明，該方法能有效提高數據處理實時性。

1 方法與技術

1.1 模型結構

數據實時處理方法面對的是一個前端分布式標簽進行信號采集，后端集中式應用程序服務器進行信號處理的離散模型。為了搭建模型，需對幾個數據指標進行評估。1)標簽采集數據大小、采樣頻率，系統(tǒng)使用標簽和閱讀器的個數；2)系統(tǒng)理解完成功能，需要多大窗口的歷史感知數據；3)實時傳感數據與歷史感知數據的比較運算耗時大小；4)應用程序服務器與數據庫服務器的數據傳輸延時等。對此我們進行測試，系統(tǒng)測試環(huán)境為：

處理器：Intel(R)Core(TM)2 Duo CPU 2.94GHz

內存：2.00GB

系統(tǒng)類型：Windows7 32位操作系統(tǒng)

開發(fā)IDE：Eclipse-java-helios-SR2-win32

數據庫：Mysql5.5.24

測試方法根據單一變量原則，每個過程只測試一個指標，量化的指標值是系統(tǒng)迭代20萬次取平均值。測試結果表明，系統(tǒng)使用標簽50個，標簽每0.6s采集一條記錄，每條記錄大小66B，系統(tǒng)一天接收的數據量大約450M，共計720萬條記錄，所有的采集數據醫(yī)院都需進行留檔備份。新建一個線程平均耗時3750.2μs，線程上下文切換平均耗時2.532μs，新建一個數據庫連接平均耗時15983.63μs；應用程序服務器完成實時傳感數據與歷史感知數據的比較運算平均耗時10227.3μs；系統(tǒng)理解完成功能，需要的時間窗口為10s，即當前時刻往前10s內的歷史記錄都有可能用到。

通過上面測試結果可知，我們需要設計一個數據實時處理方法來滿足系統(tǒng)要求，應重點解決如下三個問題：

1)閱讀器轉發(fā)數據速度很快，應用程序服務器需要準確實時地接收標簽數據，最小化數據丟失和延遲；

2)數據處理過程涉及到大量的數據庫及邏輯操作，需要提高數據查詢處理效率，滿足系統(tǒng)的實時性要求；

3)數據采集過程和數據處理過程應該相互獨立，以模塊化的原則設計一個接口來通信，避免數據間同步所帶來的開銷。

基于上述的考慮，我們設計的模型結構如圖2所示。整個數據處理流程劃分前后兩個階段，數據采集階段和數據處理階段。緩沖隊列為前后兩個階段的連接橋梁。數據采集階段專于標簽數據的采集。它維護著多個長連接線程，每個線程以TCP Socket方式與閱讀器通信，接收到的實時傳感數據直接存入緩沖隊列中而不作其它任何邏輯處理。數據處理階段專注于標簽數據的業(yè)務邏輯運算。根據系統(tǒng)測試結果，在標簽數據的處理周期中真正進行業(yè)務處理的時間只占整個周期的一部分（10227.3μs），大部分時間用在線程的建立與銷毀（3750.2μs）、數據庫連接的獲取與關閉（15983.63μs）上。為了提高數據處理效率及實現對象資源共享，我們利用池化技術維護著一個線程池和一個數據庫連接池來避免大量對象頻繁初始化及回收過程中的開銷。緩存隊列設計成FIFO（First In First Out）形式避免數據采集線程與數據處理線程所需的讀寫同步，數據采集線程從隊列尾部插入標簽數據，而數據處理線程從隊列頭部讀出標簽數據。

圖2 模型結構

1.2 多線程技術

應用程序服務器在數據采集階段和數據處理階段均使用到了多線程技術，但數據采集多線程與數據處理多線程存在顯著差別。數據采集多線程中的線程以TCP Socket方式與閱讀器通信，其生存周期與Socket鏈路連接周期相同，因而生存周期長。數據處理多線程設計的目的是利用并發(fā)提高數據處理的效率，單條標簽數據的處理周期往往比較短，可以通過采用線程池技術來實現資源復用。當緩沖隊列中有數據需要處理時，從線程池中提取線程進行業(yè)務操作，操作結束線程則返回線程池中，這樣避免了線程的頻繁建立與回收所帶來的開銷。

1.2.1 數據采集

數據采集多線程維護著一個管理線程和多個與閱讀器通信的連接線程。連接線程作為上位機終端以TCP Socket長連接方式介入閱讀器通信。在Socket通信中，閱讀器作為通信的服務端（Server），上位機作為通信的客戶端（Client），并管理連接。上位機與閱讀器以TCP長連接方式通信，一個連接鏈路上可以持續(xù)發(fā)送、接收標簽采集數據包。在TCP連接保持期間，為了避免鏈路斷開，采取在客戶端發(fā)送心跳包的方式。如果上位機5分鐘沒有收到閱讀器轉發(fā)的數據，則上位機給該閱讀器發(fā)送一個心跳包，然后等待閱讀器的返回信息。如果80秒內收不到閱讀器的應答，再發(fā)送第二個心跳包，如此連續(xù)8次，仍然沒有閱讀器的應答信號返回，則判斷此鏈路已經斷開，管理線程進行鏈路重連并將此鏈路異常寫入日志文件中。

1.2.2 數據處理

數據處理多線程維護著一個管理線程和一個線程池。管理線程創(chuàng)建、監(jiān)控線程池，掃描緩沖隊列，當緩沖隊列中有標簽數據時，則提取標簽數據分配給線程池中空閑的線程執(zhí)行。其工作時序如圖3所示。

圖3 數據處理多線程時序圖

相比于數據采集階段中相對固定的線程數目，閱讀器與連接線程個數比例為1:1，數據處理階段中線程池的線程個數具有很大伸縮空間。如果線程池太大，則池中線程不能充分利用，系統(tǒng)處理器及內存資源將因被用來維護線程池而非做實際業(yè)務操作造成資源的浪費；如果線程池太小，會出現緩沖隊列過長造成系統(tǒng)延遲嚴重，或者標簽數據來不及處理超出隊列長度，系統(tǒng)發(fā)生漏報甚至崩潰現象?；诖耍覀兲岢隽艘粋€具體的優(yōu)化方法來確定線程池的最佳大小。

用C1代表單個線程創(chuàng)建的開銷，用C2代表線程間切換的開銷，利用線程池技術能有效提高系統(tǒng)性能的理論基礎在于C1＞＞ C2[9]。當線程池中線程個數比較小時，增加線程能有效提高系統(tǒng)并發(fā)數據處理的能力，但如果線程數目過多，線程間切換開銷也隨之增大。Yibei Ling等人[10]研究表明，線程池中最佳線程數滿足如下關系：

上式中p(r)代表并發(fā)數據流的概率密度分布，n為線程池大小，最佳線程池大小不僅同C2與C1的比值相關，還同系統(tǒng)實際負載分布情況相關。

我們開發(fā)的母嬰安全監(jiān)護系統(tǒng)標簽個數N =50，標簽采樣間隔Ts = 0.6s，單個標簽在采樣周期內發(fā)射的時間點記為X，它是一個隨機變量服從均勻分布X ～ U(0,0.6)，期望值E(X)= 0.3，方差D(X)= 0.03。由于隨機變量X1,X2,…,Xn…相互獨立且服從同一分布，在N相對較大的情況下，根據中心極限定理，隨機變量之和 的標準化變量：

服從正態(tài)分布Yn～ N (0,1)，即，由系統(tǒng)測試結果可知，C1等于3750.2us，C2等于2.532us，C2與C1的比值為，因而（1）可以重新表達為：

通過查表可知N1=3.20，N2=3.21代入(3)式中，可知n為14，即線程池的最佳大小為14。

1.3 方法的緩存技術

本文研究的方法中使用兩種緩存技術，針對數據緩存的緩沖隊列和針對對象緩存的數據庫連接池。

1.3.1 緩沖隊列

為了消除階段間數據同步，實現數據采集過程與數據處理過程異步數據傳輸，我們建立了一個緩存容器。同時為了正確實時處理采集的數據，保證數據處理與數據采集的同序性。我們把緩存容器設計成隊列形式[11]，隊列是一種運算受限的線性數據結構，它只能從一端插入數據從另一端提取數據，滿足FIFO原則，其特性與數據采集處理特性相符合。緩沖隊列的主要屬性包括隊列長度，數據逗留時間，其管理圖如圖5所示。

圖4 FIFO緩存隊列管理圖

通過啟用一個管理線程實時監(jiān)控隊列的長度變化，當緩沖隊列長度達到最大閾值，管理線程增加處理線程數，當緩沖隊列長度到最小閾值時，管理線程會釋放多余的處理線程，此方法不僅能控制緩沖隊列的長度在最小閾值與最大閾值之間變化，還能滿足實時數據處理的實效性，提高系統(tǒng)的動態(tài)調控能力。

1.3.2 數據庫連接池

在數據流實時處理系統(tǒng)中，不可避免的涉及到大量的數據庫操作，應用程序服務器訪問數據庫分為四個步驟：1）應用程序服務器加載驅動程序；2）驅動程序管理器識別加載的驅動，獲取數據庫連接；3）根據獲取的數據庫連接對數據庫進行操作；4）關閉連接，釋放相關資源[12]。由我們的測試可知，數據庫連接的建立與關閉上耗時15983.63μs，比數據的比較運算10227.3μs還多。為了避免消耗大量資源的過程重復進行，我們使用數據庫連接池作為緩存對象池來解決大量線程頻繁訪問數據庫所帶來的效率問題。

數據庫連接池的技術原理如圖5所示。應用程序服務器在系統(tǒng)初始化時建立一些空閑連接放入連接池中備用，當線程有數據庫連接訪問請求時，直接從連接池申請一個數據庫連接，調用完成之后，把數據庫連接重新放入連接池中而不實際關閉。數據庫連接池中同樣存在管理器，當并發(fā)訪問量持續(xù)增加時，管理器建立一些新的數據庫連接放到連接池中。當訪問減少時，管理器則關閉一些空閑連接，避免空閑期間維護大量連接所帶來的資源消耗。

圖5 數據庫連接池技術原理圖

2 結果

為了評價數據實時處理方法的性能，我們對系統(tǒng)進行了仿真測試。使用三臺計算機搭建仿真測試平臺。應用程序服務器環(huán)境為上節(jié)中的系統(tǒng)測試環(huán)境。數據庫服務器的硬件配置為Intel Pentium D 2核2.8GHz CPU、2G內存、250G硬盤，操作系統(tǒng)為Centos 6.1、使用Mysql5.5.24作數據持久化數據庫。另外在一臺雙核4GB內存、Intel(R)Core(TM)i5 2.5GHz CPU的計算機模擬標簽數據流。仿真系統(tǒng)共有10個閱讀器、50個標簽，標簽間隔0.6s發(fā)送一條記錄，記錄大小為66B，標簽發(fā)送數據的起始時刻服從均勻分布。仿真測試平臺連接在局域網內。

應用程序和測試程序都使用Java語言開發(fā)，JDK版本為1.7.0，使用Eclipse IDE作為集成開發(fā)工具。在測試某個方法的優(yōu)化效果時，根據單一變量的原則，將測試代碼插入測試目標中，比較使用該方法和不使用該方法在同樣配置的計算機上前后性能指標的差異。我們主要比較了緩沖隊列、線程池和數據庫連接池三種技術，通過采用性能測試工具Java VisualVM來測量查看CPU及內存的使用率[13]。

表1 方法的性能測試

表1是方法的性能測試結果，我們從發(fā)射/接收數據包、接收成功率等性能指標進行評價。從上表中的測試結果可以看出：未使用三種技術時，CPU和內存的使用率都比較小，數據接收成功率很低，數據的轉發(fā)能力弱。由于標簽傳感數據發(fā)射速度很快，服務線程需要完成數據接收、數據處理、數據持久化等一系列工序，致使發(fā)射數據從Socket緩沖堆棧中溢出導致丟包。當我們在方法中加入緩沖隊列后，由于數據采集線程專于標簽數據的接收，數據的接收成功率有了大幅度提高。然而緩沖隊列中每一條數據都需要新開一個線程進行處理，線程處理完成該數據后又要進行資源回收，使得系統(tǒng)負荷大為增加，從而導致程序穩(wěn)定性很差，接收的標簽數據大部分都存入緩沖隊列中而來不及處理，延時非常厲害，從實用的角度來看，只使用緩沖隊列明顯不符合實際要求。為了避免資源重復分配、回收所帶來的開銷，利用對象資源池技術建立一個線程池，線程池中線程可以復用進行數據處理，從上面的測試結果可以看到，數據處理時間大為縮短，方法的實時性得到了明顯改善，緩沖隊列的長度也減小，數據轉發(fā)能力得到質的提高?；谕瑯拥览?，為了避免數據庫連接建立與關閉的開銷，我們引入數據庫連接池。使用數據庫連接之后，系統(tǒng)負荷（CPU峰值、CPU均值和內存均值）得到下降，數據包轉發(fā)能力接近理想值（83.33），緩沖隊列的長度也減小，證明了系統(tǒng)實時性得到了進一步提高。

3 結束語

本文研究開發(fā)的數據實時處理方法應用于醫(yī)院母嬰安全監(jiān)護系統(tǒng)，在實驗階段取得比較理想的結果，本文實現了如下創(chuàng)新：

1)分開數據采集過程與數據處理過程，整個流程劃分為前后兩個階段，階段內執(zhí)行流水線型操作，階段間使用緩沖隊列實現數據異步傳輸；

2)測試了系統(tǒng)創(chuàng)建線程、線程間切換和建立數據庫連接等操作的開銷，為系統(tǒng)進行模型設計打下數據基礎；

3)為了避免對象重復創(chuàng)立、回收帶來的系統(tǒng)開銷，我們設計實現了線程池，數據連接池，并從理論和實踐上證明了其有效性。

[1] 孫基男,黃雨,黃舒志,等. 一種基于 Petri 網的 RFID 事件檢測的形式化方法[J].計算機研究與發(fā)展,2012,49(11):2334-2343.

[2] 倪霖,鐘輝,段超.汽車制造生產線上RFID應用模式研究[J].計算機工程,2012,38(4):224-226.

[3] 廖燕.基于RFID的供應鏈管理信息系統(tǒng)集成[J].武漢理工大學學報: 信息與管理工程版,2010,32(004):610-613.

[4] 胡洋.RFID和AJAX 相結合的校園安全管理系統(tǒng)[J].計算機應用與軟件,2010,27(6):183-185.

[5] 于楠,胡金炎,鄒岸,王濤,等.一種母嬰安全監(jiān)護系統(tǒng)數據庫的設計和實現[J].計算機應用與軟件,2013,5(30):200-202.

[6] 袁文明,王東.網絡化RFID系統(tǒng)的復雜事件處理模型研究[J].計算機應用與軟件,2010,27(12):48-50.

[7] 亓開元,趙卓峰,房俊,等. 針對高速數據流的大規(guī)模數據實時處理方法[J].計算機學報,2012,35(3):477-490.

[8] 丁振華,李錦濤,羅海勇,等.RFID系統(tǒng)與傳感器網絡中的數據處理綜述[J].計算機應用研究,2008,25(3):660-664.

[9] KWAK H,LEE B,HURSON A R,et al.Effects of multithreading on cache performance[J].IEEE Transactions on Computers,1999,48(2):176-184.

[10] LING Y,MULLEN T,LIN X. Analysis of optimal thread pool size[J].ACM SIGOPS Operating Systems Review,2000,34(2):42-55.

[11] 崔慎智,陳志泊.基于多代理和多優(yōu)先隊列的短信實時并發(fā)算法[J].計算機工程,2011,37(3):278-280.

[12] 梁清翰,沈占鋒,駱劍承,等.構建LBS系統(tǒng)的數據庫連接池技術研究[J].計算機工程,2006,32(12):40-41.

[13] JUNEAU J,DEA C,GUIME F,et al. Debugging and Unit Testing[M].Java 7 Recipes. Apress,2011:213-236.