消息队列应用场景

遇到的问题：

1. 系统崩溃

2. 服务处理能力有限

3. 链路耗时长尾

4. 日志如何处理

    三个作用解耦、削峰、异步
   

解耦：请求发送到消息队列中，再进行处理

削峰： 请求先放到消息队列中，然后同时处理合适的请求数量

异步：在消息队列中，就显示成功，用户和商家之间不同步的进行处理

---

消息队列：保存消息的容器，高吞吐、高并发、高可用

• 数据复制

• kafka架构

• 批量发送

• 顺序写，增加写入速度
  
• 偏移量查找： 二分查找小于目标offset的最大的索引位置

• 时间戳索引

• 零拷贝
  

Paratition分配 ：Rebalance

手动分配：自己分

自动分配

• 消费者和集群之间进行通信，商讨分配方案

kafka问题：

数据复制后，重启，重新选举leader，但新leader和旧leader数据不一样（追赶数据），数据同步完成，Leader回切（旧leader重新成为leader）

数据的最终一致性：不同节点通过副本的直接数据复制，达到最终一致性

节点重启时间长，多台并发重启？

可能两台机器重启在一个分片上，可能其中一台机器有多个分片，会导致一个集群的不可用

回切：目的是避免，在一个集群长期运行后，所有的leader分布在少数据节点上，导致数据的不均衡

负载不均衡

• 现在不均衡，要均衡，就得迁移，要复制，又会带来大量的IO
• 所以要设计一个极其复杂且权衡IO的方案

BMQ

• 存算分离：Proxy和Broker是无状态的，不会出现数据复制的情况

• BMQ数据副本随机分配到不同节点上

kafka的数据写入，先在leader上面写好文件，然后同步到Follower上，所以对于同一副本的所有Segement都在同一台机器上，就存在单分片过大导致负载不均衡问题

状态机

• recover状态： 只有一个节点写；上次写如果失败，save checkpoint 再写 （避免索引和数据不一致的问题）

写文件流程

• 写文件失败，不等节点恢复，直接换一个节点

Proxy

多机房

• 每个机房处理全量的Paratition
  

Databus

Mirrior

• mirror中间存在消息延迟

index

Parquet

• 列式存储

RocketMQ

针对秒杀业务，峰值业务

• Queue里面存索引，真实数据再CommitLog中

消费重试&死信队列