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