【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
写数据的时候,生产者就写 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