消息队列应用场景

文章讨论了消息队列在系统解耦、削峰和异步处理中的作用,重点介绍了Kafka的架构特点,包括数据复制、Paratition分配和消费者通信。同时,提到了Kafka在数据一致性、节点重启及负载均衡方面的问题。文中还提及了其他消息队列如BMQ和RocketMQ的特性,以及消费重试和死信队列的概念。
摘要由CSDN通过智能技术生成

遇到的问题:

  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中

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

消费重试&死信队列

在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值