日志收集系統(tǒng)及其中的數據傳輸方法和本地服務器的制造方法
【技術領域】
[0001]本發(fā)明涉及互聯網技術領域，具體涉及一種日志收集系統(tǒng)及其中的數據傳輸方法和本地服務器。
【背景技術】
[0002]對于互聯網來說，獲取網站上的訪問記錄以及其他相關記錄，進行相關行為分析至關重要。因此需要進行網絡的日志的收集。
[0003]Scribe是Facebook開源的日志收集系統(tǒng)，在Facebook內部已經得到大量的應用。Scribe能夠從各種日志源上收集日志，存儲到一個中央存儲系統(tǒng)(可以是網絡文件系統(tǒng)、分布式文件系統(tǒng)等)上，以便于進行集中統(tǒng)計分析處理。Scribe為日志的“分布式收集，統(tǒng)一處理”提供了一個可擴展的，高容錯的方案。當中央存儲系統(tǒng)的網絡或者機器出現故障時，scribe會將日志轉存到本地或者另一個位置，當中央存儲系統(tǒng)恢復后，scribe會將轉存的日志重新傳輸給中央存儲系統(tǒng)。
[0004]圖1示出了 scribe系統(tǒng)的一個工作場景示意圖。如圖1所示，scribe系統(tǒng)包括客戶端、本地服務器和中心服務器。客戶端分布在各個網頁的日志源處。客戶端從日志源實時獲取日志數據并實時發(fā)送給本地服務器，本地服務器再將日志數據發(fā)送給中心服務器，最后由中心服務器將日志數據發(fā)送到中央存儲系統(tǒng)。
[0005]在實際場景中，本地服務器和中心服務器通常不在一個機房，常常需要跨機房傳輸日志數據，由于日志數據的海量性，網絡帶寬資源常常成為本地服務器到中心服務器的傳輸瓶頸，當需要傳輸的數據量很大時，數據經常會出現堆積的情況。

【發(fā)明內容】

