实现 Activity Feed、消息队列或 RDBMS 或 NoSQL DB 的最佳（可扩展、快速、可靠）方法是什么？

Question

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

How do social networking websites compute friend updates?

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

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

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

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

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

提前谢谢你！

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

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

Answer 1

我想给你一些提示：

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

  制作

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

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

对比消息队列：

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

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

rpush <name of queue> <message>

然后从您的工作进程中，您可以使用 brpop(blocking pop :)) 从队列接收消息

brpop <name of queue> 0

worker 进程生成将从 cli 开始以留在内存中，因此不会一次又一次地将 PHP 加载到内存中。

php worker.php

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