消息队列
问题引入
- 系统崩溃了（存储服务宕机了
- 同时有多个请求？
- 链路耗时长尾（操作的最后一步耗时长，一致再加载
- 日志存储（服务器坏了，日志丢掉了，该怎么办
先加入消息队列，算是一个缓存的
可以根据处理能力，从消息队列中取数据
下单后先加入消息队列，然后异步处理
这个时使用的什么软件好像？？？
消息队列是（MQ）保存消息的一个容器，本质是队列，支持高并发，高吞吐，并且高可用
常用消息队列
Kafka
使用场景
- 离线消息处理。例如日志信息---》kafka----》各种下游
- Metrics数据，一些程序的运行数据
- 用户消费数据，点赞，浏览
如何使用
创建集群-----》新建topic------》编写生产者逻辑--------》编写消费者逻辑
topic也可以看作是一个业务，partition算是一个业务里的不同分区，实现高并发，提高一个topic的吞吐能力。
partition下还有offset，消息在分区的相对位置，理解为唯一ID
partition下还有副本的概念，分布在集群的不同机器上，这样可以实现容灾的功能，高可用
副本有leader和follower，leader是进行读写的，follower拉取数据，努力保证与leader相同。follower与leader差距过大就会被剔除，例如上图的副本3。如果leader崩了，会从ISR冲选一个新的成为leader。
Controller
controller决定了集群的分配，哪个topic的哪个partition的哪个leader和follower归controller管
上层可能还有Zookeeper，与controller配合使用
一条消息的自述（运行流程
| Broker | 缓存代理，Kafka集群中的一台或多台服务器统称broker. |
|---|---|
| Kafka的生成者、消费者、broker的基本概念kafka broker |
Producer
- 批量发送（Batch
有一个弊端是等待成功后再发送下一个，如果消息量大，网络带宽不够用-----》压缩，减少消息大小，目前支持Snappy，Gzip，LZ4,ZSTD压缩算法，现在ZSTD可能更常用一些
Broker
2.Broker--数据的存储，如何存到磁盘上
Broker消息文件结构
对于每一个logsegment文件，是以文件内部的第一条消息的offset作为文件名的
Broker顺序写写入，减少磁盘寻道的时间，提高写入效率。
