标签: message-queue

MOM(面向消息的中间件)解决了什么问题？可扩展性？积分？

他们通常使用哪个域,哪些域通常不使用？

例如,谷歌是否使用此类解决方案作为其主要搜索引擎或为GMail提供支持？

那么大型网站如沃尔玛,eBay,FedEx(几乎是一家Java商店)和buy.com(几乎是MS商店)呢？妈妈是否解决了那里的需求？

当你编写一个控制服务器端的Web应用程序并且拥有一个同质环境(比如数十个所有运行Linux + Java JVM的Amazon EC2实例)以及客户端(Web浏览器)时,它是否有意义？

对于需要与服务器通信的桌面应用程序是否有意义？

或者,对于大型企业而言,它通常是由无数不同系统组成的快乐组合,需要以某种方式进行通信？

我对它们有用的东西感到有点困惑,我认为通过它们适合的地方以及它们不合适的地方,我可以更好地理解它们的用途.

我是Rabbitmq(和编程)的新手,如果这很明显,请提前对不起.我正在创建一个池来共享正在处理队列的线程,但我不确定是否应该在池中使用连接或通道.

我知道我需要通道来完成实际工作,但每个连接有一个通道(从队列中获得更多吞吐量)是否有性能优势？或者我最好只使用每个应用程序的单个连接并汇集多个渠道？

注意:因为我正在汇集资源,初始成本不是一个因素,因为我知道连接比渠道更昂贵.我对吞吐量更感兴趣.

