消息队列通信模式
点对点模式
点对点模式通常是基于拉取或者轮询的消息传送模型，这个模型的特点是发送到队列的消息被一个且只有一个消费者进行处理。生产者将消息放入消息队列后，由消费者主动的去拉取消息进行消费。点对点模型的的优点是消费者拉取消息的频率可以由自己控制。但是消息队列是否有消息需要消费，在消费者端无法感知，所以在消费者端需要额外的线程去监控。
发布订阅模式
发布订阅模式是一个基于消息送的消息传送模型，改模型可以有多种不同的订阅者。生产者将消息放入消息队列后，队列会将消息推送给订阅过该类消息的消费者（类似微信公众号）。由于是消费者被动接收推送，所以无需感知消息队列是否有待消费的消息！但是consumer1、consumer2、consumer3由于机器性能不一样，所以处理消息的能力也会不一样，但消息队列却无法感知消费者消费的速度！所以推送的速度成了发布订阅模模式的一个问题！假设三个消费者处理速度分别是8M/s、5M/s、2M/s，如果队列推送的速度为5M/s，则consumer3无法承受！如果队列推送的速度为2M/s，则consumer1、consumer2会出现资源的极大浪费！
案例引入
案例一：系统崩溃
解耦
通过将所有的行为记录发送到消息队列中，然后再由存储服务拉取进行消费。即使存储服务发生故障或宕机，消息也会发送到消息队列里，对整个的搜索流程并不影响。
案例二：服务能力有限
削峰
对于大量的请求可以放到消息队列当中，每次只去处理少量的请求。
案例三：链路耗时长尾
异步
将订单记录、库存记录与通知商家分布在不同的链路上，异步实现。
案例四：日志存储
线上日志一般放在消息队列里，通过日志专门处理的组件写入到搜索引擎里，并通过展示平台进行分析。Log->消息队列->LogStash->ES->Kibana
消息队列（MQ）是指保存消息的一个容器，本质是个队列。但这个队列需要支持高吞吐，高并发，并且高可用。
业界消息队列对比：
Kafka：分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色
RocketMQ：低延迟、强一致、高性能、高可靠、万级容量和灵活的可扩展性，在一些实时场景中运用较广
Pulsar：是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计
BMQ：和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群。
Kafka
kafka的使用：创建集群->新增Topic->编辑生产者逻辑->编写消费者逻辑
基本概念：
Topic：逻辑队列，不同Topic可以建立不同的Topic
Cluster：物理集群，每个集群中可以建立多个不同的Topic
Producer：生产者，负责将业务消息发送到Topic中
Consumer：消费者，负责消费Topic中的消息
ConsumerGroup：消费组，不同组Consumer消费进度互不干涉
Zookeeper：kafka集群依赖zookeeper来保存集群的元信息，来保证系统的可用性。
Offset：消息在partition内的相对位置信息，可以理解为唯一ID，在partition内部严格递增。
Replica：每个分片有多个Replica，Leader Replica将会从ISR中选出
提高Kafka吞吐与稳定性
Producer：批量发送、数据压缩
Broker：顺序写，消息索引，零拷贝
Consumer：Rebalance
未完后续补😭
