遇到的问题:
-
系统崩溃
-
服务处理能力有限
-
链路耗时长尾
-
日志如何处理
三个作用解耦、削峰、异步
解耦:请求发送到消息队列中,再进行处理
削峰: 请求先放到消息队列中,然后同时处理合适的请求数量
异步:在消息队列中,就显示成功,用户和商家之间不同步的进行处理
消息队列:保存消息的容器,高吞吐、高并发、高可用
- 数据复制
- 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中