为什么需要消息队列，消息队列的使用场景：
1、系统崩溃，程序出错
2、服务器能力有限、请求量巨大
3、链路耗时长尾
4、日志存储
解决方案：使用消息队列来解耦、削峰、异步
消息队列(MQ)：指保存消息的一个容器，本质是个队列，但需要支持高吞吐、高并发、并且高可用。
消息队列对比：
Kafka:分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色
RocketMQ:低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实时场景中运用较广
Pulsar:是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计
BMQ:和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群
Kafka:
使用场景：搜索服务、直播服务、订单服务、支付服务、用户行为服务
如何使用Kafka：创建集群-新建Topic-编写生产者逻辑-编写消费者逻辑
基本概念：
Topic: Kakfa中的逻辑队列，可以理解成每一个不同的业务场景就是一个不同的topic，对于这个业务来说，所有的数据都存储在这个topic中
Cluster: Kafka的物理集群，每个集群中可以新建多个不同的topic
Producer:顾名思义，也就是消息的生产端，负责将业务消息发送到Topic当中
Consumer:消息的消费端，负责消费已经发送到topic中的消息
Partition:通常topic会有多个分片，不同分片直接消息是可以并发来处理的，这样提高单个Topic的吞吐
Offset:消息在partition 内的相对位置信息，可以理解为唯一ID，在 partition内部严格递增
Replica:每个分片有多个Replica，Leader Replica将会从ISR中选出。
ZooKeeper:负责存储集群元信息，包括分区分配信息等。
消息流程：Producer生产Broker给Consumer消费
Producer支持批量发送、数据压缩
Broker支持顺序写、消息索引、零拷贝
Consumer支持Rebalance
Kafka的问题：
1、运维成本高 2、对于负载不均衡的场景，解决方案复杂 3、没有自己的缓存，完全依赖Page Cache 节跳动青训营 4、Controller和 Coordinator和Broker 在同一进程中，大量IO会造成其性能下降
