30分钟带你了解「消息中间件」Kafka、RocketMQ

2022-04-24 消息中间件

30分钟带你了解「消息中间件」Kafka、RocketMQ

文章插图

消息中间件的应用场景

异步解耦
削峰填谷
顺序收发
分布式事务一致性

腾讯应用案例：

30分钟带你了解「消息中间件」Kafka、RocketMQ

文章插图

主流 MQ 框架及对比

30分钟带你了解「消息中间件」Kafka、RocketMQ

文章插图

说明

Kafka：整个行业应用广泛
RocketMQ：阿里，从 Apache 孵化
Pulsar：雅虎开源，符合云原生架构的消息队列，社区活跃
RabbitMQ 架构比较老， AMQP并没有在主流的 MQ 得到支持
NSQ：内存型，不是最优选择
ActiveMQ、ZeroMQ 可忽略

Kafka 优点

非常成熟，生态丰富，与 Hadoop 连接紧密
吞吐非常高，可用性高sharding提升 replication 速度
主要功能：pub-sub ，压缩支持良好
可按照 at least once, at most once 进行配置使用， exactly once 需要 Consumer 配合
集群部署简单，但 controller 逻辑很复杂，实现partition 得多副本、数据一致性
controller 依赖 ZooKeeper
异步刷磁盘（除了钱的业务，很少有同步 flush 的需求）

Kafka 缺点

写入延时稳定性问题， partition 很多时Kafka 通常用机械盘，随机写造成吞吐下降和延时上升100ms ~ 500ms
运维的复杂性单机故障后补充副本数据迁移快手的优化：迁移 partition 时旧数据不动，新数据写入新 partition 一定时间后直接切换

RocketMQ

阿里根据 Kafka 改造适应电商等在线业务场景
以牺牲性能为代价增强功能安 key 对消息查询，维护 hash 表，影响 io为了在多 shard 场景下保证写入延迟稳定，在 broker 级别将所有 shard 当前写入的数据放入一个文件，形成 commitlog list ，放若干个 index 文件维护逻辑 topic 信息，造成更多的随机读
没有中心管理节点，现在看起来并没有什么用，元数据并不多
高精度的延迟消息（快手已支持秒级精度的延迟消息）

Pulsar

存储、计算分离，方便扩容存储：bookkeeperMQ逻辑：无状态的 broker 处理

发展趋势

云原生
批流一体：跑任务时，需要先把 Kafka 数据→HDFS ，资源消耗大。如果本来就存在 HDFS ，能节省很大资源
Serverless

各公司发展

快手：Kafka所有场景均在使用特殊形态的读写分离数据实时消费到 HDFS在有明显 lag 的 consumer 读取时， broker 把请求从本地磁盘转发的 HDFS不会因为有 lag 的 consumer 对日常读写造成明显的磁盘随机读写由于自己改造，社区新功能引入困难
阿里巴巴：开源 RocketMQ
字节跳动在线场景：NSQ→RocketMQ离线场景：Kafka→自研的存储计算分类的 BMQ（协议层直接兼容Kafka ，用户可以不换 client）
百度：自研的 BigPipe ，不怎么样
美团：Kafka 架构基础上用 JAVA 进行重构，内部叫 Mafka
腾讯：部分使用了自研的 PhxQueue ，底层是 KV 系统
滴滴：DDMQ对 RocketMQ 和 Kafka 进行封装多机房数据一致性可能有问题
小米：自研 Talos架构类似 pulsar ，存储是 HDFS ，读场景有优化

Kafka

Kafka官网： https://kafka.apache.org/documentation/#uses
最新版本：2.7

Kafka 是什么？

开源的消息引擎系统（消息队列/消息中间件）
分布式流处理平台
发布/订阅模型
削峰填谷

Kafka 术语

Topic：发布订阅的主题
Producer：向Topic发布消息的客户端
Consumer：消费者
Consumer Group：消费者组，多个消费者共同组成一个组
Broker：Kafka的服务进程
Replication：备份，相同数据拷贝到多台机器Leader ReplicaFollower Replica ，不与外界交互
Partition：分区，解决伸缩性问题，多个Partition组成一个Topic
Segment：partition 有多个 segment 组成

Kafka 如何持久化？

上一篇：杨坚篡位为什么能成功杨坚为什么要废掉太子

下一篇：罗柴德尔斯家族百科罗斯柴尔德家族简史