一種信息流數據的處理方法和裝置的制造方法
【技術領域】
[0001]本發明涉及計算機處理的技術領域，特別是涉及一種信息流數據的處理方法和一種信息流數據的處理裝置。
【背景技術】
[0002]隨著網絡科技的發展，目前許多產品，例如，博客(Blog)、SNS(Social NetworkSite，社會性網絡服務)、RSS (Really Simple Syndicat1n，簡易信息聚合)等等，引入了用戶關注功能，用戶可以在應用中查看到關注對象的歷史行為。
[0003]在這些產品中，大多應用了應用到了 Feed(信息流)系統，通常需要通過推(push)模式或拉(pull)模式發布Feed(信息流)數據。
[0004]在推(push)模式中，需要為每一個用戶維護一張Feed(信息流)列表，當一個用戶發生了特定行為(如發表一條短消息)，系統會往關注他的用戶(俗稱“粉絲”)的Feed(信息流)列表中推送數據。
[0005]推(push)模式模式雖然可以讓用戶快捷獲取Feed(信息流)數據，但是，如果一個用戶擁有大量的粉絲，這樣他的每一個特定行為都會造成海量的推送請求，這樣大大增加了服務器的壓力，在推送請求的高峰時段，大量的推送請求與別的業務和服務爭搶公用資源(即“羊群效應”)，發生不可預估的情況。
[0006]在拉(pull)模式中，當一個用戶發生了特定行為(如發表一條短消息)時，會將其存儲到一個臨時的Feed (信息流)列表中(只保存近期可接受范圍的數據)，用戶在登陸時根據自身需要從Feed(信息流)列表拉取Feed(信息流)數據。
[0007]拉(pull)模式雖然設計簡單，節省存儲空間，但是，Feed(信息流)列表一般需要保存最近十天或者半個月的Feed (信息流)數據，會產生很大的壓力，如果用戶關注了大量的對象，數據庫的壓力就會非常大會，影響拉取數據時的效率問題，而且一般在線的用戶，客戶端都會定期掃描，又會增加很大的壓力，可能造成請求延遲或失敗的現象發生。
【發明內容】
[0008]鑒于上述問題，提出了本發明以便提供一種克服上述問題或者至少部分地解決上述問題的一種信息流數據的處理方法和相應的一種信息流數據的處理裝置。
[0009]依據本發明的一個方面，提供了一種信息流數據的處理方法，包括:
[0010]當接收到基于第一用戶標識發起的一事件的處理請求時，按照所述處理請求處理所述事件，所述事件具有事件標識；
[0011]查找訂閱所述第一用戶標識的信息的第二用戶標識；所述第二用戶標識具有關聯的信息流列表；
[0012]將所述事件標識寫入所述信息流列表中；
[0013]將所述信息流列表中事件標識對應的事件信息發送至所述第二用戶標識對應的客戶端。
[0014]可選地，所述按照所述處理請求處理所述事件的步驟包括:
[0015]將所述事件的事件信息存儲到數據庫中。
[0016]可選地，所述查找訂閱所述第一用戶標識的信息的第二用戶標識的步驟包括:
[0017]生成事件任務；所述事件任務包括第一用戶標識、事件標識；
[0018]將所述事件任務寫入預置的任務隊列中；
[0019]由預置的守護進程從所述任務隊列中讀取所述事件任務；
[0020]由預置的守護進程查找訂閱所述第一用戶標識的信息的第二用戶標識。
[0021 ] 可選地，所述事件任務還包括事件類型；
[0022]所述將所述事件任務寫入預置的任務隊列中的步驟包括:
[0023]將所述事件任務寫入與所述事件類型匹配的、預置的任務隊列中。
[0024]可選地，所述由預置的守護進程從所述任務隊列中讀取所述事件任務的步驟包括:
[0025]由預置的守護進程按照對所述事件類型設定的讀取頻率，從所述任務隊列中按照先進先出的方式讀取所述事件任務。
[0026]可選地，所述事件類型具有優先級，第一事件類型的讀取頻率，高于，第二事件類型的讀取頻率；
[0027]其中，第一事件類型為優先級高于第二事件類型的事件類型；
[0028]第二事件類型為優先級低于第一事件類型的事件類型。
[0029]可選地，所述事件任務還包括事件類型；
[0030]所述由所述守護進程查找訂閱所述第一用戶標識的信息的第二用戶標識的步驟包括:
[0031]當所述事件類型為發布型時，由所述守護進程查找訂閱所述第一用戶標識的信息的第二用戶標識。
[0032]可選地，所述將所述事件標識寫入所述信息流列表中的步驟包括:
[0033]由預置的守護進程將所述事件標識寫入存儲在Redis數據庫中的信息流列表。
[0034]可選地，所述將所述信息流列表中事件標識對應的事件信息發送至所述第二用戶標識對應的客戶端的步驟包括:
[0035]當所述第二用戶標識關聯在線狀態時，按照所述信息流列表中事件標識的時間順序，將所述事件標識對應的事件信息發送至所述第二用戶標識對應的客戶端。
[0036]根據本發明的另一方面，提供了一種信息流數據的處理裝置，包括:
[0037]事件處理模塊，適于在接收到基于第一用戶標識發起的一事件的處理請求時，按照所述處理請求處理所述事件，所述事件具有事件標識；
[0038]用戶標識查找模塊，適于查找訂閱所述第一用戶標識的信息的第二用戶標識；所述第二用戶標識具有信息流列表；
[0039]信息流列表寫模塊，適于將所述事件標識寫入所述信息流列表中；
[0040]事件信息發送模塊，適于將所述信息流列表中事件標識對應的事件信息發送至所述第二用戶標識對應的客戶端。
[0041 ] 可選地，所述事件處理模塊還適于:
[0042]將所述事件的事件信息存儲到數據庫中。
[0043]可選地，所述用戶標識查找模塊還適于:
[0044]生成事件任務；所述事件任務包括第一用戶標識、事件標識；
[0045]將所述事件任務寫入預置的任務隊列中；
[0046]由預置的守護進程從所述任務隊列中讀取所述事件任務；
[0047]由預置的守護進程查找訂閱所述第一用戶標識的信息的第二用戶標識。
[0048]可選地，所述事件任務還包括事件類型；所述用戶標識查找模塊還適于:
[0049]將所述事件任務寫入與所述事件類型匹配的、預置的任務隊列中。
[0050]可選地，所述用戶標識查找模塊還適于:
[0051]由預置的守護進程按照對所述事件類型設定的讀取頻率，從所述任務隊列中按照先進先出的方式讀取所述事件任務。
[0052]可選地，所述事件類型具有優先級，第一事件類型的讀取頻率，高于，第二事件類型的讀取頻率；
[0053]其中，第一事件類型為優先級高于第二事件類型的事件類型；
[0054]第二事件類型為優先級低于第一事件類型的事件類型。
[0055]可選地，所述事件任務還包括事件類型；所述用戶標識查找模塊還適于:
[0056]當所述事件類型為發布型時，由所述守護進程查找訂閱所述第一用戶標識的信息的第二用戶標識。
[0057]可選地，所述信息流列表寫模塊還適于:
[0058]由預置的守護進程將所述事件標識寫入存儲在Redis數據庫中的信息流列表。
[0059]可選地，所述事件信息發送模塊還適于:
[0060]當所述第二用戶標識關聯在線狀態時，按照所述信息流列表中事件標識的時間順序，將所述事件標識對應的事件信息發送至所述第二用戶標識對應的客戶端。
[0061]本發明實施例將基于第一用戶標識觸發的事件的事件標識寫入訂閱第一用戶標識的信息的第二用戶標識關聯的信息流列表中，在第二用戶標識關聯在線狀態時，發送相應的事件信息，通過異步推送在延遲允許的時間范圍內進行事件整合統一處理，降低了數據的并發執行數，大大減輕了服務器壓力。
[0062]本發明實施例通過任務隊列有序執行事件任務，一方面，增加的災難發生時的數據可恢復手段，另一方面，保證了按時間維度的任務優先級區分。
[0063]本發明實施例中的Redis數據庫支持高并發的讀寫操作，保證了用戶信息讀寫更新的及時性，保證了用戶體驗。
[0064]上述說明僅是本發明技術方案的概述，為了能夠更清楚了解本發明的技術手段，而可依照說明書的內容予以實施，并且為了讓本發明的上述和其它目的、特征和優點能夠更明顯易懂，以下特舉本發明的【具體實施方式】。
【附圖說明】
[0065]通過閱讀下文優選實施方式的詳細描述，各種其他的優點和益處對于本領域普通技術人員將變得清楚明了。附圖僅用于示出優選實施方式的目的，而并不認為是對本發明的限制。而且在整個附圖中，用相同的參考符號表示相同的部件。在附圖中:
[0066]圖1示出了根據本發明一個實施例的一種信息流數據的處理方法實施例的步驟流程圖；
[0067]圖2示出了根據本發明一個實施例的一種Feed系統的架構圖；
[0068]圖3示出了根據本發明一個實施例的一種守護進程的處理流程示例圖；以及
[0069]圖4示出了根據本發明一個實施例的一種信息流數據的處理裝置實施例的結構框圖。
【具體實施方式】
[0070]下面將參照附圖更詳細地描述本公開的示例性實施例。雖然