这是我参与「第五届青训营 」笔记创作活动的第23天

走进消息队列

• 四个案例场景
  • 系统崩溃
  • 服务处理能力有限
  • 链路耗时长尾
  • 日志如何处理
• 解决方案
  • 解耦
  • 削峰
  • 异步
  • 日志处理

什么是消息队列？

指保存消息的一个容器，本质是一个队列，但是支持高吞吐，高并发，并且高可用

消息队列的发展

TIB -> IBM MQ/WebSphere -> MSMQ -> JMS -> AMQP/RabbitMQ -> Kafka -> RocketMQ -> Pulsar

• Kafka
  • 分布式的，分区的，多副本的日志提交网络，在高吞吐场景下发挥比较出色
• RocketMQ
  • 低延迟，强一致，高性能，高可靠，万亿级容量和灵活的可拓展性，实时场景中运用较广
• Pulsar
  • 下一代云原生分布式消息流平台，集消息存储，轻量化函数计算为一体，采用存算分离的架构设计
• BMQ
  • 和Pulsar类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群

Kafka

多用于：搜索服务，直播服务，订单服务，支付服务

如何使用

创建集群 -> 新增Topic -> 编写生产者逻辑 ->编写消费者逻辑

基本概念

Topic：逻辑队列，不同的任务可以建立不同的Topic

Cluster：物理集群，每个集群可以建立多个不同的Topic

Producer：生产这，负责将业务消息发送到Topic中

Consumer：消费者，负责消费Topic中的消息

ConsumerGroup：消费者组，不同的Consumer消费进度互不干涉

Replica：每个分片有多个Replica，Leader Replica将会从ISR中选出

存在问题

1. 运维成本高
2. 对于负载不均衡的场景，解决方案复杂
3. 没有自己的魂村，完全依赖Page Cache
4. Controller 和 coordinator和Broker在同一进程中，大量IO会造成其性能下降

BMQ

能够兼容Kafka协议，存算分离，云原生消息队列

运维操作对比

不管是重启，替换，还是扩容缩容，对比Kafka，都可以直接对外服务，并且秒级完成！

RocketMQ

大多用于电商业务线，业务涉及广泛，如：注册，订单，库存，物流等。同时也设计许多业务峰值时刻，如秒杀活动，周年庆等

相比Kafka多了标签和生产者集群两个概念

底层原理

• 架构模型
• 存储模型

高级特性

• 事务消息
• 重试
• 死信队列
• 延迟队列