这是我参与「第五届青训营 」笔记创作活动的第12天 消息队列
四个场景
系统崩溃
解耦合，宕机也没事
服务处理能力有限
削峰：每次只获得10个
链路耗时长尾
异步：消息队列异步修理订单、库存和商家
- 日志如何处理
消息队列：支持高吞吐、高并发和高可用
Kafka:分布式的、分区的、多副本的日志提交服务，高吞吐场景下发挥比较出色。
RocketMQ：低延迟、强一致、高性能、高可靠、万亿级容量、灵活可扩展性，实时场景中运用较广
Pulsar：云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计。
BMQ：Pulsar类似，存算分离，高吞吐的离线业务场景，逐步替换掉对应的Kafka集群
Kafka
日志信息、Metrics数据、用户信息
使用Kafka：创建集群；新增topic；编写生产者逻辑；编写消费者逻辑
ISR如果和Leader差距过大，会被提出ISR，如果宕机，会在ISR中选择一个副本当Leader
批量发送：减少IO次数，提高发送能力
Broker 文件结构：日志文件；偏移量索引；时间戳索引
写入：顺序写
读取：二分找到小于offset的最大文件->二分找到小于目标offset的最大索引位置
Consumer Robalance 宕机
Producer：批量发送；数据压缩
Broker：顺序写，消息索引，零拷贝
Consumer：Rebalance
Kafka重启
Kafka替换、扩容、缩容
Kafka负载不均衡 运维成本高，负载不均衡场景解决方案复杂 没有自己的缓存
RocketMQ
电商业务线：注册、订单、物流
RocketMQ多了一个标签字段，多了一个Producer Group
NameServer：告诉数据在哪一个Broker上
高级特性：
事务场景，库存-1和写入消息队列保证事务
