[發明專利]一種信息流數據的處理方法和裝置

在審

• 申請號: 201510364378.4
• 申請日: 2015-06-26
• 公開（公告）號: CN105095365A
• 公開（公告）日: 2015-11-25
• 發明（設計）人: 黃釗
• 申請（專利權）人: 北京奇虎科技有限公司;奇智軟件（北京）有限公司
• 主分類號: G06F17/30
• 分類號: G06F17/30;H04L29/06
• 代理公司: 北京潤澤恒知識產權代理有限公司 11319
• 代理人: 趙娟

技術領域

本發明涉及計算機處理的技術領域，特別是涉及一種信息流數據的處理方法和一種信息流數據的處理裝置。

背景技術

隨著網絡科技的發展，目前許多產品，例如，博客(Blog)、SNS(SocialNetworkSite，社會性網絡服務)、RSS(ReallySimpleSyndication，簡易信息聚合)等等，引入了用戶關注功能，用戶可以在應用中查看到關注對象的歷史行為。

在這些產品中，大多應用了應用到了Feed(信息流)系統，通常需要通過推(push)模式或拉(pull)模式發布Feed(信息流)數據。

在推(push)模式中，需要為每一個用戶維護一張Feed(信息流)列表，當一個用戶發生了特定行為(如發表一條短消息)，系統會往關注他的用戶(俗稱“粉絲”)的Feed(信息流)列表中推送數據。

推(push)模式模式雖然可以讓用戶快捷獲取Feed(信息流)數據，但是，如果一個用戶擁有大量的粉絲，這樣他的每一個特定行為都會造成海量的推送請求，這樣大大增加了服務器的壓力，在推送請求的高峰時段，大量的推送請求與別的業務和服務爭搶公用資源(即“羊群效應”)，發生不可預估的情況。

在拉(pull)模式中，當一個用戶發生了特定行為(如發表一條短消息)時，會將其存儲到一個臨時的Feed(信息流)列表中(只保存近期可接受范圍的數據)，用戶在登陸時根據自身需要從Feed(信息流)列表拉取Feed(信息流)數據。

拉(pull)模式雖然設計簡單，節省存儲空間，但是，Feed(信息流)列表一般需要保存最近十天或者半個月的Feed(信息流)數據，會產生很大的壓力，如果用戶關注了大量的對象，數據庫的壓力就會非常大會，影響拉取數據時的效率問題，而且一般在線的用戶，客戶端都會定期掃描，又會增加很大的壓力，可能造成請求延遲或失敗的現象發生。

發明內容

鑒于上述問題，提出了本發明以便提供一種克服上述問題或者至少部分地解決上述問題的一種信息流數據的處理方法和相應的一種信息流數據的處理裝置。

依據本發明的一個方面，提供了一種信息流數據的處理方法，包括：

當接收到基于第一用戶標識發起的一事件的處理請求時，按照所述處理請求處理所述事件，所述事件具有事件標識；

查找訂閱所述第一用戶標識的信息的第二用戶標識；所述第二用戶標識具有關聯的信息流列表；

將所述事件標識寫入所述信息流列表中；

將所述信息流列表中事件標識對應的事件信息發送至所述第二用戶標識對應的客戶端。

可選地，所述按照所述處理請求處理所述事件的步驟包括：

將所述事件的事件信息存儲到數據庫中。

可選地，所述查找訂閱所述第一用戶標識的信息的第二用戶標識的步驟包括：

生成事件任務；所述事件任務包括第一用戶標識、事件標識；

將所述事件任務寫入預置的任務隊列中；

由預置的守護進程從所述任務隊列中讀取所述事件任務；

由預置的守護進程查找訂閱所述第一用戶標識的信息的第二用戶標識。

可選地，所述事件任務還包括事件類型；

所述將所述事件任務寫入預置的任務隊列中的步驟包括：

將所述事件任務寫入與所述事件類型匹配的、預置的任務隊列中。

可選地，所述由預置的守護進程從所述任務隊列中讀取所述事件任務的步驟包括：

由預置的守護進程按照對所述事件類型設定的讀取頻率，從所述任務隊列中按照先進先出的方式讀取所述事件任務。

可選地，所述事件類型具有優先級，第一事件類型的讀取頻率，高于，第二事件類型的讀取頻率；

其中，第一事件類型為優先級高于第二事件類型的事件類型；

第二事件類型為優先級低于第一事件類型的事件類型。

可選地，所述事件任務還包括事件類型；

所述由所述守護進程查找訂閱所述第一用戶標識的信息的第二用戶標識的步驟包括：

當所述事件類型為發布型時，由所述守護進程查找訂閱所述第一用戶標識的信息的第二用戶標識。

可選地，所述將所述事件標識寫入所述信息流列表中的步驟包括：

由預置的守護進程將所述事件標識寫入存儲在Redis數據庫中的信息流列表。

可選地，所述將所述信息流列表中事件標識對應的事件信息發送至所述第二用戶標識對應的客戶端的步驟包括：