一種數據處理方法和裝置製造方法
2023-05-04 10:32:56 1
一種數據處理方法和裝置製造方法
【專利摘要】本申請提供了一種數據處理方法和裝置。該方法包括：接收來自用戶終端的請求，所述請求攜帶用戶ID；確定與所述用戶ID相關聯的所有關聯用戶ID；從所有關聯用戶ID中選擇出N個滿足設定條件的特定用戶ID，拉取所述N個特定用戶ID對應的最新用戶數據，並返回給所述用戶終端；所述N小於等於一個頁面所要求的用戶數據數量M。採用本發明，能夠實現在頁面請求時節省數據傳輸的帶寬資源。
【專利說明】一種數據處理方法和裝置
【技術領域】
[0001]本申請涉及網際網路技術，特別涉及一種數據處理方法和裝置。
【背景技術】
[0002]在網際網路技術中，用戶原創內容(UGC:User Generated content)是一種用戶使用網際網路的新方式，所謂UGC，其是由原來的僅以下載為主變成下載和上傳並重的方式，目前，社區網絡、視頻分享、和微博都是UGC的主要應用形式。以微博為例，下面描述現有針對微博的處理方式:
[0003]針對一個微博用戶，其最多具有2000個收聽用戶，其中，為便於描述，可將該收聽用戶稱為偶像(Uin)。而一個微博用戶對應的微博首頁，其按照時間排列最多展示70條微博消息，其中，一條微博消息與一個微博用戶對應，也就是說，一個微博用戶對應的微博首頁展示的70條微博消息最多是由70個Uin發表的。
[0004]參見圖1，圖1為現有微博消息處理架構圖。微博用戶發布的微博消息離散分布在底層設備(簡稱底層svr)，比如，在圖1中，底層設備I僅負責編號為I至1000的微博用戶發布的微博消息，底層設備2僅負責編號為1001至2000的微博用戶發布的微博消息，底層設備3僅負責編號為2001至3000的微博用戶發布的微博消息，依次類推，直至底層設備N。當編號為I的微博用戶對應的微博首頁需要展示微博消息時，該微博用戶通過客戶端向與連接底層設備的接口機發送首頁讀請求，當接口機接收到首頁讀請求後，找到該編號為I的微博用戶對應的2000個Uin，然後分別向負責管理該2000個Uin發布的微博消息的底層設備發送首頁讀請求，當底層設備收到首頁讀請求後，將其負責的該2000個Uin中任一微博用戶發布的微博消息返回給接口機，接口機收到底層設備返回的該2000個Uin發布的微博消息後，按照微博消息發布時間降序排列該2000個Uin發布的微博消息，選取前70個偶像發布的微博消息返回給微博首頁展示，具體如圖2所示。
[0005]基於上面描述可以看出，在現有微博消息處理過程中，微博首頁為了展示70條微博消息，就需要獲取2000個Uin發布的微博消息，通過遍歷該2000個Uin發布的微博消息選取最新的70條微博消息展示，而剩下的1930條微博消息是不予展示的，也就是說，該剩下的1930條微博消息的獲取是無用的，但是，獲取該剩下的1930條微博消息是需要帶寬資源的，這顯然會浪費大量的帶寬資源。
【發明內容】
[0006]本申請提供了一種數據處理方法和裝置，以在頁面請求時節省數據傳輸的帶寬資源。
[0007]本申請提供的技術方案包括:
[0008]一種數據處理方法，包括:
[0009]接收來自用戶終端的請求，所述請求攜帶用戶ID ；
[0010]確定與所述用戶ID相關聯的所有關聯用戶ID ；[0011]從所有關聯用戶ID中選擇出N個滿足設定條件的特定用戶ID，拉取所述N個特定用戶ID對應的最新用戶數據，並返回給所述用戶終端；所述N小於等於一個頁面所要求的用戶數據數量M。
[0012]一種數據處理裝置，該裝置包括:接收模塊、確定模塊和處理模塊；其中，
[0013]所述接收模塊，用於接收來自用戶終端的請求，所述請求攜帶用戶ID ；
[0014]所述確定模塊，用於確定與所述用戶ID相關聯的所有關聯用戶ID ；
[0015]所述處理模塊，包含選擇單元和數據處理單元；
[0016]其中，所述選擇單元，用於從所述確定模塊確定的所有關聯用戶ID中選擇出N個滿足設定條件的特定用戶ID ；
[0017]所述數據處理單元，用於拉取所述N個特定用戶ID對應的最新用戶數據，並返回給所述用戶終端；所述N小於等於一個頁面所要求的用戶數據數量M。
[0018]由以上技術方案可以看出，本發明中，在接收到用戶終端的請求時，從與該用戶相關聯的所有關聯用戶ID中選擇出N個滿足設定條件的特定用戶ID，僅拉取所述N個特定用戶ID對應的最新用戶數據，並返回給所述用戶終端，所述N小於等於所述頁面要求的用戶數據數量M，這相比於現有技術中拉取該用戶相關聯的所有關聯用戶ID的最新用戶數據，一方面能夠節省帶寬資源，另一方面，能夠節約成本。
【專利附圖】
【附圖說明】
[0019]圖1為現有微博消息處理架構圖；
[0020]圖2為現有微博首頁頁面處理微博消息示意圖；
[0021]圖3為本發明實施例提供的方法流程圖；
[0022]圖4為本發明實施例提供的用戶數據拉取實現流程圖；
[0023]圖5為本發明實施例提供的用戶ID選擇流程圖；
[0024]圖6為本發明實施例提供的應用架構圖；
[0025]圖7a為本發明實施例提供的微博消息發布時間和微博用戶ID對應關係示意圖；
[0026]圖7b為本發明實施例提供的按照微博消息發布時間排列的微博用戶ID隊列示意圖；
[0027]圖8為本發明實施例提供的裝置結構圖。
【具體實施方式】
[0028]為了使本發明的目的、技術方案和優點更加清楚，下面結合附圖和具體實施例對本發明進行詳細描述。
[0029]參見圖3，圖3為本發明實施例提供的方法流程圖。如圖3所示，該流程可包括以下步驟:
[0030]步驟301，接收來自用戶終端的請求，所述請求攜帶用戶標識(ID)。
[0031]以微博應用為例，則，針對任一微博用戶終端，其在戶微博首頁頁面展示之前會發送請求至伺服器，以從伺服器獲取需要展示的用戶數據。其中，為便於伺服器獲取其需要展示的用戶數據，其一般在發送的請求中攜帶微博用戶終端對應的用戶ID。
[0032]步驟302，確定與用戶ID相關聯的所有關聯用戶ID。[0033]優選地，本發明中，可預先設置每一用戶ID的關係鏈，通過該關係鏈中標出了該用戶ID相關聯的所有用戶ID。仍以微博應用為例，通常，一個微博用戶ID最多有2000個相關聯的收聽用戶ID，基於此，本發明在設置一微博用戶ID的關係鏈時，可將該微博用戶ID的2000個收聽用戶ID設置到其關係鏈中，作為其相關聯的用戶。
[0034]基於預先設置每一用戶ID的關係鏈描述，本步驟302可在接收到請求後，依據該請求攜帶的用戶ID從預先設置的關係鏈中找到該用戶ID對應的關係鏈，將該關係鏈標出的所有用戶ID作為與所述請求攜帶的用戶ID相關聯的所有用戶ID (記為關聯用戶ID)。
[0035]步驟303，從所有關聯用戶ID中選擇出N個滿足設定條件的特定用戶ID，拉取所述N個特定用戶ID對應的最新用戶數據，並返回給所述用戶終端；所述N小於等於一個頁面所要求的用戶數據數量M。
[0036]仍以微博應用為例，通常，一個微博頁面最多展示70條微博消息，但該微博用戶ID的關聯用戶ID最多有2000個，本步驟303通過預先設定條件，從該2000個關聯用戶ID中選擇出N個比如70個或者小於70個滿足設定條件的特定用戶ID，僅拉取該N個特定用戶ID對應的最新用戶數據，並非全部拉取該2000個關聯用戶ID對應的最新用戶數據，這能夠減少拉取的用戶數據數量，節省帶寬資源。
[0037]至此，完成圖3所示流程。
[0038]需要說明的是，本發明中，作為一個實施例，上述步驟303中，拉取所述N個特定用戶ID對應的最新用戶數據可通過圖4所示流程實現:
[0039]參見圖4，圖4為本發明實施例提供的用戶數據拉取實現流程圖。如圖4所示，該流程可包括以下步驟:
[0040]步驟401，從所有底層設備(svr)中確定出用於管理所述N個特定用戶ID的底層設備。
[0041]通常，用戶ID、以及該用戶ID的所有用戶數據都是由底層設備管理的，其中，底層設備的數量可在組網時進行設置，這裡不再具體描述。
[0042]步驟402，識別該確定出的底層設備的數量L。
[0043]步驟403，將所述請求分成L份請求包，並對應發送至該確定出的L個底層設備，每一份請求包攜帶所述N個特定用戶ID中的至少一個，其中，請求包攜帶的特定用戶ID實質為該請求包發送至的底層設備管理的用戶ID。
[0044]以上述的N取值為70為例，假如本步驟402識別出的L為3，其中，70個用戶ID中，有30個由底層設備I管理，30個由底層設備2管理，以及剩下的10個用戶ID由底層設備3管理，則本步驟403中，將上述步驟301接收的請求分成以下3份請求包:請求包1、請求包2、請求包3，在請求包I中攜帶由底層設備I管理的30個用戶ID，並發送至底層設備I，在請求包2中攜帶由底層設備2管理的30個用戶ID，並發送至底層設備2，在請求包3中攜帶由底層設備3管理的10個用戶ID，並發送至底層設備3。
[0045]步驟404，接收所述L個底層設備返回的用戶數據，每一個底層設備返回的用戶數據為其接收的請求包攜帶的特定用戶ID對應的最新用戶數據。
[0046]至此，通過圖4所示流程即可拉取N個用戶ID對應的最新用戶數據。仍以微博應用為例，通常，一個微博用戶ID的微博首頁頁面最多展示70條微博消息，但該微博用戶ID相關聯的用戶ID最多有2000個，通過圖4所示流程，本發明從該2000個用戶ID中選擇出N個比如70個或者小於70個滿足設定條件的用戶ID，僅向負責管理N個用戶ID的底層設備發送請求包，並非向負責關聯該2000個用戶ID的底層設備發送請求包，這降低了底層設備的負載，發送的請求包數量也相應減少，節省了昂貴的帶寬資源，也節約了底層設備的成本，能夠使得底層設備在很長時間內不需要擴容。
[0047]另外，本發明中，作為一個實施例，上述步驟303中，從確定的所有關聯用戶ID中選擇出N個滿足設定條件的特定用戶ID可包括圖5所示的流程。
[0048]參見圖5，圖5為本發明實施例提供的用戶ID選擇流程圖。如圖5所示，該流程可包括以下步驟:
[0049]步驟501，將確定的所有關聯用戶ID發送給預設的網絡設備，所述網絡設備用於記錄任一用戶ID對應的動作行為。
[0050]這裡，預設的網絡設備可為一臺機器，也可為其他實現形式，本發明並不具體限定。
[0051]步驟502，接收網絡設備返回的N個用戶ID，所述網絡設備返回的N個用戶ID是由所述網絡設備從接收的所有關聯用戶ID中選擇出的動作行為滿足設定條件的特定用戶ID0
[0052]至此，完成圖5所示流程。其中，為使圖4和圖5所示流程便於理解，以本發明應用於微博應用為例，則結合圖4和圖5所示流程本發明示出了對應的應用架構圖，具體見圖6，這裡不再詳細描述。
[0053]需要說明的是，本發明中，所述用戶ID對應的用戶數據為用戶原創內容UGC;基於此，所述用戶ID對應的動作行為為所述UGC更新或發布的時間；所述動作行為滿足設定條件包括:UGC發布時間或更新時間最新。
[0054]優選地，作為本發明一個實施例，所述UGC具體實現時可為微博消息，基於此，上述步驟501中，用戶ID對應的動作行為至少包括:微博消息發布時間；以及，步驟502中，動作行為滿足設定條件可包括:微博消息發布時間最新。
[0055]下面以UGC具體實現時為微博消息為例對圖5所示流程進行描述:
[0056]在微博應用中，一個微博用戶ID相關聯的用戶ID最多有2000個，則基於圖5所示流程中的步驟501，可將一個微博用戶ID相關聯的2000個用戶ID發送給預設的網絡設備，當網絡設備收到該2000個用戶ID後，從記錄的所有用戶ID中選取出該2000個用戶ID對應的微博消息發布時間，具體如圖7a所示，之後，對該選取出的2000個用戶ID的微博消息發布時間按照微博消息發布時間進行順序排列，排列結果如圖7b所示，其中，在圖7b中，微博消息發布時間最新的用戶ID排在最前，其他次之，依次類推。以N取值為70為例，則之後網絡設備從圖7b所示的隊列中選擇出前70個用戶ID。
[0057]需要說明的是，上面描述的UGC為微博消息只是一種舉例，並非限定本發明，優選地，本發明中，UGC也可為即時通信應用空間發布或更新的消息；相應地，上述步驟501中，所述用戶ID對應的動作行為至少包括:即時通信應用空間的消息發布或更新時間；上述步驟502中，所述動作行為滿足設定條件包括:更新時間最新或發布時間最新。
[0058]至此，完成本發明提供的描述。
[0059]下面對本發明提供的裝置進行描述。
[0060]參見圖8，圖8為本發明實施例提供的裝置結構圖。如圖8所示，該裝置可包括:接收模塊、確定模塊和處理模塊；其中，
[0061]所述接收模塊，用於接收來自用戶終端的請求，所述請求攜帶用戶ID ；
[0062]所述確定模塊，用於確定與所述用戶ID相關聯的所有關聯用戶ID ；
[0063]所述處理模塊，包含選擇單元和數據處理單元；
[0064]其中，所述選擇單元，用於從所述確定模塊確定的所有關聯用戶ID中選擇出N個滿足設定條件的特定用戶ID ；
[0065]所述數據處理單元，用於拉取所述N個特定用戶ID對應的最新用戶數據，並返回給所述用戶終端；所述N小於等於一個頁面所要求的用戶數據數量M。
[0066]優選地，本發明中，所述選擇單元通過以下步驟從所述確定模塊確定的所有關聯用戶ID中選擇出N個滿足設定條件的特定用戶ID:
[0067]將所有關聯用戶ID發送給預設的網絡設備，所述網絡設備用於記錄任一用戶ID對應的動作行為；
[0068]接收網絡設備返回的N個用戶ID，所述網絡設備返回的N個用戶ID是由所述網絡設備從接收的所有關聯用戶ID中選擇出的動作行為滿足設定條件的特定用戶ID。
[0069]作為本發明的一個實施例，所述用戶ID對應的用戶數據為用戶原創內容UGC ;
[0070]所述用戶ID對應的動作行為為所述UGC更新或發布的時間；
[0071]所述動作行為滿足設定條件包括:UGC發布時間或更新時間最新。
[0072]作為本發明的一個實施例，所述UGC為微博消息；或者，
[0073]所述UGC為即時通信應用空間發布的消息。
[0074]優選地，本發明中，所述數據處理單元通過以下步驟拉取N個特定用戶ID對應的最新用戶數據:
[0075]從所有底層設備svr中確定出用於管理所述N個特定用戶ID的底層設備；
[0076]識別該確定出的底層設備的數量L，將所述請求分成L份請求包，並對應發送至該確定出的L個底層設備，每一份請求包攜帶所述N個特定用戶ID中的至少一個特定用戶ID ；
[0077]接收所述L個底層設備返回的用戶數據，每一個底層設備返回的用戶數據為其接收的請求包攜帶的特定用戶ID對應的最新用戶數據。
[0078]至此，完成圖8所示的裝置描述。
[0079]由以上技術方案可以看出，本發明中，在接收到用戶終端的請求時，從與該用戶相關聯的所有關聯用戶ID中選擇出N個滿足設定條件的特定用戶ID，僅拉取所述N個特定用戶ID對應的最新用戶數據，並返回給所述用戶終端，所述N小於等於所述頁面要求的用戶數據數量M，這相比於現有技術中拉取該用戶相關聯的所有關聯用戶ID的最新用戶數據，一方面能夠節省帶寬資源，另一方面，能夠節約成本。
[0080]以上所述僅為本發明的較佳實施例而已，並不用以限制本發明，凡在本發明的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本發明保護的範圍之內。
【權利要求】
1.一種數據處理方法，其特徵在於，該方法包括: 接收來自用戶終端的請求，所述請求攜帶用戶ID ； 確定與所述用戶ID相關聯的所有關聯用戶ID ； 從所有關聯用戶ID中選擇出N個滿足設定條件的特定用戶ID，拉取所述N個特定用戶ID對應的最新用戶數據，並返回給所述用戶終端；所述N小於等於一個頁面所要求的用戶數據數量M。
2.根據權利要求1所述的方法，其特徵在於，所述從所有關聯用戶ID中選擇出N個滿足設定條件的特定用戶ID包括: 將所有關聯用戶ID發送給預設的網絡設備，所述網絡設備用於記錄任一用戶ID對應的動作行為； 接收網絡設備返回的N個用戶ID，所述網絡設備返回的N個用戶ID是由所述網絡設備從接收的所有關聯用戶ID中選擇出的動作行為滿足設定條件的特定用戶ID。
3.根據權利要求2所述的方法，其特徵在於，所述用戶ID對應的用戶數據為用戶原創內容UGC ； 所述用戶ID對應的動作行為為所述UGC更新或發布的時間； 所述動作行為滿足設定條件包括=UGC發布時間或更新時間最新。
4.根據權利要求3所述的方法，其特徵在於， 所述UGC為微博消息；或者， 所述UGC為即時通信應用空間發布的消息。
5.根據權利要求1所述的方法，其特徵在於，所述拉取N個特定用戶ID對應的最新用戶數據包括: 從所有底層設備svr中確定出用於管理所述N個特定用戶ID的底層設備； 識別該確定出的底層設備的數量L，將所述請求分成L份請求包，並對應發送至該確定出的L個底層設備，每一份請求包攜帶所述N個特定用戶ID中的至少一個特定用戶ID; 接收所述L個底層設備返回的用戶數據，每一個底層設備返回的用戶數據為其接收的請求包攜帶的特定用戶ID對應的最新用戶數據。
6.一種數據處理裝置，其特徵在於，該裝置包括:接收模塊、確定模塊和處理模塊；其中， 所述接收模塊，用於接收來自用戶終端的請求，所述請求攜帶用戶ID ； 所述確定模塊，用於確定與所述用戶ID相關聯的所有關聯用戶ID ； 所述處理模塊，包含選擇單元和數據處理單元； 其中，所述選擇單元，用於從所述確定模塊確定的所有關聯用戶ID中選擇出N個滿足設定條件的特定用戶ID ； 所述數據處理單元，用於拉取所述N個特定用戶ID對應的最新用戶數據，並返回給所述用戶終端；所述N小於等於一個頁面所要求的用戶數據數量M。
7.根據權利要求6所述的裝置，其特徵在於，所述選擇單元通過以下步驟從所述確定模塊確定的所有關聯用戶ID中選擇出N個滿足設定條件的特定用戶ID: 將所有關聯用戶ID發送給預設的網絡設備，所述網絡設備用於記錄任一用戶ID對應的動作行為；接收網絡設備返回的N個用戶ID，所述網絡設備返回的N個用戶ID是由所述網絡設備從接收的所有關聯用戶ID中選擇出的動作行為滿足設定條件的特定用戶ID。
8.根據權利要求7所述的裝置，其特徵在於，所述用戶ID對應的用戶數據為用戶原創內容UGC ； 所述用戶ID對應的動作行為為所述UGC更新或發布的時間； 所述動作行為滿足設定條件包括=UGC發布時間或更新時間最新。
9.根據權利要求8所述的裝置，其特徵在於， 所述UGC為微博消息；或者， 所述UGC為即時通信應用空間發布的消息。
10.根據權利要求6所述的裝置，其特徵在於，所述數據處理單元通過以下步驟拉取N個特定用戶ID對應的最新用戶數據: 從所有底層設備svr中確定出用於管理所述N個特定用戶ID的底層設備； 識別該確定出的底層設備的數量L，將所述請求分成L份請求包，並對應發送至該確定出的L個底層設備，每一份請求包攜帶所述N個特定用戶ID中的至少一個特定用戶ID ； 接收所述L個底層設備返 回的用戶數據，每一個底層設備返回的用戶數據為其接收的請求包攜帶的特定用戶ID對應的最新用戶數據。
【文檔編號】H04L29/08GK103914477SQ201310003705
【公開日】2014年7月9日 申請日期:2013年1月6日 優先權日:2013年1月6日
【發明者】王瑤 申請人:騰訊科技（北京）有限公司