2019-06-27总结里的的第二条ack=all和第六条的说明是不是有冲突作者回复: 其实不冲突。如果ISR中只有1个副本了，acks=all也就相当于acks=1了，引入min.insync.replicas的目的就是为了做一个下限的限制：不能只满足于ISR全部写入，还要保证ISR中的写入个数不少于min.insync.replicas。
6 25
2019-06-27最后一个问题，难道新增分区之后，producer先感知并发送数据，消费者后感知，消费者的offset会定位到新分区的最后一条消息？消费者没有提交offset怎么会从最后一条开始的呢？作者回复: 如果你配置了auto.offset.reset=latest就会这样的
9- 2019-07-05新建分区丢失是因为没有offset就从lastest开始读取，可以改成没有offset的时候从ealiest读取应该就可以了 1 8
2019-06-30单个 Consumer 程序使用多线程来消费消息说起来容易，写成代码却异常困难，因为你很难正确地处理位移的更新，也就是说避免无消费消息丢失很简单，但极易出现消息被消费了多次的情况。
关于这个问题，老师能否提供个java代码的最佳实践? 谢谢!作者回复: 写过一两篇，https://www.cnblogs.com/huxi2b/p/7089854.html，
但总觉得不太完美。如果你想深入了解的话，推荐读一下Flink Kafka Connector的源码 6
2019-06-27consumer改用"从最早位置"读解决新加分区造成的问题 6
2019-07-14老师，我想问个问题，假如一个topic有3个partion ，我有三个消费端去消费topic，这三个消费端，是怎么去对应三个partion?曾经在线上遇到过消费太慢，导致消息重新均衡，重复消费了，有好的解决方法吗？作者回复: 通常情况下能够保障每个consumer消费一个分区。如果消费慢，需要看到底是哪里慢？是Kafka给你消息的速度慢还是你自己处理消息的速度慢。可以适当增加max.poll.interval.ms看看
4
2019-06-28老师，你好。仔细阅读文稿后，仍有一些困惑
1、如果只用 send()方法（fire and forget）， 即使配置retries，producer也是不知道消息状态，是不会重试的。所以说配置retries，要搭配send(msg, callback)，这么理解正确么？
2、配置了retries, producer是怎么知道哪条消息发送失败了，然后重试作者回复: 1. 不是。如果配置了retries，即使调用send(msg)也是会重试的。这是Kafka producer自己实现的机制，不需要用户干预
2. Broker发送response给producer，里面会保存error信息以及那个(些)batch出错了 3 4
2019-06-28多线程消费这么确保手动提交offset管理不会丢失呢，期待老师给一个消费端最佳实践 4
2019-06-27看了评论区回答还是不太理解，第二条ack=all与第六条min.insync.replicas 怎样协调工作的，总感觉是有冲突的。
问题是：
第二条的“已提交”和第六条的“已提交”是同一个意思吗？如果是同一个意思，那定义为什么不一样呀？作者回复: acks=all表示消息要写入所有ISR副本，但没要求ISR副本有多少个。min.insync.replicas做了这样的保证
4 3
2019-06-27这个问题我想个办法就是程序停止再增加分区，如果不能停止那就找个通知机制了。请教一个问题min.insync.replicas这个参数如果设置成3，假设副本数设置为4，那岂不是只支持一台broker坏掉的情况？本来支持三台坏掉的，老师我理解的对不对作者回复: 嗯嗯，是的。本来就是为了更强的消息持久化保证，只能牺牲一点高可用性了~~
2 3
2019-08-03老师，
如果我有10个副本，isr=10，然后我配置ack=all，min.insync.replicas=5，
这时候这两个参数以谁为准，生产一个消息，必须是全部副本都同步才算提交，还是只要5个副本才算提交？作者回复: min.insync.replicas是保证下限的。acks=all的含义是producer会等ISR中所有副本都写入成功才返回，但如果不设置min.insync.replicas = 5，默认是1，那么假设ISR中只有1个副本，只要写入这个副本成功producer也算其正常写入，因此min.insync.replicas保证的写入副本的下限。
2
2019-06-281 外部持久化每个topic的每个消费者组的每个patition的offset。
2 程序重启时继续上一次的offset
3 监控每个partition的offset，每次的from offset和to offset是不是线性连续的消费
4 允许重复消费，在消费端去重展开 2
2019-06-27不知道是不是可以这样，生产者感知到了有新分区加入立即通知broke端下的消费者不能消费消息，直到消费端都感应到了加入的新分区之后，生产者和消费者才继续工作 2
2019-06-27老师问下
第7条 一个副本挂掉 整个分区不能用了 是因为每次都必须保证可用副本个数 必须跟提交时候一致 才可以正常使用,又没有冗余副本导致的嘛?作者回复: 是因为不满足min.insync.replicas的要求了。比如该参数=2，当前ISR中只剩1个副本了，那么producer就没法生产新的消息了。
1 2
2019-06-27如果consumer改用"从最早位置"读解决新加分区造成的问题，那会不会导致旧的分区里的已被消费过的消息重新全部被消费一次作者回复: 只要位移没有越界以及有提交的位移，那么就不会出现这种场景。
1 2
2020-01-09老师好，请教一个问题，ack=1的时候，min.insync.replicas还会生效吗？或者说还有必要吗，感谢 🤝作者回复: 不生效，min.insync.replicas只有在acks=-1时才生效
1
2019-11-16老师好，有个问题，就是：retries 和 send里面的callback，是什么关系？因为有说retries是kafka自动重试的次数，那么还要callback干吗，callback的意义在哪里呢？ 如果一定要坚持用send(callback)api，那么retries是用来干吗的呢？ 这两者之间的关系是什么呢？谢谢。作者回复: callback可以处理消息发送之后的逻辑，不一定就是失败的逻辑。retries是预防那种瞬时错误的，比如网络抖动这种问题，让Kafka自动重试一下会比较方便不是吗
1
2019-11-01请问消息的createTimestamp 是在生产者服务器上生成的，还是在进入不同partition 后生成的？我能不能根据这个时间戳来判断不同分区的消息原始全局顺序？谢谢🙏作者回复: 在生产者服务器上生成的。个人感觉不可以，毕竟每个producer服务器上的时钟不是实时同步的。事实上，用时钟来保证同步性是一件非常不靠谱的事情
1- 2019-08-24老师，课后问题会出一节课统一解答吗 1 1
2019-06-27老师好，针对producer为filebeat有什么是建议配置的吗？我们生产好像没有配置这方面的参数 1