构建通知系统 [英] Building a notification system

问题描述

我刚开始为我们的页面(社交游戏类型)构建 Facebook 风格的通知系统，我现在正在研究设计此类系统的最佳方式.我对如何向用户推送通知或类似的东西(甚至现在)不感兴趣.我正在研究如何在服务器上构建系统(如何存储通知、在哪里存储它们、如何获取它们等等......).

I am at the start of building a Facebook style notification system for our page (social gaming type) and I'm now researching what would be the best way to design such system. I'm not interested in how to push notifications to the user or anything like that (for now even). I am researching how to build the system on the server (how to store notifications, where to store them, how to fetch them etc...).

所以......我们有一些要求:

So ... some requirements that we have:

• 在高峰时间，我们有大约 1000 名并发登录用户(还有更多来宾，但他们在这里无关紧要，因为他们不会收到通知)，这将产生许多事件
• 会有不同类型的通知(用户 A 将你加为好友，用户 B 对你的个人资料发表评论，用户 C 喜欢你的图片，用户 D 在游戏 X 中击败了你，......)
• 大多数事件会为 1 个用户生成 1 条通知(用户 X 点赞了您的图片)，但也有一些情况会生成多个通知(例如用户 Y 的生日)
• 通知应该组合在一起；例如，如果四个不同的用户喜欢某张图片，则该图片的所有者应该收到一个通知，说明四个用户喜欢该图片，而不是四个单独的通知(就像 FB 一样)

好的，所以我的想法是我应该创建某种队列，以便在事件发生时存储它们.然后我会有一个后台工作(gearman?)来查看该队列并根据这些事件生成通知.然后，此作业会将每个用户的通知存储在数据库中(因此，如果一个事件影响 10 个用户，则会有 10 个单独的通知).然后，当用户打开带有通知列表的页面时，我会为他阅读所有这些通知(我们考虑将其限制为 100 个最新通知)并将它们组合在一起，然后最终显示它们.

OK so what I was thinking is that I should create some sort of queue where I would store events when they happen. Then I would have a background job (gearman?) that would look at that queue and generate notifications based on those events. This job would then store notifications in the database for each user (so if an event affects 10 users, there would be 10 separate notifications). Then when user would open a page with the list of notifications I would read all those notifications for him (we ware thinking to limiting this to 100 latest notifications) and group them together and then finally display them.

我对这种方法担心的事情:

Things I'm concerned about with this approach:

• 复杂到地狱:)
• 数据库是这里最好的存储(我们使用 MySQL)还是我应该使用其他东西(redis 似乎也很合适)
• 我应该存储什么作为通知?用户 ID、发起事件的用户 ID、事件类型(以便我可以对它们进行分组并显示适当的文本)但是我有点不知道如何存储通知的实际数据(例如 URL&title喜欢的图像).我应该在生成通知时烘焙"该信息，还是应该存储受影响的记录(图像、个人资料等)的 ID，并在显示通知时从数据库中提取信息.
• 这里的性能应该没问题，即使我在显示通知页面时必须即时处理 100 个通知
• 每个请求都可能出现性能问题，因为我必须向用户显示未读通知的数量(这本身可能是一个问题，因为我会将通知组合在一起).但是，如果我在后台生成通知视图(它们被分组的位置)而不是即时生成，则可以避免这种情况

那么您如何看待我提出的解决方案和我的顾虑?如果您认为我应该在这里提及任何其他相关内容，请发表评论.

So what do you think about my proposed solution and my concerns? Please comment if you think I should mention anything else that would be relevant here.

哦，我们正在为我们的页面使用 PHP，但我认为这不应该是一个重要因素.

Oh, we are using PHP for our page, but that shouldn't be a big factor here I think.

推荐答案

通知是关于某事(对象 = 事件、友谊..)被某人(演员)更改(动词 = 添加、请求..)并报告给用户(主体).这是一个规范化的数据结构(尽管我使用过 MongoDB).您需要将更改通知某些用户.所以它是每个用户的通知..这意味着如果有 100 个用户参与，你会生成 100 个通知.

A notification is about something (object = event, friendship..) being changed (verb = added, requested..) by someone (actor) and reported to the user (subject). Here is a normalized data structure (though I've used MongoDB). You need to notify certain users about changes. So it's per-user notifications.. meaning that if there were 100 users involved, you generate 100 notifications.

╔═════════════╗      ╔═══════════════════╗      ╔════════════════════╗
║notification ║      ║notification_object║      ║notification_change ║
╟─────────────╢      ╟───────────────────╢      ╟────────────────────╢
║ID           ║—1:n—→║ID                 ║—1:n—→║ID                  ║
║userID       ║      ║notificationID     ║      ║notificationObjectID║
╚═════════════╝      ║object             ║      ║verb                ║
                     ╚═══════════════════╝      ║actor               ║
                                                ╚════════════════════╝

(在您认为合适的地方添加时间字段)

(Add time fields where you see fit)

这基本上用于对每个对象的更改进行分组，以便您可以说您有 3 个好友请求".并且按演员分组很有用，因此您可以说用户詹姆斯邦德在您的床上进行了更改".这也使您能够根据需要翻译和计算通知.

This is basically for grouping changes per object, so that you could say "You have 3 friend requests". And grouping per actor is useful, so that you could say "User James Bond made changes in your bed". This also gives ability to translate and count notifications as you like.

但是，由于对象只是一个 ID，您需要通过单独的调用获取有关您想要的对象的所有额外信息，除非对象实际更改并且您想要显示该历史记录(例如用户将事件标题更改为...")

But, since object is just an ID, you would need to get all extra info about object you want with separate calls, unless object actually changes and you want to show that history (so for example "user changed title of event to ...")

由于网站上的用户的通知接近实时，我会将它们与 nodejs + websockets 客户端联系起来，当添加更改时，php 会将所有侦听器的更新推送到 nodejs.

Since notifications are close to realtime for users on the site, I would tie them with nodejs + websockets client with php pushing update to nodejs for all listeners as change gets added.

这篇关于构建通知系统的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！