消息队列
（一）在同一时刻出现庞大的业务量时，如果出现系统崩溃、服务处理能力有限、链路耗时长和日志问题时应该如何处理？
场景一：系统崩溃
方案：解耦
通过增加消息队列的方式，减少模块之间的耦合，为系统提供信息备份，避免系统崩溃带来的损失
场景二：服务处理能力有限
方案：削峰
通过增加消息队列的方式，请求存在消息队列之后，进行请求的批量处理。
场景三：链路耗时长
方案：异步
同时处理多个订单的不同阶段，缩短多个订单的处理时间，提高订单处理效率。
场景四：日志问题
方案：暂存
（二）消息队列：保存信息的一个容器，本质是一个队列，但是需要支持高吞吐，高并发和高可用性。
（三）业界消息队列的对比
1．Kafka：分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色。
2．RocketMQ（阿里）：低延迟、强一致性、高性能、高可靠，万亿级的容量和灵活的可扩展性，在一些实时场景中运用较广。
3．Pulsar（腾讯）：是下一代云原生分布式信息流平台，集信息、存储，轻量化函数式计算为一体，采用存算分离的架构设计。
4．BMQ：和Pulsar类似。
（四）Kafka
业务场景：日志信息处理、Metrics数据和用户行为的处理。
1．如何使用kafka
创建集群->新增Topic->编写生产者逻辑->编写消费者逻辑
2．基本概念
整体：
Topic: Kakfa中的逻辑队列，可以理解成每一个不同的业务场景就是一个不同的topic，对于这个业务来说，所有的数据都存储在这个topic中。 Cluster: Kafka的物理集群，每个集群中可以新建多个不同的topic。 Producer:顾名思义，也就是消息的生产端，负责将业务消息发送到Topic当中。 Consumer:消息的消费端，负责消费已经发送到topic中的消息。 Partition:通常topic会有多个分片，不同分片直接消息是可以并发来处理的，这样提高单个Topic的吞吐。 ConsumerGroup:消费者组，不同组Consumer消费进度互不干涉。
Topic内部：
对于每一个Partition来说，每一条消息都有一个唯一的Offset
Offset：消息在partition内的相对位置信息，可以理解为唯一ID，在partition内部严格递增。
Partition内部：
每个副本有多个partition
Replica:分片的副本，分布在不同的机器上，可用来容灾，Leader对外服务，Follower异步去拉取Leader的数据进行一个同步，如果Leader挂掉了，可以将Follower提升威Leader再华外进行服务
ISR:意思是同步中的副本，对于Follower来说，始终和Leader是有一定差距的，但当这个差距比较小的时候，我们就可以将这个Follower副本加入到ISR中，不在ISR中的副本是不允许提升成Leader的
在ISR当中如果Leader这个副本所在的机器宕机了，那么可以在ISR当中选择一个副本重新成为Leader，继续为生产者或者消费者提供服务,保证其高可用性。
3．Kafka副本分布：
Broker代表每一个kafka的节点，所有的Broker节点最终组成了一个集群。整个图表示，图中整个集群，包含了4个Broker机器节点，集群有两个Topic，分别是Topic1和Topic2,，Topic1有两个分片，Topic2有1个分片，每个分片都是三副本的状态。这里中间有一个Broker同时也扮演了Controller的角色，Controller是整个集群的大脑，负责对副本和Broker进行分配
4．kafka架构
ZooKeeper:负责存储集群元信息，包括分区分配信息等
5．一条消息的处理流程
（1）Producer：
生产者将消息发送给Broker，途中采用批量发送的方式，目的是减少IO次数，加强发送能力，当一条消息很大的时候通过压缩，减少消息的大小
（2）Broker
Broker如何将文件写入本地磁盘
① Broker信息文件结构：
.Index文件：也就是Offset的映射。
.timeindex文件：与index文件类似。
将LogSegment的第一条offset作为右边的文件的命名
