一種gps數據入庫處理方法和系統的制作方法

文檔序號：7811979閱讀：320來源：國知局

一種gps數據入庫處理方法和系統的制作方法
【專利摘要】本發(fā)明提供一種GPS數據入庫處理方法，通過I/O完成端口技術實現底層的通訊網關與TCP服務端之間傳輸GPS報文，使用報文任務池和工作線程池處理報文后分級緩存、批量寫入數據庫并完善錯誤處理。本發(fā)明的優(yōu)點在于，不僅提高了系統性能和數據傳輸量，而且避免了傳輸過程的數據堵塞，同時在實際應用中提升了對海量GPS數據處理的完整性。
【專利說明】一種GPS數據入庫處理方法和系統

【技術領域】
[0001] 本發(fā)明涉及一種數據入庫處理方法，更具體地說涉及一種海量GPS數據入庫的處理方法。

【背景技術】
[0002] 目前行業(yè)內，GPS數據處理入庫平臺所接入數量達到海量GPS報文數量級的比較少，一般是作為系統的一部分。對于接收報文、處理報文并展示到客戶端，現在并未將這個環(huán)節(jié)作為單獨的一個服務，劃分為整個大型系統中的一個重要模塊進行優(yōu)化，所以就會存在著一些缺陷?，F有技術存在的缺點有以下幾點：
[0003] 1、通訊網關接收到GPS終端的數據后，直接處理報文并入庫，處理報文和入庫的環(huán)節(jié)會占用大部分的資源，并容易因此阻塞接收的隊列，造成隊列滿，報文丟失，降低通訊網關接收終端報文的負載量；
[0004] 2、通訊網關直接入庫，中間環(huán)節(jié)需要緩存接收報文的隊列、處理報文的隊列、處理完等待入庫的數據的隊列，內存負荷很容易達到極限，影響處理數據的吞吐量；
[0005] 3、數據庫的連接數有限，連接數過多時，操作數據庫時可能產生資源沖突和競爭的機率越大，一個庫所能接入的入庫服務是有限的，通訊網關的數目受到限制，無法進行負載均衡。

【發(fā)明內容】

