Php 实现活动提要、消息队列、RDBMS或NoSQL DBs的最佳（可扩展、快速、可靠）方法是什么？

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

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

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

然而，我仍然必须仔细阅读每一条消息并对其进行处理（除非我的方法完全错误）。那么，在RDBMS中存储所有内容和使用消息队列（除了pubsubb协议的实现）之间有什么区别呢

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

欢迎提出意见/建议/批评。：）

提前谢谢你

附言：有一篇关于FriendFeed如何实现它的有趣文章（）。然而，我觉得“黑客”将MySQL推出了它的舒适领域（这只是关系数据，没有关系数据使用RDBMS有什么意义？）

---

p.p.S.：我看到使用消息队列的另一个问题（可能是因为我对这项技术不熟悉）是，一旦消息被“消费者”获取，它就会从队列中删除，但是，我希望它能够持续任意时间。

我想给你一些提示：

• 不要使用RDBMS，而是使用内存（FAST）数据库，例如。希望你能在redis上同意我的观点，redis速度非常快。作为另一个旁注，我想指出安装redis是儿童游戏：）
  制造

对于使用C的PHP来说，有一个很好的例子，所以速度也会非常快。 -如果我理解正确，您会认为pubsubbub与消息队列相同，但它们不是：

发言的各方（服务器） pubsubb协议可以得到 近即时通知（通过 webhook回调）当主题（提要 他们感兴趣的URL）已更新

与消息队列相比：

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

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

---

我希望这是给你的，如果你有任何问题，我非常愿意回答；）

阿尔弗雷德，首先感谢您的回复和建议！非常感谢。>如果我理解正确，您会认为pubsubbub与消息队列>相同，但事实并非如此：是的，我确实理解其中的区别（如果您阅读我的帖子，您可以看到我使用RabbitMQ作为pubsubbub协议的消息队列）。正如您所建议的，我一直在阅读有关redis的文章（这是一本非常好的教程：）。但是，将所有更新发送到所有订阅（使用循环）；这不是有点资源密集吗（比如说一百万张唱片？）。。。在我之前的评论中，我补充道：模型不应该反过来吗？（这样订阅者只在需要时（即不提前）获取记录）？我希望我能够澄清。@a110y有了redis，一切都在内存中（非阻塞），所以速度会非常快。您可以不费吹灰之力地从辅助进程执行该循环。您可以使用消息队列将指向tweet（消息）的指针（对键的引用）添加到每个用户，而不是执行昂贵的连接（SQL！！！）此外，我还想指出Simon解释redis=>的这篇优秀教程。我希望这也有道理；）+1获取有用的链接。在全速运行之前，我将尝试实现一个原型。但是，您能否进一步澄清一下您的实现？实现目标的最佳方式是什么；在Redis中使用发布/订阅还是“收件箱”方法？提前道歉如果我的问题听起来太明显，我对Redis非常陌生（只有一天的曝光时间：p），我很难将我的RDBMS脑袋绕到其他数据库范式（K/V、基于文档等）上@a110y抱歉，但我在度假，但我会从pubsub开始（缩放效果非常好，但我认为收件箱会缩放得更好）因为这很容易实现（1秒；））。但我认为“收件箱”会扩展得更好，但那是在将来当你有很多用户的时候；）。你应该先让它工作起来，然后考虑我认为的缩放问题。。。虽然inbox方法也可以写得非常快（在一天内（可能是几天内）。当我有空的时候，我会试着写些东西。。。

rpush <name of queue> <message>

brpop <name of queue> 0

php worker.php