消息队列｜青训营四个场景如何解决系统崩溃存储服务崩溃解耦先把记录放进消息队列服务处理能力有限削峰订单都

四个场景如何解决
- 系统崩溃存储服务崩溃
  - 解耦先把记录放进消息队列
- 服务处理能力有限
  - 削峰订单都放入消息队列处理从里面拉取
- 链路耗时长
  - 放入消息队列异步
- 日志如何处理
  - 日志放入消息队列
- 消息队列保存消息的容器需要支持高吞吐 高并发 高可用
Kafaka
- 使用场景
  - 日志信息
  - Metrics数据
  - 用户的行为（搜索点赞评论收藏）
- 如何使用
  - 创建集群（Cluster）
  - 新增Topic （逻辑队列）会有多个分区（Partition）
  - 编写生产者逻辑（Producer）
  - 编写消费者逻辑（Consumer (Group) ）
- Offset 在partition的相对位置可以理解为唯一ID 内部严格递增
- Replica 副本主从的角色 Leader Follower 会有多个差距过大的会被踢出 ISR概念
- Controller 架构图 还有一些该概念可以再去了解了解
- Producer 提高吞吐和稳定性的功能以下三方面
  - Batch 分批发送解决QPS
  - 数据压缩解决数据量太大 ZSTD压缩算法
- Broker
  - Broker消息文件结构顺序写提高写入效率
  - 二分查找稀疏索引
  - 传统数据拷贝有多次内核态到用户态（写入同理）
  - 采取零拷贝直接从磁盘读数据到Buffer 再到网卡
- Consumer
  - 数据分配：手动分配自动分配
  - Rebalance 策略（比较复杂）
- 缺点：
  - Kafka重启 Leader切换追赶数据数据同步 Leader回切
  - 替换扩容缩容
  - 只要有节点变动都会有数据复制带来的成本
  - 负载不均衡需要迁移需要复制（复制本身就带来负载）
  - 运维成本高负载均衡方案复杂没有自己的缓冲
  - 三层在一个进程有可能一起挂
BMQ （自研）兼容Kafka 存算分离支持云原生
- 多了个Proxy
- 重启替换扩容缩容秒级完成 Kafaka 小时甚至天
- 数据分配均匀
- 状态机
- Broker写文件流程
  - 数据校验
  - 放到buffer
  - 异步线程写入
  - 返回策略
- Datanode 节点挂换个节点
- 请求数据->Wait->Cache->Storage
- 如果缓存有直接返回没有去Storage
- 多机房部署
- 高级特性
- 泳道消息
- Databus
- Parquet 列式存储
RocketMQ----用于实时的业务跳过了简单介绍一下

RocketMQ 是一个开源的分布式消息中间件系统，由阿里巴巴集团开发和维护。它被设计用于解决大规模分布式系统中的消息传递和通信问题。RocketMQ 具有高吞吐量、低延迟、高可靠性和强大的扩展性，被广泛应用于各种场景，如电子商务、物联网、金融、大数据等。

消息队列｜ 青训营

消息队列｜青训营