“发送确认”模式:即生产者通过MQ发送消息后,MQ需要将“已发送成功/失败”反馈给生产者,告知生产者消息已投递成功,此方式可确保消息正确地发送至RabbitMQ
“消费确认”模式:即消费者监听到MQ中队列的消息并执行完对应的业务逻辑后,需要发送“消息已被成功监听、消费”反馈给MQ,此方式可保证接收方正确接收并消费了消息,消费成功后消息将从队列中移除
“避免消息重复投递”:生产者在生产消息时,MQ内部会针对每条消息生成一个MsgId,该标识可以作为去重的依据(消息投递失败并重传),避免重复的消息进入队列
“消息消费时保证幂等性”:这一点可以利用业务本身的特性来实现,即每个业务实体一般都会有一个唯一的ID,就像数据库表中唯一的主键一样,在监听消费处理时根据ID作为去重的依据
“持久化”:将队列、交换机、消息都设置为持久化模式,确保消息在投递、发送期间出现MQ服务宕机后重启恢复过来时消息依旧存在
“消息消费重试机制”:指的是消费者在监听、消费、处理消息的过程中出现了异常,导致业务逻辑没有处理成功,此时可以开启“消息重入队列”机制,设置消息重入队列N次 进行 重试消费
“消息投递补偿机制”:指的是消息在生产、投递期间出现“投递失败”,也就是“发送不成功”的情况,此时可以将其加入到DB中,并开启定时任务,拉取那些投递不成功的消息,重新投递入队列,如此一来便可以保证消息不丢失且准备被投递
流程图
特性 | activeMQ | RabbitMQ | Kafka | RocketMQ |
---|---|---|---|---|
PRODUCER-CUMSUMER | 支持 | 支持 | 支持 | 支持 |
PUBLISH-SUBSCRIBE | 支持 | 支持 | 支持 | 支持 |
REQUEST-REPLY | 支持 | 支持 | 支持 | |
API完备性 | 高 | 高 | 高 | 低(静态配置) |
多语言支持 | 支持java优先 | 语言无关 | 支持java优先 | 支持 |
单机吞吐量 | 万级 | 万级 | 十万级 | 单机万级 |
消息延迟 | 微秒级 | 毫秒级 | ||
可用性 | 高(主从) | 高(主从) | 非常高(分布式) | 高 |
消息丢失 | 低 | 理论上不会丢失 | ||
消息重复 | 可控性 | 理论上会有重复 | ||
文档完备性 | 高 | 高 | 高 | 中 |
快速入门 | 有 | 有 | 有 | 无 |
部署难度 | 低 | 中 | 高 | |
java,中小型项目 | erlang语言,不好修改底层,不建议选用 | 编程语言Scala,大数据领域主流MQ | java,适用于大型集群项目 |