构建通知系统

Question

我正在为我们的页面（社交游戏类型）构建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，但这不应该是我认为的一个重要因素。

Answer 1

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

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

（添加在您认为合适的时间字段）

这基本上是为每个分组对象的更改，这样你就可以说：“你有3个好友请求”。每个演员的分组是有用的，所以你可以说“用户詹姆斯邦德在你的床上做出了改变”。这也可以根据需要翻译和计算通知。

但是，由于对象只是一个ID，所以需要使用单独的调用来获取关于所需对象的所有额外信息，除非对象实际发生更改并且要显示该历史记录（例如“用户更改了事件标题...“）

由于通知对于网站用户来说接近实时，所以我会将它们与nodejs + websockets客户端绑定，并将php更新添加到所有侦听器的nod​​ejs中，以便添加更改。

Answer 2

这实在是一个抽象的问题，所以我想我们只需要讨论它，而不是指出你应该做什么或不应该做什么。

这就是我想你的顾虑：

• 是，通知系统是复杂的，但不是地狱，但。在建模和实现这些系统时可以有多种不同的方法，并且可以具有从中等到高级的复杂性;

• Pesonally，我总是试图使东西数据库驱动。为什么？因为我可以保证对所发生的一切有完全的控制 - 但那只是我自己，你可以在没有数据库驱动的方法的情况下进行控制;相信我，你会想要控制这种情况;

• 让我举例说明一个真实的案例给你，这样你就可以从某个地方开始。在过去的一年中，我已经在某种社交网络中建立并实施了一个通知系统（当然不是脸谱网）。我用来在那里存储通知的方式？我有一个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个问题等等）。

让我知道这个模式是否有问题。