[0006]鑒于上述問題，提出了本發(fā)明以便提供一種克服上述問題或者至少部分地解決上述問題的一種日志收集系統(tǒng)及其中的數據傳輸方法和本地服務器。
[0007]依據本發(fā)明的一個方面，提供了一種日志收集系統(tǒng)中的數據傳輸方法，應用于包括客戶端、本地服務器和中心服務器的日志收集系統(tǒng)，該方法包括:
[0008]本地服務器接收客戶端從日志源獲取后發(fā)送的日志數據；
[0009]本地服務器將接收的日志數據進行壓縮后發(fā)送給中心服務器，由中心服務器對所接收到的日志數據進行解壓縮后發(fā)送至中央存儲系統(tǒng)。
[0010]可選地，所述本地服務器接收客戶端從日志源獲取后發(fā)送的日志數據包括:將接收到的日志數據按照該日志數據的分類放入對應的隊列中；其中，本地服務器有用于存放不同分類的日志數據的多個隊列；
[0011]所述本地服務器將接收的日志數據進行壓縮后發(fā)送給中心服務器包括:從隊列中取日志數據，對取出的日志數據進行壓縮后發(fā)送給中心服務器。
[0012]可選地，該方法在本地服務器將接收的日志數據進行壓縮后，并在發(fā)送給中心服務器之前，進一步包括:對壓縮后的日志數據進行base64編碼，然后再發(fā)送給中心服務器；中心服務器對所接收日志數據進行解壓縮之前，先進行base64解碼。
[0013]可選地，所述本地服務器將接收的日志數據進行壓縮包括:采用ZLIB算法或LZO算法對日志數據進行壓縮。
[0014]可選地，所述將接收到的日志數據按照該日志數據的分類放入對應的隊列中包括:由本地服務器的多個接收工作線程接收客戶端發(fā)送的日志數據，并按照該日志數據的分類放入對應的隊列中；
[0015]所述從隊列中取日志數據包括:由本地服務器的多個發(fā)送工作線程從多個隊列中取日志數據。
[0016]依據本發(fā)明的另一個方面，提供了一種日志收集系統(tǒng)中的本地服務器，包括:接收單元、壓縮單元和發(fā)送單元；
[0017]所述接收單元，適于接收客戶端從日志源獲取后發(fā)送的日志數據；
[0018]所述壓縮單元，適于將接收單元接收的日志數據進行壓縮；
[0019]所述發(fā)送單元，適于將壓縮單元壓縮的日志數據發(fā)送給中心服務器，使得中心服務器對所接收到的日志數據進行解壓縮后發(fā)送至中央存儲系統(tǒng)。
[0020]可選地，該本地服務器進一步包括:用于存儲多個隊列的存儲單元；
[0021 ] 所述接收單元，適于將接收到的日志數據按照該日志數據的分類放入對應的隊列中；
[0022]所述壓縮單元，適于從隊列中取日志數據，對取出的日志數據進行壓縮。
[0023]可選地，該本地服務器進一步包括:編碼單元，適于對壓縮單元壓縮后的日志數據進行base64編碼；
[0024]所述發(fā)送單元，適于將編碼單元進行base64編碼后的日志數據發(fā)送給中心服務器，使得中心服務器對日志數據進行解壓縮之前，先進行base64解碼。
[0025]可選地，所述壓縮單元，適于采用ZLIB算法或LZO算法對日志數據進行壓縮。
[0026]依據本發(fā)明的又有個方面，提供了一種日志收集系統(tǒng)，其中，該系統(tǒng)包括:客戶端、中心服務器和如上述任一項所述的本地服務器。
[0027]根據本發(fā)明的這種本地服務器接收客戶端從日志源獲取后發(fā)送的日志數據，本地服務器將接收的日志數據進行壓縮后發(fā)送給中心服務器，由中心服務器對所接收到的日志數據進行解壓縮后發(fā)送至中央存儲系統(tǒng)的技術方案，由于在本地服務器和中心服務器之間進行了數據的壓縮傳輸，從而節(jié)省了本地服務器和中心服務器之間的傳輸帶寬資源，緩解了數據堆積的壓力。
[0028]上述說明僅是本發(fā)明技術方案的概述，為了能夠更清楚了解本發(fā)明的技術手段，而可依照說明書的內容予以實施，并且為了讓本發(fā)明的上述和其它目的、特征和優(yōu)點能夠更明顯易懂，以下特舉本發(fā)明的【具體實施方式】。
【附圖說明】
[0029]通過閱讀下文優(yōu)選實施方式的詳細描述，各種其他的優(yōu)點和益處對于本領域普通技術人員將變得清楚明了。附圖僅用于示出優(yōu)選實施方式的目的，而并不認為是對本發(fā)明的限制。而且在整個附圖中，用相同的參考符號表示相同的部件。在附圖中:
[0030]圖1示出了 scribe系統(tǒng)的一個工作場景示意圖；
[0031]圖2示出了根據本發(fā)明一個實施例的一種日志收集系統(tǒng)中的數據傳輸方法的流程圖；
[0032]圖3示出了根據本發(fā)明一個實施例的本地服務器中的數據接收和發(fā)送示意圖；
[0033]圖4示出了根據本發(fā)明一個實施例的一種日志收集系統(tǒng)中的本地服務器的結構圖；
[0034]圖5示出了根據本發(fā)明又一個實施例的一種日志收集系統(tǒng)中的本地服務器的結構圖；
[0035]圖6示出了根據本發(fā)明又一個實施例的一種日志收集系統(tǒng)的組成示意圖。
【具體實施方式】
[0036]下面將參照附圖更詳細地描述本公開的示例性實施例。雖然附圖中顯示了本公開的示例性實施例，然而應當理解，可以以各種形式實現本公開而不應被這里闡述的實施例所限制。相反，提供這些實施例是為了能夠更透徹地理解本公開，并且能夠將本公開的范圍完整的傳達給本領域的技術人員。
[0037]圖2示出了根據本發(fā)明一個實施例的一種日志收集系統(tǒng)中的數據傳輸方法的流程圖。圖2所示的方法用于包括客戶端、本地服務器和中心服務器的日志收集系統(tǒng)，該日志收集系統(tǒng)從各種日志源收集日志數據并存儲到中央存儲系統(tǒng)中。如圖2所示，該日志收集系統(tǒng)中的數據傳輸方法包括:
[0038]步驟S210，本地服務器接收客戶端從日志源獲取后發(fā)送的日志數據。
[0039]步驟S220，本地服務器將接收的日志數據進行壓縮后發(fā)送給中心服務器，由中心服務器對所接收到的日志數據進行解壓縮后發(fā)送至中央存儲系統(tǒng)。
[0040]圖2所示的方法，由于在本地服務器和中心服務器之間進行了數據的壓縮傳輸，從而節(jié)省了本地服務器和中心服務器之間的傳輸帶寬資源，緩解了數據堆積的壓力。
[0041 ] 在本發(fā)明的一個實施例中，圖2所示方法中的步驟S210中的本地服務器接收客戶端從日志源獲取后發(fā)送的日志數據具體為:本地服務器將接收到的日志數據按照該日志數據的分類放入對應的隊列中；其中，本地服務器有用于存放不同分類的日志數據的多個隊列。步驟S220中的本地服務器將接收的日志數據進行壓縮后發(fā)送給中心服務器具體為:從隊列中取日志數據，對取出的日志數據進行壓縮后發(fā)送給中心服務器。
[0042]在本發(fā)明的一個實施例中，在本地服務器中由工作線程來完成數據的接收和發(fā)送，則所述將接收到的日志數據按照該日志數據的分類放入對應的隊列中具體為:由本地服務器的多個接收工作線程接收客戶端發(fā)送的日志數據，并按照該日志數據的分類放入對應的隊列中。所述從隊列中取日志數據具體為:由本地服務器的多個發(fā)送工作線程從多個隊列中取日志數據。
[0043]圖3示出了根據本發(fā)明一個實施例的本地服務器中的數據接收和發(fā)送示意圖。參見圖3，本地服務器中的接收工作線程接收來自客戶端的日志數據，根據日志數據的分類放入相應的隊列中。例如當前收到的日志數據屬于分類2，則放入分類2的隊列中。需要說明的是接收工作線程可以是多個。本地服務器中的發(fā)送工作線程從各隊列取數據，對取出的日志數據進行壓縮后發(fā)送給中心服務器。需要說明的是發(fā)送工作線程也可以是多個。
[0044]在本發(fā)明的一個實施例中，本地服務器對日志數據進行壓縮具體可以采用ZLIB算法或LZO(Lempel-Ziv-Oberhumer)算法進行壓縮。兩種壓縮算法各有優(yōu)缺點，可以根據實際的情況選擇。ZLIB壓縮比高，但比較浪費cpu資源；LZ0壓縮比低，對CPU要求不高。
[0045]在本發(fā)明的一個實施例中，本地服務器對日志數據進行壓縮后，并在發(fā)送給中心服務器之前，進一步對壓縮后的日志數據進行base64編碼，然后再發(fā)送給中心服務器。則相應地，中心服務器對所接收日志數據進行解壓縮之前，先進行base64解碼，再進行解壓縮。
[0046]在實際當中，在特定的集群配置環(huán)境下，本地服務器和中心服務器跨機房配置，由于跨機房的帶寬資源比較吃緊，因此本發(fā)明實施例中的上述方案，能夠在很大程度上節(jié)省網絡的1資源，從而節(jié)省服務成本。
[0047]在本發(fā)明的一個實施例中，將上述實施例中所述的數據傳輸方法應用于Scribe系統(tǒng)中。這樣，可以解決Scribe系統(tǒng)中的本地服務器和中心服務器跨機房配置時的帶寬資源吃緊問題。
[0048]圖4示出了根據本發(fā)明一個實施例的一種日志收集系統(tǒng)中的本地服務器的結構圖。如圖4所示，本地服務器400包括:接收單元410、壓縮單元420和發(fā)送單元430。
[0049]接收單元410，適于接收客戶端從日志源獲