MQ · Elastic Code

应用场景
#

业务解耦：业务上不需要依赖
异步调用：可能会关注结果（采用回调或者反馈队列等方式）
流量削峰：用于突发流量，而不是持续流量（系统性能优化）
消息分发：用于多个消费者关注同一消息（多人订阅）

消息队列对比
#

消费语义
#

至少一次：消息不会丢失，但有可能被重复发送处理，其适用于对消息传递可靠性有要求，但可以容忍消息重复的场景，如事件通知
至多一次：消息可能会丢失，但绝不会重复入队，其适用于对消息传递可靠性要求不高的场景，如日志记录。
精准一次：消息不会丢失，也不会被重复发送，其适用于关键业务场景，需要严格保证消息处理一次且仅一次，如金融交易处理

rabbitMQ / kafka 如何保证消费精准一次（exactly-once）：

https://blog.csdn.net/qq_30009397/article/details/126766269

参考：
#

消息队列十连问：https://mp.weixin.qq.com/s/x5ugQ-GPbslOH12nYewnFg

消息队列对比、选型、剖析：https://cloud.tencent.com/developer/article/2449704

rabbitMQ

kafka

https://www.cnblogs.com/fulongyuanjushi/p/16457753.html https://www.cnblogs.com/arthinking/p/15422958.html 队列即管道管道坏了怎么办，能不能滴水不漏、无缝切换 -〉高可用问题管道断电了，管道中的数据是丢还是留 -〉数据安全性问题上游进来的水太猛了，管道会不会爆开？ -〉吞吐量的问题 Exchange 类型 Direct：完全匹配，只会转发到指定的 routing key，topic 的特殊形式，应用于高可靠的任务分发，如交易、转账等 Fanout：扇出，广播模式。直接广播到所有绑定到自身的队列，不关注 routing key， Topic：模糊匹配，routing key 中通过 * （一个）或者 # （0 或多个）来筛选不同的路由。应用于多个下游系统订阅上游系统的某个事件 Header ：匹配 AMQP 协议消息头而不是 routing key，和 direct 一样属于完全匹配，基本上也废弃了

MQ

应用场景
#

消息队列对比
#

消费语义
#

参考：
#

RabbitMQ

Kafka

应用场景#

消息队列对比#

消费语义#

参考：#

应用场景
#

消息队列对比
#

消费语义
#

参考：
#