用戶狀態統計系統及方法
【專利摘要】本發明公開了一種用戶狀態統計系統及方法，至少能夠解決傳統的單機統計方式因受限于單個服務器的處理速度以及內存容量而無法滿足互聯網用戶大規模增長需求，以及不支持擴展、災備效果不佳的技術問題。該用戶狀態統計系統包括：服務器集群，以及與服務器集群相連的SSDB數據庫，其中，服務器集群包括多個服務器節點，各個服務器節點分別用于處理各個用戶終端發送的打點請求，并根據打點請求生成用戶狀態消息，將用戶狀態消息提供給SSDB數據庫；SSDB數據庫用于對各個服務器節點提供的用戶狀態消息進行統計，根據統計結果生成并存儲用戶狀態信息。
【專利說明】
用戶狀態統計系統及方法
技術領域
[0001]本發明涉及網絡通信技術領域，具體涉及一種用戶狀態統計系統及方法。【背景技術】
[0002]隨著互聯網技術的日趨成熟，網絡應用的種類和數量也越來越多，出現了多種多樣的網絡應用，例如網絡游戲、網絡直播等。為了更好地為用戶提供服務，這些網絡應用的提供商往往需要對用戶狀態進行統計。
[0003]目前，在統計用戶狀態時，是由一個單獨的服務器節點接收來自在線用戶終端的打點請求，獲取其中包含的打點數據，并將根據打點數據得到的用戶狀態信息保存到內存中。當需要查詢某用戶的狀態時，由該服務器節點從內存中讀取用戶狀態信息并反饋查詢結果。[〇〇〇4]由于目前的用戶狀態信息采用內存存儲方式，因此，只能通過單機實現用戶在線狀態的統計。然而，單機統計的方式僅適用于用戶量級較小的應用場景中，隨著互聯網用戶的增多，一個網絡應用的在線用戶數量動輒達到千萬級甚至億萬級的量級，受到單個服務器的處理速度以及內存容量的制約，傳統的單機統計方式無法支持如此龐大的用戶量。而且，這種基于內存存儲的單機統計方式也無法支持擴展:如果將用于統計用戶狀態的服務器擴展到兩個或多個，由于各個服務器分別通過各自的內存來存儲用戶狀態信息，所以，當需要查詢某用戶的狀態時，無法確定該從哪個服務器中進行查詢。由此可見，傳統的單機統計方式無法滿足互聯網用戶大規模增長的需求。不僅如此，在單機統計的方式中，如果該服務器故障，將直接導致統計過程的中斷。
[0005]由此可見，在傳統的實現方式中，受到單個服務器的內存容量的制約，導致無法統計大量級的用戶人數，且不支持擴展、災備效果不佳。
【發明內容】
[0006]鑒于上述問題，提出了本發明以便提供一種克服上述問題或者至少部分地解決上述問題的用戶在線狀態統計系統及方法。
[0007]依據本發明的一個方面，提供了一種用戶狀態統計系統，包括:服務器集群，以及與服務器集群相連的SSDB數據庫，其中，服務器集群包括多個服務器節點，各個服務器節點分別用于處理各個用戶終端發送的打點請求，并根據打點請求生成用戶狀態消息，將用戶狀態消息提供給SSDB數據庫;SSDB數據庫用于對各個服務器節點提供的用戶狀態消息進行統計，根據統計結果生成并存儲用戶狀態信息。
[0008]可選地，用戶狀態消息包括用戶上線消息和用戶下線消息，且各個用戶終端在其在線期間，每隔預設時間間隔發送一次打點請求，則各個服務器節點具體用于:每當接收到用戶終端發送的打點請求后，判斷是否存儲有對應于該用戶終端的定時器，如果判斷結果為是，則根據本次打點請求向對應于該用戶終端的定時器發送延續指令;如果判斷結果為否，則創建對應于該用戶終端的定時器，并為該用戶終端生成用戶上線消息；其中，各個服務器節點持續地對本地存儲的各個定時器進行監測，每當監測到在預設的超時時間閾值內未接收到延續指令的定時器時，將該定時器銷毀，并為該定時器所對應的用戶終端生成用戶下線消息。
[0009]可選地，打點請求中包括應用信息字段，且應用信息字段進一步包括多個分別指示不同維度的應用信息的子字段，則對應于一個用戶終端的定時器進一步包括多個子定時器，各個子定時器分別對應于不同維度的狀態信息;并且，用戶上線消息進一步包括各個維度所對應的用戶上線消息，且用戶下線消息進一步包括各個維度所對應的用戶下線消息。
[0010]可選地，系統進一步包括:公共消息隊列模塊以及后端處理模塊，其中，各個服務器節點用于將生成的用戶狀態消息存儲到公共消息隊列模塊中，后端處理模塊用于讀取公共消息隊列模塊中的用戶狀態消息，并根據讀取到的用戶狀態消息修改SSDB數據庫中存儲的用戶狀態信息。
[0011]可選地，服務器集群中進一步包括:至少一個反向代理模塊，用于接收各個用戶終端發送的打點請求，獲取打點請求中包含的用戶標識，通過預設的哈希算法對用戶標識進行計算，根據計算結果將各個打點請求分配給各個服務器節點處理。
[0012]可選地，反向代理模塊進一步用于:檢測各個服務器節點的工作狀態，當檢測到出現故障的服務器節點時，停用出現故障的服務器節點；并在檢測到故障恢復時，重新啟用出現故障的服務器節點。
[0013]可選地，系統進一步包括:與SSDB數據庫相連的查詢服務器，用于根據接收到的查詢請求，查詢SSDB數據庫中存儲的用戶狀態信息，并返回與該查詢請求相對應的查詢結果； 并且，查詢服務器進一步用于:監測各個應用和/或應用的各個維度的用戶在線人數，當監測到的用戶在線人數的變化率大于預設閾值時，發出報警提示信息。
[0014]可選地，打點請求中包括應用類型字段，則服務器節點進一步用于:根據應用類型字段將用戶狀態消息推送給對應類型的應用。
[0015]可選地，打點請求為異步請求消息。
[0016]依據本發明的另一方面，提供了一種用戶狀態統計方法，包括:通過服務器集群中的多個服務器節點處理各個用戶終端發送的打點請求;根據打點請求生成用戶狀態消息， 將用戶狀態消息發送給SSDB數據庫;通過SSDB數據庫對各個服務器節點提供的用戶狀態消息進行統計，根據統計結果生成并存儲用戶狀態信息。
[0017]可選地，用戶狀態消息包括用戶上線消息和用戶下線消息，且各個用戶終端在其在線期間，每隔預設時間間隔發送一次打點請求，則根據打點請求生成用戶狀態消息的步驟具體包括:每當接收到用戶終端發送的打點請求后，判斷是否存儲有對應于該用戶終端的定時器，如果判斷結果為是，則根據本次打點請求向對應于該用戶終端的定時器發送延續指令;如果判斷結果為否，則創建對應于該用戶終端的定時器，并為該用戶終端生成用戶上線消息;其中，各個服務器節點持續地對本地存儲的各個定時器進行監測，每當監測到在預設的超時時間閾值內未接收到延續指令的定時器時，將該定時器銷毀，并為該定時器所對應的用戶終端生成用戶下線消息。
[0018]可選地，打點請求中包括應用信息字段，且應用信息字段進一步包括多個分別指示不同維度的應用信息的子字段，則對應于一個用戶終端的定時器進一步包括多個子定時器，各個子定時器分別對應于不同維度的狀態信息;并且，用戶上線消息進一步包括各個維度所對應的用戶上線消息，且用戶下線消息進一步包括各個維度所對應的用戶下線消息。
[0019]可選地，將用戶狀態消息發送給SSDB數據庫的步驟具體包括:各個服務器節點將生成的用戶狀態消息存儲到預設的公共消息隊列模塊中，由預設的后端處理模塊將公共消息隊列模塊中的用戶狀態消息提供給SSDB數據庫。
[0020]可選地，通過服務器集群中的多個服務器節點處理各個用戶終端發送的打點請求的步驟具體包括:通過至少一個反向代理模塊接收各個用戶終端發送的打點請求，獲取打點請求中包含的用戶標識，通過預設的哈希算法對用戶標識進行計算，根據計算結果將各個打點請求分配給各個服務器節點處理。
[0021]可選地，方法進一步包括步驟:通過反向代理模塊檢測各個服務器節點的工作狀態，當檢測到出現故障的服務器節點時，停用出現故障的服務器節點;并在檢測到故障恢復時，重新啟用出現故障的服務器節點。
[0022]可選地，方法包括:根據接收到的查詢請求，查詢SSDB數據庫中存儲的用戶狀態信息，并返回與該查詢請求相對應的查詢結果;并且，方法進一步包括:監測各個應用和/或應用的各個維度的用戶在線人數，當監測到的用戶在線人數的變化率大于預設閾值時，發出報警提示信息。
[0023]可選地，打點請求中包括應用類型字段，則方法進一步包括步驟:根據應用類型字段將用戶狀態消息推送給對應類型的應用。
[0024]可選地，打點請求為異步請求消息。
[0025]在本發明提供的用戶狀態統計系統及方法中，通過包含多個服務器節點的服務器集群接收來自各個用戶終端的打點請求，并根據打點請求生成用戶狀態消息，將該用戶狀態消息提供給SSDB數據庫，以供SSDB數據庫根據用戶狀態消息維護用戶狀態信息。由此可見，在本發明中，服務器節點通過集群形式實現，且數量為多個，因而能夠并行處理各個用戶終端發來的打點請求，大幅提高了服務器節點的處理速度，縮短了響應時間，能夠同時服務于更多的用戶終端。另外，由于用戶狀態信息存儲在SSDB數據庫內，而非存儲在服務器節點的內存中，因此，上述服務器集群中所包含的服務器節點的數量可以靈活調整:當用戶數量多時，可以通過掛接一個服務器節點來服務于更多的用戶；當用戶數量少時，可以摘除一個服務器節點以節約成本。由此可見，本申請提供的方式具有較強的可擴展性，系統設計較為靈活。除此之外，當某一個服務器節點故障時，其他服務器節點依然能夠確保整個系統的正常運行，因此，本申請提供的方式具有較強的災備功能。
[0026]上述說明僅是本發明技術方案的概述，為了能夠更清楚了解本發明的技術手段， 而可依照說明書的內容予以實施，并且為了讓本發明的上述和其它目的、特征和優點能夠更明顯易懂，以下特舉本發明的【具體實施方式】。【附圖說明】
[0027]通過閱讀下文優選實施方式的詳細描述，各種其他的優點和益處對于本領域普通技術人員將變得清楚明了。附圖僅用于示出優選實施方式的目的，而并不認為是對本發明的限制。而且在整個附圖中，用相同的參考符號表示相同的部件。在附圖中:
[0028]圖1示出了本發明一個實施例提供的用戶狀態統計系統的結構圖；
[0029]圖2示出了本發明另一具體實施例提供的用戶狀態統計系統的結構圖；
[0030]圖3示出了本發明一個實施例提供的用戶狀態統計方法的流程圖；[〇〇31 ]圖4示出了本發明一個具體實施例提供的用戶狀態統計方法的流程圖。【具體實施方式】
[0032]下面將參照附圖更詳細地描述本公開的示例性實施例。雖然附圖中顯示了本公開的示例性實施例，然而應當理解，可以以各種形式實現本公開而不應被這里闡述的實施例所限制。相反，提供這些實施例是為了能夠更透徹地理解本公開，并且能夠將本公開的范圍完整的傳達給本領域的技術人員。
[0033]本發明實施例提供了一種用戶狀態統計系統及方法，至少能夠解決傳統的單機統計方式因受限于單個服務器的處理速度以及內存容量而無法滿足互聯網用戶大規模增長需求，以及不支持擴展、災備效果不佳的技術問題。
[0034]圖1示出了本發明一個實施例提供的用戶狀態統計系統的功能框圖。如圖1所示， 該用戶狀態統計系統包括:服務器集群11，以及與服務器集群11相連的SSDB數據庫12。其中，服務器集群11包括多個服務器節點10,各個服務器節點10分別用于處理各個用戶終端發送的打點請求，并根據打點請求生成用戶狀態消息，將用戶狀態消息提供給SSDB數據庫 12;SSDB數據庫12用于對各個服務器節點10提供的用戶狀態消息進行統計，根據統計結果生成并存儲用戶狀態信息。
[0035]由此可見，在本發明中，服務器節點通過集群形式實現，且數量為多個，因而能夠并行處理各個用戶終端發來的打點請求，大幅提高了服務器節點的處理速度，縮短了響應時間，能夠同時服務于更多的用戶終端。另外，由于用戶狀態信息存儲在SSDB數據庫內，而非存儲在服務器節點的內存中，因此，上述服務器集群中所包含的服務器節點的數量可以靈活調整:當用戶數量多時，可以通過掛接一個服務器節點來服務于更多的用戶；當用戶數量少時，可以摘除一個服務器節點以節約成本。由此可見，本申請提供的方式具有較強的可擴展性，系統設計較為靈活。除此之外，當某一個服務器節點故障時，其他服務器節點依然能夠確保整個系統的正常運行，因此，本申請提供的方式具有較強的災備功能。
[0036]圖2示出了本發明一個具體實施例提供的用戶狀態統計系統的結構示意圖。如圖2 所示，該系統包括:服務器集群20、公共消息隊列模塊21、后端處理模塊22、SSDB數據庫23以及查詢服務器24。其中，服務器集群20又進一步包括:第一反向代理模塊201、第二反向代理模塊202、第一服務器節點203、第二服務器節點204以及第三服務器節點205。下面結合圖2 詳細介紹該系統的各個部件/模塊的具體結構和功能:[〇〇37]服務器集群20能夠通過多個服務器節點并行處理大量用戶終端發來的打點請求， 并根據打點請求生成用戶狀態消息。具體地，在本實施例中，由第一反向代理模塊201和第二反向代理模塊202來接收大量用戶終端發送的打點請求。其中，每個用戶終端在其在線期間，每隔預設時間間隔發送一次打點請求，以表明其當前處于在線狀態。第一反向代理模塊 201和第二反向代理模塊202可以通過兩臺單獨的Nginx反向代理服務器來實現。反向代理模塊的功能主要是接收來自前端的用戶終端的打點請求，并將打點請求發送給服務器集群中的各個服務器節點。另外，本領域技術人員也可以對反向代理模塊的數量和具體形式進行靈活更改，例如，可以設置一個或更多個反向代理模塊，另外，反向代理模塊也可以采用其他形式的網絡服務器來實現。而且，反向代理模塊除了采用單獨的網絡服務器來實現之夕卜，也可以直接集成在各個服務器節點上，例如，將第一反向代理模塊201直接集成在第一服務器節點203上，將第二反向代理模塊202直接集成在第二服務器節點204上。另外，在本發明其他的實施例中，本領域技術人員也可以省略第一反向代理模塊201和第二反向代理模塊202,直接由各個服務器節點來接收用戶終端的打點請求。[〇〇38]反向代理模塊的功能至少包括如下兩點:第一，反向代理模塊可以將多個用戶終端發來的打點請求按照一定的規則分配給各個服務器節點，以使各個服務器節點相互并行工作，從而能夠同時處理海量用戶終端的請求，提高系統吞吐量，降低處理時延，并近似實現負載均衡的效果。為此，各個反向代理模塊接收到用戶終端發送的打點請求后，獲取本次打點請求中包含的用戶標識，通過預設的哈希算法對該用戶標識進行計算，并根據計算結果將各個打點請求分配給各個服務器節點處理。除了采用哈希算法外，也可以采用隨機算法來分配打點請求，或者，也可以將各次接收到的打點請求依次發給各個服務器節點處理。 另外，由于各個服務器節點需要對用戶終端的狀態進行持續維護，因此，優選地，同一用戶終端發送的各次打點請求應分配給同一服務器節點處理，例如，假設用戶終端A首次發送的打點請求由第一服務器節點203處理，則該用戶終端A后續發送的打點請求都應由第一服務器節點203處理，如果由于分發錯誤或網絡傳輸錯誤等各類原因導致用戶終端A后續發送的某一次打點請求分配給了第二服務器節點204,則第二服務器節點204通過預設的哈希算法對該用戶標識進行計算后，確認該打點請求應由第一服務器節點203處理，則第二服務器節點204將本次打點請求轉發給第一服務器節點203。由此可見，在本實施例中，各個服務器節點本身還具備對打點請求中的用戶標識進行計算的能力，因此能夠確保同一用戶終端發送的各次打點請求均由同一服務器節點處理，從而便于服務器節點對用戶終端的狀態進行持續維護。[〇〇39]第二，反向代理模塊還可以檢測各個服務器節點的工作狀態，當檢測到出現故障的服務器節點時，停用出現故障的服務器節點；并在檢測到該故障恢復時，重新啟用之前出現故障的服務器節點。由此，能夠提高系統的魯棒性，防止因某一服務器節點出現故障而影響整個系統的正常運行，使系統具備較好的災備效果。例如，反向代理模塊201向服務器節點發送打點請求后，要求服務器節點返回確認數據包，若某一服務器節點在規定時間內未返回確認數據包，則反向代理模塊確定相應的服務器節點出現故障，從而暫時停用該服務器節點，將原本由該服務器節點處理的打點請求切換到其他的服務器節點處理。另外，也可以通過服務器節點定期向反向代理模塊發送心跳包的方式來檢測各個服務器節點是否出現故障。
[0040]各個服務器節點接收到打點請求后，根據打點請求對相應的用戶終端的狀態進行維護，并根據用戶終端的狀態生成用戶狀態消息。具體地，服務器節點可以根據用戶狀態文件來維護各個用戶終端的狀態。其中，用戶狀態文件可以通過字典、日志等多種形式實現， 其中記錄了所有處于在線狀態的用戶終端所對應的狀態記錄。當服務器節點接收到用戶終端發送的打點請求后，獲取打點請求中包含的用戶標識，并在預設的用戶狀態文件中查詢是否包含該用戶標識所對應的狀態記錄。如果在預設的用戶狀態文件中查詢到了該用戶標識所對應的狀態記錄，說明該用戶終端已經上線并處于在線狀態；如果在預設的用戶狀態文件中未查詢到該用戶標識所對應的狀態記錄，說明該用戶終端剛剛上線，相應地，為該用戶終端生成的用戶狀態消息為用戶上線消息。
[0041]除了通過用戶狀態文件來維護各個用戶終端的狀態之外，為了更加有效地監測各個用戶終端的上線動作和下線動作，在本實施例中，也可以通過定時器來記錄各個用戶終端的狀態。相應地，每當服務器節點接收到用戶終端發送的打點請求后，判斷是否存儲有對應于該用戶終端的定時器，如果判斷結果為是，說明該用戶終端已經處于在線狀態，則根據本次打點請求向對應于該用戶終端的定時器發送延續指令;如果判斷結果為否，說明該用戶終端剛剛上線，則創建對應于該用戶終端的定時器，并為該用戶終端生成用戶上線消息； 其中，各個服務器節點持續地對本地存儲的各個定時器進行監測，每當監測到在預設的超時時間閾值內未接收到延續指令的定時器時，將該定時器銷毀，并為該定時器所對應的用戶終端生成用戶下線消息。由此可見，通過定時器能夠監測到各個用戶終端的上線動作和下線動作，并在用戶終端上線時生成用戶上線消息，在用戶終端下線時生成用戶下線消息。 用戶狀態消息除包含上述的用戶上線消息和用戶下線消息外，還可以進一步包含用于指示用戶終端目前處于在線狀態的用戶在線消息等。
[0042]在本實施例中，各個服務器節點將生成的用戶狀態消息存儲到公共消息隊列模塊 21中。其中，公共消息隊列模塊用于通過公共消息隊列對用戶狀態消息進行有序存儲，其可以通過一臺單獨的服務器實現，也可以集成在SSDB數據庫上。公共消息隊列是一種先進先出的分布式消息隊列，能夠在消息傳輸過程中作為保存消息的容器，從而為程序或組件提供異步的通信機制，使發送方和接收方不必同時在線，也不必了解對方，就可以相互傳輸消息。在本實施例中，通過公共消息隊列模塊21對各個服務器節點生成的用戶狀態消息進行統一存儲。存儲在公共消息隊列模塊21中的用戶狀態消息由后端處理模塊22負責處理。具體地，后端處理模塊22可以通過服務器上的一個進程來實現。后端處理模塊22與公共消息隊列模塊21之間可以通過訂閱模式或點對點模式等多種方式進行通信。每當公共消息隊列模塊21中存儲了新的用戶狀態消息時，后端處理模塊22負責讀取該用戶狀態消息，并根據該用戶狀態消息修改SSDB數據庫中存儲的用戶狀態信息。例如，當后端處理模塊讀取到的用戶狀態消息為用戶上線消息時，則在SSDB數據庫中增加相應用戶終端的上線狀態信息； 當后端處理模塊讀取到的用戶狀態消息為用戶下線消息時，則在SSDB數據庫中刪除相應用戶終端的上線狀態信息。[〇〇43] SSDB數據庫23負責根據后端處理模塊發送的指令對用戶狀態信息進行存儲及維護。在SSDB數據庫中記錄了各個用戶終端的上線時間、下線時間、在線時長等具體信息。由于SSDB服務器為高性能數據庫服務器，其能夠提供內存式存儲服務，且支持擴容，能夠在存儲容量不足時通過掛接一個SSDB服務器來實現擴容存儲方案，從而實現存儲容量的自由擴展。因此，通過SSDB數據庫能夠存儲海量的用戶狀態信息。[〇〇44]查詢服務器24能夠根據接收到的查詢請求，查詢SSDB數據庫23中存儲的用戶狀態信息，并返回與該查詢請求相對應的查詢結果。其中，查詢服務器不僅能夠查詢各個用戶終端的當前狀態、在線時長等信息，還能夠進行多維度、多類型的查詢。
[0045]所謂多維度的查詢，是指能夠查詢某一具體應用的各個維度的信息。例如，以游戲應用為例來說，該應用至少包含平臺、游戲和區服這三個不同維度的應用信息；又如，以熊貓直播應用為例來說，該應用至少包含終端類型(如PC web端和安卓端)、房間號這兩個不同維度的應用信息。為了能夠提供多個維度的查詢，首先，需要在上文提到的用戶終端發送的打點請求中包含多個維度的信息，例如，打點請求為“/Hit/Proc?uid = &loc = &prj = &sec = &0ther=”，其中，“loc”字段為應用信息字段，該字段進一步包括多個分別指示不同維度的應用信息的子字段。
[0046]假設某用戶終端A在上午10:00發送的打點請求中的應用信息字段為l〇C = y〇Uxi dzz| si，該字段內包含三個子字段，各個子字段之間用豎線分隔，第一個子字段“youxi”用于表示發送本次打點請求的用戶終端A目前處于游戲平臺在線狀態，第二個子字段“dzz”用于表示發送本次打點請求的用戶終端目前在線的游戲名稱為“大主宰”，第三個子字段“si” 用于表示發送本次打點請求的用戶終端目前在線的區服為“si區服”。服務器節點接收到本次打點請求后，需要為用戶終端A創建對應的定時器A，以指示用戶終端A處于在線狀態，為了清楚地顯示出用戶終端A在應用的各個維度的在線情況，服務器節點所創建的定時器A還需要進一步包括三個子定時器，其中，子定時器A1用于記錄用戶終端A在上午10:00時處于游戲平臺在線狀態，子定時器A2用于記錄用戶終端A在上午10:00時處于游戲平臺中的“大主宰”游戲在線狀態，子定時器A3用于記錄用戶終端A在上午10:00時處于游戲平臺的“大主宰”游戲中的“s 1”區服在線狀態。
[0047]假設該用戶終端A在上午10:10發送的打點請求中的應用信息字段為l〇C = y〇Uxi dzz|S2,由此可以看出，用戶終端A處于游戲平臺中的大主宰游戲的s2區服在線狀態。服務器節點接收到本次打點請求后，為用戶終端A對應的定時器A發送延續指令，以延續定時器A 的生命周期，從而指示用戶終端A仍然處于在線狀態。另外，由于用戶終端A依然處于游戲平臺在線狀態，因此，為子定時器A1發送延續指令，從而指示用戶終端A仍然處于游戲平臺在線狀態。由于用戶終端A依然處于游戲“大主宰”在線狀態，因此，為子定時器A2發送延續指令，從而指示用戶終端A仍然處于游戲平臺中的“大主宰”游戲的在線狀態。但是，由于用戶終端A從si區服換到了 s2區服，因此，將子定時器A3銷毀，以表明用戶終端A已不在si區服， 并重新創建子定時器A3’，子定時器A3’用于記錄用戶終端A在上午10:10時處于游戲平臺的 “大主宰”游戲中的“s2”區服在線狀態。
[0048]又假設該用戶終端A在上午10: 20發送的打點請求中的應用信息字段為loc = youxi | hazg | si，由此可以看出，用戶終端A處于游戲平臺中的“黑暗之光”游戲的si區服在線狀態。服務器節點接收到本次打點請求后，為用戶終端A對應的定時器A發送延續指令，以延續定時器A的生命周期，從而指示用戶終端A仍然處于在線狀態。另外，由于用戶終端A依然處于游戲平臺在線狀態，因此，為子定時器A1繼續發送延續指令，從而指示用戶終端A仍然處于游戲平臺在線狀態。由于用戶終端A已退出游戲“大主宰”，因此，將子定時器A2銷毀， 并重新創建子定時器A2’，子定時器A2’用于記錄用戶終端A處于游戲平臺中的“黑暗之光” 游戲的在線狀態。同理，由于用戶終端A已退出大主宰游戲的s2區服，因此，將子定時器A3’ 銷毀，并重新創建子定時器A3”，子定時器A3”用于記錄用戶終端A在上午10:20時處于游戲平臺的“黑暗之光”游戲中的“s2”區服在線狀態。
[0049]相應地，在上述過程中，服務器節點生成的用戶狀態消息也進一步包括多個維度的狀態消息。例如，當接收到用戶終端A在上午10:00發送的打點請求后，服務器節點生成用于指示用戶終端A上線的用戶上線消息，同時，在該用戶上線消息中進一步包括多個維度的子消息，例如，第一子消息用于指示用戶終端A在游戲平臺上線，第二子消息用于指示用戶終端A在游戲平臺的大主宰游戲上線，第三子消息用于指示用戶終端A在游戲平臺的大主宰游戲的si區服上線。當接收到用戶終端A在上午10:10發送的打點請求后，服務器節點進一步生成用于指示用戶終端A在游戲平臺的大主宰游戲的si區服下線的子消息，以及用于指示用戶終端A在游戲平臺的大主宰游戲的s2區服上線的子消息。同理，當接收到用戶終端A 在上午10:20發送的打點請求后，服務器節點進一步生成用于指示用戶終端A在游戲平臺的大主宰游戲下線的子消息以及在游戲平臺的大主宰游戲的s2區服下線的子消息，以及用于指示用戶終端A在游戲平臺的黑暗之光游戲上線的子消息以及用于指示用戶終端A在游戲平臺的黑暗之光游戲的si區服上線的子消息。由此可見，SSDB數據庫中存儲了應用的各個維度的上下線狀態信息，因此，查詢服務器可以查詢某一具體維度所對應的用戶狀態信息， 例如，可以查詢某用戶終端在游戲平臺的在線時間、在大主宰游戲(或黑暗之光等其他游戲)的在線時間、以及在某一游戲的si區服或s2區服的在線時間等。
[0050]所謂多類型的查詢，是指本系統支持對多種應用類型所對應的用戶狀態進行統計和查詢，為此，需要在打點請求中進一步包含應用類型字段。例如，本系統支持游戲應用、熊貓直播應用、聊天應用等多種應用類型，當打點請求為“/Hit/Proc?uid = &loc = &prj = & sec = &other = ”時，通過其中的“pr j”字段來表示具體應用的類型。服務器節點可以通過 uhttp: //hulk.corp.qiho0.net: 8360/console/service/qconf，；地址中的 “qconf” 字段來設置應用類型所對應的配置信息，例如，當“qconf”字段的值為1時，表示需要向對應類型的應用推送用戶狀態消息；當“qconf”字段的值為0時，表示不需要向對應類型的應用推送用戶狀態消息。具體地，可以根據應用提供商的具體需求來配置“qconf”字段的值，例如，假設游戲應用提供商希望了解用戶的實時狀態，則可以通過服務器節點向游戲應用實時推送用戶上/下線消息。
[0051]另外，本系統中的查詢服務器除了支持多維度、多類型的查詢之外，還可以進一步監測系統中其他模塊的工作狀態，例如，查詢服務器持續監測各個應用和/或應用的各個維度的用戶在線人數，當監測到某一應用或某一應用的某一維度的用戶在線人數的變化率大于預設閾值時，則發出報警提示信息。例如，當大主宰游戲的用戶在線人數在常規時段(如白天)內突然發生較大的波動時，例如，從1萬人在線突然跌至1〇〇人在線，則可以推測該系統中的某一模塊，例如某一臺服務器節點出現了故障，因此，通過監測在線人數的實時變化率還能夠起到報警提示的作用。[〇〇52]綜上所述，在本實施例提供的用戶狀態統計系統中，能夠實時統計大量用戶終端的在線狀態，并且，能夠進行多維度、多類型的狀態統計和查詢。另外，在本系統中，用戶狀態信息并非存儲在服務器節點的內存中，而是存儲在后端的SSDB數據庫中，因此，系統容量不必受限于單臺服務器節點的內容，且服務器節點的數量可以根據實際需要進行靈活地增加或刪減，使系統設計更為靈活。另外，在本系統中，通過公共消息隊列模塊實現了前端的用戶終端和服務器節點與后端的SSDB數據庫之間的異步處理，用戶終端可以通過異步方式發送打點請求，后端SSDB數據庫通過異步方式進行處理，從而使用戶終端及服務器節點能夠更加高效地運行。
[0053]圖3示出了本發明另一實施例提供的用戶狀態統計方法的流程圖。如圖3所示，該方法具體包括如下步驟:[〇〇54]步驟S310:通過服務器集群中的多個服務器節點處理各個用戶終端發送的打點請求。
[0055]具體實現時，可以由各個服務器節點直接接收并處理各個用戶終端的打點請求。也可以通過至少一個反向代理模塊接收各個用戶終端發送的打點請求，反向代理模塊獲取打點請求中包含的用戶標識，通過預設的哈希算法對用戶標識進行計算，根據計算結果將各個打點請求分配給各個服務器節點處理。總之，通過多個服務器節點能夠實現并行處理、 冗余備份等多重效果。
[0056]步驟S320:根據打點請求生成用戶狀態消息，將用戶狀態消息發送給SSDB數據庫。 [〇〇57]其中，用戶狀態消息包括用戶上線消息和用戶下線消息，且各個用戶終端在其在線期間，每隔預設時間間隔發送一次打點請求。具體地，該步驟可以通過如下方式實現:每當接收到用戶終端發送的打點請求后，判斷是否存儲有對應于該用戶終端的定時器，如果判斷結果為是，則根據本次打點請求向對應于該用戶終端的定時器發送延續指令;如果判斷結果為否，則創建對應于該用戶終端的定時器，并為該用戶終端生成用戶上線消息；其中，各個服務器節點持續地對本地存儲的各個定時器進行監測，每當監測到在預設的超時時間閾值內未接收到延續指令的定時器時，將該定時器銷毀，并為該定時器所對應的用戶終端生成用戶下線消息。除采用定時器的實現方式外，還可以靈活采用日志、字典等多種方式來維護用戶狀態信息。[〇〇58]步驟S330:通過SSDB數據庫對各個服務器節點提供的用戶狀態消息進行統計，根據統計結果生成并存儲用戶狀態信息。
[0059]具體地，可以由SSDB數據庫直接接收各個服務器節點發送的用戶狀態消息，也可以由各個服務器節點將生成的用戶狀態消息存儲到預設的公共消息隊列模塊中，然后由預設的后端處理模塊將公共消息隊列模塊中的用戶狀態消息提供給所述SSDB數據庫。總之， 本領域技術人員可以靈活采用多種方式實現本步驟。
[0060]上述步驟的具體實現細節可參照上一實施例中相應部分的描述，此處不再贅述。
[0061]圖4示出了本發明另一具體實施例提供的用戶狀態統計方法的流程圖。如圖4所示，該方法具體包括如下步驟:[〇〇62]步驟S410:反向代理模塊接收到用戶終端發送的打點請求后，將打點請求分配給一臺服務器節點中的框架接口模塊。
[0063]其中，用戶終端的數量為多個，各個用戶終端可以通過異步通信的方式向反向代理模塊發送打點請求。其中，用戶終端發送的打點請求的形式可以是“online:80(rid)”。 [〇〇64]具體地，可以參照圖2所示的系統框圖來理解本實施例中的方法。反向代理模塊根據打點請求中包含的用戶標識將各個打點請求分配給各個服務器節點。例如，假設本次打點請求分配給第一服務器節點，則反向代理模塊將本次打點請求發送給第一服務器節點中的框架接口模塊(例如hero框架接口接口)，該框架接口模塊通過預設的端口，例如“9010” 端口來接收反向代理模塊發來的打點請求，例如，反向代理模塊發來的打點請求的形式為 “9010(rid)”，表示該打點請求的目的地址為9010端口。另外，框架接口模塊還可以向反向代理模塊返回響應消息或心跳包，以表明其所在的服務器節點處于正常工作狀態。[〇〇65]步驟S420:框架接口模塊將打點請求發送給該框架接口模塊所在的服務器節點。 [〇〇66]具體地，第一服務器節點上的框架接口模塊通過9010端口接收到來自反向代理模塊的打點請求“9010(rid)”后，將其發送給該框架接口模塊所在的第一服務器節點進行處理，框架接口模塊發送的打點請求的形式可以是hit(rid)。其中，框架接口模塊的主要作用在于向反向代理模塊提供統一的通信接口，因此，各臺服務器節點通過框架接口模塊來接收打點請求能夠顯著節約開發人員的開發成本。
[0067]步驟S430:服務器節點對接收到的打點請求進行處理，以生成用戶狀態消息，并將用戶狀態消息發送給公共消息隊列模塊。
[0068]具體地，服務器節點接收到打點請求后，可以通過字典、日志、定時器等多種方式來維護用戶狀態。例如，每當服務器節點接收到用戶終端發送的打點請求后，判斷是否存儲有對應于該用戶終端的定時器，如果判斷結果為是，說明該用戶終端已經處于在線狀態，則根據本次打點請求向對應于該用戶終端的定時器發送延續指令;如果判斷結果為否，說明該用戶終端剛剛上線，則創建對應于該用戶終端的定時器，并為該用戶終端生成用戶上線消息;其中，各個服務器節點持續地對本地存儲的各個定時器進行監測，每當監測到在預設的超時時間閾值內未接收到延續指令的定時器時，將該定時器銷毀，并為該定時器所對應的用戶終端生成用戶下線消息。由此可見，通過定時器能夠監測到各個用戶終端的上線動作和下線動作，并在用戶終端上線時生成用戶上線消息，在用戶終端下線時生成用戶下線消息。用戶狀態消息除包含上述的用戶上線消息和用戶下線消息外，還可以進一步包含用于指示用戶終端目前處于在線狀態的用戶在線消息等。[〇〇69]步驟S440:公共消息隊列模塊將存儲的用戶狀態消息提供給后端處理模塊。
[0070]其中，公共消息隊列模塊用于對用戶狀態消息進行有序存儲。公共消息隊列是一種先進先出的分布式消息隊列，能夠在消息傳輸過程中作為保存消息的容器，從而為程序或組件提供異步的通信機制，使發送方和接收方不必同時在線，也不必了解對方，就可以相互傳輸消息。后端處理模塊與公共消息隊列模塊之間可以通過訂閱模式或點對點模式等多種方式進行通信。具體地，可以由后端處理模塊訂閱公共消息隊列中的內容，相應地，每當公共消息隊列進行更新后，后端處理模塊自動獲取到更新消息，并根據更新消息來讀取公共消息隊列中的內容。
[0071]步驟S450:后端處理模塊根據讀取到的用戶狀態消息更新SSDB數據庫中存儲的用戶狀態信息。[〇〇72]具體地，當后端處理模塊讀取到的用戶狀態消息為用戶上線消息時，則在SSDB數據庫中增加相應用戶終端的上線狀態信息；當后端處理模塊讀取到的用戶狀態消息為用戶下線消息時，則在SSDB數據庫中刪除相應用戶終端的上線狀態信息。[〇〇73]步驟S460:查詢服務器根據接收到的查詢請求，查詢SSDB數據庫中存儲的用戶狀態信息，并返回與該查詢請求相對應的查詢結果。
[0074]其中，查詢服務器不僅能夠查詢各個用戶終端的當前狀態、在線時長等信息，還能夠進行多維度、多類型的查詢。具體的查詢過程可以參照上一實施例中相應部分的描述，此處不再贅述。
[0075]在本發明提供的用戶狀態統計系統及方法中，通過包含多個服務器節點的服務器集群接收來自各個用戶終端的打點請求，并根據打點請求生成用戶狀態消息，將該用戶狀態消息提供給SSDB數據庫，以供SSDB數據庫根據用戶狀態消息維護用戶狀態信息。由此可見，在本發明中，服務器節點通過集群形式實現，且數量為多個，因而能夠并行處理各個用戶終端發來的打點請求，大幅提高了服務器節點的處理速度，縮短了響應時間，能夠同時服務于更多的用戶終端。另外，由于用戶狀態信息存儲在SSDB數據庫內，而非存儲在服務器節點的內存中，因此，上述服務器集群中所包含的服務器節點的數量可以靈活調整:當用戶數量多時，可以通過掛接一個服務器節點來服務于更多的用戶；當用戶數量少時，可以摘除一個服務器節點以節約成本。由此可見，本申請提供的方式具有較強的可擴展性，系統設計較為靈活。除此之外，當某一個服務器節點故障時，其他服務器節點依然能夠確保整個系統的正常運行，因此，本申請提供的方式具有較強的災備功能。
[0076]在此提供的算法和顯示不與任何特定計算機、虛擬系統或者其它設備固有相關。 各種通用系統也可以與基于在此的示教一起使用。根據上面的描述，構造這類系統所要求的結構是顯而易見的。此外，本發明也不針對任何特定編程語言。應當明白，可以利用各種編程語言實現在此描述的本發明的內容，并且上面對特定語言所做的描述是為了披露本發明的最佳實施方式。[〇〇77]在此處所提供的說明書中，說明了大量具體細節。然而，能夠理解，本發明的實施例可以在沒有這些具體細節的情況下實踐。在一些實例中，并未詳細示出公知的方法、結構和技術，以便不模糊對本說明書的理解。[〇〇78]類似地，應當理解，為了精簡本公開并幫助理解各個發明方面中的一個或多個，在上面對本發明的示例性實施例的描述中，本發明的各個特征有時被一起分組到單個實施例、圖、或者對其的描述中。然而，并不應將該公開的方法解釋成反映如下意圖:即所要求保護的本發明要求比在每個權利要求中所明確記載的特征更多的特征。更確切地說，如下面的權利要求書所反映的那樣，發明方面在于少于前面公開的單個實施例的所有特征。因此， 遵循【具體實施方式】的權利要求書由此明確地并入該【具體實施方式】，其中每個權利要求本身都作為本發明的單獨實施例。[〇〇79]本領域那些技術人員可以理解，可以對實施例中的設備中的模塊進行自適應性地改變并且把它們設置在與該實施例不同的一個或多個設備中。可以把實施例中的模塊或單元或組件組合成一個模塊或單元或組件，以及此外可以把它們分成多個子模塊或子單元或子組件。除了這樣的特征和/或過程或者單元中的至少一些是相互排斥之外，可以采用任何組合對本說明書(包括伴隨的權利要求、摘要和附圖)中公開的所有特征以及如此公開的任何方法或者設備的所有過程或單元進行組合。除非另外明確陳述，本說明書(包括伴隨的權利要求、摘要和附圖)中公開的每個特征可以由提供相同、等同或相似目的的替代特征來代替。
[0080]此外，本領域的技術人員能夠理解，盡管在此的一些實施例包括其它實施例中所包括的某些特征而不是其它特征，但是不同實施例的特征的組合意味著處于本發明的范圍之內并且形成不同的實施例。例如，在下面的權利要求書中，所要求保護的實施例的任意之一都可以以任意的組合方式來使用。
[0081]本發明的各個部件實施例可以以硬件實現，或者以在一個或者多個處理器上運行的軟件模塊實現，或者以它們的組合實現。本領域的技術人員應當理解，可以在實踐中使用微處理器或者數字信號處理器(DSP)來實現根據本發明實施例的裝置中的一些或者全部部件的一些或者全部功能。本發明還可以實現為用于執行這里所描述的方法的一部分或者全部的設備或者裝置程序(例如，計算機程序和計算機程序產品)。這樣的實現本發明的程序可以存儲在計算機可讀介質上，或者可以具有一個或者多個信號的形式。這樣的信號可以從因特網網站上下載得到，或者在載體信號上提供，或者以任何其他形式提供。
[0082]應該注意的是上述實施例對本發明進行說明而不是對本發明進行限制，并且本領域技術人員在不脫離所附權利要求的范圍的情況下可設計出替換實施例。在權利要求中， 不應將位于括號之間的任何參考符號構造成對權利要求的限制。單詞“包含”不排除存在未列在權利要求中的元件或步驟。位于元件之前的單詞“一”或“一個”不排除存在多個這樣的元件。本發明可以借助于包括有若干不同元件的硬件以及借助于適當編程的計算機來實現。在列舉了若干裝置的單元權利要求中，這些裝置中的若干個可以是通過同一個硬件項來具體體現。單詞第一、第二、以及第三等的使用不表示任何順序。可將這些單詞解釋為名稱。
[0083]本發明還公開了 B10、一種用戶狀態統計方法，包括:
[0084]通過服務器集群中的多個服務器節點處理各個用戶終端發送的打點請求；[〇〇85]根據所述打點請求生成用戶狀態消息，將所述用戶狀態消息發送給SSDB數據庫；
[0086]通過SSDB數據庫對各個服務器節點提供的用戶狀態消息進行統計，根據統計結果生成并存儲用戶狀態信息。
[0087]B11、根據B10所述的方法，其中，所述用戶狀態消息包括用戶上線消息和用戶下線消息，且各個用戶終端在其在線期間，每隔預設時間間隔發送一次打點請求，
[0088]則所述根據所述打點請求生成用戶狀態消息的步驟具體包括:每當接收到用戶終端發送的打點請求后，判斷是否存儲有對應于該用戶終端的定時器，如果判斷結果為是，則根據本次打點請求向對應于該用戶終端的定時器發送延續指令;如果判斷結果為否，則創建對應于該用戶終端的定時器，并為該用戶終端生成用戶上線消息;其中，各個服務器節點持續地對本地存儲的各個定時器進行監測，每當監測到在預設的超時時間閾值內未接收到延續指令的定時器時，將該定時器銷毀，并為該定時器所對應的用戶終端生成用戶下線消息。
[0089]B12、根據B11所述的方法，其中，所述打點請求中包括應用信息字段，且所述應用信息字段進一步包括多個分別指示不同維度的應用信息的子字段，則對應于一個用戶終端的定時器進一步包括多個子定時器，各個子定時器分別對應于不同維度的狀態信息;并且， 所述用戶上線消息進一步包括各個維度所對應的用戶上線消息，且所述用戶下線消息進一步包括各個維度所對應的用戶下線消息。
[0090]B13、根據B10-12任一所述的方法，其中，所述將所述用戶狀態消息發送給SSDB數據庫的步驟具體包括:
[0091]各個服務器節點將生成的用戶狀態消息存儲到預設的公共消息隊列模塊中，由預設的后端處理模塊將所述公共消息隊列模塊中的用戶狀態消息提供給所述SSDB數據庫。 [〇〇92]B14、根據B10-13任一所述的方法，其中，所述通過服務器集群中的多個服務器節點處理各個用戶終端發送的打點請求的步驟具體包括:
[0093]通過至少一個反向代理模塊接收各個用戶終端發送的打點請求，獲取所述打點請求中包含的用戶標識，通過預設的哈希算法對所述用戶標識進行計算，根據計算結果將各個打點請求分配給各個服務器節點處理。[〇〇94]B15、根據B14所述的方法，其中，所述方法進一步包括步驟:通過反向代理模塊檢測各個服務器節點的工作狀態，當檢測到出現故障的服務器節點時，停用所述出現故障的服務器節點;并在檢測到所述故障恢復時，重新啟用所述出現故障的服務器節點。[〇〇95]B16、根據B10-15任一所述的方法，其中，所述方法包括:根據接收到的查詢請求，查詢所述SSDB數據庫中存儲的用戶狀態信息，并返回與該查詢請求相對應的查詢結果；
[0096]并且，所述方法進一步包括:監測各個應用和/或應用的各個維度的用戶在線人數，當監測到的用戶在線人數的變化率大于預設閾值時，發出報警提示信息。[〇〇97]B17、根據B10-16任一所述的方法，其中，所述打點請求中包括應用類型字段，則所述方法進一步包括步驟:根據所述應用類型字段將用戶狀態消息推送給對應類型的應用。 [0〇98]B18、根據B10-17任一所述的方法，其中，所述打點請求為異步請求消息。
【主權項】
1.一種用戶狀態統計系統，包括:服務器集群，以及與所述服務器集群相連的SSDB數據 庫，其中，所述服務器集群包括多個服務器節點，各個服務器節點分別用于處理各個用戶終端發 送的打點請求，并根據所述打點請求生成用戶狀態消息，將所述用戶狀態消息提供給所述 SSDB數據庫；所述SSDB數據庫用于對各個服務器節點提供的用戶狀態消息進行統計，根據統計結果 生成并存儲用戶狀態信息。2.根據權利要求1所述的系統，其中，所述用戶狀態消息包括用戶上線消息和用戶下線 消息，且各個用戶終端在其在線期間，每隔預設時間間隔發送一次打點請求，則各個服務器節點具體用于:每當接收到用戶終端發送的打點請求后，判斷是否存儲 有對應于該用戶終端的定時器，如果判斷結果為是，則根據本次打點請求向對應于該用戶 終端的定時器發送延續指令;如果判斷結果為否，則創建對應于該用戶終端的定時器，并為 該用戶終端生成用戶上線消息；其中，各個服務器節點持續地對本地存儲的各個定時器進 行監測，每當監測到在預設的超時時間閾值內未接收到延續指令的定時器時，將該定時器 銷毀，并為該定時器所對應的用戶終端生成用戶下線消息。3.根據權利要求2所述的系統，其中，所述打點請求中包括應用信息字段，且所述應用 信息字段進一步包括多個分別指示不同維度的應用信息的子字段，則對應于一個用戶終端 的定時器進一步包括多個子定時器，各個子定時器分別對應于不同維度的狀態信息;并且， 所述用戶上線消息進一步包括各個維度所對應的用戶上線消息，且所述用戶下線消息進一 步包括各個維度所對應的用戶下線消息。4.根據權利要求1-3任一所述的系統，其中，所述系統進一步包括:公共消息隊列模塊 以及后端處理模塊，其中，各個服務器節點用于將生成的用戶狀態消息存儲到所述公共消 息隊列模塊中，所述后端處理模塊用于讀取所述公共消息隊列模塊中的用戶狀態消息，并 根據讀取到的用戶狀態消息修改所述SSDB數據庫中存儲的用戶狀態信息。5.根據權利要求1-4任一所述的系統，其中，所述服務器集群中進一步包括:至少一個 反向代理模塊，用于接收各個用戶終端發送的打點請求，獲取所述打點請求中包含的用戶 標識，通過預設的哈希算法對所述用戶標識進行計算，根據計算結果將各個打點請求分配 給各個服務器節點處理。6.根據權利要求5所述的系統，其中，所述反向代理模塊進一步用于:檢測各個服務器 節點的工作狀態，當檢測到出現故障的服務器節點時，停用所述出現故障的服務器節點;并 在檢測到所述故障恢復時，重新啟用所述出現故障的服務器節點。7.根據權利要求1-6任一所述的系統，其中，所述系統進一步包括:與所述SSDB數據庫 相連的查詢服務器，用于根據接收到的查詢請求，查詢所述SSDB數據庫中存儲的用戶狀態 信息，并返回與該查詢請求相對應的查詢結果；并且，所述查詢服務器進一步用于:監測各個應用和/或應用的各個維度的用戶在線人 數，當監測到的用戶在線人數的變化率大于預設閾值時，發出報警提示信息。8.根據權利要求1-7任一所述的系統，其中，所述打點請求中包括應用類型字段，則所 述服務器節點進一步用于:根據所述應用類型字段將用戶狀態消息推送給對應類型的應 用。9.根據權利要求1-8任一所述的系統，其中，所述打點請求為異步請求消息。10.—種用戶狀態統計方法，包括:通過服務器集群中的多個服務器節點處理各個用戶終端發送的打點請求；根據所述打點請求生成用戶狀態消息，將所述用戶狀態消息發送給SSDB數據庫；通過SSDB數據庫對各個服務器節點提供的用戶狀態消息進行統計，根據統計結果生成 并存儲用戶狀態信息。
【文檔編號】H04L12/24GK106027289SQ201610304635
【公開日】2016年10月12日
【申請日】2016年5月9日
【發明人】段兵營
【申請人】北京奇虎科技有限公司, 奇智軟件（北京）有限公司