[發明專利]一種實時計費系統

無效

• 申請號: 201010269563.2
• 申請日: 2010-08-31
• 公開（公告）號: CN101924638A
• 公開（公告）日: 2010-12-22
• 發明（設計）人: 楊利軍;郜時紅;姚永壯;井衛軍;蔣建平
• 申請（專利權）人: 北京云快線軟件服務有限公司
• 主分類號: H04L12/14
• 分類號: H04L12/14;G06F17/30
• 代理公司: 北京集佳知識產權代理有限公司 11227
• 代理人: 逯長明;王寶筠

技術領域

本發明涉及數據處理領域，特別是涉及一種實時計費系統。

背景技術

計費是內容分發網絡(Content?Delivery?Network，CDN)服務提供商的業務與運營支撐系統(BOSS)的必備的基礎功能之一。在CDN領域一般都采用日志計費的方式，即把加速服務器的訪問日志收集起來，然后按造預定方式匯總每條日志訪問所產生的流量，再經過預置的一系列計算，生成當前日志所產生的費用。在生成日志費用的時候一般由數據庫執行，需要將每一條訪問日志的域名、時間和產生的流量等信息匯總，并可以通過程序或者存儲過程來匯總。通常的做法可以是每5分鐘設置一個采樣點，即一個域名在同一個5分鐘之內的訪問產生的流量算為一個采樣點。目前，流量和帶寬之間有如下所示的計算公式：平均帶寬(bps)＝(總流量(B)*8)/(60(s)*5))。

采用現有技術進行計費的方式示例如下：假設全網加速的有5000個域名，每個域名有100臺服務器提供服務，每個頻道每5分鐘的流量數據合并為1條(在進入數據庫之前匯總)，那么按照服務器的維度入庫時，一天的數據量有：5000*100*288＝144,000,000(條記錄)。即使不按服務器的維度，按照節點數(中型的CDN提供商大概擁有幾十個節點)統計的數據量也不會降下來，仍然在1億條以上。這個數據量還是匯總之后的數據量，那么臨時入庫前的冗余數據量(即一個時間點多條數據)更是龐大，如果在數據庫中保留3個月的數據，數據量可能會達到百億條。

從上述過程中可以看出，采用傳統的方法將信息匯總入庫并計算日志費用時，都集中于數據庫進行計算，由于計費的日志信息量非常大，就對數據庫造成非常大的壓力，降低了數據庫的計算速度和性能。在實際應用中，計費周期通常是按月進行的，因此，由于計算完之后的數據量依然很大，查詢一個月的計費信息也是非常的慢，就導致了查詢效率也很低。進一步的，由于CDN行業激烈的競爭，單一的計費方法早已不能適應業務的發展，由于多數用戶都是存在多域名加速的情況，因此如何合理地對多域名計費是需要考慮的一個問題。

因此，目前需要本領域技術人員迫切解決的一個技術問題就是：如何能夠提出一種實時計費方法，主要用以解決現有技術中計費和查詢效率過低的技術問題，還能進一步的適應用戶存在多域名加速的應用場景。

發明內容

本發明所要解決的技術問題是提供一種實時計費方法，主要用以解決現有技術中計費和查詢效率過低的技術問題，還能進一步的適應用戶存在多域名加速的應用場景。

本發明的另一個目的是將上述構思應用于具體的應用環境中，提供一種實時計費系統，從而保證該方法的實現和應用。

為解決上述技術問題，本發明實施例提供了一種實時計費系統，包括：

獲取數據文件模塊，用于獲取各個節點的數據文件；

生成臨時數據模塊，用于將所述各個節點的數據文件匯總后直接保存至臨時數據庫；

多級匯總模塊，用于對臨時數據庫中的數據文件進行多級匯總，以得到滿足預置條數的數據記錄并保存至查詢數據庫中；

查詢計費模塊，用于按照時間段信息從所述查詢數據中獲取相應的數據記錄并進行計費。

優選的，所述獲取數據文件模塊具體包括：

分析日志子模塊，用于在每個節點上對本節點的計費日志進行分析；

生成數據文件子模塊，用于刪除所述計費日志中的冗余數據，以生成各個節點的數據文件。

優選的，所述多級匯總模塊具體包括：

生成數據子模塊，用于將所述數據文件轉換為每域名周期性的生成一條數據；

合并子模塊，用于針對各個域名合并所述生成的多條數據；

匯總子模塊，用于將所述多條數據按照頻道和時間信息進行匯總，以減少數據庫中的數據量。

優選的，所述查詢計費模塊具體包括：

獲取帶寬數據子模塊，用于依據時間段信息獲取業務類型相同的域名的帶寬數據；

計費子模塊，用于針對所述獲取到的帶寬數據采用預置的計費算法進行計費。

優選的，還包括：

生成計費賬單模塊，用于生成滿足用戶需求的計費賬單。

與現有技術相比，本發明具有以下優點：