走进消息队列

消息队列前世今生

系统崩溃

解耦

服务器处理能力有限

削峰

链路耗时长尾

异步

日志如何处理

日志处理

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

消息队列-Kafka

离线消息处理

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

日志信息、metrics数据、用户行为

如何使用kafka

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

Offset：消息在partition内的相对位置信息，可以理解为唯一ID，在partition内部严格递增

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

一条消息的自述

Producer 生产 Broker 消费 Consumer

如果发送一条信息，等到其成功后再发一条会有什么问题？

批量发送可以减少IO次数，从而加强发送能力

如果消息量很大，网络带宽不够用，如何解决？

通过压缩，减少消息大小

Broker如何存储到磁盘？

磁盘结构

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

Kafka采用顺序写，以提高写入效率

Broker如何找到消息？

Consumer通过发送FetchRequest请求消息数据，Broker会将指定Offset处的消息，按照时间窗口和消息大小窗口发送给Consumer

Broker偏移量索引文件二分找到小于目标offset的最大文件

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

Broker零拷贝

Consumer 消息的接收端

如何解决Partition再Consumer Group中的分配问题？

通过手动进行分配，哪一个Consumer消费哪一个Partition 完全由业务决定

问题：
1.不能自动容灾
2.变更时数据启停

自动分配 High-Level

Coordinator 某一个consumer group自动分配

Consumer Rebalance

总共讲了哪些可以帮助Kafka提高吞吐量或者稳定性的功能？

Producer：批量发送、数据压缩

Broker：顺序写，消息索引，零拷贝

Consumer：Rebalance

Kafka问题

1.数据复制问题
重启操作
1.关闭、重启
2.Leader切换，追赶数据
3.数据同步完成
4.Leader回切
替换、扩容、缩容

2.负载不均衡

问题总结

1.运维成本高

2.对于负载不均衡的场景，解决方案复杂

3.没有自己的缓存，完全依赖Page Cache

4.Controller和Coordinator和Broker在同一进程中，大量IO会造成其性能下降

消息队列- BMQ

为了解决Kafka的问题

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

运维操作对比

HDFS写文件

写文件Failover

Proxy 读取流程

等待机制，Proxy在没有数据的情况下，会在wait等待一段时间，再返回用户侧，一般来讲由两个配置决定——数据大小的窗口、时间窗口，降低IO压力。有Cache（和Kafak不同）

多机房部署

Proxy到Broker有跨机房操作

高级特性

泳道信息
多个人同时测试，需要等待上一个人测试完成
对于PPE的消费者来说，资源没有生产环境多，所以无法承受生产环境的流量
解决主干泳道流量隔离问题以及泳道资源重复创建问题

生产者 Databus
直接使用原生SDK会有什么问题？
1.客户端配置较为复杂
2.不支持动态配置，更改配置需要停掉服务
3.对于latency不是很敏感的业务，batch效果不佳
1.简化消息队列客户端复杂度
2.解耦业务与Topic
3.缓解集群压力，提高吞吐

集群mirror镜像
使用mirror通过最终一致的方式，解决跨region读写问题

消息拉出来之后建索引、Parquet
直接在BMQ中将数据结构化，配置索引DDL，异步构建索引后，通过Index Query服务读出数据

消息队列- RocketMQ

低延时，针对电商业务线；也会涉及秒杀

消息队列学习