常用消息中间件对比

本文正在参与【[ 一起秋招吧 ] 】 征文活动，一起来聊聊校招的那些事吧，牛客周边和百元京东卡等你来领~

大家好，我是小羽，专注于后端开发相关知识的分享。今天将给大家带来的是关于后端面试关于常用消息中间件的对比介绍。

消息队列的优缺点，使用场景

优点：
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，高可用、高可靠，社区活跃度一般、支持语
  言较少
  吞吐量单机十万