使用 PHP 和 MySQL 的通知/新闻提要答案

【问题标题】：Notification/News feed with PHP and MySQL使用 PHP 和 MySQL 的通知/新闻提要
【发布时间】：2011-01-18 07:20:42
【问题描述】：

我一直致力于开发一个复杂的 PHP 系统，该系统融合了社交网络理念中的元素，但针对的是一群封闭的人。我有几个模块、照片和视频画廊、每个模块和子模块的完整评论系统、私人消息、带有 GUI 的个人电子邮件等等。

我的问题是，无论我多么努力，我似乎都无法以一种高效的方式为通知和新闻提要部分设计后端，就像 facebook 那样。这些模块几乎都是事件驱动的，因此将它们连接到通知系统应该不是问题。希望一些集体头脑风暴能解决我的问题。

我只会在这篇文章中解决我对通知部分的担忧（如果我也包含新闻提要，这将成为一个非常长且混乱的帖子）。

这是我的第一个 MySQL 表草稿。

通知ID 首要的关键 通知模块 模块类型外键 - 照片、视频、评论、消息 通知构造函数 触发创建此通知的元素的外键（类型为“notificationModule”） 通知用户 此通知针对的用户 通知时间 创建通知的时间 通知标志 通知已读标志

可能的问题/冲突

如果一个用户评论了两个不同用户已经评论过的照片，会触发三个通知吗？照片上传者一个，每个评论者一个？（影响 notificationUser）
- notificationTime 是创建时间。继上述问题后，我们是否应该不创建新通知，该字段应替换为 notificationUpdateTime 或者可能存在于它旁边？

我的目标是降低代码复杂性和提高数据库效率。试图将数据库层与代码层分开让我在网站的这一部分感到困惑:(

我对所有问题和想法持开放态度。

【问题讨论】：

我只是想确保我清楚您的要求。您是否建议将数据库用作一种通知队列？换句话说，让事件将通知放入表中，然后有一个单独的脚本或进程来使用它们，从表中删除它们并传递它们？如果是这样，这似乎是解决问题的一种相当有效且可扩展的方法。
是的，这正是我所提议的。尽管我担心的是处理通知的脚本的效率。最好有一个脚本来根据数据库中的条目查找要通知的用户，还是直接将这些通知直接针对一个用户。这意味着如果有 10 个人已经在评论某事，则向数据库中插入 10 个新条目。

标签： php mysql notifications social-networking

【解决方案1】：

有两种方法可以处理新闻源：

写入时扇出
读取时扇出

您正在使用写时扇出方法。在这种情况下，您会为每个相关用户生成一个新的个人活动。

这种方法很快就会失败，尤其是当您允许用户拥有无限数量的追随者时。每当发生频繁的活动时，您都必须在数据库中为每 1000 多个关注者保存一个新条目。

当您添加群组和不同类型的受众群体时，事情会变得更加复杂。如果您现在只想将活动广播给 A 组而不是 B 组中的人（例如，您创建一个状态并希望限制查看者）怎么办？如果您想向 A 组和 B 组广播，但 A 和 B 中都有用户不想接收两次相同的活动，会发生什么情况？如果要在创建 Activity 后更改其可见性怎么办？

使用扇出写入方法实际上是不可能的，或者至少非常困难。这就是为什么我更喜欢后者的原因——阅读方法的扇出。

考虑一下：

用户有一组与其 ID 相关联的新闻源频道。这些频道的格式为{{ object_name}}:{{ object_id }}。您可以为新闻源和通知设置单独的集，这样您就可以取消一个对象的通知，而无需将其从新闻源中删除。

当用户注册接收来自某个对象的更新时，他们会将与该对象关联的频道添加到他们的频道列表中。您可以使用简单的 Redis 集。例如，如果我加入活动 #1，我会将event:1 添加到我的频道列表中。

当事件 #1 上的属性发生变化时，只会创建一次新活动。此活动有一个名为“观察者”的字段，它是对它可见的频道的名称。在这种情况下，观察者是 'event:1`。

当用户拉取他们的活动提要时，他们首先会获得其订阅频道的列表。然后，他们检索观察者在其频道列表中的所有活动提要项。

也

我只是不确定如何将其变成通知系统。使用 fan out on read 方法，我有一组通知通道，如上所述。当一个对象的属性发生变化时，我会向数据库写入一个所有订阅用户都会收到的新通知。唯一的问题是：如何逐个用户阅读通知？我还没有弄清楚那部分。

【讨论】：

【解决方案2】：

休息几天后，我改变了对新闻提要和通知系统的思考方式。我采用的方法是，每个事件（评论、标签等）都会触发一个关于两个用户的通知，即参与者和通知所针对的用户（例如一个标记和一个被标记的用户）。另一部分的新闻提要将从通知条目中获取合理的最近条目（假设它不是私人的，例如私人消息）并构建一个提要。这似乎对数据库造成了压力，但我认为在有 100 个（最大）用户的情况下这不会是一个问题。感谢您的输入瑞恩 :)

【讨论】：