建立通知系统

Question

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

那么......我们有一些要求:

• 在高峰时段,我们有大约1k个并发登录用户(以及更多的访客,但他们没关系因为他们没有通知)会产生很多事件
• 会有不同类型的通知(用户A已将您添加为朋友,用户B已对您的个人资料发表评论,用户C已喜欢您的图片,用户D已在游戏X中击败您,...)
• 大多数事件将为1个用户生成1个通知(用户X喜欢您的图像),但是会有一个事件会生成许多通知的情况(例如,用户Y的生日)
• 通知应该组合在一起; 如果例如四个不同的用户喜欢某个图像,那么该图像的所有者应该得到一个通知,说明四个用户喜欢该图像而不是四个单独的通知(就像FB一样)

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

我对这种方法的关注:

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

那么您如何看待我提出的解决方案和我的担忧？如果您认为我应该提及其他与此相关的内容,请发表评论.

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

Answer 1

通知是关于某人(对象=事件,友谊......)被某人(演员)改变(动词=添加,请求...)并报告给用户(主题)的通知.这是一个规范化的数据结构(虽然我使用过MongoDB).您需要通知某些用户有关更改的信息.所以它是每用户通知..意味着如果涉及100个用户,则会生成100个通知.

???????????????      ?????????????????????      ??????????????????????
?notification ?      ?notification_object?      ?notification_change ?
???????????????      ?????????????????????      ??????????????????????
?ID           ?—1:n—??ID                 ?—1:n—??ID                  ?
?userID       ?      ?notificationID     ?      ?notificationObjectID?
???????????????      ?object             ?      ?verb                ?
                     ?????????????????????      ?actor               ?
                                                ??????????????????????

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

这基本上是为每个对象分组更改,因此您可以说"您有3个朋友请求".每个演员的分组很有用,所以你可以说"用户James Bond在你的床上做了改变".这也可以根据需要翻译和计算通知.

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

由于通知对于网站上的用户来说接近实时,我会将它们与nodejs + websockets客户端绑定,并将更新添加到所有侦听器时将更新推送到nodejs.

Answer 2

这实际上是一个抽象的问题,所以我想我们只是要讨论它而不是指出你应该或不应该做什么.

以下是我对您的担忧的看法:

• 是的,通知系统很复杂,但不是很糟糕.您可以在建模和实现此类系统时使用许多不同的方法,并且它们可以具有从中等到高级的复杂性;

• 顺便说一句,我总是试图让数据库驱动.为什么？因为我可以保证完全控制正在发生的一切 - 但这只是我,你可以在没有数据库驱动的方法的情况下控制; 相信我,你会想要控制那个案子;

• 让我举一个真实案例给你,所以你可以从某个地方开始.在过去的一年里,我已经在某种社交网络中建模并实现了一个通知系统(当然不是像facebook那样).我以前在那里存储通知的方式？我有一个notifications表,我保留了generator_user_id(生成通知的用户的ID),target_user_id(显而易见的,不是吗？),notification_type_id(引用具有通知类型的不同表),以及所有我们需要填充表格的必要内容(时间戳,标志等).我的notification_types表曾经与notification_templates表有关系,为每种类型的通知存储了特定的模板.例如,我有一个POST_REPLY类型,有一个类似的模板{USER} HAS REPLIED ONE OF YOUR #POSTS.从那里,我只把它{}作为变量和#作为参考链接;

• 是的,性能应该而且必须没问题.当您想到通知时,您会想到服务器从头到脚推送.如果你打算用ajax请求或其他什么来做,你将不得不担心性能.但我认为这是第二次关注;

我设计的那种模式当然不是唯一可以遵循的模式,也不是最好的模型.我希望我的回答至少会让你走向正确的方向.

Answer 3

??????????????????????
?notification        ?
??????????????????????
?Username            ?
?Object              ?
?verb                ?
?actor               ?
?isRead              ?
??????????????????????

这看起来很好,而不是有2个收藏.您可以通过用户名,对象和isRead查询以获取新事件(例如3个待处理的朋友请求,4个问题等...)

如果此架构存在问题,请告诉我.