我正在做实时的web应用程序开发。
浏览器用户应该能够通过node.js服务器相互通信。其中一个用户写了一条消息，所有其他用户都会得到它。
我不太明白RabbitMQ是如何工作的。但从快速阅读来看，它似乎处理消息的发布/订阅。
用户(在浏览器中)发布内容，订阅者(在其他浏览器中)获得该消息。这不是Socket。IO用websockets做什么?
以下是我的问题:
- 它们各自的优点/缺点是什么?
- 可以套接字。. io替换RabbitMQ?
- 有场景我需要RabbitMQ的web应用程序，其中Socket。IO还不够吗?
Update
是否有场景我需要RabbitMQ用于web应用程序，其中Socket。io不足够了吗?浏览器用户应该能够通过node.js服务器相互通信。一个如果用户写了一条消息，所有其他用户都将得到它。
当你只有这些简单的要求时，socket。。只有当你想以一种受控的方式离线处理你的作业(繁重的)时，你才需要一个消息队列。
http://en.wikipedia.org/wiki/Message_queue:消息队列提供异步通信协议，意思是消息的发送者和接收者不需要与之交互
这个句子需要理解。生产者(一个进程)将作业放入队列，消费者通过从队列中获取作业进行消费。大多数情况下，消费者是并发使用多个作业的多个进程。消费者无法区分他们正在消费的是什么工作。
这使得队列为a先进先出(FIFO)数据结构。
我认为这是队列的一个重要属性。先进先出(First-In-First-Out)属性，尽管使用了像beanstald这样的高级消息队列，您可以为作业指定优先级。
我希望这是有意义的;)
你能不能解释得再详细一点，以便我们能给你一个更好的答复?我在做实时的网络应用发展。
我不太明白RabbitMQ是如何工作的。但从快速阅读来看，似乎的发布/订阅消息。
请参阅下面关于消息队列的引用。让它慢慢消化一下。您也可以阅读有关消息队列的WIKI。
用户(在浏览器中)发布Something和订阅者(in other)浏览器)得到这个消息。这难道不是套接字。IO正在做的是尚?
插座。IO支持很多不同的传输(也包括websockets)，因为大多数浏览器都不支持websockets。但是举例来说，Google Chrome已经支持websockets了。我相信websockets是未来的传输方式(但不是现在!)当你看着Socket。你会注意到Socket. io的浏览器支持页面。IO支持所有主流浏览器(有些甚至是旧的)。好的是，它把这个包裹在一个很好的API中。
优点/缺点是什么对每一个人来说?
你在比较苹果和橘子，所以比较这个有点奇怪。
<标题> RabbitMQ h1>
RabbitMQ是一个消息代理。的主要思想很简单:它接受和转发消息。你可以把它想象成邮局:当你把邮件寄到你所在的邮箱我很确定邮差先生会的最终把邮件送到你的接收方。使用这个比喻RabbitMQ是一个邮筒，一个邮局和一个邮递员。优势
- 这是一个非常好的消息队列。我个人会使用redis或beanstalk。
缺点:
- 不是真正的"浏览器"。
<标题> socket . io h1>
优势插座。IO的目标是制作实时应用在所有浏览器和移动设备，模糊不同之间的区别运输机制。
- 为浏览器设置
缺点- 不是消息队列
可以套接字。. io替换RabbitMQ?
可以套接字。. io替换RabbitMQ?
不，你不能，因为它们是两个完全不同的东西。你是在拿苹果和橘子作比较。你应该试着从我引用的网站中理解这两种描述。
RabbitMQ是一种非常灵活的创建网络拓扑的方式。它是成熟的，受支持的，并且来自金融领域(在金融领域，他们已经做了很长时间的消息传递)。我使用RabbitMQ服务器端，并使用其他协议通过"网关"连接到RabbitMQ。
在幕后，RabbitMQ是用一种超简洁的函数式语言Erlang编写的。这本身没什么大不了的，但争论的是，如果你知道你在做什么，并且可以用更少的代码行来表达，那么它最终会更可靠和可测试。
顺便说一句:Erlang被Facebook和Twitter用于他们的幕后工作。
现在，RabbitMQ不仅仅是一个网络套接字类型的东西…这是基于"保证交货"。该特性对于企业情况非常重要。RabbitMQ，也可以用来扩展…事实上，还有更多……我说得不公平。我不能评论node.js，因为我还没有机会玩它。我很喜欢RabbitMQ。
re:插座。io(我们说的是websockets吗?)——如果这是针对浏览器的(正如上面的帖子所建议的)，你可以把它桥接到RabbitMQ中。