这是我参与「第五届青训营 」伴学笔记创作活动的第 7 天
消息队列
本次了解了消息队列的底层原理 架构等等
引入
四个场景：
-
系统奔溃
如果因为服务器宕机导致本地日志丢掉了，要怎么处理。
这里引入消息队列进行解耦，即使这里的存储服务发生故障，这里的消息也会存储到消息队列中。
-
服务处理能力有限
引入消息队列来进行削峰
-
链路耗时长尾
挺有意思的，就是使用消息队列存储，使得同一个任务能够被不同的对象消费，这样就能够异步地执行这个任务了（不过这里执行一致性似乎需要保证，比如中间有一个环节出错了，那应该还是需要整体回滚）
-
日志如何处理
什么是消息队列?
消息队列(MQ)，指保存消息的一个容器，本质是个队列。但这个队列呢，需要支持高吞吐，高并发，并且高可用。
业界消息队列对比：
- Kafka: 分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色
- RocketMQ:低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些 实时场景中运用较广
- Pulsar:是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、 采用存算分离的架构设计
- BMQ:和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步 替换掉对应的Kafka集群
Kafka
如何使用Kafka
- 创建集群
- 新增Topic
- 编写生产者逻辑
- 编写消费者逻辑;
相关概念
- Topic:逻辑队列，不同Topic可以建立不同的Topic
- Cluster:物理集群，每个集群中可以建立多个不同的Topic
- Producer:生产者，负责将业务消息发送到Topic中
- Consumer:消费者，负责消费Topic中的消息
- ConsumerGroup:消费者组，不同组Consumer消费进度互不干涉
- Parition是topic的一个分区概念，不同分区的消息是可以并发处理的
- Offset :消息在partition内的相对位置信息，可以理解为唯一ID, 在partition内部严格递增。
- Replica：每个分片有多个Replica, L eader Replica将会从ISR中选出。
- ZooKeeper:负责存储集群元信息，包括分区分配信息等
从一条消息的视角，看看为什么Kafka能支撑这么高的吞吐
-
如果发送一条消息，等到其成功后再发一条会有什么问题? 显然发送能力不够，所以有了批量发送，批量发送可以减少IO次数，从而加强发送能力
-
但还有一个问题，如果单个信息的量很大，而且此时并发和吞吐都很大，此时带宽不够用怎么办？此时引出了数据压缩，通过压缩，减少消息大小，目前支持Snappy、 Gzip、 LZ4、ZSTD压缩算法。
存储
partition的副本最终都以日志的形式写入到磁盘中
对于一个log 会切分成多个logSegment（有顺序的）
然后单个logSegment组成就是：
-
.log(日志文件) （真实消息数据）
-
.index(偏移量索引文件)
（相对位置）
-
.timeindex(时间戳索引文件)
-
其他文件
上面索引的文件命名似乎是按照每一个segment的索引开始数字来记录的
Broker-磁盘结构 移动磁头找到对应磁道，磁盘转动，找到对应扇区，最后写入。 寻道成本比较高，因此顺序写可以减少寻道所带来的时间成本。
Broker-如何找到消息
Consumer通过发送FetchRequest请求消息数据，Broker 会将指定Offset处的消息，按照时间窗口和消息 大小窗口发送给Consumer,寻找数据这个细节是如何做到的呢?
-
偏移量索引查找
二分找到小于目标offset的最大文件（根据上面的命名规则来的)
索引是稀疏索引
-
时间戳索引文件
二分找到小于目标时间戳最大的索引位置，在通过寻找offset的方式找到最终数据。
其实就是一个二级索引，这里先根据时间戳找到offset，再根据offset找到对应的postion
