【kafka】记录用-----------1

在这里插入图片描述

  • 主题(topic):消息的第一次分类
    • 根据人为的划分条件将消息分成不同的主题
      • 主题的划分是人为的根据不同的任务情景去划分
        • 比如,我们有两个主题,一个是"订单",另一个是"库存"。每个主题代表一个消息流。
      • 主题的名称作为主题的为一标识符,我们需要保证其唯一性
      • Topic是一个逻辑上的概念,并不能直接在图中把Topic的相关单元画出
  • 分区(partition):消息的第二次分类
    • 区域化同主题中的消息:分区管理同主题的消息
      • 不同主题下分区标识可以相同
      • 每个分区都有一个唯一的标识
  • 分区偏移(partition offset):消息的第三次分类
    • 同一分区内的不同消息都有唯一的偏移
      • 消息的偏移值是唯一且按照顺序递增的。kafka分配消息时确定
    • 不同分区内的消息的偏移可以相同

🫱🏽 kafka分区策略

  1. 默认分区策略(DefaultPartitioner): 如果消息没有指定 key,或者指定的 key 为 null,那么默认分区策略会采用轮询(round-robin)的方式将消息均匀地分配到所有可用分区。请添加图片描述
  2. 基于 key 的分区策略(PartitionByKey): 如果消息指定了 key,那么基于 key 的分区策略会根据 key 的哈希值将消息分配到对应的分区。这确保具有相同 key 的消息总是被分配到同一个分区,以保证消息的顺序性。
  3. 自定义分区策略: 用户可以根据自己的需求实现自定义的分区策略。这可以通过实现 Kafka 提供的 Partitioner 接口来完成。
  • 分区备份(replicas of partition):分区的备份,用于防止数据丢失。
    • 备份时机
      • 消息写入
      • 消费者拉取
      • 后台任务

🫱🏽 kafka后台同步策略

后台同步任务是 Kafka 内部自动管理的,不需要人为干预。Kafka 设计了一些后台任务来确保副本之间的同步和数据的一致性,以提高整个系统的可用性和可靠性。

这些后台同步任务包括:

  1. Leader 的心跳检测: Kafka 集群中的每个分区都有一个领导者(Leader),领导者会定期发送心跳消息给追随者(Followers)。这有助于检测领导者的健康状态。
  2. 追随者的数据拉取: 追随者会定期从领导者拉取缺失的数据,以保持与领导者的同步。这有助于处理因追随者滞后或宕机而导致的数据不一致。
  3. Leader 的日志清理: 领导者会定期清理旧的日志段,删除过时的消息。这确保了存储在磁盘上的数据不会无限增长,也有助于提高性能。

  • 经纪人(Brokers):负责维护发布数据的系统,每个代理可以管理一个或多个主题的分区。
    • 同一主题下可能有1-n 经纪人
    • 同一分区任意时刻只能由一个经纪人管理
    • 经纪人的分配区域管理
      • 一个主题和N个代理中有N个分区,每个代理将有一个分区。
      • 一个主题中有N个分区并且多于N个代理(n + m),则第一个N代理将具有一个分区,并且下一个M代理将不具有用于该特定主题的任何分区。
      • 一个主题中有N个分区并且小于N个代理(n-m),每个代理将在它们之间具有一个或多个分区共享。 由于代理之间的负载分布不相等,不推荐使用此方案

  • 领导者(Leader):负责处理该分区的读写请求
    • 职责:
      • 消息追加到分区的日志文件,这确保了分区的写入顺序

        • 不同分区的消息顺序不做保证
        • 同一分区下的消息顺序是根据消息的写入的先后顺序有序存储
      • 消息的复制和同步:

        • 消息异步地复制到追随者(Followers)

          步骤详细过程举例(假设分区有3个追随者,需要2个确认)
          初始状态:一个分区有一个领导者和多个追随者。领导者和追随者的副本都在 ISR 中,表示它们与领导者同步。
          生产者写入消息:生产者产生一条新消息并发送给领导者。领导者接收到消息后,将消息追加到分区的日志文件。生产者发送消息A,领导者将A追加到日志。
          消息异步复制到追随者:领导者开始异步地将写入的消息复制到追随者。追随者接收到领导者的复制请求,将消息追加到它们的日志文件中。追随者1、追随者2接收A并将A追加到各自日志。
          等待 ISR 中的确认:尽管消息复制是异步进行的,领导者必须等待 ISR 中的一定数量的追随者确认已成功复制。等待追随者1、追随者2确认。两者是异步的。
          如果 ISR 中的足够数量的追随者确认成功复制,领导者将响应给生产者,表示消息已成功写入。追随者1、追随者2确认,领导者响应。
          消息的持久性和有序性:由于消息已成功写入 ISR 中的足够数量的追随者,可以确保消息的持久性。消息A被持久化,即使领导者宕机,ISR 中的副本可以被选为新的领导者,从而保证消息的持久性。
          由于等待 ISR 中的追随者确认,保证了消息的有序性。领导者会按照消息写入的顺序等待确认,以确保整个分区的消息顺序性。领导者需要等待一定数量的追随者确认后才能继续处理下一条消息。这确保了消息在分区内的有序存储。
      • 追随者的管理

        • 心跳机制:检测追随者状态(在线、宕机、滞后)
          • 在线(心跳表现 | ISR中)

            • 追随者定期发送心跳消息,表示自己在线
            • 如果追随者的心跳正常,领导者将其包含在 ISR 中,表示它是同步的。
          • 宕机(心跳表现 | ISR中)

            • 领导者在一定时间内没有受到心跳信息,无法确认追随者的在线状态
            • 领导者可能将宕机的追随者移出 ISR,等待其他追随者的确认。
          • 滞后(心跳表现 | ISR中)

            • 追随者仍定期发送心跳消息,但在处理消息上存在滞后。
            • 领导者可能将滞后太多的追随者移出 ISR,以确保 ISR 中的副本是相对同步的。

            滞后主要指的是追随者在处理消息时相对于领导者的位置较远,即它的日志文件中的消息相对较旧。这是通过追随者的日志文件中的偏移量(offset)来衡量的。

      • 读操作的响应

        • 领导者负责处理来自消费者的读取请求。
          • 消费者可以从领导者或者任意一个追随者拉取消息。领导者负责返回正确的消息,确保读取操作的正确性。
      • 故障转移

        • 如果领导者宕机或者发生故障,Kafka 集群会自动进行领导者选举。新的领导者将被选举出来,确保分区的可用性。这是通过使用 ZooKeeper 进行协调的。
      • 日志清理

        • 领导者定期进行日志清理,删除过时的日志段,以释放磁盘空间。这有助于保持存储的合理大小
  • 追随者(Follower):备份节点是领导者的追随者,它们会按照领导者的指令更新数据。如果领导者失败,追随者可以接管并保持系统正常运行。
  • 消费者:
    • 同一消费组中,消费者不能同时消费同一分区的消息

    • 消费者分配消费分区策略

      • 初始化(静态)
        请添加图片描述

      • 动态变化

        • 同一消费组内,增加消费者
          请添加图片描述请添加图片描述

        • 增加消费组

        在这里插入图片描述

  • 25
    点赞
  • 24
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 2
    评论
