MQ组件盘点，哪些你用在了生产中？ - 王欣说AI|信息安全|AIGC|AI

对比分析一下市面上都有哪些mq，区别一下这些消息队列的不同，分析其优缺点。

市面上的MQ也好几种了，ActiveMq、RabbitMq、rocketMq、kafka、Pulsar。最近国内又陆陆续续开源了几个MQ，如：去哪儿网开源的qmq、腾讯开源的TubeMq、拍拍贷开源的pmq。
现在想需要对比区别一下这些消息队列的不同，分析其优缺点。

一、基本比较

二、各自优缺点

1、Kafka

大数据行业标配组件

2、RocketMq

有事务性消息、私信队列等支持，适合交易场景

3、Pulsar

新贵，地域复制、多租户、扩展性比较好

4、RabbitMq

erlang编写，性能较好。有不少互联网公司用。不过因为erlang，社区开发者较少

5、ActiveMq

项目较老，不够活跃，会丢消息，不适合在互联网项目使用

三、一些问题

1、Kafka的数据丢失问题

一开始就是存储在PageCache上的，定期flush到磁盘上的，也就是说，不是每个消息都被存储在磁盘了，如果出现断电或者机器故障等，PageCache上的数据就丢失了。
这个是总结出的到目前为止没有发生丢失数据的情况


props.put("compression.type", "gzip");

props.put("linger.ms", "50");

props.put("acks", "all");

props.put("retries ", MAX_VALUE);
props.put("reconnect.backoff.ms ", 20000);
props.put("retry.backoff.ms", 20000);


props.put("unclean.leader.election.enable", false);

props.put("enable.auto.commit", false);
限制客户端在单个连接上能够发送的未响应请求的个数。设置此值是1表示kafka broker在响应请求之前client不能再向同一个broker发送请求。注意：设置此参数是为了避免消息乱序
props.put("max.in.flight.requests.per.connection", 1);

2、Kafka重复消费原因

强行kill线程，导致消费后的数据，offset没有提交，partition就断开连接。比如，通常会遇到消费的数据，处理很耗时，导致超过了Kafka的session timeout时间（0.10.x版本默认是30秒），那么就会re-blance重平衡，此时有一定几率offset没提交，会导致重平衡后重复消费。
如果在close之前调用了consumer.unsubscribe()则有可能部分offset没提交，下次重启会重复消费

kafka数据重复 kafka设计的时候是设计了(at-least once)至少一次的逻辑，这样就决定了数据可能是重复的，kafka采用基于时间的SLA(服务水平保证)，消息保存一定时间（通常为7天）后会被删除