• 海贼王
    2019-07-09
    相对于zookeeper方案可能的劣势是,kafka得保证offset topic的读写都是线性一致的。

    但是有个疑惑,如果kafka自己实现了类似zab协议的话,那写性能会比zk高吗

    作者回复: hmm.... 哈哈哈,不知道。。。。

     2
     7
  • mellow
    2019-07-09
    老师能讲一下,同一个group下的consumer启动之后是怎么去offset topic 拿到该group上次消费topic每个partition的最新offset呢?是根据key来定位offset topic的partition吗,然后拿到所有消息得到最新的offset吗

    作者回复: 它会去寻找其Coordinator Leader副本对应的broker去拿。根据group.id找到对应Coordinator的分区数

    
     6
  • 注定非凡
    2019-11-03
    1,诞生背景
        A :老版本的Kafka会把位移信息保存在Zk中,当Consumer重启后,自动从Zk中读取位移信息。这种设计使Kafka Broker不需要保存位移数据,可减少Broker端需要持有的状态空间,有利于实现高伸缩性。
        B :但zk不适用于高频的写操作,这令zk集群性能严重下降,在新版本中将消费者的位移数据作为一条条普通的Kafka消息,提交至内部主题(_consumer_offsets)中保存。实现高持久性和高频写操作。

    2,特点:
        A :位移主题是一个普通主题,同样可以被手动创建,修改,删除。。
        B :位移主题的消息格式是kafka定义的,不可以被手动修改,若修改格式不正确,kafka将会崩溃。
        C :位移主题保存了三部分内容:Group ID,主题名,分区号。

    3,创建:
        A :当Kafka集群中的第一个Consumer程序启动时,Kafka会自动创建位移主题。也可以手动创建
        B :分区数依赖于Broker端的offsets.topic.num.partitions的取值,默认为50
        C :副本数依赖于Broker端的offsets.topic.replication.factor的取值,默认为3

    4,使用:
        A :当Kafka提交位移消息时会使用这个主题
        B :位移提交得分方式有两种:手动和自动提交位移。
        C :推荐使用手动提交位移,自动提交位移会存在问题:只有consumer一直启动设置,他就会无限期地向主题写入消息。

    5,清理:
        A :Kafka使用Compact策略来删除位移主题中的过期消息,避免位移主题无限膨胀。
        B :kafka提供专门的后台线程定期巡检待compcat的主题,查看是否存在满足条件的可删除数据。

    6,注意事项:
        A :建议不要修改默认分区数,在kafka中有些许功能写死的是50个分区
        B :建议不要使用自动提交模式,采用手动提交,避免消费者无限制的写入消息。
        C :后台定期巡检线程叫Log Cleaner,若线上遇到位移主题无限膨胀占用过多磁盘,应该检查此线程的工作状态。
    展开
    
     4
  • 蛋炒番茄
    2019-07-09
    “自动提交位移有一个显著的优点,就是省事,你不用操心位移提交的事情,就能保证消息消费不会丢失”,对于这一点我表示疑问啊❓我记得你在之前的章节里面讲过自动提交不仅会增加消息可重复消费的可能,也可能导致部分消息丢失。比如说虽然消息拉取下来但是还没消费完就已经提交,此时服务挂了这样情况。
    
     4
  • 耿斌
    2019-07-24
    与 ZooKeeper 方案相比,它可能的劣势;
    想到的是,当集群中有一台 Broker 故障下线,可能会造成 __consumer_offset 丢失,导致重复消费
     3
     3
  • 🤡
    2019-08-12
    对GroupId 还有疑惑,假设一个Group下有 3 个Consumer , 那这三个Consumer 对应的groupid 应该是一样的。这样的话怎么做key做唯一区分呢

    作者回复: 每个client都有自己的member id和client id用于区分彼此

    
     2
  • Coder4
    2019-07-11
    老师好,前几年一直有个说法,说kafka不适合创建过多topic,请问现在的新版还有这个问题么?

    作者回复: topic过多其实是指分区数过多。会有两个可能的问题:1. controller无法管理这么多分区;2. 分区数过多导致broker物理随机IO增加,减少吞吐量。

    第一个问题社区算是修复了吧,目前单controller能够支持20w的分区数,况且社区也在考虑做多controller方案;第二个问题目前没有太多直接的修复举措,只能说具体问题具体分析吧

    
     2
  • 永光
    2019-07-11
    位移主题,适用于高频写的操作,为什么ZooKeeper不适用于这种高频的写操作?zookeeper 也可以按照<Group ID,主题名,分区号 > 来写入呀?

    作者回复: ZooKeeper本身只是一个分布式协调框架,znode中保存的数据多是那些不怎么频繁修改的元数据,本身不适合频繁更新。

    是的,旧版本consumer就是这么使用ZooKeeper来保存位移的

     1
     2
  • nightmare
    2019-07-09
    比如多个线程同时消费一个分区的话,位移这么处理
     3
     2
  • yyyiue
    2019-07-09
    请问offset是以最新的为准,还是值最大的为准?

    作者回复: 最新的

     1
     2
  • Eco
    2020-01-15
    有个问题想请教一下,这个位移主题,Consumer是像消费其他主题的分区的内容一样去获取数据的话,那么这本身不也得有个位移,那这个位移又保存到哪里的呢?这样下去不就陷入了一个死循环了吗?要么就不是像正常的消费消息那样去从位移主题获取当前消费者对于某个主题的分区的位移?

    作者回复: 好问题!其实Kafka并不太关注__consumer_offsets消费的情况,不过Coordinator的确会在JVM中把所有分区当前已提交的最新位移缓存起来,并且通过这个缓存来决定哪个consumer当前消费到了哪个位移。

     1
     1
  • Ball
    2020-01-10
    老师我有问题想请教下,如果我有一个 Consumer 实例且开启了自动提交 offset,Consumer 正在消费一个业务分区的消息,那么:
    1、提交给 offset 分区操作肯定是发生在消费业务消息之后发生的,那这个操作是在同一个线程内完成的,还是说后台有个线程在异步写 offset。
    2、基于上面那个场景,是不是 Consumer 最少只要和 Broker 建立一个 TCP 连接即可正常消费了?

    作者回复: 1. 同一个线程
    2. 是的,但通常还会与Coordinator建立TCP连接,另外获取元数据请求时也可能建立新的TCP连接。总之,当正常消费时,与broker创建一个TCP连接即可消费

    
     1
  • 张天屹
    2019-11-28
    对于自动提交位移这里有两点疑惑,第一个老师说“能够避免消息丢失”,那如果自动提交之后,业务处理失败呢,不久丢失消息了吗?第二个老师说“最新消息为100,没有继续生产,这个时候消费者会不断自动提交最新位移100”,既然没有消费了,为什么还要提交呢?消费了100就提交100,之后没有消费就意味着位移没变,为啥还要提交呢?这两个问题的根源都在于不是很清楚自动位移提交的触发条件,是消费就触发吗?还是没有发生异常就触发?还是定时触发?

    作者回复: 现在自动提交位移的设计就是不管你有没有消费,就是阶段性地提交位移,即使是提交相同的位移

    
     1
  • 宋晓明
    2019-07-30
    老师 消息从producer到broker里的partition其实都是有序的,这是kafka的机制保证的,那么假如我的consumer是单线程的,也能保证消费是有序的,但是吞吐量就下降了。如果consumer是多线程,如果保证有序性?

    作者回复: 如果是多个分区,即使是但consumer线程,也没法保证全局的顺序性。这是无法规避的

    
     1
  • ban
    2019-07-10
    老师,你说偏移量都保存到了__consumer_offsets,确实看到生成了,但是为什么我在zk还是能看到偏移量信息,记录在
    consumers/{group}/offsets/{topic}/{partition}。
    这两个有什么区别吗,还是说zk会记录还是因为我们的程序手动改成提交到zk里面了。

    作者回复: 如果使用使用老版本consumer,还是会记录在ZooKeeper中的

     1
     1
  • 玉剑冰锋
    2019-07-10
    不好意思老师,地铁上有点匆忙提问的问题没有描述清楚,我想的问的是1.文章提到__consumer_offset这个topic记录的offset信息和zk中记录的offset信息有啥区别?
    2.__consumer_offset这个topic我线上环境没有副本,文章提到副本默认是3,是我配置的问题吗?发现这个问题以后我就在线添加副本,过去好几天了仍然有十几个in progress,另外有没有办法强制终止掉这个任务重新添加副本?

    作者回复: 1. 没什么区别。你可以简单认为就是换个地方保存:)
    2. 这个其实是个bug,不过现在已经修复了。如果reassign hang住了,手动删除Zk下对应的znode就能恢复

    
     1
  • 玉剑冰锋
    2019-07-10
    现在kafka中同样还在使用zk,每个主题也会记录位移,跟主题位移有啥区别?另外我线上主题位置没有副本,之前从来没动过,这是啥原因导致的?

    作者回复: “每个主题也会记录位移,跟主题位移有啥区别” 这是什么意思呢?没看懂。。。。

    “我线上主题位置没有副本” 这又是什么意思呢。。。

    
     1
  • aof
    2019-07-09
    劣势就是zk是基于内存的,而位移主题要保存到broker上,也就是磁盘……
    
     1
  • nico
    2019-07-09
    大神 Kafka可以发送 定时消息吗,制定某一时刻接受到消息 拜托🙏

    作者回复: 需要自己写代码实现,Kafka没有天然提供这个功能

     1
     1
  • 西边一抹残阳
    2020-01-04
    胡老师,消费者提交的位移消息,保存到位移主题分区是随机的吗?就是某一个消费者的提交第一个位移数据保存在位移主题的A分区里面,第二个位移数据保存在位移主题的B分区里面
    还有消费者是怎样获取已消费的位移数据

    作者回复: 不是随机的。通常来说,同一个group下的所有消费者提交的位移数据保存在位移主题的同一个分区下

    
    
我们在线,来聊聊吧