jeesuite-libs分布式架构开发套件。包括缓存(一二级缓存、自动缓存管理)、队列、分布式定时任务、文件服务(七牛、阿里云OSS、fastDFS)、日志、搜索、代码生成、API网关、配置中心、统一认证平台、分布式锁、分布式事务、集成dubbo、spring boot支持、统一监控等。所有release版都经过严格测试并在生产环境稳定运行4年+。 功能列表: cache模块 基于配置支持单机、哨兵、分片、集群模式自由切换 更加简单的操作API封装 一级缓存支持(ehcache & guava cache)、分布式场景多节点自动通知 多组缓存配置同时支持 (一个应用多个redis server) 分布式模式开关 kafka模块 基于spring封装简化配置和调用方式 基于配置新旧两版Consumer API兼容支持 支持二阶段处理,即:fetch线程同步处理和process线程异步处理 消费成功业务处理失败自动重试或自定义重试支持 process线程池采用LinkedTransferQueue,支持线程回收和队列大小限制,确保系统崩溃等不会有数据丢失。 支持特殊场景发送有状态的消息(如:同一个用户的消息全部由某一个消费节点处理) producer、consumer端监控数据采集,由(jeesuite-admin)输出 兼容遗留kafka系统、支持发送和接收无封装的消息 mybatis模块 代码生成、自动CRUD、可无缝对接mybaits增强框架Mapper 基于properties配置多数据源支持,无需修改XML 读写分离,事务内操作强制读主库 基于注解自动缓存管理(所有查询方法结果自动缓存、自动更新,事务回滚缓存同步回滚机制) 自动缓存实现基于jeesuite-cache和spring-data-redis 分页组件 敏感操作拦截 scheduler模块 支持分布式保证单节点执行(按节点平均分配job) 支持failvoer,自动切换故障节点 支持多节点下并行计算 支持无注册中心单机模式 支持自定义重试策略 支持配置持久化(启动加载、变更保存) 支持控制台(jeesuite-admin)任务监控、开停、动态修改调度时间策略、手动触发执行 jeesuite-security 配置简单(初始化一个类即可) 满足认证授权基本需求 更加贴近日常使用业务场景 可选本地session和共享session 可选是否支持多端同时登录 dubbo、springboot跨服务登录状态传递支持 rest模块 自动resonse封装(xml、json) i18n request、response日志记录 自动友好错误 校验框架 filesystem模块 七牛文件服务支持 阿里云OSS文件服务支持 fastDFS文件系统支持 支持spring集成 配置式切换服务提供商 common模块 一些常用工具类 common2模块(需要依赖一些组件或者基础设置) 分布式锁 分布式全局ID生成器 excel导入导出 jeesuite-springboot-starter模块 springboot集成支持

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

烂尾主教

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值