消息队列

本节课主要讲解了，底层原理，架构设计，高级特性

场景： 上完课回到宿舍，想买新出的游戏机，突然想到抖音直播活动，打开手机打开了直播搜索，打开了游戏机的详情页，在用户搜索后，搜索记录存储过程中发生了宕机怎么办？

同时处理多条订单请求，面对庞大的请求量，何去何从。？

一套流程，发起订单，库存记录-1，订单记录-1，通知商家的流程，花费时间太长？

本地日志丢掉了，如何处理？

1.解耦：先存到消息队列当中，再启用存储服务。

2.削峰：每次只获取10个请求进行处理。

3.异步：异步执行订单。库存，通知商家的操作。

4.先存到消息队列，再通过一系列技术，进行一个简单的分期。

什么是消息队列？？？！！

消息的一个容器，高吞吐 高并发 高可用

前世今生

诞生于1983年，TIB的出现，IBM，MSMQ，JMS，AMQP，Kafka，RocketMQ，Pulsar

对比：

Kafka：高吞吐发挥出色 RocketMQ：实时场景是中运用较广 Pulsar（TX在用）：集消息，存储，轻量化函数式计算为一体，采用存算分离的架构设计 BMQ：于Pulsar类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的KafKa集群

Kafka

使用场景：

离线的日志信息，（搜索，直播，订单，支付）Metrics数据（程序状态的采集），用户行为（搜索，点赞，评论，收藏）

基本使用：

创建集群->新增Topic->编写生产者逻辑->编写消费者逻辑

基本概念：

Topic：逻辑队列，不同的Topic可以建立不同的Topic Cluster：物理集群，每个集群中可以建立多个不同的Topic Producer：生产者，负责将业务信息发送到Topic中 Consumer：消费者，负责消费Topic中的信息 ConsumerGroup：消费者组，不同组Consumer消费进度互不干涉。

Offset：消息在partition内的相对位置信息，可以理解为唯一id，在partition内部严格递增

Replica：每个分片有多个，Replica，LeaderReplica将从ISR中选出