这是我参与「第五届青训营 」伴学笔记创作活动的第 6 天
遇到如下场景，如何解决？
- 系统崩溃 -> 解耦
- 服务处理能力有限 -> 削峰
- 链路耗时长尾 -> 异步
- 日志如何处理
消息队列对比
- Kafka: 分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色
- RocketMQ: 低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实时场景中运用较广
- Pulsar: 是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计
- BMQ: 和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群
Kafka
基本概念
- Topic: 逻辑队列，不同 Topic 可以建立不同的 Topic
- Cluster: 物理集群，每个集群中可以建立多个不同的 Topic
- Producer: 生产者，负责将业务消息发送到 Topic 中
- Consumer: 消费者，负责消费 Topic 中的消息
- ConsumerGroup: 消费者组，不同组 Consumer 消费进度互不干涉
Kafka架构的主要术语包括Topic、Record和Broker。Topic由Record组成，Record持有不同的信息，而Broker则负责复制消息。
Offset
Offset: 消息在 partition 内的相对位置信息，可以理解为唯一ID，在 partition 内部严格递增
Replica
每个分片有多个 Replica，Leader Replica 将会从 ISR 中选出
Repica:分片的副本，分布在不同的机疑上，可用来容灾,Leader对外服务，Follower异步去拉取leader的数据进行同步，如果leader挂掉了，可以将Follower提升成为Leader再对外进行服务 ISR:意思是同步中的副本，对于Follower来说，始终和leader是有一定差距的，但当这差比较小的时候，我们就可以将这个Follower副本加入到ISR中，不在ISR中的本是不允许提升成Leader的
数据复制
下面这幅图代表着Kafka中副本的分布图。途中Broker代表每一个Kafka的节点，所有的Broker节点最终组成了一个集群,整个图表示，图中整个集群，包含了4个Broker机器节点，集群有两个Topic，分别是Topic1和Topic2， Topic1有两个分片，Topic2有1个分片,每个分片都是三副本的状态。这里中间有一个Broker同时也扮演了Controller的角色，Controller是整个集群的大脑，负责对副本和Broker进行分配。
Porducer
对于Porducer 有批量发送，数据压缩（默认采用Snappy，现在用ZSTD较多）等处理。
Broker
Broker寻找消息，对于偏移量索引文件和时间戳索引文件，均采用二分法寻找
Broker可采用零拷贝
Consumer
Partition该由哪个Consumer来消费的问题，可以采用手动分配或者自动分配。、
