MQ
2022-10-03 13:24:36 1 举报
AI智能生成
聊聊 MQ 那点事
作者其他创作
大纲/内容
系统解耦
异步通知
流量削峰
作用
高性能
数据冗余
故障自动恢复
高可用
数据可靠性
资源可伸缩
特性
追尾读
追赶读
消费者消费数据的情况
基础知识
从 Kafka 到 Pulsar 的进阶之路
面试官让我重构 Kafka,懵了……
参考资料
物理模型
逻辑模型
怎么保证高可用?主从复制,对每个 partition 维护若干冗余副本
偏移量 offset
架构设计
常见问题
给某个 partition 新增一个 follower 副本
扩容后需要做 Reassign Partitions
复制 partition 数据,IO 消耗大
broker 和 partition 的数据存储牢牢绑定在一起
消息持久化并不可靠,可能丢消息。
读写操作可能会互相影响,互相争用内存资源
监控体系不完善,排查问题较为繁琐
不支持死信队列和延迟队列
消息重置不方便
没有租户概念,需要手动维护多个集群,不方便运维。
Kafka 痛点
完全依赖操作系统的 Page Cache
业务需求不便
Kafka
broker 是无状态的,所以很容易借助 k8s 这样的基础设施实现弹性扩缩容。
broker 把数据存储的关键任务甩给了分布式日志存储系统 BookKeeper
broker 和数据的关联关系记录在 zookeeper 中:在 broker 间转移 partition 只需简单修改元数据即可,完全不会涉及数据复制
多层的存算分离架构
怎么保证高可用?采用 Quorum 机制,消息会被并发地“以滚动的方式”选取不同的 bookie 节点进行写入 - 数据被均匀地冗余存储
通过条带化写入的形式,非常方便对 bookie 节点可以进行快速故障恢复和扩容
节点对等架构
读写隔离:bookie 节点实现读写隔离,写入不再依赖 Page Cache,保证数据可靠性
Bookkeeper 架构设计
自带监控体系,broker,bookie 相关指标清晰,方便快速定位问题
支持多租户,可以按照不同小组和对应的服务级别来管理消息保存时间、持久化、堆积清除策略等,统一维护一套 Pulsar 集群。方便运维
采用存储和计算分离的云原生的架构
支持死信队列和延迟队列。
重置消息简单快捷
Pulsar
Pulsar VS Kafka 性能对比
相关产品
MQ
0 条评论
回复 删除
下一页