1、引言
如何解决以下4个场景：
- 系统崩溃
- 服务器处理能力有限
- 链路耗时长
- 日志如何处理 解决方案：
- 1、解耦
- 2、削峰
- 3、异步
- 4、日志处理
总的来说：消息队列（MQ）,是指保持消息的一个容器，本质上是一个队列。该队列需要支持高吞吐、高并发、并且高可用
2、消息队列-Kafka
2.1、使用场景：
- 日志信息
- Metrics数据
- 用户行为
2.2、如何使用Kafka
2.3、基本概念：
- Topic: 逻辑队列，不同Topic可以建立不同的Topic
- Cluster：物理集群：每个集群中可以建立多个不同的Topic
- Producer：生产者：负责将业务消息发送到Topic中
- Consumer：消费者：负责消费Topic中的消息
- ConsumerGroup：消费者组：不同组Consumer消费进度互不干涉
- Offset:消息在partition内部的相对位置信息，可以理解为唯一ID，在partition内部严格递增
- 每个分片有多个Replica,Leader Replica将会从ISR中选出
2.4 数据复制
2.5 Kafka 架构
ZooKeeper:负责存储集群元信息，包括分区分配信息等
2.6、一条消息的自述
- Producer--生产-->Broker--消费-->Consumer
2.7、Producer-批量发送
- 批量发送可以减少IO次数，从而加强发送能力
- 缺点：如果消息量很大，网络带宽不够用，效率低下
数据压缩：
- 通过压缩技术，减少消息大小，目前支持Snappy、Gzip、LZ4、ZSTD压缩算法
2.8 Broker消息文件结构
Broker-磁盘结构
Broker-如何找到消息
Consumer通过发送FetchRequest请求消息数据，Broker会将指定Offset处的消息，按时间窗口和消息大小窗口发送给Consumer：
偏移量索引文件
- 采用二分找到目标offset的最大文件
Broker时间戳索引文件
二分找到小于目标时间戳最大的索引位置，在通过寻找offset的方式找到最终数据。
2.9、Consumer-消息的接收端
- Low Level：通过手动分配，哪一个Consumer消费哪一个Partition完全由业务来决定
缺点：不能自动容灾，不能自主启频
- High Level：自动分配：
Consumer Rebalance
小结：哪些方法可以提高Kafka吞吐量或者稳定的功能？
- Producer：批量发送、数据压缩
- Broker：顺序写，消息索引、零拷贝
- Consumer：Rebalance
2.10、 Kafka-数据复制问题
2.11、Kafka-重启操作
2.13、Kafka- 替换、扩容、缩容
流程:
- 关机，重启
- Leader切换、追赶数据
- 数据同步完成
- Leader回切
2.14、Kafka-负载不均衡
Kafka-问题总结
- 1、运维成本高
- 2、对于负载不均衡的场景、解决方案复杂
- 3、没有自己的缓存，完全依赖Page Cache
- Controller和Coordinator和Broker在同一进程中，大量IO会造成其性能下降
