【Advanced Java】消息队列

为什么要用消息队列

优点:

  • 解耦,producer 无需关心 consumer
  • 异步,consumer 异步写库
  • 削峰,高峰期

缺点:

  • 可用性降低
  • 复杂度提高。重复消费,消息丢失,消息顺序性
  • 一致性
特性 ActiveMQ RabbitMQ RocketMQ Kafka
单机吞吐量 万级,比 RocketMQ、Kafka 低一个数量级 同 ActiveMQ 10 万级,支撑高吞吐 10 万级,高吞吐,一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic 数量对吞吐量的影响 topic 可以达到几百/几千的级别,吞吐量会有较小幅度的下降,这是 RocketMQ 的一大优势,在同等机器下,可以支撑大量的 topic topic 从几十到几百个时候,吞吐量会大幅度下降,在同等机器下,Kafka 尽量保证 topic 数量不要过多,如果要支撑大规模的 topic,需要增加更多的机器资源
时效性 ms 级 微秒级,这是 RabbitMQ 的一大特点,延迟最低 ms 级 延迟在 ms 级以内
可用性 高,基于主从架构实现高可用 同 ActiveMQ 非常高,分布式架构 非常高,分布式,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用
消息可靠性 有较低的概率丢失数据 基本不丢 经过参数优化配置,可以做到 0 丢失 同 RocketMQ
功能支持 MQ 领域的功能极其完备 基于 erlang 开发,并发能力很强,性能极好,延时很低 MQ 功能较为完善,还是分布式的,扩展性好 功能较为简单,主要支持简单的 MQ 功能,在大数据领域的实时计算以及日志采集被大规模使用

高可用

HA, HighAvailability

RabbitMQ

  • 单机模式
  • 普通集群模式(无高可用)。数据在一台实例上,其他的同步 queue 元信息(用元信息找到存放数据的实例)
  • 镜像集群模式

Kafka

kafka-arch.png

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

消费的时候,只会从 leader 去读,但是只有当一个消息已经被所有 follower 都同步成功返回 ack 的时候,这个消息才会被消费者读到。

重复消费

通常由下游保证。

可靠消息

  • 生产者丢了 => MQ ack
  • MQ 丢了 => MQ ack until persistence completion
  • consumer 丢了 => consumer ack

消费积压

  • 紧急扩容,加速消费
  • 大量积压快过期了,可以先批量重导

设计一个 MQ

  • 可伸缩性,broker->topic->partition
  • 可靠性,持久化到磁盘,顺序写
  • 可用性,leader->follower

Reference