我正在爲我們的頁面(社交遊戲類型)構建Facebook樣式通知系統,現在我正在研究設計此類系統的最佳方式。我對如何將通知推送給用戶或類似的東西不感興趣(現在甚至是)。我正在研究如何在服務器上構建系統(如何存儲通知,如何存儲它們,如何獲取它們等)。構建通知系統
所以......一些要求,我們有:
- 在高峯時期,我們有1K左右同時登錄用戶(以及更多的客人,但他們不事這裏他們不會有通知)會產生很多事件
- 會有不同類型的通知(用戶A已將您添加爲朋友,用戶B已對您的個人資料發表了評論,用戶C已經喜歡您的圖片,用戶D已經在遊戲X中擊敗了您,...)
- 大多數事件會爲1個用戶生成1個通知(用戶X已經喜歡您的圖片),但會出現一種情況t會生成很多通知(例如用戶Y的生日)
- 通知應該組合在一起;如果例如四個不同的用戶喜歡一些圖像,該圖像的所有者應該得到一個通知,指出四個用戶都喜歡的形象,而不是四個單獨的通知(就像FB一樣)
行,所以我在想什麼我應該創建一些隊列,以便在事件發生時存儲事件。然後我會有一個後臺作業(gearman?),它會查看該隊列並根據這些事件生成通知。這項工作然後將通知存儲在每個用戶的數據庫中(所以如果一個事件影響10個用戶,將會有10個單獨的通知)。然後,當用戶打開一個包含通知列表的頁面時,我會閱讀所有這些通知(我們希望限制爲100個最新通知)並將它們組合在一起,然後顯示出來。
事情我很擔心這種做法:
- 複雜的地獄:)
- 在數據庫這裏最好的存儲(我們正在使用MySQL),或者我應該用別的東西(Redis的好像也很適合)
- 我應該存儲什麼作爲通知?用戶ID,發起事件的用戶ID,事件類型(以便我可以將它們分組並顯示適當的文本),但是我有點不知道如何存儲通知的實際數據(例如URL &標題被喜歡的圖像)。我應該在生成通知時「烘焙」該信息,還是應該存儲受影響的記錄(圖像,配置文件等)的ID,並在顯示通知時將信息從數據庫中拉出。
- 即使我在顯示通知頁面時不得不處理100個通知,在這裏性能仍然可以正常運行
- 每個請求可能存在性能問題,因爲我必須向用戶顯示未讀通知的數量(這可能是一個問題,因爲我會將通知分組在一起)。這可以避免,雖然如果我在後臺生成通知視圖(在何處分組),而不是即時的
因此,您如何看待我提出的解決方案和我的擔憂?如果您認爲我應該提及其他與此相關的內容,請發表評論。
哦,我們在頁面上使用PHP,但這不應該是我認爲的一個重要因素。
需要多少時間才能將此通知系統作爲一個人的努力來完成。我只是想估計一下相應的時間表。 – Shaharyar 2015-11-24 10:55:36
@Shaharyar我認爲這取決於通知系統的複雜性。 – tyan 2016-04-20 06:43:32
我使用與MySQL相同的系統來構建基於優先級的通知系統。好的是,它可以擴展到幾千個用戶,如果超過這個數字,它會爆炸,特別是Android和GCM。我想知道MySQL的替代品,比如redis,rabbitMQ,Kafka,它們自然地展現了一個消息隊列,一種功能。 – 2017-01-23 13:57:33