[0006] 本發(fā)明要解決的技術問題之一，在于提供一種GPS數據入庫處理方法，通過I/O 完成端口技術實現底層的通訊網關與TCP服務端之間傳輸GPS報文，并使用報文任務池和工作線程池處理報文后批量寫入數據庫并完善錯誤處理，不僅提高了系統性能和數據傳輸量，而且避免了傳輸過程的數據堵塞，同時在實際應用中提升了對海量GPS報文入庫錯誤處理的完整性。
[0007] 本發(fā)明要解決的技術問題之一，一種GPS數據入庫處理方法是這樣實現的：所述方法包括I/O完成端口技術傳輸GPS報文的過程、報文任務池和工作線程池處理GPS報文的過程、GPS報文入庫的過程和完善GPS報文入庫錯誤處理的過程：
[0008] 所述I/O完成端口技術傳輸GPS報文的過程是：通訊網關作為客戶端，將GPS報文封裝在復數個數據傳輸socket中，GPS數據入庫處理系統作為TCP服務端，客戶端將所述復數個數據傳輸socket通過計算機的端口發(fā)送到TCP服務端完成GPS報文的接收，具體步驟如下：
[0009] 步驟11、初始化后，在所述服務端上創(chuàng)建一偵聽socket,并將所述偵聽socket與服務端的一個端口綁定，以便實現GPS報文的一對多傳輸；
[0010] 步驟12、在TCP服務端上創(chuàng)建一個SocketAsyncEventArgs類的連接對象，將所述連接對象與所述偵聽socket綁定，所述連接對象開始異步檢測與其綁定的端口中是否有數據傳輸socket接入：當有一個所述數據傳輸socket請求連接時，所述連接對象就接入該數據傳輸socket，而所述偵聽socket則繼續(xù)檢測與其綁定的端口；
[0011] 步驟13、在TCP服務端上創(chuàng)建一個SocketAsyncEventArgs類的接收對象，所述接收對象與接入的數據傳輸socket進行綁定，并開始接收GPS報文：若接收到的GPS報文的數據長度等于零，則關閉對應接入的數據傳輸socket并釋放與其綁定的接收對象；若接收到的GPS報文的數據長度大于零，則進行粘包處理：如果接收到的GPS報文的數據包是完整的，直接放入報文緩沖隊列，如果接收到的GPS報文的數據包是不完整的，則先放入接收緩沖區(qū)等待繼續(xù)接收直至數據包完整再放入報文緩沖隊列；
[0012] 步驟14、TCP服務端收到GPS報文后，根據所接收GPS報文的先后順序依次做出收包正常的應答返回給客戶端；
[0013] 所述報文任務池和工作線程池處理GPS報文的過程包括：
[0014] 步驟21、在TCP服務端上創(chuàng)建復數個報文解析線程對報文緩沖隊列中的GPS報文進行解析，根據解析得到的不同類型，所述報文解析線程將各不同類型的GPS報文放入到報文任務池的復數個報文隊列中，所述復數個報文隊列與各不同類型的GPS報文一一對應；
[0015] 步驟22、所述報文任務池的各報文隊列均采用雙緩沖概念實現讀寫分離：各報文隊列均對應兩個任務池緩存區(qū)，分別是任務池緩存區(qū)1和任務池緩存區(qū)2,先將各報文隊列中的GPS報文寫入與其對應的任務池緩存區(qū)1，當GPS報文入庫處理比較慢或者TCP服務端連接數非常多的情況下，任務池緩存區(qū)1內的GPS報文會慢慢堆積，達到最大值，這時各報文隊列中余下的GPS報文會寫入到與其對應的任務池緩存區(qū)2,最后從各報文隊列對應的任務池緩存區(qū)1和任務池緩存區(qū)2中批量讀取出GPS報文，對應寫入到各報文隊列的緩存文件中；
[0016] 步驟23、所述工作線程池根據報文任務池中不同類型的報文隊列相應配置至少一個工作處理線程，工作處理線程負責將步驟22所述各報文隊列對應的緩存文件中的GPS報文讀取出來并進行相應的處理；
[0017] 所述GPS報文入庫的過程是：TCP服務器調用數據訪問層，批量寫入所述處理好的 GPS報文到數據庫；
[0018] 所述完善GPS報文入庫錯誤處理的過程：
[0019] 在GPS報文入庫時，若出現SQL語句執(zhí)行出錯，將執(zhí)行錯誤的GPS報文寫入到報文任務池中的錯誤緩存隊列進行處理：如果遇到的是網絡問題，則再重復執(zhí)行該所述SQL語句兩次，仍然錯誤的情況下，在系統中創(chuàng)建錯誤緩存文件，將GPS報文寫入所述錯誤緩存文件中，如果是該所述SQL語句本身有問題，則直接將GPS報文寫入錯誤緩存文件，以備回收或者用戶排查錯誤原因。
[0020] 進一步的，所述報文任務池的各報文隊列處理GPS報文數量超過與其對應的兩個任務池緩存區(qū)的容量時，各報文隊列中等待入庫的GPS報文先寫入到各報文隊列的緩存文件中，通過創(chuàng)建監(jiān)測線程定時讀取系統CPU的占用情況：當系統CPU占用率低于百分之二十時，利用信號量來通知工作處理線程回收所述各報文隊列對應的緩存文件。
[0021] 進一步的，所述方法中還包括報警短信服務，所述工作處理線程將GPS報文中的報警報文解析出來后，根據用戶設定的報警條件判斷是否需要報警，如果滿足報警條件，則發(fā)送報警短信給對應的聯系人。
[0022] 進一步的，所述方法中還包括日志查看，在整個GPS報文入庫過程中，用戶都可以查看日志，所述日志分為主日志、報警短信日志、緩存回收日志和錯誤處理日志，把它們按日期分文件夾保存，這樣分開保存、分開查看，既減少用戶檢索日志的時間又方便查看日志的詳細信息。
[0023] 本發(fā)明要解決的技術問題之二，在于提供一種GPS數據入庫處理系統，通過I/O 完成端口技術實現底層的通訊網關與TCP服務端之間傳輸GPS報文，并使用報文任務池和工作線程池處理報文后批量寫入數據庫并完善錯誤處理，不僅提高了系統性能和數據傳輸量，而且避免了傳輸過程的數據堵塞，同時在實際應用中提升了對海量GPS報文入庫錯誤處理的完整性。
[0024] 本發(fā)明要解決的技術問題之二，一種GPS數據入庫處理系統是這樣實現的：所述系統包括TCP報文接收模塊、報文處理模塊、數據入庫模塊和錯誤處理模塊：
[0025] 所述TCP報文接收模塊：通過I/O完成端口技術傳輸GPS報文：通訊網關作為客戶端，將GPS報文封裝在復數個數據傳輸socket中，GPS數據入庫處理系統作為TCP服務端，客戶端將所述復數個數據傳輸socket通過計算機的端口發(fā)送到TCP服務端完成GPS報文的接收，具體步驟如下：
[0026] 步驟11、初始化后，在所述服務端上創(chuàng)建一偵聽socket,并將所述偵聽socket與服務端的一個端口綁定，以便實現GPS報文的一對多傳輸；
[0027] 步驟12、在TCP服務端上創(chuàng)建一個SocketAsyncEventArgs類的連接對象，將所述連接對象與所述偵聽socket綁定，所述連接對象開始異步檢測與其綁定的端口中是否有數據傳輸socket接入：當有一個所述數據傳輸socket請求連接時，所述連接對象就接入該數據傳輸socket，而所述偵聽socket則繼續(xù)檢測與其綁定的端口；
[0028] 步驟13、在TCP服務端上創(chuàng)建一個SocketAsyncEventArgs類的接收對象，所述接收對象與接入的數據傳輸socket進行綁定，并開始接收GPS報文：若接收到的GPS報文的數據長度等于零，則關閉對應接入的數據傳輸socket并釋放與其綁定的接收對象；若接收到的GPS報文的數據長度大于零，則進行粘包處理：如果接收到的GPS報文的數據包是完整的，直接放入報文緩沖隊列，如果接收到的GPS報文的數據包是不完整的，則先放入接收緩沖區(qū)等待繼續(xù)接收直至數據包完整再放入報文緩沖隊列；
[0029] 步驟14、TCP服務端收到GPS報文后，根據所接收GPS報文的先后順序依次做出收包正常的應答返回給客戶端；
[0030] 所述報文處理模塊：通過報文任務池和工作線程池處理GPS報文，具體包括：
[0031] 步驟21、在TCP服務端上創(chuàng)建復數個報文解析線程對報文緩沖隊列中的GPS報文進行解析，根據解析得到的不同類型，所述報文解析線程將各不同類型的GPS報文放入到報文任務池的復數個報文隊列中，所述復數個報文隊列與各不同類型的GPS報文一一對應；
[0032] 步驟22、所述報文任務池的各報文隊列均采用雙緩沖概念實現讀寫分離：各報文隊列均對應兩個任務池緩存區(qū)，分別是任務池緩存區(qū)1和任務池緩存區(qū)2,先將各報文隊列中的GPS報文寫入與其對應的任務池緩存區(qū)1，當GPS報文入庫處理比較慢或者TCP服務端連接數非常多的情況下，任務池緩存區(qū)1內的GPS報文會慢慢堆積，達到最大值，這時各報文隊列中余下的GPS報文會寫入到與其對應的任務池緩存區(qū)2,最后從各報文隊列對應的任務池緩存區(qū)1和任務池緩存區(qū)2中批量讀取出GPS報文，對應寫入到各報文隊列對應的緩存文件中；
[0033] 步驟23、所述工作線程池根據報文任務池中不同類型的報文隊列相應配置至少一個工作處理線程，工作處理線程負責將步驟22所述各報文隊列的緩存文件中的GPS報文讀取出來并進行相應的處理；
[0034] 所述數據入庫模塊：TCP服務端調用數據訪問層，批量寫入GPS報文到數據庫；
[0035] 所述錯誤處理模塊：在GPS報文入庫時，若出現SQL語句執(zhí)行出錯，將執(zhí)行錯誤的 GPS報文寫入到報文任務池中的錯誤緩存隊列進行處理：如果遇到的是網絡問題，則再重復執(zhí)行該所述SQL語句兩次，仍然錯誤的情況下，在系統中創(chuàng)建錯誤緩存文件，將GPS報文寫入所述錯誤緩存文件中，如果是該所述SQL語句本身有問題，則直接將GPS報文寫入錯誤緩存文件，以備回收或者用戶排查錯誤原因。
[0036] 進一步的，所述報文任務池的各報文隊列處理GPS報文數量超過與其對應的兩個任務池緩存區(qū)的容量時，各報文隊列中等待入庫的GPS報文先寫入到各報文隊列的緩存文件中，通過創(chuàng)建監(jiān)測線程定時讀取系統CPU的占用情況：當系統CPU占用率低于百分之二十時，利用信號量來通知工作處理線程回收所述各報文隊列對應的緩存文件。
[0037] 進一步的，所述系統中還包括報警短信服務模塊：所述工作處理線程將GPS報文中的報警報文解析出來后，根據用戶設定的報警條件判斷是否需要報警，如果滿足報警條件，則發(fā)送報警短信給對應的聯系人。
[0038] 進一步的，所述系統中還包括日志模塊，在整個GPS報文入庫過程中，用戶都可以查看日志，所述日志分為主日志、報警短信日志、緩存回收日志和錯誤處理日志，把它們按日期分文件夾保存，這樣分開保存、分開查看，既減少用戶檢索日志的時間又方便查看日志的詳細信息。
[0039] 本發(fā)明具有如下優(yōu)點：
[0040] 1、通過I/O完成端口技術實現通訊網關與TCP服務端之間傳輸GPS報文：提高了系統性能和傳輸數據的吞吐量，可以支持一對多的架構，便于底層平臺擴展，實現負載均衡；
[0041] 2、使用報文任務池和工作線程池：避免了處理報文環(huán)節(jié)引起的傳輸環(huán)節(jié)的數據堵塞，提高系統吞吐量；線程數目可以根據需要配置，最大程度的利用服務器資源；可以縮短任務請求的響應時間；
[0042] 3、分級緩存，批量寫入機制：降低了對數據庫的訪問頻率，也提高了入庫的效率；
[0043] 4、錯誤緩存機制：便于事后故障原因分析和排查，提升了在實際應用中對海量 GPS數據處理的完整性。