我们正在实现一个REST API,它将启动多个长时间运行的后端任务.我一直在阅读RESTful Web Services Cookbook,建议使用指向正在处理的任务的Content-Location标头返回HTTP 202/Accepted.(例如http://www.example.org/orders/tasks/1234),让客户端轮询此URI以获取有关长时间运行任务的更新.

我们的想法是让REST API立即将消息发布到队列,后台工作者角色从队列中获取消息并使用队列启动多个后端任务.我用这种方法看到的问题是如何为任务分配一个唯一的ID,然后让客户端通过向Content-Location URI发出GET来请求任务的状态.

如果REST API立即发布到队列,那么它可以生成GUID并将其作为添加到队列的消息的属性附加,但是获取请求的状态变得很尴尬.

另一个选择是让REST API立即向数据库添加一个条目(假设一个订单,带有一个新的订单ID),具有初始状态,然后在队列中放入一条消息以启动后台任务,然后将更新该数据库记录.API将在Content-Location标头的URI中返回此新订单ID,以供客户端在检查任务状态时使用.

以某种方式首先添加数据库条目,然后将消息添加到队列似乎是向后的,但仅将请求添加到队列使得难以跟踪进度.

推荐的方法是什么？

非常感谢您的见解.

我正在尝试学习消息传递系统.我发现RabbitMq和NServiceBus在很少的地方一起使用.我的问题是

1. 如果我使用RabbitMQ那么为什么我需要NServiceBus？反之亦然
2. 什么NServiceBus可以做但RabbitMQ或卡夫卡不能？
3. 我可以一起使用NServiceBus和kafka吗？或者Apache-Kafka不需要NServiceBus

这两张图片来自http://zguide.zeromq.org/page:all.

如果我们忽略推拉模式中的下沉,这两种模式之间有什么区别？消息的传输方式是否存在差异,如果是,有什么区别？

我们有一个应用程序将使用RabbitMQ并有几个不同的队列在层之间传递消息.

最初,我计划使用多个直接交换,每个消息类型一个,但看起来使用不同的路由键绑定与队列进行单个主题交换将实现相同的目的.

进行单次交换似乎也更容易维护,但我想知道是否有任何好处(如果有的话)以另一种方式做到这一点？

选项1,使用多个直接交换:

ExchangeA (type: direct)
-QueueA

ExchangeB (type: direct)
-QueueB

ExchangeC (type: direct)
-QueueC

选项2,使用单一主题交换:

Exchange (type: topic)
-QueueA  (receives messages from exchange with routing key of "TypeA")
-QueueB  (receives messages from exchange with routing key of "TypeB")
-QueueC  (receives messages from exchange with routing key of "TypeC")

我需要为我的新项目选择一个新的队列代理.

这次我需要一个支持pub/sub的可伸缩队列,并且必须保持消息排序.

我读过亚历克西斯的评论:他写道:

"事实上,我们认为RabbitMQ比Kafka提供更强的订购"

我在rabbitmq docs中阅读了消息订购部分:

"消息可以使用AMQP方法返回队列,这些方法具有重新排队参数(basic.recover,basic.reject和basic.nack),或者由于在保留未确认的消息时关闭了通道...使用2.7.0及更高版本它仍然有可能为个人消费者,观察消息无序如果队列中有多个用户.这是因为谁可能重新排队消息的其他用户的行为.从队列中的消息总是在发布顺序举行的视角. "

如果我需要按订单处理消息,我只能使用带有独占队列的rabbitMQ给每个消费者吗？

RabbitMQ仍然被认为是有序消息排队的一个很好的解决方案吗？

我想知道RabbitMQ在单个服务器上可以处理多少个最大队列？

它取决于RAM吗？它取决于erlang进程吗？

根据生产者分配的分区,Kafka将传入的消息拆分为分区.来自分区的消息然后被不同消费者组中的消费者使用.

这种架构让我担心使用Kafka作为工作/任务队列,因为我必须在生产时指定分区,这间接限制了哪些消费者可以使用它,因为分区只发送给消费者组中的一个消费者.我宁愿不提前指定分区,因此无论哪个消费者可以接受该任务都可以这样做.有没有办法在Kafka架构中构建分区/生产者,其中任务可以由下一个可用的消费者提取,而不必在生成工作时通过选择分区来提前分工？

对此主题仅使用一个分区会将所有任务放在同一队列中,但每个使用者组的使用者数量限制为1,因此每个使用者必须位于不同的组中.然后,所有任务都分配给每个消费者群体,这不是我正在寻找的那种工作队列.

Apache Kafka适合用作任务队列吗？

在Facebook应用程序和云计算时代,我正在重新思考大型多人游戏.

假设我要在现有的开放协议之上构建一些东西,我想为1,000,000个并发播放器提供服务,只是为了解决问题.

假设每个玩家都有一个传入的消息队列(用于聊天和诸如此类),平均有一个传入的消息队列(公会,区域,实例,拍卖......),因此我们有2,000,000个队列.玩家将一次收听1-10个队列.每个队列平均每秒可能有1条消息,但某些队列将具有更高的速率和更多的侦听器(例如,级别实例的"实体位置"队列).假设系统排队延迟不超过100毫秒,这对于温和的动作导向游戏来说是可以的(但不是像Quake或Unreal Tournament这样的游戏).

从其他系统,我知道在单个1U或刀片盒上为10,000个用户提供服务是一个合理的期望(假设没有其他任何昂贵的东西,比如物理模拟或诸如此类的东西).

因此,使用交叉开关集群系统,客户端连接到连接网关,然后连接到消息队列服务器,我们每个网关有100个用户,有100个网关机器,每个队列服务器有100个消息队列,有100个队列机器.再次,仅适用于一般范围.每台MQ机器上的连接数量很小:大约100,与每个网关通信.网关上的连接数量会更高:客户端为10,100,连接所有队列服务器.(除此之外,为游戏世界模拟服务器添加一些连接或诸如此类的东西,但我现在试图将它保持分离)

如果我不想从头开始构建这个,我必须使用一些存在的消息传递和/或排队基础结构.我能找到的两个开放协议是AMQP和XMPP.XMPP的预期用途更像是这个游戏系统所需要的,但开销非常明显(XML,加上冗长的状态数据,以及必须在顶部构建的各种其他通道).AMQP的实际数据模型更接近我上面描述的内容,但所有用户似乎都是大型企业级公司,工作负载似乎与工作流程相关,而不是与实时游戏更新相关.

有没有人可以分享这些技术或其实现的日常经验？