您好,登录后才能下订单哦!
这期内容当中小编将会给大家带来有关消息中间件Kafka、RocketMQ该怎么理解,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以有所收获。
消息中间件的应用场景
异步解耦
削峰填谷
顺序收发
分布式事务一致性
Kafka:整个行业应用广泛
RocketMQ:阿里,从 apache 孵化
Pulsar:雅虎开源,符合云原生架构的消息队列,社区活跃
RabbitMQ 架构比较老,AMQP并没有在主流的 MQ 得到支持
NSQ:内存型,不是最优选择
ActiveMQ、ZeroMQ 可忽略
非常成熟,生态丰富,与 Hadoop 连接紧密
吞吐非常高,可用性高sharding提升 replication 速度
主要功能:pub-sub,压缩支持良好
可按照 at least once, at most once 进行配置使用,exactly once 需要 Consumer 配合
集群部署简单,但 controller 逻辑很复杂,实现partition 得多副本、数据一致性
controller 依赖 ZooKeeper
异步刷磁盘(除了钱的业务,很少有同步 flush 的需求)
写入延时稳定性问题,partition 很多时Kafka 通常用机械盘,随机写造成吞吐下降和延时上升100ms ~ 500ms
运维的复杂性单机故障后补充副本数据迁移快手的优化:迁移 partition 时旧数据不动,新数据写入新 partition 一定时间后直接切换
阿里根据 Kafka 改造适应电商等在线业务场景
以牺牲性能为代价增强功能安 key 对消息查询,维护 hash 表,影响 io为了在多 shard 场景下保证写入延迟稳定,在 broker 级别将所有 shard 当前写入的数据放入一个文件,形成 commitlog list,放若干个 index 文件维护逻辑 topic 信息,造成更多的随机读
没有中心管理节点,现在看起来并没有什么用,元数据并不多
高精度的延迟消息(快手已支持秒级精度的延迟消息)
存储、计算分离,方便扩容存储: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官网: https://kafka.apache.org/documentation/#uses
最新版本:2.7
开源的消息引擎系统(消息队列/消息中间件)
分布式流处理平台
发布/订阅模型
削峰填谷
Topic:发布订阅的主题
Producer:向Topic发布消息的客户端
Consumer:消费者
Consumer Group:消费者组,多个消费者共同组成一个组
Broker:Kafka的服务进程
Replication:备份,相同数据拷贝到多台机器Leader ReplicaFollower Replica,不与外界交互
Partition:分区,解决伸缩性问题,多个Partition组成一个Topic
Segment:partition 有多个 segment 组成
消息日志(Log)保存数据,磁盘追加写(Append-only)避免缓慢的随机I/O操作高吞吐
定期删除消息(日志段)
https://www.open-open.com/lib/view/open1421150566328.html
每个 partition 相当于一个巨型文件→多个大小相等 segment 数据文件中
每个 partition 只需要顺序读写就行了,segment 文件生命周期由配置决定
segment file 组成:index file:索引文件data file:数据文件
segment file 文件命名规则:全局第一个 segment 是 0后序每个加上全局 partition 的最大 offset
一对 segment file
message 物理结构
Kafka的消息组织方式:主题-分区-消息
一条消息,仅存在某一个分区中
提高伸缩性,不同分区可以放到不同机器,读写操作也是以分区粒度
轮询
随机
按 key 保序,单分区有序
只对“已提交”的消息做有限度的持久化保证已提交的消息:消息写入日志文件有限度的持久化保证:N个 broker 至少一个存活
生产者丢失数据producer.send(msg) 异步发送消息,不保证数据到达Kafkaproducer.send(msg, callback) 判断回调
消费者程序丢失数据应该「先消费消息,后更新位移的顺序」新问题:消息的重复处理多线程异步处理消息,Consumer不要开启自动提交位移,应用程序手动提交位移
在 ZooKeeper帮助下管理和协调整个 Kafka 集群
运行过程中,只能有一个 Broker 成为控制器
在 ZooKeeper 创建 /controller 节点,第一个创建成功的 Broker 被指定为控制器。
主题管理(创建、删除、增加分区)
分区重分配
领导者选举
集群成员管理(新增 Broker、Broker 主动关闭、Broker 宕机)(ZooKeeper 临时节点)
数据服务:最全的集群元数据信息
只有一个 Broker 当控制器,单点失效,立即启用备用控制器
团队内部,某些操作要同时更新多个数据源
业务团队 A 完成某个操作后,B 业务的某个操作也必须完成,A 业务并不能直接访问 B 的数据库
公司之间,用户付款后,支付系统(支付宝/微信)必须通知商家的系统更新订单状态
先完成数据源 A 的事务(一阶段)
成功后通过某种机制,保证数据源 B 的事务(二阶段)也一定最终完成不成功,会不断重试直到成功为止或达到一定重试次数后停止(配合对账、人工处理)
为了保证最终一致,消息系统和业务程序需要保证:
消息发送的一致性:消息发送时,一阶段事务和消息发送必须同时成功或失败
消息存储不丢失:消息发送成功后,到消息被成功消费前,消息服务器(broker)必须存储好消息,保证发生故障时,消息不丢失
消费者不丢失消息:处理失败不丢弃,重试直到成功为止
目标 :本地事务、消息发送必须同时成功/失败
问题
先执行本地事务,再发送消息,消息可能发送失败
可把失败的消息放入内存,稍后重试,但成功率也无法达到 100%
解决方案`* 先发送半消息(Half Msg,类似 Prepare 操作),不会投递给消费者
半消息发送成功,再执行 DB 操作
DB 操作执行成功后,提交半消息
1 异常,半消息发送失败,本地 DB 没有执行,整个操作失败,DB/消息的状态一致(都没有提交)
2 异常/超市生产者以为失败了,不执行 DBbroker 存储半消息成功,等不到后续操作,会询问生产者是提交还是回滚(第6步)
3 DB操作失败:生产者在第 4 步告知 broker 回滚半消息
4 提交/回滚半消息失败:broker 等不到这个操作,触发回查(第 6 步)
5、6、7回查失败:RocketMQ 最多回查 15 次
上述就是小编为大家分享的消息中间件Kafka、RocketMQ该怎么理解了,如果刚好有类似的疑惑,不妨参照上述分析进行理解。如果想知道更多相关知识,欢迎关注亿速云行业资讯频道。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。