【專利附圖】

【附圖說明】
[0044] 下面參照附圖結合實施例對本發(fā)明作進一步的說明。
[0045] 圖1為本發(fā)明系統的應用示意圖。
[0046] 圖2為本發(fā)明方法的GPS報文接收流程圖。
[0047] 圖3為本發(fā)明方法一實施例粘包算法示意圖。
[0048] 圖4為本發(fā)明方法的數據處理與入庫示意圖。
[0049] 圖5為本發(fā)明方法一實施例寫入GPS報文示意圖。
[0050] 圖6為本發(fā)明方法一實施例讀取GPS報文示意圖。

【具體實施方式】
[0051] 請參照圖1所示的系統應用示意圖，本發(fā)明一種GPS數據入庫處理系統，可以接收來自通訊網關的GPS報文并進行處理后再放入數據庫，該系統廣泛應用于各種車載系統中。
[0052] 本發(fā)明一種GPS數據入庫處理方法具體包括：I/O完成端口技術傳輸GPS報文的過程、報文任務池和工作線程池處理GPS報文的過程、GPS報文入庫的過程和完善GPS報文入庫錯誤處理的過程：
[0053] 所述I/O完成端口技術傳輸GPS報文的過程是：通訊網關作為客戶端，將GPS報文封裝在復數個數據傳輸socket中，GPS數據入庫處理系統作為TCP服務端，客戶端將所述復數個數據傳輸socket通過計算機的端口發(fā)送到TCP服務端完成GPS報文的接收，具體步驟如圖2所示：
[0054] 步驟11、初始化后，在所述服務端上創(chuàng)建一偵聽socket,并將所述偵聽socket與服務端的一個端口綁定，以便實現GPS報文的一對多傳輸；
[0055] 步驟12、在TCP服務端上創(chuàng)建一個SocketAsyncEventArgs類（所述 SocketAsyncEventArgs類是· NET中封裝的異步socket類）的連接對象（所述連接對象可以是acceptEventArgs對象），將所述連接對象與所述偵聽socket綁定，所述連接對象開始異步檢測與其綁定的端口中是否有數據傳輸socket接入：當有一個所述數據傳輸socket 請求連接時，所述連接對象就接入該數據傳輸socket,而所述偵聽socket則繼續(xù)檢測與其綁定的端口；
[0056] 步驟13、在TCP服務端上創(chuàng)建一個SocketAsyncEventArgs類的接收對象（所述接收對象可以是ReceiveEventArgs對象），所述接收對象與接入的數據傳輸socket進行綁定，并開始接收GPS報文：若接收到的GPS報文的數據長度等于零，則關閉對應接入的數據傳輸socket并釋放與其綁定的接收對象；若接收到的GPS報文的數據長度大于零，則進行粘包處理：如果接收到的GPS報文的數據包是完整的，直接放入報文緩沖隊列，如果接收到的GPS報文的數據包是不完整的，則先放入接收緩沖區(qū)等待繼續(xù)接收直至數據包完整再放入報文緩沖隊列；
[0057] 在本實施例中，所述粘包處理采用分包算法，主要過程如圖3所示：
[0058] 所述接收對象的緩沖區(qū)初始值設為4M，包括接收緩沖區(qū)和未使用區(qū)域，整個緩沖區(qū)的大小可以根據操作系統及系統內存來調整。將接收對象的接收緩存區(qū)接收到的數據按照開始位置和偏移量將數據取出，找到包頭標識及包長，按照包長進行分包，將完整的數據包放入到數據包緩沖隊列，如果還有剩余數據，循環(huán)的按照這個步驟分包，直至到達所述緩沖區(qū)偏移量的位置：如果剛好數據是復數個完整的包，設置接收對象的接收緩沖區(qū)的接收起始位置為〇,否則將未接收完整的包（殘包）拷貝到接收緩沖區(qū)的起始位置，設置起始位置為殘包的長度，設置接收緩沖區(qū)大小為：緩沖區(qū)實際大小減去殘包長度；然后繼續(xù)接收，繼續(xù)進行上述的分包步驟。因為在TCP傳輸過程中，發(fā)送方發(fā)送的若干數據到接收方接收時通常會粘成一包，所以需要進行粘包處理；
[0059] 步驟14、TCP服務端收到GPS報文后，根據所接收GPS報文的先后順序依次做出收包正常的應答返回給客戶端；
[0060] 請參照圖4,所述報文任務池和工作線程池處理GPS報文的過程如下：
[0061] 步驟21、在TCP服務端上創(chuàng)建復數個報文解析線程對報文緩沖隊列中的GPS報文進行解析，根據解析得到的不同類型，所述報文解析線程將各不同類型的GPS報文放入到報文任務池的復數個報文隊列中，所述復數個報文隊列與各不同類型的GPS報文一一對應；
[0062] 如圖4所示，以創(chuàng)建四個報文解析線程為例，在TCP服務端上創(chuàng)建四個報文解析線程對接收到的GPS報文進行解析，根據解析得到的不同類型，所述報文解析線程將各不同類型的GPS報文放入到報文任務池對應的報文隊列中，包括定位報文隊列、報警報文隊列、應答報文隊列、外設報文隊列和自檢報文隊列等；
[0063] 步驟22、所述報文任務池的各報文隊列均采用雙緩沖概念實現讀寫分離：各報文隊列均對應兩個任務池緩存區(qū)，分別是任務池緩存區(qū)1和任務池緩存區(qū)2,先將各報文隊列中的GPS報文寫入與其對應的任務池緩沖區(qū)1，當GPS報文入庫處理比較慢或者TCP服務端連接數非常多的情況下，任務池緩存區(qū)1內的GPS報文會慢慢堆積，達到最大值，這時各報文隊列中余下的GPS報文會寫入到與其對應的任務池緩存區(qū)2,最后從各報文隊列對應的任務池緩存區(qū)1和任務池緩存區(qū)2中批量讀取出GPS報文，對應寫入到各報文隊列的緩存文件中；
[0064] 現舉例說明一報文隊列通過兩個任務池緩存區(qū)實現寫入GPS報文和讀取GPS報文過程：
[0065] 所述寫入GPS報文的過程如圖5所示：
[0066] 步驟221、先設置任務池緩存區(qū)序號bufflD ;
[0067] 步驟222、若bufflD = 1，將報文隊列中的GPS報文添加到任務池緩存區(qū)1，當任務池緩存區(qū)1內的GPS報文達到最大值時，設置bufflD = 2,此時報文隊列中余下的GPS報文會寫入到任務池緩存區(qū)2中；若bufflD = 2,將報文隊列中的GPS報文添加到任務池緩存區(qū)2,當任務池緩存區(qū)2內的GPS報文達到最大值時，設置bufflD = 1，此時報文隊列中余下的GPS報文會寫入到任務池緩存區(qū)1中；
[0068] 步驟223、寫入完GPS報文后設置寫緩存線程信號量；
[0069] 所述讀取GPS報文過程如圖6所示：
[0070] 步驟224、讀取寫緩存線程信號量；
[0071] 步驟225、若bufflD = 2,讀取任務池緩存區(qū)1內的GPS報文，若bufflD = 1，讀取任務池緩存區(qū)2內的GPS報文；
[0072] 步驟226、將從兩個任務池緩存區(qū)內取出的GPS報文寫入到報文隊列的緩存文件中；
[0073] 步驟227、獲取所述報文隊列的緩存文件名稱；
[0074] 步驟228、依據報文隊列的緩存文件名稱判斷該緩存目錄所在的磁盤空間容量，若所述容量小于等于100M，則發(fā)送告警郵件并丟棄該緩存文件中的GPS報文，若所述容量大于100M，則仍然將GPS報文寫入到報文隊列的緩存文件中；
[0075] 但是，當報文任務池的各報文隊列處理GPS報文數量超過與其對應的兩個任務池緩存區(qū)的容量時，各報文隊列中等待入庫的GPS報文先寫入到各報文隊列的緩存文件中，通過創(chuàng)建監(jiān)測線程定時讀取系統CPU的占用情況：當系統CPU占用率低于百分之二十時，利用信號量來通知工作處理線程回收所述各報文隊列對應的緩存文件；
[0076] 步驟23、所述工作線程池根據報文任務池中不同類型的報文隊列相應配置至少一個工作處理線程，例如定位報文隊列配置八個定位報文處理線程，報警報文隊列配置四個報警報文處理線程等（請參閱圖4);工作處理線程負責將步驟22所述各報文隊列對應的緩存文件中的GPS報文讀取出來并進行相應的處理，例如報警報文，工作線程將報警報文解析出來后根據用戶設定的報警條件判斷是否需要下發(fā)報警，如果需要，則發(fā)送報警短信給對應的聯系人；
[0077] 所述GPS報文入庫的過程是：TCP服務器調用數據訪問層，批量寫入所述處理好的 GPS報文到數據庫；
[0078] 所述完善GPS報文入庫錯誤處理的過程：
[0079] 在GPS報文入庫時，若出現SQL語句執(zhí)行出錯，將執(zhí)行錯誤的GPS報文寫入到報文任務池中的錯誤緩存隊列進行處理：如果遇到的是網絡問題，則再重復執(zhí)行該所述SQL語句兩次，仍然錯誤的情況下，在系統中創(chuàng)建錯誤緩存文件，將GPS報文寫入所述錯誤緩存文件中，如果是該所述SQL語句本身有問題，則直接將GPS報文寫入錯誤緩存文件，以備回收或者用戶排查錯誤原因。
[0080] 在整個GPS報文入庫過程中，用戶都可以查看日志，所述日志分為主日志、報警短信日志、緩存回收日志和錯誤處理日志，把它們按日期分文件夾保存，這樣分開保存、分開查看，既減少用戶檢索日志的時間又方便查看日志的詳細信息。
[0081] 基于以上方法，本發(fā)明一種GPS數據入庫處理系統，包括TCP報文接收模塊、報文處理模塊、數據入庫模塊和錯誤處理模塊：
[0082] 所述TCP報文接收模塊：通過I/O完成端口技術傳輸GPS報文：通訊網關作為客戶端，將GPS報文封裝在復數個數據傳輸socket中，GPS數據入庫處理系統作為TCP服務端，客戶端將所述復數個數據傳輸socket通過計算機的端口發(fā)送到TCP服務端完成GPS報文的接收，具體步驟如下：
[0083] 步驟11、初始化后，在所述服務端上創(chuàng)建一偵聽socket,并將所述偵聽socket與服務端的一個端口綁定，以便實現GPS報文的一對多傳輸；
[0084] 步驟12、在TCP服務端上創(chuàng)建一個SocketAsyncEventArgs類的連接對象，將所述連接對象與所述偵聽socket綁定，所述連接對象開始異步檢測與其綁定的端口中是否有數據傳輸socket接入：當有一個所述數據傳輸socket請求連接時，所述連接對象就接入該數據傳輸socket，而所述偵聽socket則繼續(xù)檢測與其綁定的端口；
[0085] 步驟13、在TCP服務端上創(chuàng)建一個SocketAsyncEventArgs類的接收對象，所述接收對象與接入的數據傳輸socket進行綁定，并開始接收GPS報文：若接收到的GPS報文的數據長度等于零，則關閉對應接入的數據傳輸socket并釋放與其綁定的接收對象；若接收到的GPS報文的數據長度大于零，則進行粘包處理：如果接收到的GPS報文的數據包是完整的，直接放入報文緩沖隊列，如果接收到的GPS報文的數據包是不完整的，則先放入接收緩沖區(qū)等待繼續(xù)接收直至數據包完整再放入報文緩沖隊列；
[0086] 步驟14、TCP服務端收到GPS報文后，根據所接收GPS報文的先后順序依次做出收包正常的應答返回給客戶端；
[0087] 所述報文處理模塊：通過報文任務池和工作線程池處理GPS報文，具體包括：
[0088] 步驟21、在TCP服務端上創(chuàng)建復數個報文解析線程對報文緩沖隊列中的GPS報文進行解析，根據解析得到的不同類型，所述報文解析線程將各不同類型的GPS報文放入到報文任務池的復數個報文隊列中，所述復數個報文隊列與各不同類型的GPS報文一一對應；
[0089] 步驟22、所述報文任務池的各報文隊列均采用雙緩沖概念實現讀寫分離：各報文隊列均對應兩個任務池緩存區(qū)，分別是任務池緩存區(qū)1和任務池緩存區(qū)2,先將各報文隊列中的GPS報文寫入與其對應的任務池緩存區(qū)1，當GPS報文入庫處理比較慢或者TCP服務端連接數非常多的情況下，任務池緩存區(qū)1內的GPS報文會慢慢堆積，達到最大值，這時各報文隊列中余下的GPS報文會寫入到與其對應的任務池緩存區(qū)2,最后從各報文隊列對應的任務池緩存區(qū)1和任務池緩存區(qū)2中批量讀取出GPS報文，對應寫入到各報文隊列的緩存文件中；
[0090] 但是，當報文任務池的各報文隊列處理GPS報文數量超過與其對應的兩個任務池緩存區(qū)的容量時，各報文隊列中等待入庫的GPS報文先寫入到各報文隊列的緩存文件中，通過創(chuàng)建監(jiān)測線程定時讀取系統CPU的占用情況：當系統CPU占用率低于百分之二十時，利用信號量來通知工作處理線程回收所述各報文隊列對應的緩存文件；
[0091] 步驟23、所述工作線程池根據報文任務池中不同類型的報文隊列相應配置至少一個工作處理線程，工作處理線程負責將步驟22所述各報文隊列對應的緩存文件中的GPS報文讀取出來并進行相應的處理；
[0092] 所述數據入庫模塊：TCP服務端調用數據訪問層，批量寫入GPS報文到數據庫；
[0093] 所述錯誤處理模塊：在GPS報文入庫時，若出現SQL語句執(zhí)行出錯，將執(zhí)行錯誤的 GPS報文寫入到報文任務池中的錯誤緩存隊列進行處理：如果遇到的是網絡問題，則再重復執(zhí)行該所述SQL語句兩次，仍然錯誤的情況下，在系統中創(chuàng)建錯誤緩存文件，將GPS報文寫入所述錯誤緩存文件中，如果是該所述SQL語句本身有問題，則直接將GPS報文寫入錯誤緩存文件，以備回收或者用戶排查錯誤原因。
[0094] 報警短信服務模塊：所述工作處理線程將GPS報文中的報警報文解析出來后，根據用戶設定的報警條件判斷是否需要報警，如果滿足報警條件，則發(fā)送報警短信給對應的聯系人。
[0095] 日志模塊：在整個GPS報文入庫過程中，用戶都可以查看日志，所述日志分為主日志、報警短信日志、緩存回收日志和錯誤處理日志，把它們按日期分文件夾保存，這樣分開保存、分開查看，既減少用戶檢索日志的時間又方便查看日志的詳細信息。
[0096] 雖然以上描述了本發(fā)明的【具體實施方式】，但是熟悉本【技術領域】的技術人員應當理解，我們所描述的具體的實施例只是說明性的，而不是用于對本發(fā)明的范圍的限定，熟悉本領域的技術人員在依照本發(fā)明的精神所作的等效的修飾以及變化，都應當涵蓋在本發(fā)明的權利要求所保護的范圍內。
【權利要求】
1. 一種GPS數據入庫處理方法，其特征在于，所述方法包括I/O完成端口技術傳輸GPS 報文的過程、報文任務池和工作線程池處理GPS報文的過程、GPS報文入庫的過程和完善 GPS報文入庫錯誤處理的過程：所述I/O完成端口技術傳輸GPS報文的過程是：通訊網關作為客戶端，將GPS報文封裝在復數個數據傳輸socket中，GPS數據入庫處理系統作為TCP服務端，客戶端將所述復數個數據傳輸socket通過計算機的端口發(fā)送到TCP服務端完成GPS報文的接收，具體步驟如下：步驟11、初始化后，在所述服務端上創(chuàng)建一偵聽socket，并將所述偵聽socket與服務端的一個端口綁定，以便實現GPS報文的一對多傳輸；步驟12、在TCP服務端上創(chuàng)建一個SocketAsyncEventArgs類的連接對象，將所述連接對象與所述偵聽socket綁定，所述連接對象開始異步檢測與其綁定的端口中是否有數據傳輸socket接入：當有一個所述數據傳輸socket請求連接時，所述連接對象就接入該數據傳輸socket,而所述偵聽socket則繼續(xù)檢測與其綁定的端口；步驟13、在TCP服務端上創(chuàng)建一個SocketAsyncEventArgs類的接收對象，所述接收對象與接入的數據傳輸socket進行綁定，并開始接收GPS報文：若接收到的GPS報文的數據長度等于零，則關閉對應接入的數據傳輸socket并釋放與其綁定的接收對象；若接收到的 GPS報文的數據長度大于零，則進行粘包處理：如果接收到的GPS報文的數據包是完整的，直接放入報文緩沖隊列，如果接收到的GPS報文的數據包是不完整的，則先放入接收緩沖區(qū)等待繼續(xù)接收直至數據包完整再放入報文緩沖隊列；步驟14、TCP服務端收到GPS報文后，根據所接收GPS報文的先后順序依次做出收包正常的應答返回給客戶端；所述報文任務池和工作線程池處理GPS報文的過程包括：步驟21、在TCP服務端上創(chuàng)建復數個報文解析線程對報文緩沖隊列中的GPS報文進行解析，根據解析得到的不同類型，所述報文解析線程將各不同類型的GPS報文放入到報文任務池的復數個報文隊列中，所述復數個報文隊列與各不同類型的GPS報文一一對應；步驟22、所述報文任務池的各報文隊列均采用雙緩沖概念實現讀寫分離：各報文隊列均對應兩個任務池緩存區(qū)，分別是任務池緩存區(qū)1和任務池緩存區(qū)2,先將各報文隊列中的 GPS報文寫入與其對應的任務池緩存區(qū)1，當GPS報文入庫處理比較慢或者TCP服務端連接數非常多的情況下，任務池緩存區(qū)1內的GPS報文會慢慢堆積，達到最大值，這時各報文隊列中余下的GPS報文會寫入到與其對應的任務池緩存區(qū)2,最后從各報文隊列對應的任務池緩存區(qū)1和任務池緩存區(qū)2中批量讀取出GPS報文，對應寫入到各報文隊列的緩存文件中；步驟23、所述工作線程池根據報文任務池中不同類型的報文隊列相應配置至少一個工作處理線程，工作處理線程負責將步驟22所述各報文隊列對應的緩存文件中的GPS報文讀取出來并進行相應的處理；所述GPS報文入庫的過程是：TCP服務器調用數據訪問層，批量寫入所述處理好的GPS 報文到數據庫；所述完善GPS報文入庫錯誤處理的過程：在GPS報文入庫時，若出現SQL語句執(zhí)行出錯，將執(zhí)行錯誤的GPS報文寫入到報文任務池中的錯誤緩存隊列進行處理：如果遇到的是網絡問題，則再重復執(zhí)行該所述SQL語句兩次，仍然錯誤的情況下，在系統中創(chuàng)建錯誤緩存文件，將GPS報文寫入所述錯誤緩存文件中，如果是該所述SQL語句本身有問題，則直接將GPS報文寫入錯誤緩存文件，以備回收或者用戶排查錯誤原因。
2. 根據權利要求1所述的一種GPS數據入庫處理方法，其特征在于：所述步驟22還包括，當報文任務池的各報文隊列處理GPS報文數量超過與其對應的兩個任務池緩存區(qū)的容量時，各報文隊列中等待入庫的GPS報文先寫入到各報文隊列的緩存文件中，通過創(chuàng)建監(jiān) 測線程定時讀取系統CPU的占用情況：當系統CPU占用率低于百分之二十時，利用信號量來通知工作處理線程回收所述各報文隊列對應的緩存文件。
3. 根據權利要求1所述的一種GPS數據入庫處理方法，其特征在于：所述步驟23包括報警短信服務：所述工作處理線程將GPS報文中的報警報文解析出來后，根據用戶設定的報警條件判斷是否需要報警，如果滿足報警條件，則發(fā)送報警短信給對應的聯系人。
4. 根據權利要求1所述的一種GPS數據入庫處理方法，其特征在于：在整個GPS報文入庫過程中，用戶都能查看日志，所述日志分為主日志、報警短信日志、緩存回收日志和錯誤處理日志，把它們按日期分文件夾保存，這樣分開保存、分開查看，既減少用戶檢索日志的時間又方便查看日志的詳細信息。
5. -種GPS數據入庫處理系統，其特征在于：所述系統包括TCP報文接收模塊、報文處理模塊、數據入庫模塊和錯誤處理模塊：所述TCP報文接收模塊：通過I/O完成端口技術傳輸GPS報文：通訊網關作為客戶端，將GPS報文封裝在復數個數據傳輸socket中，GPS數據入庫處理系統作為TCP服務端，客戶端將所述復數個數據傳輸socket通過計算機的端口發(fā)送到TCP服務端完成GPS報文的接收，具體步驟如下：步驟11、初始化后，在所述服務端上創(chuàng)建一偵聽socket，并將所述偵聽socket與服務端的一個端口綁定，以便實現GPS報文的一對多傳輸；步驟12、在TCP服務端上創(chuàng)建一個SocketAsyncEventArgs類的連接對象，將所述連接對象與所述偵聽socket綁定，所述連接對象開始異步檢測與其綁定的端口中是否有數據傳輸socket接入：當有一個所述數據傳輸socket請求連接時，所述連接對象就接入該數據傳輸socket,而所述偵聽socket則繼續(xù)檢測與其綁定的端口；步驟13、在TCP服務端上創(chuàng)建一個SocketAsyncEventArgs類的接收對象，所述接收對象與接入的數據傳輸socket進行綁定，并開始接收GPS報文：若接收到的GPS報文的數據長度等于零，則關閉對應接入的數據傳輸socket并釋放與其綁定的接收對象；若接收到的 GPS報文的數據長度大于零，則進行粘包處理：如果接收到的GPS報文的數據包是完整的，直接放入報文緩沖隊列，如果接收到的GPS報文的數據包是不完整的，則先放入接收緩沖區(qū)等待繼續(xù)接收直至數據包完整再放入報文緩沖隊列；步驟14、TCP服務端收到GPS報文后，根據所接收GPS報文的先后順序依次做出收包正常的應答返回給客戶端；所述報文處理模塊：通過報文任務池和工作線程池處理GPS報文，具體包括：步驟21、在TCP服務端上創(chuàng)建復數個報文解析線程對報文緩沖隊列中的GPS報文進行解析，根據解析得到的不同類型，所述報文解析線程將各不同類型的GPS報文放入到報文任務池的復數個報文隊列中，所述復數個報文隊列與各不同類型的GPS報文一一對應；步驟22、所述報文任務池的各報文隊列均采用雙緩沖概念實現讀寫分離：各報文隊列均對應兩個任務池緩存區(qū)，分別是任務池緩存區(qū)1和任務池緩存區(qū)2,先將各報文隊列中的 GPS報文寫入與其對應的任務池緩存區(qū)1，當GPS報文入庫處理比較慢或者TCP服務端連接數非常多的情況下，任務池緩存區(qū)1內的GPS報文會慢慢堆積，達到最大值，這時各報文隊列中余下的GPS報文會寫入到與其對應的任務池緩存區(qū)2,最后從各報文隊列對應的任務池緩存區(qū)1和任務池緩存區(qū)2中批量讀取出GPS報文，對應寫入到各報文隊列的緩存文件中；步驟23、所述工作線程池根據報文任務池中不同類型的報文隊列相應配置至少一個工作處理線程，工作處理線程負責將步驟22所述各報文隊列對應的緩存文件中的GPS報文讀取出來并進行相應的處理；所述數據入庫模塊：TCP服務端調用數據訪問層，批量寫入GPS報文到數據庫；所述錯誤處理模塊：在GPS報文入庫時，若出現SQL語句執(zhí)行出錯，將執(zhí)行錯誤的GPS 報文寫入到報文任務池中的錯誤緩存隊列進行處理：如果遇到的是網絡問題，則再重復執(zhí) 行該所述SQL語句兩次，仍然錯誤的情況下，在系統中創(chuàng)建錯誤緩存文件，將GPS報文寫入所述錯誤緩存文件中，如果是該所述SQL語句本身有問題，則直接將GPS報文寫入錯誤緩存文件，以備回收或者用戶排查錯誤原因。
6. 根據權利要求5所述的一種GPS數據入庫處理系統，其特征在于：所述報文任務池的各報文隊列處理GPS報文數量超過與其對應的兩個任務池緩存區(qū)的容量時，各報文隊列中等待入庫的GPS報文先寫入到各報文隊列的緩存文件中，通過創(chuàng)建監(jiān)測線程定時讀取系統CPU的占用情況：當系統CPU占用率低于百分之二十時，利用信號量來通知工作處理線程回收所述各報文隊列對應的緩存文件。
7. 根據權利要求5所述的一種GPS數據入庫處理系統，其特征在于：還包括報警短信服務模塊：所述工作處理線程將GPS報文中的報警報文解析出來后，根據用戶設定的報警條件判斷是否需要報警，如果滿足報警條件，則發(fā)送報警短信給對應的聯系人。
8. 根據權利要求5所述的一種GPS數據入庫處理系統，其特征在于：還包括日志模塊，在整個GPS報文入庫過程中，用戶都能查看日志，所述日志分為主日志、報警短信日志、緩存回收日志和錯誤處理日志，把它們按日期分文件夾保存，這樣分開保存、分開查看，既減少用戶檢索日志的時間又方便查看日志的詳細信息。
【文檔編號】H04L12/803GK104158757SQ201410414439
【公開日】2014年11月19日申請日期:2014年8月21日優(yōu)先權日:2014年8月21日
【發(fā)明者】鄒山青, 魏軍福, 葉偉, 莊藝園, 陳建靈申請人:福建星海通信科技有限公司

完整全部詳細技術資料下載