惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
The Last Watchdog
The Last Watchdog
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
T
Troy Hunt's Blog
L
LINUX DO - 最新话题
C
Check Point Blog
T
Threat Research - Cisco Blogs
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
罗磊的独立博客
V
Vulnerabilities – Threatpost
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
J
Java Code Geeks
Apple Machine Learning Research
Apple Machine Learning Research
大猫的无限游戏
大猫的无限游戏
S
Security @ Cisco Blogs
IT之家
IT之家
T
The Exploit Database - CXSecurity.com
The GitHub Blog
The GitHub Blog
D
Docker
Engineering at Meta
Engineering at Meta
AWS News Blog
AWS News Blog
S
Security Affairs
U
Unit 42
P
Palo Alto Networks Blog
V
Visual Studio Blog
Y
Y Combinator Blog
D
DataBreaches.Net
Forbes - Security
Forbes - Security
阮一峰的网络日志
阮一峰的网络日志
美团技术团队
Security Latest
Security Latest
aimingoo的专栏
aimingoo的专栏
Simon Willison's Weblog
Simon Willison's Weblog
A
Arctic Wolf
博客园_首页
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
H
Hacker News: Front Page
博客园 - 司徒正美
博客园 - Franky
宝玉的分享
宝玉的分享
TaoSecurity Blog
TaoSecurity Blog
Latest news
Latest news
Scott Helme
Scott Helme
MongoDB | Blog
MongoDB | Blog
量子位
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
C
Cisco Blogs
P
Privacy International News Feed
Application and Cybersecurity Blog
Application and Cybersecurity Blog

RabbitMQ

一个任务有 10 个处理步骤,在 mq 中把每一个步骤都设置成一个 TOPIC,在 mq 里 将这么多任务步骤细分这么多 topic 的好处该怎么回答? - V2EX 请教一下各位大佬 rabbitMq 接收数据的问题 - V2EX RabbitMQ 使用过程中,什么时候才需要新建 exchange? - V2EX 求问 RabbitMQ 一个 queue 多个 consumer 只有少部分能收到信息是怎么回事 - V2EX RabbitMQ 在有多个消费者(单个应用部署多个实例)的情况下如何保证顺序消费 - V2EX 客户端连接 rabbitmq 如何验证客户端合法性? - V2EX springboot 集成 RabbitMQ 的问题 - V2EX AMQP 1.0 的现状? - V2EX RabbitMQ 不能实现消息超时之后自动重新分发吗? - V2EX 在 Mac OS X 下安装 RabbitMQ - V2EX
rabbitMQ 的 topic 模式下,如何实现有 N 个订阅者,发布一条消息后,当 N 个消费者都拿到这个消息后将该消息销毁(确认消费) - V2EX
zzNaLOGIC · 2020-09-15 · via RabbitMQ

这是一个创建于 2098 天前的主题,其中的信息可能已经有所发展或是发生改变。

第 1 条附言  ·  2020 年 9 月 16 日

已考虑中解决方案:
1.使用 fanout 模式广播,同时每个消费者单独监听一个队列,将需要的队列全部绑定到 fanout 交换机,每个消费者在自己的队列里拿到消息就直接确认消费。fanout 模式可以保证所有消费者都拿到,目前 topic 方案的问题在于,所有消费者都监听一个队列,同时只有一个消费者可以拿到消息,如果拿到就确认后面的消费者就拿不到消息了,如果不确认无法知道所有消费者都拿到消息了,最终销毁消息无法实现。而 fanout 方案可以保证所有人都拿到消息且所有人都可以拿到消息就确认,实现单条消息向所有消费者都推送一次。缺点是每个消费者都需要一个队列。

第 2 条附言  ·  2020 年 9 月 16 日

2.改用 redis 的发布订阅,redis 的发布订阅只会向所有订阅者推送一次随后就自动丢弃。可以实现这个场景。但 redis 的发布订阅问题在于消息可靠性不高。无法持久化,这就得考虑业务对消息丢失的容忍度。以我目前这个场景容忍度是符合要求的

zzNaLOGIC

2

zzNaLOGIC      2020 年 9 月 15 日 via Android

@xiaodoudou rabbitmq 好像是没有类似的方法的,topic 类型虽然是可以实现每个消费者都接受到,但没办法做到每个消费者消费一次就销毁

npe

3

npe      2020 年 9 月 16 日 via iPhone

只知道 Kafka 有 consumer group

zzNaLOGIC

4

zzNaLOGIC      2020 年 9 月 16 日 via Android

@npe 可惜现在没这条件再布一个

zzNaLOGIC

6

zzNaLOGIC      2020 年 9 月 16 日

@scnace 这是个好方案!学习了 虽然现在生产上来不及重新规划了,暂时确定用 redis 先让程序跑起来。但可以学习下,日后改进的时候用