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

问题描述

我正在开始为我们的网页（社交游戏类型）构建一个Facebook风格的通知系统，我正在研究设计这种系统的最佳方式。我对如何将通知推送给用户或任何类似的东西（现在甚至）不感兴趣。我正在研究如何在服务器上构建系统（如何存储通知，在哪里存储它们，如何获取它们等）。

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

• 在高峰时段，我们有大约1k个并发登录的用户（还有更多的客人，但他们将会产生许多事件


• 将有不同类型的通知（用户A已将您添加为朋友，用户B已经评论过您的个人资料，用户C已经喜欢您的图像，用户D已经在X游戏中殴打了您...）


• 大多数活动将为1个用户生成1个通知（用户X已经喜欢您的图像）但是会有一个事件会产生许多通知（例如，它是用户Y的生日）


• 通知应该分组在一起;如果例如四个不同的用户喜欢某些图像，该图像的所有者应该收到一个通知，指出四个用户喜欢图像，而不是四个单独的通知（就像FB一样）

OK，所以我在想的是，我应该创建一些队列，我会在事件发生时存储事件。那么我会有一个后台工作（ gearman ？），它会查看该队列并根据这些事件生成通知。然后，此作业会将通知存储在每个用户的数据库中（因此，如果事件影响10个用户，则会有10个单独的通知）。然后当用户打开一个带有通知列表的页面时，我会读取所有这些通知（我们考虑将其限制为100个最新通知），并将它们分组在一起，然后最终显示。

我担心这种方法的事情：

• 复杂的地狱：）


• 是数据库中最好的存储（我们正在使用MySQL）或者应该使用别的东西（redis看起来也很适合）


• 应该作为通知存储什么？用户ID，发起事件的用户ID，事件的类型（以便我可以对它们进行分组并显示适当的文本），但是我不知道如何存储通知的实际数据（例如URL的&喜欢的图像）。当我生成通知时，我应该烘烤该信息，或者应该存储受影响的记录（图像，配置文件...）的ID，并在显示通知时将信息从数据库中拉出。


• 即使在显示通知页面时，我必须处理100个通知，因为每个请求都可能出现性能问题，因为我必须向用户显示未读通知的数量（这可能是一个问题，因为我将通知组合在一起）。这可以避免，尽管如果我在后台生成通知视图（在哪里被分组），而不是即时的

哦，我们正在为我们的网页使用PHP，但这不应该是一个重要因素在这里我想。

解决方案

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

 ╔═══ ═════════════════════════════════════════════════ ═══╗
║notification║║notification_object║║notification_change║
╟───────────────────────────────────────────────────────────────────────────────────────────────────────── ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── →║ID║
║userID║║notificationID║║notificationObjectID║
╚════════════╝║object║║verb║
╚═══ ════════════════╝ ║║║
╚══════════════════╝
  

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

这基本上是用于对每个对象进行分组更改，以便您可以说你有3朋友请求。并且每个演员的分组是有用的，所以你可以说用户詹姆斯·邦德改变你的床。这也可以根据您的需要翻译和统计通知。

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

由于通知对于网站上的用户来说是接近实时的，所以我将把它们与nodejs + websockets客户端，随着更改被添加，php将更新推送到nodejs。

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:

• at peak times we have about 1k concurrent logged-in users (and many more guests, but they don't matter here as they will not have notifications) that will generate many events
• there will be different types of notifications (user A has added you as a friend, user B has commented on your profile, user C has liked your image, user D has beaten you on game X, ...)
• most events will generate 1 notification for 1 user (user X has liked your image), but there will be cases where one event will generate many notifications (it's user Y's birthday for instance)
• notifications should be grouped together; if for instance four different users like some image, the owner of that image should get one notification stating that four users have liked the image and not four separate notifications (just like FB does)

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:

• complex as hell :)
• is database the best storage here (we are using MySQL) or should I use something else (redis seems like a good fit too)
• what should I store as a notification? user ID, user ID who initiated the event, type of event (so that I can group them and display appropriate text) but then I kinda don't know how to store the actual data of the notification (for instance URL&title of the image that was liked). Should I just "bake" that info when I generate the notification, or should I store the ID of the record (image, profile, ...) being affected and pull the info out of the DB when displaying the notification.
• performance should be OK here, even if I have to process 100 notifications on-the-fly when displaying the notifications page
• possible performance problem on every request because I would have to display the number of unread notifications to the user (which could be a problem in its own since I would group notifications together). This could be avoided though if I generated the view of notifications (where they are grouped) in the background and not on-the-fly

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.

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

解决方案

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)

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.

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 ...")

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屋！