PHP/MYSQL 帮助向所有用户（关注者）甚至数百万用户发出通知
我想在 PHP/MYSQL 中创建一个系统，通过该系统，站点的用户可以关注/取消关注同一站点的其他用户，并且当用户执行某些活动时，该用户的所有关注者都应该收到通知。
我知道我可以创建一个名为 notifications 的单独数据库表，并为每个需要像 Facebook 那样单独通知的用户插入行，但我不会限制用户（即在 Facebook 上，你不能拥有超过 5000 个朋友），在我的网站上，用户可以关注他们想要的任意数量的用户，如果某个用户有 100 万个关注者，那么在我的服务器上，他的每一个活动都会让我的服务器崩溃。
那么如何完成这个任务，我的Mysql数据库需要使用什么样的设计，我需要以什么方式调用这些行，以便我可以向用户的所有关注者发送通知，并且服务器也永远不会失望。
I want to make a system in PHP/MYSQL through which users of a site can follow/unfollow other users of the same site and when a user do some activity then that user's all followers should get a notification.
I know that I can create a seperate db tables called notifications and insert row in it for each user who needs to be notified separably like Facebook did, but i will not restrict users (i.e. on Facebook you cannot have more then 5000 friends), on my site users can follow any amount of users they wish, and if some user have 1 million followers then on my server his each and every activity will let my server down.
So how to accomplish this task, what kind of design do I need to use for my Mysql database, in what way do I need to call those rows so that i can send notifications to all followers of the user and the server also never let down.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
关注者从他关注的用户那里获取通知。这样，通知就是表中的一行。理由是，虽然我可能有数百万粉丝，但我关注的人数却很少（可能不到 1000 人）。
另外：考虑缓存策略。
The follower pulls the notifications from the users he follows. That way, a notification is a single row in a table. The rational is, that while I might have millions of followers, the number of people that I follow is quite small (probably less than 1000).
Also: think about a caching strategy.
将您的建议与奥斯瓦尔德的答案和评论结合起来。
作者创建更新，然后将记录添加到通知表中。如果作者有 10,000 个关注者，则有 10,000 个条目。这将变得相当大，并且需要使用优化、缓存等。
然后，关注者会以一定的时间间隔进行连接（通过类似于 Facebook 网络或手持设备的客户端）并获取通知。在这种情况下，我会收到来自我上次访问或所有作者的通知。同样，正如您所指出的，这可能是 10,000 行，但是使用更好的密钥，检索会很快，因为您只会收到关注者（他们的 ID）的通知。收到后，删除待处理的通知。
第二种选择是修改通知，只包含作者、帖子和日期的条目。关注者连接，查询自上次搜索以来的新帖子，然后按作者过滤它们。尝试在第一个查询中删除尽可能多的记录，然后尝试将过滤器作为第二个查询或缓存的参考搜索。不要尝试链接两个查询，因为您会杀死数据库服务器。首先使用键/索引获取最小的集合。
如果关注者有几个作者，请先查询作者更新，然后再查询日期。否则，先按日期搜索，然后按作者搜索。
Use a combination of your suggestion and the answer and comments from Oswald.
The author creates an update, which will then add records to the notifications table(s). If the author has 10,000 followers, then there are 10,000 entries. This will become quite large, and optimization, caching, etc... will need to be used.
The follower then connects at some interval (via a client similar to Facebook web or hand held) and pulls their notifications. In this case, I get notifications from my last visit or all my authors. Again, this may be 10,000 rows as you indicated, but with better keys, the retrieval will be quick, since you get notifications for the follower only (their ID). Once received, delete the pending notifications.
The second alternative would be to modify the notifications to simply have an entry for the author, and the post, and a date. The follower connects, queries for new postings since his last search, and then filter them by author. Try to remove as many records as possible in the first query, then attempt the filter as a second query or cached reference search. Do not try to link both queries as you will kill the database server. Using keys/indexes to get the smallest set first.
If the follower has a few authors, query for author updates first, then after the date. Otherwise, search after the date then by authors.