的全部資源子標識；
[0132]2)獲取子模塊1904，用于從訪問的資源服務器獲取全部資源子標識所指示的資源。
[0133]在上述場景下，與前述通過對訂閱者相關的訂閱單的處理以實現(xiàn)對訂閱ID和資源ID的預配置的方式對應，可選地，如圖20所示，在本發(fā)明實施例中，與第一獲取單元1302耦合地，上述資源推送裝置還可以包括:
[0134]I)第四獲取單元2002，用于獲取與任一資源對應的注冊單，其中，注冊單包括任一資源的以下至少之一的相關信息:資源地址、資源子標識、相關的日志類型、資源名稱、資源描述，其中，資源地址為任一資源所在的資源服務器的地址，資源子地址為在任一資源所在的資源服務器上訪問任一資源的端口號。
[0135]在上述場景下，可以進一步地根據(jù)訂閱單和注冊單獲取與日志類型對應的合并查詢表，其中，該合并查詢表一方面記錄有上述訂閱ID集，另一方面可以記錄有資源地址集，并且，在該合并查詢表中，該資源地址集中的每一個資源地址對應記錄有多個資源子標識。
[0136]進一步地，在本發(fā)明實施例中，上述注冊單還可以由資源管理前臺進行接收，其中，該注冊單的提供方既可以是資源的生產(chǎn)者，也可以是由資源的生產(chǎn)或維護人員直接在資源管理前臺所提供的操作界面上輸入或編輯的內(nèi)容，等，進而由資源的生產(chǎn)者所生產(chǎn)、并存放在資源服務器上的資源的相關信息可以注冊在資源管理前臺，而資源管理前臺可以對資源的相關信息進行維護，或者將這些信息轉(zhuǎn)發(fā)給資源的訂閱者，以作為訂閱者訂閱資源，比如生成訂閱單時的參考。
[0137]通過上述方式，資源的生產(chǎn)者可以僅負責資源的生產(chǎn)和注冊，而無需考慮與訂閱者之間的關聯(lián)，從而達到了資源生產(chǎn)與訂閱者解耦的目的。其中，值得注意的是，在本發(fā)明的一些實施例中，上述資源的生產(chǎn)者也可以位于上述資源服務器上，本發(fā)明對此不作限定。
[0138]在另一方面，上述資源管理前臺還可以用于接收前述的訂閱單，類似地，該訂閱單的提供方既可以是訂閱者，也可以是由資源的生產(chǎn)或維護人員直接在資源管理前臺所提供的操作界面上輸入或編輯的內(nèi)容，等。其中，作為一種可選的實施方式，訂閱單與注冊單均可以通過資源管理前臺進行編寫和維護，從而使得該資源管理前臺成為一個面向管理系統(tǒng)的管理人員的唯一的接口，進而降低整個管理系統(tǒng)的維護成本。
[0139]通過以上描述，本發(fā)明給出了第一獲取單元1302中所述的從資源服務器獲取資源ID集所指示的全部資源的【具體實施方式】，然而這并非是本發(fā)明唯一的實現(xiàn)方式。例如，在本發(fā)明的一些實施例中，上述多個訂閱者所訂閱的全部資源均存放在一個資源服務器上，則上述資源ID也可以不包括該資源服務器的地址，而是通過其他方式，比如建立連接的方式來訪問并獲取對應的資源。
[0140]在另一方面，上述實施方式作為針對常見的資源在計算機網(wǎng)絡上的分布形態(tài)而提出，并不意味著對本發(fā)明構成了限定，例如在本發(fā)明的一些實施例中，在資源推送裝置與提供不同資源的多個資源服務器之間還可以設置有資源管理服務器，以便對該處理設備發(fā)出的資源獲取請求進行響應，進而由該資源管理服務器根據(jù)存儲在其本地的存儲結構表來獲取該處理設備所需的全部資源，比如在分布式文件系統(tǒng)中，上述資源管理服務器可以是數(shù)據(jù)倉庫服務器，而存儲結構表可以是元數(shù)據(jù)或名稱結構表等。
[0141]在以上描述的基礎上，本發(fā)明將通過以下實施例對查找單元1306中將獲取到的全部資源中為多個訂閱者中的某一訂閱者所訂閱的資源的具體推送方式進行詳細描述。
[0142]根據(jù)本發(fā)明實施例提供的資源推送裝置，在查找單元1306中，可以從獲取的全部資源中查找出多個訂閱者中的每一個所訂閱的資源，并通過發(fā)送單元1308，根據(jù)訂閱ID集將查找出的多個訂閱者中的每一個所訂閱的資源發(fā)送給多個訂閱者中對應的訂閱者。
[0143]具體地，如圖21所示，作為一種可行的實施方式，第二獲取單元1304可以包括:
[0144]I)存儲模塊2102，用于從資源服務器獲取資源ID集中的每一資源ID所標識的資源，并將獲取的每一資源ID所標識的資源存儲到存儲區(qū)中；
[0145]2)記錄模塊2104，用于將每一資源ID所標識的資源在存儲區(qū)中的存儲位置的標識記錄到位置索引中；
[0146]其中，查找單元1306可以包括:
[0147]I)第二查找模塊2106，用于查找多個訂閱者中的每一個對應的訂閱單中包括的全部資源ID ；
[0148]2)第二獲取模塊2108，用于根據(jù)位置索引從與全部資源ID對應的存儲位置獲取存儲區(qū)中存儲的資源。
[0149]進一步地，如圖22所示，發(fā)送單元1308可以包括:
[0150]I)封裝模塊2202，用于將查找出的多個訂閱者中的每一個所訂閱的一個或多個資源封裝成為與每一訂閱者對應的資源包；
[0151]2)發(fā)送模塊2204，用于將資源包發(fā)送給對應的訂閱者。
[0152]在上述場景下，為進一步實現(xiàn)資源的生產(chǎn)者與訂閱者的解耦，可選地，如圖23所示，與查找單元1306耦合地，上述資源推送裝置還可以包括:
[0153]I)生成單元2302，用于生成與資源包的封裝相對應的解包例程，并通過資源管理前臺將解包例程發(fā)送給多個訂閱者。
[0154]在本發(fā)明實施例中，面向不同的訂閱者的上述解包例程既可以是相同的，也可以是不同的、與每一訂閱者對應的例程，例如，作為一種可選的方式，上述解包例程可以根據(jù)接收到的訂閱單自動地生成，并由資源管理前臺分發(fā)給對應的訂閱者。
[0155]實施例3
[0156]在本發(fā)明實施例中，還提供了一種資源服務系統(tǒng)，其中，該系統(tǒng)可以包括如實施例2中所述的資源推送裝置和多個訂閱者。
[0157]以下將結合附圖24至26給出本發(fā)明的一個更為具體的實施方式，以作為根據(jù)本發(fā)明以上實施例提供的上述資源推送方法、裝置以及資源服務器系統(tǒng)的參考。
[0158]可選地，如圖24所示，在本發(fā)明實施例中，資源服務系統(tǒng)的總體架構可以包括:資源中心前臺、資源中心后臺、以及策略單元，其中，該策略單元用于根據(jù)接收到的資源生成并執(zhí)行安全策略。
[0159]如圖24所示，資源中心可以劃分為資源中心前臺和資源中心后臺，其中，資源中心前臺可以用于提供資源注冊、修改、查看、訂閱、資源訂閱解包API下載、資源及訂閱的修改流水查詢等功能。此外，可選地，資源中心前臺還可以進一步提供API自動生成的功能，以根據(jù)訂閱的資源自動生成相應的解包API，供訂閱者下載使用，并自動生成資源外掛時的用于解析資源中心請求以及封裝資源響應包的API，供資源生產(chǎn)者下載使用。而資源中心的后臺可以包括日志接收機、資源中心邏輯層以及各資源服務器，其中，日志接收機可以用于接收生產(chǎn)系統(tǒng)的操作流水日志，做相關的基礎解析，資源中心邏輯層負責接收日志接收機過來的請求，并根據(jù)資源訂閱信息獲取訂閱者需要的資源并組裝推送給資源訂閱者，資源服務器或者說各類資源的生產(chǎn)者可以用于生產(chǎn)資源，并提供資源中心邏輯層的查詢服務，以在收到資源中心邏輯層的查詢服務時把相關資源響應給資源中心。其中，在本發(fā)明實施例中，訂閱的資源的推送是基于日志觸發(fā)的，訂閱了某種類型的日志以及相關資源后，當邏輯層收到該類型的日志就會請求其訂閱的資源，資源完備后推送給訂閱者。
[0160]具體地，在本發(fā)明實施例中，資源中心前臺可以作為資源和訂閱的管理和操作的平臺提供給資源服務器的管理人員，其中，前臺功能可以包括:資源注冊、資源查看、資源訂閱以及API下載。資源注冊是資源生產(chǎn)者向資源中心注冊資源，具體地，資源注冊可以注冊如下信息:
[0161]I)資源的名稱和描述，便于資源訂閱者查看；
[0162]2)資源的類型，資源可以根據(jù)特性以及資源直接的依賴關系共分為三類:日志資源、屬性資源、臨時計數(shù)資源，其中，日志資源表示日志接收機的輸出數(shù)據(jù)，屬性資源表示值特性化的一些屬性數(shù)據(jù)，臨時計數(shù)資源表示對用戶行為操作的累計計數(shù)，其中，臨時計數(shù)性資源會依賴日志資源或?qū)傩再Y源做某些數(shù)據(jù)的累計計數(shù)；
[0163]3)資源的服務的IP地址和端口，也就是資源邏輯層請求資源的地址；
[0164]4)資源的負責人；
[0165]5)資源的具體定義，描述資源的具體訂閱，方便訂閱者了解資源的具體含義，并作為API自動生成的依據(jù)。
[0166]資源中心前臺可以維護一張資源表，資源注冊成功后會在資源表里新增一條記錄，該資源表也是資源邏輯層的資源配置表來源，資源邏輯層通過加載該資源表獲取資源配置。資源查看頁面可以提供給資源訂閱者資源，查找需要訂閱資源的頁面，并且可以支持對已注冊的資源的修改。資源訂閱頁面可以提供資源訂閱功能，其中，訂閱者可以在資源訂閱頁面上勾選需要訂閱的資源，進而在提交訂閱成功后，可以生成一條新的訂閱單。類似地，資源中心前臺還可以維護一張訂閱表，新增一個訂閱單就會在該表新增一條記錄，邏輯層通過訂閱表來獲取訂閱信息。訂閱表主要包括訂閱ID、訂閱的日志類型、訂閱的具體資源ID，訂閱修改時間等信息。
[0167]此外，在面向訂閱者時，資源中心前臺除提供訂閱單的查詢功能外，還可以提供針對某個訂閱單下載其對應的訂閱信息解包API的功能。進一步地，資源中心前臺還可以提供資源和訂閱修改的流程的查看，以便于跟蹤修改、定位問題。
[0168]在另一方面，如圖24所示，資源中心后臺可以包括日志接收機、邏輯層和資源服務器。以下將重點闡述邏輯層的實現(xiàn)方案，邏輯層是整個平臺的核心模塊，負責根據(jù)資源及訂閱配置請求組裝各訂閱者所訂閱的資源，并推送給訂閱者，完成資源從資源生產(chǎn)者到資源消費者的推送功能，實現(xiàn)生產(chǎn)和消費的解耦。
[0169]如圖25所示，在本發(fā)明實施例中，邏輯層啟動時會啟動一個配置進程，啟動加載資源和訂閱的配置信息，且當前臺資源或訂閱變更時會通知配置進程，配置進程重新加載配置。配置進程加載資源和訂閱的配置后會計算出屬性資源合并查詢表和臨時資源合并查詢表，請求資源時根據(jù)這兩張表做快速的資源請求和分發(fā)。
[0170]在圖25中，業(yè)務進程是邏輯層處理資源請求和推送的核心模塊，根據(jù)資源之間的依賴關系，邏輯層做兩層會話(sess1n)的請求，這兩次sess1n分別處理第一層的屬性化資源的請求和第二層的臨時資源的請求。
[0171]其中，第一層sess1n直接根據(jù)屬性資源合并查詢表，向所有該日志類型關聯(lián)的屬性資源服務器請求資源，請求到所有的屬性資源后做第二層sess1n的請求，由于第二次sess1n的資源累計依賴于第一層sess1n屬性資源做計數(shù),在第二層請求的時會帶上屬性化資源。第二層sess1n請求時根據(jù)臨時資源合并查詢表做請求。
[0172]在以上描述的基礎上，考慮到微博每天的生產(chǎn)系統(tǒng)寫操作日志有1.9億條，每個訂閱同時可以訂閱多個資源，如果對每次訂閱都單獨請求每個資源，則在整個系統(tǒng)中與請求相關的收發(fā)包的數(shù)量將是巨大的，這對于服務器的網(wǎng)卡和CPU網(wǎng)卡中斷構成了較大的負擔，從而增大了資源服務器及整個資源服務系統(tǒng)的處理壓力。針對這一問題，本發(fā)明實施例采用了一種合并快速查詢的方式，其中，這里的合并包括兩層含義:1)對日志類型的多個訂閱單的請求資源做合并，計算出一個日志類型的所有訂閱單訂閱的資源合集，一次日志操作只要請求資源合集，再根據(jù)訂閱做組裝分發(fā)；2)資源服務的合并，對相關的資源可以通過一個接口進程做打包查詢，提高資源中一次請求的效率。
[0173]在本發(fā)明實施例中，快速合并查詢的實現(xiàn)是通過屬性資源合并查詢表和臨時資源合并查詢表來實現(xiàn)的，以下將結合圖26對根據(jù)本發(fā)明實施例提供的資源推送方法進行解釋。
[0174]在圖26中，屬性資源合并查詢表和臨時