消息队列基础

消息队列基础 为什么使用消息队列

解耦、削峰、异步

消息队列带来的缺点

系统复杂性增加、一致性问题、系统可用性降低

消息队列对比 特性ActiveMQRabbitMQRocketMQkafka开发语言javaerlangjavascala单机吞吐量万级万级10万级10万级时效性ms级us级ms级ms级以内可用性高(主从架构)高(主从架构)非常高(分布式架构)非常高(分布式架构)功能特性成熟的产品，在很多公司得到应用；有较多的文档；各种协议支持较好基于erlang开发，所以并发能力很强，性能极其好，延时很低;管理界面较丰富MQ功能比较完备，扩展性佳只支持主要的MQ功能，像一些消息查询，消息回溯等功能没有提供，毕竟是为大数据准备的，在大数据领域应用广。

rabbitMQ 社区活跃，功能齐全，适合中小型公司。
rocketMQ 吞吐量大，适合中大型公司技术能力强。
KAFKA      大数据实时计算、日志采集。

高可用 RabbitMQ 单机模式 普通集群模式

每个机器包含队列元数据。实际数据在一台机器上。消费数据同步拉取，提升消费吞吐量。

1、集群内大量数据传输

2、可用性无保障 ，queue所在节点挂掉，数据丢失。

没有什么所谓的高可用性，这方案主要是提高吞吐量的。

镜像集群模式

创建镜像集群策略，队列指定策略，队列元数据、实际数据都存在每个节点上。每个节点都有队列的镜像。
不是分布式的，队列数据量很大的话，较消耗磁盘。

kafka

由多个 broker 组成，每个 broker 是一个节点；你创建一个 topic，这个 topic 可以划分为多个 partition，每个 partition 可以存在于不同的 broker 上，每个 partition 就放一部分数据。
每个机器都有broker进程，创建一个topic，指定partion数量3个，partion在不同机器上。

写数据的时候，生产者就写 leader，然后 leader 将数据落地写本地磁盘，接着其他 follower 自己主动从 leader 来 pull 数据。一旦所有 follower 同步好数据了，就会发送 ack 给 leader，leader 收到所有 follower 的 ack 之后，就会返回写成功的消息给生产者。（当然，这只是其中一种模式，还可以适当调整这个行为）
消费的时候，只会从 leader 去读，但是只有当一个消息已经被所有 follower 都同步成功返回 ack 的时候，这个消息才会被消费者读到。

RocketMQ 部署方式优点缺点备注单个Master模式一旦Broker重启或者宕机时，会导致整个服务不可用，不建议线上环境使用；多个Master模式配置简单，单个Master宕机或重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高。单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会收到影响。当使用多master无slave的集群搭建方式时，master的brokerRole配置必须为ASYNC_MASTER。如果配置为SYNC_MASTER，则producer发送消息时，返回值的SendStatus会一直是SLAVE_NOT_AVAILABLE。多Master多Slave模式——异步复制即使磁盘损坏，消息丢失的非常少，但消息实时性不会受影响，因为Master宕机后，消费者仍然可以从Slave消费，此过程对应用透明，不需要人工干预，性能同多Master模式几乎一样。Master宕机，磁盘损坏情况，会丢失少量信息多Master多Slave模式——同步双写数据与服务都无单点，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高；性能比异步复制模式稍低，大约低10%左右，发送单个消息的RT会稍高，目前主宕机后，备机不能自动切换为主机，后续会支持自动切换功能。

如果数据对高可用要求比较高，采用多master，多slave模式–同步双写，虽然虽然会降低效率，增加运营成功，但是对于系统解耦和可用性来说是值得的。 

保障消息不重复消费

消息队列消费需要保障不能多也不能少，不能多要保障幂等性，不能少保障消息不丢失（下一章节会介绍）。

RabbitMQ、RocketMQ、Kafka，都有可能会出现消息重复消费的问题。通常重复消费问题通常不是 MQ 自己保证的，是由我们开发策略来保证的。

幂等策略

• 比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update 一下好吧。
• 比如你是写 Redis，那没问题了，反正每次都是 set，天然幂等性。
• 比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的 id，类似订单 id 之类的东西，然后你这里消费到了之后，先根据这个 id 去比如 Redis 里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个 id 写 Redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。
• 比如基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了，重复数据插入只会报错，不会导致数据库中出现脏数据。

可靠性传输 RabbitMQ 生产者丢失数据

通常两种方式：事务机制、/confirm/i机制。

事务机制和 /confirm/i 机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是 /confirm/i 机制是异步的，你发送个消息之后就可以发送下一个消息，然后那个消息 RabbitMQ 接收了之后会异步回调你的一个接口通知你这个消息接收到了。

所以一般在生产者这块避免数据丢失，都是用 /confirm/i 机制的。

自身丢失数据

开启 RabbitMQ 的持久化，就是消息写入之后会持久化到磁盘，哪怕是 RabbitMQ 自己挂了，恢复之后会自动读取之前存储的数据，一般数据不会丢。除非极其罕见的是，RabbitMQ 还没持久化，自己就挂了，可能导致少量数据丢失，但是这个概率较小。

设置持久化有两个步骤：

• 创建 queue 的时候将其设置为持久化
  这样就可以保证 RabbitMQ 持久化 queue 的元数据，但是它是不会持久化 queue 里的数据的。
• 第二个是发送消息的时候将消息的 deliveryMode 设置为 2
  就是将消息设置为持久化的，此时 RabbitMQ 就会将消息持久化到磁盘上去。

持久化可以跟生产者那边的 /confirm/i 机制配合起来，只有消息被持久化到磁盘之后，才会通知生产者 ack 了，所以哪怕是在持久化到磁盘之前，RabbitMQ 挂了，数据丢了，生产者收不到 ack，你也是可以自己重发的。

消费者丢失数据

关闭 RabbitMQ 的自动 ack，可以通过一个 api 来调用就行，然后每次你自己代码里确保处理完的时候，再在程序里 ack 一把。

KAFKA  生产端丢失

设置 acks=all，一定不会丢，要求是，你的 leader 接收到消息，所有的 follower 都同步到了消息之后，才认为本次写成功了。如果没满足这个条件，生产者会自动不断的重试，重试无限次。

自身丢失

• 给 topic 设置 replication.factor 参数：这个值必须大于 1，要求每个 partition 必须有至少 2 个副本。
• 在 Kafka 服务端设置 min.insync.replicas 参数：这个值必须大于 1，这个是要求一个 leader 至少感知到有至少一个 follower 还跟自己保持联系，没掉队，这样才能确保 leader 挂了还有一个 follower 吧。
• 在 producer 端设置 acks=all：这个是要求每条数据，必须是写入所有 replica 之后，才能认为是写成功了。
• 在 producer 端设置 retries=MAX（很大很大很大的一个值，无限次重试的意思）：这个是要求一旦写入失败，就无限重试，卡在这里了。

消费端丢失

关闭自动提交 offset，在处理完之后自己手动提交 offset，就可以保证数据不会丢。但是此时确实还是可能会有重复消费，比如你刚处理完，还没提交 offset，结果自己挂了，此时肯定会重复消费一次，自己保证幂等性就好了。

RocketMQ

关注公众号，发送 ms 免费获取 海量JAVA大厂面试题。