消息队列

消息队列(MQ)，指保存消息的一个容器，本质是个队列。但这个队列呢，需要支持高吞吐，高并发，并且高可用。

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

Kafka

使用场景

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

怎么使用

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

组件概念

Topic:逻辑队列，不同Topic可以建立不同的Topic
Cluster:物理集群，每个集群中可以建立多个不同的Topic
Producer:生产者，负责将业务消息发送到Topic中
Consumer:消费者，负责消费Topic中的消息
ConsumerGroup:消费者组，不同组Consumer消费进度互不干涉
Offset :消息在partition内的相对位置信息，可以理解为唯一ID，在 partition内部严格递增。
Replica：每个分片有多个Replica,Leader Replica将会从ISR中选出。

可以设置多个分区的leader 在不同主机上。

生产者可以批量发送消息，节约时间成本，减少IO次数，增强发送能力。还可以通过压缩，减少消息大小，目前支持Snappy、Gzip、LZ4、ZSTD压缩算法

Broker

Broker的消息文件结构：

Broker磁盘结构：移动磁头找到对应磁道，磁盘转动，找到对应扇区，最后写入。寻道成本比较高，因此顺序写可以减少寻道所带来的时间成本。

采用顺序写的方式进行写入，以提高写入效率。

Consumer通过发送FetchRequest请求消息数据，Broker 会将指定Offset处的消息，按照时间窗口和消息大小窗口发送给Consumer，寻找数据这个细节是如何做到的呢?

首先二分找到小于目标offset的最大文件。
二分找到小于目标 offset的最大索引位置。
二分找到小于目标时间戳最大的索引位置，在通过寻找 offset的方式找到最终数据。

Consumer

怎么分配partition到Consumer Group中？

一、通过手动进行分配，哪一个Consumer消费哪一个Partition完全由业务来决定。缺点：

不能自动去容错容灾，一个consumer挂掉，那么对应的partition就停止消费了。
如果新增了一台Consumer4，那是不是又需要停掉整个集群，重新修改配置再上线。

二、对于不同的Consumer Group来讲，都会选取一台Broker当做Ccodinator，而Coordinator的作用就是帮助onsumerGroup进行分片的分配，也叫做分片的rebslance，使用这种方式,如果ConsumerGroup中有发生宕机，或者有新的Consumer加入，整个partition和Consumer都会重新进行分配来达到一个稳定的消费状态。

Rebanlance

帮助kafka提高吞吐量和稳定性：

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

那么kafka也存在问题的：

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

BMQ

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

与kafka对比

具体操作	Kafka	BMQ
重启	需要数据复制,分钟级重启	重启后可直接对外服务，秒级完成
替换	需要数据复制,分钟级替换,甚至天级别	替换后可直接对外服务，秒级完成
扩容	需要数据复制,分钟级扩容，甚至天级别	扩容后可直接对外服务，秒级完成
缩容	需要数据复制，分钟级缩容，甚至天级别	缩容后可直接对外服务，秒级完成

HDFS写文件流程

随机选择一定数量的 DataNode进行写入。

在BMQ集群中，对于单个副本来讲，是随机分配到不同的节点上面的。

保证对于任意分片在同一时刻只能在一个 Broker上存活

写文件流程

FailOver：
如果DataNode节点挂了或者是其他原因导致我们写文件失败，应该如何处理?
肯定是不能继续等着它恢复，谁知道啥时候能恢复呢，所以我们就选择正常的节点创建新的文件写入。

组件

Databus

简化消息队列客户端复杂度
解耦业务与Topic
缓解集群压力，提高吞吐

Index:
直接在BMQ中将数据结构化，配置索引DDL，异步构建索引后，通过Index Query服务读出数据.

Parquet:
Apache Parquet是Hadoop生态圈中一种新型列式存储格式，它可以兼容Hadoop生态圈中大多数计算框架(Hadoop、Spark等)，被多种查询引擎支持(Hive、Impala、Drill等)。

直接在BMQ中将数据结构化，通过 Parquet Engine，可以使用不同的方式构建Parquet格式文件。

RocketMQ

名称	Kafka	RocketMQ
逻辑队列	Topic	Topic
消息体 020	Message	Message
标签	无	Tag
分区	Partition	ConsumerQueue
生产者	Producer	Producer
生产者集群	无	Producer Group
消费者	Consumer	Consumer
消费者集群	Consumer Group	Consumer Group
集群控制器	Controller	Nameserver

简介

RocketMQ是阿里研发的一个队列模型的消息中间件，后开源给apache基金会成为了apache的顶级开源项目，具有高性能、高可靠、高实时、分布式特点。

普通消息
定时/延时消息
顺序消息
事务消息
消息发送重试和流控机制
消费者分类
消息过滤
消费者负载均衡
消费进度管理
消费重试
消息存储和清理机制

延时

定时消息是 Apache RocketMQ 提供的一种高级消息类型，消息被发送至服务端后，在指定时间后才能被消费者消费。通过设置一定的定时时间可以实现分布式场景的延时调度触发效果。

失败

处理失败消息，一般两种处理方法，重试和丢弃失败消息。

Apache RocketMQ 客户端连接服务端发起消息发送请求时，可能会因为网络故障、服务异常等原因导致调用失败。为保证消息的可靠性， Apache RocketMQ 在客户端SDK中内置请求重试逻辑，尝试通过重试发送达到最终调用成功的效果。

同步发送和异步发送模式均支持消息发送重试。

重试流程

生产者在初始化时设置消息发送最大重试次数，当出现上述触发条件的场景时，生产者客户端会按照设置的重试次数一直重试发送消息，直到消息发送成功或达到最大重试次数重试结束，并在最后一次重试失败后返回调用错误响应。

同步发送：调用线程会一直阻塞，直到某次重试成功或最终重试失败，抛出错误码和异常。
异步发送：调用线程不会阻塞，但调用结果会通过异常事件或者成功事件返回。

消息队列kafka、MQ