用于FanOut消息传递的RabbitMQ工作队列
我正在尝试扩展RabbitMQ消息传递系统。当前的系统非常简单——生产者向扇出交换发送消息，消息由多个消费者处理——经典的扇出路由。
我有多个不同类型的消费者（例如：一个打印到屏幕，一个记录到文件，一个保存到数据库，…）。我的挑战——我不确定扩大消费者规模的最佳方式是什么。如果我添加来自同一类型的其他使用者，我将在数据库中获得两个日志或两个条目。。。（假设两个DB消费者从同一扇出交换中消费）。
我想我可以创建一个发布到工作队列的消费者，但我想知道Rabbitmq中是否有更好的“内置”解决方案。
先谢谢你了ZF
共有1个答案
如果您需要缩放消费者以更快地消耗来自扇出交换的所有消息，则需要竞争性消费；因此，您需要更多的消费者附加到绑定到扇出交换的同一队列中。
这样，每个消费者都将独立地消费来自其他消费者的一批消息。批处理中的消息数量由预取计数属性（http://www.rabbitmq.com/consumer-prefetch.html）定义。
这样，在您的情况下，您应该能够缩放消费者，避免数据库中的双日志和双条目。
-
在队列选项卡的rabbitMQ web界面上，我看到了“概述”面板，我在其中找到了以下内容： 排队消息： 准备好了 未确认 总数 我猜“总数”是多少。但什么是“准备就绪”和“未确认”？“准备好了”——传递给消费者的信息？“未确认”-？ 消息费率： 发表 交付 重新交付 承认 这些信息是什么？尤其是“重新交付”和“确认”？这是什么意思？
-
概念 消费者完成一个任务可能需要一段时间，如果其中一个消费者处理一个长的任务并且只完成了一部分，如果它突然挂掉了，会发生什么情况？ RabbitMQ一旦向消费者传递了一条消息，就会立即将该消息标记为删除。在这种情况下突然有个消费者挂掉了，将会丢失正在处理的信息，以及后续应该发送给该消费者的信息，因为该消费者无法接收到 为了保证消息在发送过程中不丢失，RabbitMQ引入消息应答机制 消息应答机制指
-
Work Queues 工作队列 工作队列（又称任务队列）的主要思想是避免立即执行资源密集型任务，而不得不等待它完成的情况。 相反我们安排任务在之后执行。把任务封装为消息并将其发送给到队列。在后台运行的工作进程将弹出任务并最终执行作业。当有多个工作线程时，这些工作线程将一起处理这些任务。 1 轮训分发消息 在这个案例中我们会启动两个线程，一个消息发送线程，我们来看看这两个工作线程是如何工作的 1.
-
我正在尝试使用FireBase云消息传递。我正在接收令牌，但它没有从控制台收到任何通知。这是我的舱单： 我的代码与示例中的代码几乎相同： 我在这里检查了一个问题，Firebase云消息通知未被设备接收，但仍然无法工作。
-
添加了从FCM到Facebook的API密钥 但从FB控制台“推送活动设置验证”到有效的“您的设备令牌”-不工作 错误： 无法验证用于发送消息的发件人帐户。这可能是由于无效的项目号作为密钥发送，或者密钥是有效的，但禁用了FCM服务，或者我们的服务器没有在服务器密钥IP中列入白名单。 是什么导致了这些问题？有什么日志我可以看吗？
-
我想使用谷歌的Firebase为网络构建一个消息应用程序。在这个应用程序中，用户应该向/从其他用户发送和接收消息。我检查了谷歌的Firebase网站，但我迷路了。你能告诉我从哪里开始吗？你能给我看任何与Firebase网络消息相关的教程或类似的东西吗？我欢迎任何建议。谢谢。