消息队列的优缺点,使用场景
优点:
1、解耦,降低系统之间的依赖
2、异步处理,不需要同步等待
3、削峰填谷,将流量从高峰期引到低谷期进行处理
缺点:
1、增加了系统的复杂度,幂等、重复消费、消息丢失等问题的带入
2、系统可用性降低,mq的故障会影响系统可用
3、一致性,消费端可能失败
场景:
日志采集、发布订阅等
如何保证消息不被重复消费
幂等:
一个数据或者一个请求,重复来多次,确保对应的数据是不会改变的,不能出错。
思路:
- 如果是写 redis,就没问题,反正每次都是 set ,天然幂等性
- 生产者发送消息的时候带上一个全局唯一的id,消费者拿到消息后,先根据这个id去 redis里查一下,之前有没消费过,没有消费过就处理,并且写入这个 id 到 redis,如果消费过了,则不处理。
- 基于数据库的唯一键
Kafka、ActiveMQ、RabbitMQ、RocketMQ 对比
ActiveMQ:
JMS规范,支持事务、支持XA协议,没有生产大规模支撑场景、官方维护越来越少
RabbitMQ:
erlang语言开发、性能好、高并发,支持多种语言,社区、文档方面有优势,erlang语言不利于java程序员二次开发,依赖开源社区的维护和升级,需要学习AMQP协议、学习成本相对较高以上吞吐量单机都在万级
kafka:
高性能,高可用,生产环境有大规模使用场景,单机容量有限(超过64个分区响应明显变长)、社区更新慢,吞吐量单机百万
rocketmq:
java实现,方便二次开发、设计参考了kafka,高可用、高可靠,社区活跃度一般、支持语言较少,吞吐量单机十万
相关文章
暂无评论...