2019-06-18老师 advertised.listeners 这个配置能否再解释一下。感觉配置了 listeners之后就不用配置这个了呀？作者回复: advertised.listeners主要是为外网访问用的。如果clients在内网环境访问Kafka不需要配置这个参数。
常见的玩法是：你的Kafka Broker机器上配置了双网卡，一块网卡用于内网访问（即我们常说的内网IP）；另一个块用于外网访问。那么你可以配置listeners为内网IP，advertised.listeners为外网IP。 4 35
2019-06-18请教老师
gg.handler.kafkahandler.Mode = tx
gg.handler.kafkahandler.Mode = op
这两个的差别。我们遇到时 dml 数据会丢失的情况。用的是 op 。
谢谢作者回复: 搜了一下，像是Oracle GoldenGate Kafka Adapter的参数。我没有用过，从文档中看这两者的区别是：当设置成op单个数据库表的变更（插入、更新、删除）会被当成一条Kafka消息发送；当设置成tx时，数据库事务所做的所有变更统一被封装进一条Kafka消息，并在事务提交后被发送。
显然，后者有事务性的保障，至少有原子性方面的保证，不会丢失部分CDC数据。 9
2019-06-18老师帮我们讲讲这个参数吧auto.offset.reset，我有时候删除一个topic时会导致offset异常，出现重复消费问题，不知道跟这个参数有没有关系？？作者回复: 不太懂“删除topic后还出现重复消费”是什么意思？删完了还要继续消费它吗？
当consumer启动后它会从Kafka读取它上次消费的位移。情况1： 如果 Kafka broker端没有保存这个位移值，那么consumer会看auto.offset.reset的脸色
情况2：consumer拿到位移值开始消费，如果后面发现它要读取消息的位移在Kafka中不存在（可能对应的消息已经被删除了），那么它也会看auto.offset.reset的脸色
情况3：除以上这两种情况之外consumer不会再顾忌auto.offset.reset的值
怎么看auto.offset.reset的脸色呢？简单说就是earliest从头消息；latest从当前新位移处消费。 7- 2019-06-24胡老师，我在kafka升级过程中遇到过这样的问题，就是升级后的Kafka与之前的Kafka 的配置完全一样，就是版本不一样了。但是5个Broker后，Kafka Manager工具中，只有1个Broker有数据进入进出。后来同时添加了以下4个参数：
rebalance.max.retries=4
auto.leader.rebalance.enable=true
leader.imbalance.check.interval.seconds=300
leader.imbalance.per.broker.percentage=10
再重启Kafka，5个Broker都有数据进入进出，但是我不清楚这到底是哪个参数起到了决定性的作用。其中就有老师讲的auto.leader.rebalance.enable这个参数，但是我这里设置的是true？展开作者回复: 只有一个broker有数据进出，我猜是因为这样的原因：1. 首先你的主题分区副本数是1；2. 在你升级的过程中所有分区的Leader副本都变更到了同一台broker上。
后面开启了auto.leader.rebalance.enable=true之后它定期将Leader副本分散到不同broker上了。 1 4 
2019-06-19和本节无关，消息队列重复消费问题有什么太好的办法吗？我们现在的做法是把offset和消费后的计算结果一并保存在业务系统中，有没有更好的做法作者回复: 可以试试Kafka 0.11引入的事务
4
2019-06-18老师好！关于Unclean这个参数，将其设置为false之后，就意味着如果ISR内的所有broker都宕机，那么这个分区就不可用了。
刚好我前几天看到饶军在2013年的一次报告上讲到Kafka在CAP问题上的取舍，他说，因为Kafka是部署在一个DataCenter中的，而一个DataCenter很少会出现Partitioning的情况，所以Kafka放弃了分区容忍性。
我想问的是，Kafka舍弃了分区容忍性这一点是否可以体现在社区默认将Unclean设置为false上呢？
附上报告的地址：https://www.youtube.com/watch?v=XcvHmqmh16g
关于CAP的取舍出现在21:50左右的地方。谢谢老师！展开作者回复: 首先，CAP理论有很多有歧义的地方，我很好奇为什么国内很多人追捧CAP，其实对于分布式系统而言，很多一致性问题都是CAP覆盖不了的。
其次，我个人觉得饶大神并不是说Kafka放弃了P，其实Kafka是依托于ZooKeeper以及合理配置minIsr等参数来规避脑裂的。
第三，我翻看了社区对此提案的讨论，变更为false就是很朴素的思想：用户在默认情况下可能更加关心数据一致性，不想数据丢失。如果用户想要更高的可用性，手动调整即可。你可以看看社区对此问题的讨论：https://www.mail-archive.com/dev@kafka.apache.org/msg63086.html 4
2019-06-24👍，相当于把Kafka里面的一些坑预先告诉了我们。 2- 2019-06-19胡老师您好，我对这两个参数有些疑问：
（1）auto.leader.rebalance.enable 这个值设置为true，那么您说的定期重新选举，应该有个触发的条件吧？我刚才跟同事沟通过，他说是跟每台broker的leader数量有关，如果leader分布不均衡就会触发重新选举leader，但是感觉说的还是不够具体，您能给解答下吗，感谢
（2）log.retention.bytes这个参数，您说的对于总磁盘容量来说，那我这样理解您看正确不（极端情况）---这个值我设置为100G，我机器有3个磁盘，每个磁盘大小1T，每个磁盘有不同topic的partition且，如果一个租户恶意写数据到自己的topic，造成某块磁盘的partition大小为100G，那么这台broker是不是所有topic都无法继续写入数据了？劳烦您解答下，感谢展开作者回复: 1. 的确是有个比例，要超过这个比例才会触发preferred leader选举。这个比例由broker端参数leader.imbalance.per.broker.percentage控制，默认是10%。举个例子，如果一个broker上有10个分区，有2个分区的leader不是preferred leader，那么就会触发
2. 没太明白为什么写到100GB，broker就不能继续写入了？ 3 2 
2019-06-18老师，对于磁盘坏掉以后转移到其他磁盘的机制，我有点疑问，如果已经坏掉，则不可读了，那么是不是只能从副本去转移了，如果从副本转移那就有可能会丢失部分最新的数据吧？作者回复: 不会啊，broker会重建副本，然后走正常的同步机制：从leader处拉取数据。
4 2
2019-12-13auto.leader.rebalance.enable
关于这个参数的设置，我有一点不同的意见，官网说的是如果某个broker挂了，那分布在他上的leader副本就会自动切换到其他活着的broker上，但是挂掉的broker重启之后，集群并不会将他之前的leader副本再切换回来，这样就会使其他broker上leader副本数较多，而该broker上无leader副本（无新主题创建），从而造成负载不均衡的情况。
这时我们可以通过 kafka-preferred-replica-election.sh 脚本来重新平衡集群中的leader副本。但是我们配置这个参数为true的话，controller角色就会每五分钟（默认）检查一下集群不平衡的状态，进而重新平衡leader副本。作者回复: 同意。不过实际上，线上环境贸然大面积迁移副本leader是非常有风险的事情：）
1
2019-09-18老师好，请问unclean.leader.election.enable设置为false之后，如果leader副本挂掉了那这个分区就无法使用了，是不是意味数据会丢失呢？作者回复: leader挂掉了Kafka会从ISR剩下的副本中选择一个当leader，但如果ISR也没有副本了，leader就选不出来了。如果设置unclean.leader.election.enable=true，则允许Kafka从那些不在ISR但依然存活的副本中选择一个出来当leader。此时是有数据丢失的风险的
1
2019-08-21[2019-08-21 20:25:24,619] WARN [Producer clientId=console-producer] Error while fetching metadata with correlation id 57 : {test=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
老师，请教一下，这个错误是什么参数配置错了导致的呢？作者回复: 如果只是偶尔抛出不用管，通常是因为没有找到对应的主题所致。不是参数配置错导致
1
2019-07-16没有这种 Failover 的话，我们只能依靠 RAID 来提供保障
— 这个说法我觉得不是很妥当。我们不用RAID应该是具备足够的 replica 吧，和Failover没有必然联系 1- 2019-06-19老师，最近别人问我一个问题，假如现有集群已经有3个分区，动态添加两个分区, 原有的分区会迁移数据到新增的分区吗？
作者回复: 不会。已有数据将一直“躺在”原有分区中。
1 1 
2019-06-19请问老师，坏掉的数据是怎么自动转移到其他磁盘上的呢？作者回复: 可能有点没说清楚。
1. Broker自动在好的路径上重建副本，然后从leader同步；
2. Kafka支持工具能够将某个路径上的数据拷贝到其他路径上 1
2019-06-18'如果设置成 false，那么就坚持之前的原则，坚决不能让那些落后太多的副本竞选 Leader。'想问一下老师，每个partition的副本保存的数据不是应该和leader是一模一样的吗？为什么会有丢失的？作者回复: 它们是异步拉取消息的，必然有一个时间窗口导致它和leader中的数据是不一致的，或者说它是落后于leader的。
1
2019-06-18刚用的时候大一点的消息就有问题，后来知道是message.max.bytes,不过老师是不是打错单位了，记得是900多KB。今天干货很多作者回复: 感谢反馈，sorry，笔误了:(
1- 2019-06-18老师好，如果磁盘坏掉了，这些数据是什么机制读取到其他磁盘上的呢？不是都坏了吗？不应该读取其他副本中的数据了吗？这个磁盘上的数据就算是丢失了吗？
作者回复: Broker会在好的目录上重建副本。另外Kafka也提供了工具将某块磁盘上的数据直接搬移到另一个磁盘上，毕竟磁盘坏了也不是不能修好：）
1 
2019-06-18后面会单独讲解producer，consumer相关配置参数吧？还有这个参数delete.topic.enable，胡老师有什么建议么？作者回复: 后面讲到producer和consumer会有涉及，但不会专门来讲，毕竟很多人反映单纯讲配置参数太枯燥了，还是结合具体的使用场景来讲比较好。另外建议delete.topic.enable保持默认值true就好，毕竟不能删除topic总显得不太方便。只是要注意权限设置即可，不可能 让任何人都能有删除topic的权限。
1
2020-01-10能够实现故障转移：即 Failover。这是 Kafka 1.1 版本新引入的强大功能。要知道在以前，只要 Kafka Broker 使用的任何一块磁盘挂掉了，整个 Broker 进程都会关闭。但是自 1.1 开始，这种情况被修正了，坏掉的磁盘上的数据会自动地转移到其他正常的磁盘上，而且 Broker 还能正常工作。还记得上一期我们关于 Kafka 是否需要使用 RAID 的讨论吗？这个改进正是我们舍弃 RAID 方案的基础：没有这种 Failover 的话，我们只能依靠 RAID 来提供保障。这段话不太理解作者回复: 简单来说，就是1.1版本之前，如果Kafka使用的任何一块硬盘坏掉了，Broker就会宕机。1.1版本之后不会了~