这是我参与「第五届青训营 」伴学笔记创作活动的第14天
消息队列是什么
- 解耦
- 削峰
- 异步
- 日志处理
消息队列(MQ), 指保存消息的一个容器, 本质是个队列. 但这个队列, 需求支持高吞吐, 高并发, 并且高可用
生成 -> [Message Message Message] -> 消费
消息队列的前世今生
TIB: 诞生于1985年, 服务于金融机构和新闻机构 IBM MQ/WebSphere: 诞生于1993年, 商业消息队列平台市场主要玩家 MSMQ: 微软发布于1997年 JMS: 诞生于2001年, 本质上是一套Java API AMQP/RabbitMQ: 规范发布于2004年, 同年RabbitMQ面市 Kafka: 2010年由Linked开源 RocketMQ: 2011年阿里中间件团队自研 Pulsar: 2012年诞生于Yahoo内部
业界消息队列对比
Kafka: 分布式的, 分区的, 多副本的日志提交服务, 在高吞吐场景下发挥较为出色 RocketMQ: 低延迟, 强一致, 高性能, 高可靠, 万亿级容量和灵活的可扩展性, 在一些实时场景中运用较广 Pulsar: 是下一代云原生分布式消息流平台, 集消息, 存储, 轻量化函数式计算为一体, 采用存算分离的架构设计 BMQ: 和Pulsar架构类似, 存算分离, 初期定位是承接高吞吐的离线业务场景, 逐步替换对于的Kafka集群
消息队列-Kafka
kafka使用场景:
业务日志、用户行为数据、Metrics数据
基本概念:
Topic: 逻辑队列, 不同的业务可以建立不同的Topic Partition: Topic的分区, 不同分区可以并发处理, 以此提高吞吐能力 Cluster: 物理集群, 每个集群中可以建立多个不同的Topic Producer: 生产者, 负责将业务消息发送到Topic中 Consumer: 消费者, 负责消息Topic中的消息 ConsumerGroup: 消费者组, 不同组Consumer消费进度互不干涉
Offset: 消息在Partition内的相对位置消息, 可以理解为唯一ID, 在Partition内部严格递增
Replica: 每个分片有多个Replica, Leader Replica将会在ISR中选出 ISR: In-Sync Replicas(Replica-Leader以及与Leader相差不大的Replica-Follower们)
Kafka缺点
- 运维成本高 数据复制问题: 节点变动(重启, 替换, 扩容, 缩容)都会带来数据复制问题, 带来很大的时间, 人力成本
- 对于复杂不均衡的场景, 解决方案复杂
- 没有字节的缓存, 完全依赖Page Cache
- Controller和Coordinator和Broker在同一进程中, 大量IO会造成性能下降
消息队列-BMQ
兼容Kafka协议, 存算分离, 云原生消息队列
加了层Proxy
引入了HDFS分布式存储
运维操作由分钟级甚至天级, 优化为秒级
Partition状态机, 保证对于任意分片在同一时刻只能在一个Broker上存活
Parquet: Hadoop生态圈中一种新型列式存储格式
消息队列-RocketMQ
名称 | Kafka | RocketMQ 逻辑队列 | Topic | Topic 消息体 | Message | Message 标签 | 无 | tag 分区 | Partition | ConsumerQueue 生产者 | Producer | Producer 生产者集群 | 无 | Producer Group 消费者 | Consumer | Consumer 消费者集群 | Consumer Group | Consumer Group 集群控制器 | Controller | Nameserver
