2

我需要为与许多流行的社交网络平台类似（相同）的系统构建活动源（流？更准确的“生命流”。）。我最初的尝试是使用 RDBMS，但由于需要大量的 JOIN，我很快放弃了这个想法。在寻找其他可能（和更适合）的方法时，我偶然发现了以下帖子：

社交网站如何计算好友更新？

接受使用消息队列的建议，我花了一些时间研究 RabbitMQ 及其 PubSubHubbub 协议。我假设了以下方法：

1）每个用户都有一个“主题”
2）其他用户订阅该主题
3）当用户执行某些操作时，会发布一条消息，然后将其关联（解析引用）、格式化（人性化语言、链接等）。 ) 并使用 PHP 脚本聚合（X、Y 和 Z 已在帖子 P 上发表评论）。

但是，我仍然必须浏览每条消息并对其进行处理（除非我的方法完全错误）。那么，将所有内容存储在 RDBMS 和使用消息队列（PubSubHubbub 协议的实现除外）之间有什么区别？

有没有更有效的方法来构建这样一个系统？（如果有，请注明）

欢迎评论/建议/批评。:)

先感谢您！

PS：有一篇关于 FriendFeed 如何实现它的有趣文章（http://bret.appspot.com/entry/how-friendfeed-uses-mysql）。但是，我觉得“黑客”将 MySQL 推出了它的舒适领域（这只是关系数据，使用没有关系数据的 RDBMS 有什么意义？）

PPS：我看到的另一个使用消息队列的问题（也许是因为我是这项技术的新手）是，一旦消息被“消费者”获取，它就会从队列中删除，但是，我希望它持续存在任意时间。

4

1 回答 1

2

我想给你一些建议：

  • 不要使用 RDBMS，而是使用内存（FAST）数据库，例如redis。希望你在 redis基准测试中同意我的观点，redis 非常快。作为另一个旁注，我想指出安装 redis 是小菜一碟:)。

    制作

有一个用于 PHP 的redis 客户端，它使用 C，所以它也将非常快。- 如果我理解正确，您认为 pubsubhubbub 与消息队列相同，但它们不是：

当他们感兴趣的主题（提要 URL）更新时，使用 PubSubHubub 协议的各方（服务器）可以获得近乎即时的通知（通过 webhook 回调）。

与消息队列：

在计算机科学中，消息队列和邮箱是用于进程间通信或同一进程内的线程间通信的软件工程组件。他们使用队列进行消息传递——控制或内容的传递。

您可能认为它们是相同的（它们有一些相似之处），但它们并不相同。对于我的消息队列，我会使用 redis（redis 非常强大，因为它也有一个基本的消息队列 :)）。您可以使用rpush将消息（工作单元）放入队列中。

rpush <name of queue> <message>

然后从您的工作进程中，您可以使用brpop接收来自队列的消息（阻止 pop :)）

brpop <name of queue> 0

worker 进程 spawn 将从cli启动以保留在内存中，因此不会一次又一次地将 PHP 加载到内存中。

php worker.php

我希望这对您有帮助，如果您有任何问题，我非常愿意回答他们；）

于 2011-01-19T21:40:02.617 回答