一、消息队列会遇到的问题

1.系统崩溃
解决方法——解耦
2.服务处理能力有限
解决方法——削峰
3.链路耗时长尾
解决方法——异步
4.日志如何处理
解决方法——日志处理

二、相关的基本概念

消息队列：指保存消息的一个容器，本质是个队列，但这个队列需要支持高吞吐，高并发，且高可用。
发展历程：TIB诞生于1985年，服务于金融机构和新闻机构；IBM MQ／Web sphere诞生于1993年，商业消息队列平台市场主要玩家；MSMQ由微软于1993年发布；JMS诞生于2001年，本质上是一套JAVAAPI；AMQP/RabbitMQ规范发布于2004年，同年，Rabbit MQ面市；Kafka（分布式、分区、多副本的日志提交服务，在高吞吐场景下发挥较为出色）于２０１０年由Linked开源；RocketMQ，２０１１年阿里中间件团队自研；Pulsar（是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计），２０１２年诞生于Yahoo内部。

三、业界消息队列对比

Kafka

使用场景

搜索服务、直播服务、订单服务、支付服务

使用方法

创建集群—新增Topic（逻辑队列）—编写生产者逻辑—编写消费者逻辑

基本概念

Topic
Cluster：物理集群，每个集群可建立多个Topic
Producer：生产者，负责将业务消息发送到Topic中
Consumer：消费者，负责消费Topic中Kafka
partition：Topic内的队列
Offset：消息在partition内的相对位置信息，可以理解为唯一ID，在partition内部严格递增。
Replica：每个分片有对个Replica，Leader　Replica将从ISR（In—Sync Replicas）中选出。

帮助Kafka提高稳定性的功能

Producer：批量发送，数据压缩
Broker：顺序写，消息索引，零拷贝
Consumer：Rebalance

Kafka问题

数据复制问题；重启操作；替换（类似重启）、扩容、缩容；负载不均衡；

问题总结

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

Pulsar

RocketMQ

低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实时场景中运用较广。

BMQ

特点：兼容Kafka协议，存算分离，云原生消息队列，BMQ的架构模型，解决了Kafka存在的问题。
BMQ高级特性：泳道，Databus，Mirror，Index，Parque。