1. 消息经常堆积起来，不能消费了，重启服务就能继续消费了。
消息堆积可能原因如下：1. 生产速度大于消费速度，这样可以适当增加分区，增加consumer数量，提升消费TPS；2. consumer消费性能低，查一下是否有很重的消费逻辑（比如拿到消息后写HDFS或HBASE这种逻辑就挺重的），看看是否可以优化consumer TPS；3. 确保consumer端没有因为异常而导致消费hang住; 4. 如果你使用的是消费者组，确保没有频繁地发生rebalance
2.broker通过网络拿到消息后，落盘的规则是什么？来一条消息就落盘一条？还是积攒够一定的量再落盘？
实际上这个交由OS来决定，Kafka不管
3.从追主，新的消息是主主动推给各个从的？还是从主动拉取的？如果是主动拉取，从怎么知道主有新的消息的？
从拉取的方式。Kafka定义了水位的概念来标识拉取的进度
4.新增分区导致消息全部丢失
新增加了分区之后consumer和producer不会立即感知，通常可能会等待一段时间。如果producer先感知到了并向新分区发送消息，那么consumer后感知到之后直接从最新位移开始读取消息，那么之前发送的消息就不会被消费了
5.设置 acks = all。表明所有副本 Broker 都要接收到消息，该消息才算是“已提交”。如果所有的Broker都要收到消息才能算作已提交，会不会对系统的吞吐量影响很大？另外这里的副本指的是不是仅仅是ISR?
影响还是很大的。acks=all时，大部分的请求处理延时都花在了follower同步上。
是的，acks=all表明所有ISR中的副本都要同步。
6.有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保证的写入副本的下限。
7.key是不是必须得完全一样，才能保证会发送到同一个分区？
根据默认分区策略，同一个key的消息肯定会发送到同一个分区
8.如果kafka搭了集群，有三个broker，分别是broker1、broker2、broker3。这时候我对名称为test的topic发送消息，key设置为A，消息会随机发送到三个broker上去吗？那这样的话顺序不就乱了吗？如果我想保证所有的消息都顺序，是不是需要指定发送到其中一个broker？
首先，你的消息会被发送到某个分区的leader副本上。这个分区的leader副本只能存在于3个broker中的一个，但是如果test的副本数是那么一条消息也会被备份到其他两个broker上。只是只有leader副本对外提供服务，因此没有顺序乱的情况出现。
如果想保证顺序，指定消息key即可，这样能保证分送到同一个分区上。是否发到同一个broker上无关紧要
9.跨地区的kafka集群，创建的两个partition都在一个地方怎么办呢？创建topic时可以选择在哪些节点上创建partition吗？默认是随机选择节点创建partition吗？
kafka-topics支持在创建topic时指定partition放在那些broker上
10.一个topic三个分区与三个单分区的topic在吞吐量以及负载均衡上有什么区别吗？
感觉没什么区别，只是缓存中的微弱区别罢了。
11.分区实现负载均衡提高吞吐量，一台机器多个分区也会有负载均衡效果？也会提高吞吐量？如果会那我一台机器一个kafka 分多少分区合适？我看有人一台机器一个kafka也分了五六个分区。这样做有什么好处？
通常1台broker上有多个分区依然能提升TPS，毕竟单个分区消耗不掉大部分的系统资源。当然一切以实际测试结果为准。
12. 广州机房怎么消费广州partition的数据，consumer如何指定消费的partition。这个能讲下吗
使用这个方法：consumer.assign()直接消息指定分区
13.创建分区，分区的各个副本是怎样在节点上分布的？添加新分区后，新分区的副本又是怎样在节点上分布的？
"分区的各个副本是怎样在节点上分布的" --- 如果不考虑机架信息的话，你基本上可以认为是轮询的分配方案，新分区的副本的分布也是相同的原理。
14. 消息在同一个分区是能保证消息的顺序性，现在多个produce向 broker 发送消息，是怎么保证先发送的消息是被broker优先接收并优先存储的？有没有可能后发的消息被优先存储呢？
多个producer发送的消息彼此之间没有前后顺序之分。谁在谁前面都是可能的，上面的情况是有可能的
15.key在哪指定，怎么指定啊 ?
Producer发送消息的时候可以直接指定key，比如producer.send(new ProducerRecord("my-topic", "key", "value"));
16.同一个分区可能会分布在不同的机器节点上吗??
同一个分区的不同副本可能分布在不同的机器上
17.怎么保证分区里数据和生产者消息顺序是一致这个问题?
1是，一个生产者，发两次消息，但是网络原因，消息到达的顺序和消息发送的顺序不一致，
防止乱序可以通过设置max.in.flight.requests.per.connection=1来保证
max.in.flight.requests.per.connection = 1 限制客户端在单个连接上能够发送的未响应请求的个数。设置此值是1表示kafka broker在响应请求之前client不能再向同一个broker发送请求。注意：设置此参数是为了避免消息乱序
2是两个生产者，这时候消息如何确定消息的顺序呢。
两个生产者生产的消息无法保证顺序，因为它们本身就没有前后之分，它们是并发的关系。
18.List<PartitionInfo> availablePartitions = cluster.availablePartitionsForTopic(topic);这个可用分区和不可用分区中的可用是什么概念
leader=-1或者说没有leader的分区就是不可用分区
19.消费者要获取分区号是不是只能从zookeeper中获取呢，还有没有其他方式？
可以用过API的方式从Broker端获取，比如KafkaConsumer.partitionsFor方法
20.那partition的个数是从哪配置的呢 ?
topic创建的时候指定了分区数
21.两个跨区域的集群zookeeper放在那个城市呢？广州还是北京？还有就是能否使用多topic？比如广州一个topic北京一个topic。还有这样做和您建议的分区方式比有什么优劣性的不同呢？
Zk集群没有一定要放在哪个城市。这个例子只是配合分区策略引出的，而且的确也有大厂这么使用。其实更好的做法还是多集群的方式。每个IDC有自己的Kafka集群，彼此同步。至于多topic的方式如果业务分割得清晰实际上是更好的解决方案：）
22.事务型 Producer 是具体怎么实现多分区以及多会话上的消息无重复的呢？
主要的机制是两阶段提交（2PC）。引入了事务协调器的组件帮助完成分布式事务
23.在kafka中，事务型的producer对于数据写入失败，为什么还要将对应的数据日志写入，这么做的好处是什么？数据写入失败后为什么不直接丢弃掉？
是因为broker端无法单独做出判断。另外写入之后无法直接丢弃，只能依靠其他字段实现跳过该消息
24.kafka事物支持多个producer吗？
不支持
25. 事务也是只针对同一个topic么
可以多个 topic
26.集群中的任意一台broker都拥有整个集群的所有broker的信息？
producer会向任意一个broker请求元数据，因为所有broker都缓存了相同的集群元数据信息
27.topic的数量多大范围比较合适？
topic数量只要不是太多，通常没有什么影响。如果单台broker上分区数超过2k，那么可能要关注是否会出现性能问题了。
28. producer连接是每个broker一个连接，跟topic没有关系是吗？（consumer也是这样是吗？）
也不能说没有关系。客户端需要和topic下各个分区leader副本所在的broker进行连接的
29.Kafka的元数据信息是存储在zookeeper中的，而Producer是通过broker来获取元数据信息的，那么这个过程是否是这样的，Producer向Broker发送一个获取元数据的请求给Broker，之后Broker再向zookeeper请求这个信息返回给Producer?
集群元数据持久化在ZooKeeper中，同时也缓存在每台Broker的内存中，因此不需要请求ZooKeeper.
30.kafka更新元数据的方法只有每5分钟的轮训吗，如果有监控zk节点之类的，是不是可以把轮询元数据时间调大甚至取消
Clients端有个参数metadata.max.age.ms强制刷新元数据，默认的确是5分钟。新版本Clients不会与ZooKeeper交互，所以感觉和ZooKeeper没什么关系。。。
31.Producer应该只跟Controller节点更新元数据，以及相关的topic机器交互数据，而不应该跟所有的机器创建连接；有个疑问，当 Producer 更新了集群的元数据信息之后，如果发现与某些broker没有连接，就去创建，为什么会去创建跟producer无关的连接？
有可能也会连接这些Broker的。Clients获取到集群元数据后知道了集群所有Broker的连接信息。下次再次获取元数据时，它会选择一个负载最少的Broker进行连接。如果发现没有连接也会创建Socket，但其实它并不需要向这个Broker发送任何消息。
32.消费组中的消费者个数如果超过topic的分区数，就会有消费者消费不到数据。但如果是同一个消费组里的两个消费者通过assign方法订阅了同一个TopicPartition，是不是会有一个消费者不能消费到消息？
如果使用assign，则表明该consumer是独立consumer（standalone consumer），它不属于任何消费者组。独立consumer可以订阅任何分区，彼此之间也没有关系，即两个独立consumer可以订阅并消费相同的分区
33.每个订阅者都必须要订阅主题的所有分区，是否意味着每个订阅者都需要消费所有的分区的所有消息？
不会。每个订阅者分配一部分分区消费
34.我理解一个主题下进行分区消费就可以满足日需求了，Consumer Group为什么设计成可以订阅多个主题，什么样的场景会使订阅多个主题？
没有什么规定要求什么场景下需要订阅多个主题。事实上，对于默认的分区策略，一个组订阅多个主题的做法会导致分配的极不均匀，但我们依然还是能够找出一些场景，使得这么做是有意义的。比如消费者组订阅多组传感器的数据，我们不确定未来新增传感器的主题名到底是什么，但可以约定所有传感器的主题名以sensor开头，那么此时让group订阅以sensor开头的所有主题就能动态地检测后续新增的主题。这个场景是不是有意义些？
35.什么场景下消费者组中的一个实例会是一个进程中的线程呢？
如果你的client端机器非常强劲，只启动一个consumer实例单线程消费未免有些浪费，你可以以启动多个线程的方式来充分利用资源。
36.consumer group可以删除吗？或者有其他命令管理吗？
可以删除。使用kafka-consumer-groups命令
37.如果有100个分区，100个同组消费者，在启动这100个消费者过程中会发生100次rebalace吗
目前不会 ???
38.单消费实例在gc下会出现重平衡吗. 还是因为重平衡导致gc出现 ?
可能出现gc导致rebalance的
39.既然kafka 曾经独立出zk来存储consumer group 的offset 是有好处的，仅仅因为zk不太适合做频繁的更新，才又整合到kafka中，为什么不考虑另外一种工具适合做频繁的更新操作去存储它。
社区希望对所有的东西都能有掌控度，而不是依赖其他第三方组件
40.Consumer group是第一个消费者订阅的时候创建的吗？后面订阅该topic的消费者会不会自动加入该消费者组 ???
Consumer group是第一个消费者订阅的时候创建的
这个消费者设置了相同的groupID，那么不论是否订阅该topic，都会属于这个消费者组。
41.Rebalance无法避免，又很慢，如果只是站在使用者的角度看的话，那这kafka怎么感觉很不行啊，在考虑技术栈的时候难道放弃它？
社区2.3引入了static consumer，这样consumer程序正常的停机重启不会rebalance，可以试试.
42.broker发生变化也是同样会发生reblance吧，虽然和consumer数目变化一样
不会的
43.消费者位移 是记录 分区和偏移量的 没有记录是哪个消费者,这样的话下一个消费者来消费这个分区时候 偏移量是重置的嘛?
不会重置，如果这个分区由组内其他consumer分配了，也是接着之前的进度继续消费。
44.多个group订阅同一个topic时候 不同group可以同时访问一个leader分区嘛?
可以
45.保存位移的分区有多少个分区多少个副本那？我们可以设置吗？
默认560个分区，3个副本。可以设置也可以自行创建
46.kafka有基于时间戳的消费方式吗？比如我想从某个时间点之后投入kafka的数据开始消费？
有，KafkaConsumer有offsetsForTimes方法
47.集群扩容，需要对__consumer_offset这个topic进行reassign，请问有没有坑啊？需要注意哪些事项呢？期待您的回答，谢谢
reassign操作很容易出错，不只是对__consumer_offsets。我个人的建议哈：
1. 业务低峰时段做；
2. 不要topic级别整体迁移，最好按照分区级别来做。比如一次迁移几个分区这样
48.说kafka不适合创建过多topic，请问现在的新版还有这个问题么？
topic过多其实是指分区数过多。会有两个可能的问题：1. controller无法管理这么多分区；2. 分区数过多导致broker物理随机IO增加，减少吞吐量。
第一个问题社区算是修复了吧，目前单controller能够支持20w的分区数，况且社区也在考虑做多controller方案；
第二个问题目前没有太多直接的修复举措，只能说具体问题具体分析吧
49.假设一个Group下有 3 个Consumer , 那这三个Consumer 对应的groupid 应该是一样的。这样的话怎么做key做唯一区分呢
每个client都有自己的member id和client id用于区分彼此
50.消息从producer到broker里的partition其实都是有序的，这是kafka的机制保证的，那么假如我的consumer是单线程的，也能保证消费是有序的，但是吞吐量就下降了。如果consumer是多线程，如果保证有序性？
如果是多个分区，即使是但consumer线程，也没法保证全局的顺序性。这是无法规避的
51.怎样手动提交位移呢
手动调用commitSync或commitAsync方法
52.consumer offset 本身就是个主题。它是怎么实现自己offset 管理的
Kafka自己管理的，其实和普通主题原理是类似的
53.为什么位移主题写入消息时，不直接替换掉原来的数据，像 HashMap 一样呢？而是要堆积起来，另起线程来维护位移主题
位移主题也是主题，也要遵循Kafka底层的日志设计思路，即append-only log
54. 一个kafka集群只有一个位移主题么？
每个Kafka集群都只有一个位移主题.
55. consumer 是如何从这个位移主题中拿到曾经属于自己组的offset呢
首先找到对应的Coordinator，Coordinator保存了这些数据，然后consumer向Coordinator发送请求去请求这些数据
56.__consumer_offsets 这个主题的元数据信息还是会在 Zookeeper 中注册吧？只是位移的信息变更存储在了 Kafka 中吗？
不是。位移提交这件事从设计到实现与ZooKeeper完全没有关联了。
57.如果同一个group 的不同consumer 设置的session.timeout.ms 的不一样怎么办？协调者以最后一个consumer 为准吗？
取最大的
58.“每个 Consumer 实例都会定期地向 Coordinator 发送心跳请求，表明它还存活着。”这个是后台自动触发的还是每次主动poll消息触发的啊？
0.10.1之前是在调用poll方法时发送的，0.10.1之后consumer使用单独的心跳线程来发送
59.内部topic可以增加分区数量吗？有实践过吗？有一个很大集群，内部topic某个分区的副备偶发的被剔除isr然后再加入，观察发现这个分区的写入较大，所以希望增加分区数量。
别增加。目前源代码中内部topic的分区被hard code成50了，如果后面修改会造成各种问题。已经有对应的bug来解决此事了，但代码还没有merge
60.之前poll的数据还是会被继续进行业务逻辑处理，若在rebalance停止消费期间offset并未进行提交，可能会造成该partition里面的同一批消息被重新分配给其他消费实例，造成重复消费问题。
是的
61.这个Rebalance是针对ConsumerGroup消费的某一个主题的，还是针对所有消费主题的？如果给消费者组增加了一个新的topic，会对该ConsumerGroup在其他已经消费的主题再平衡吗？
针对整个group的。如果消费者组订阅信息发生变化也是会发生rebalance的。
62. 0.9版本里面好像没有最长消费时间参数max.poll.interval.ms，在0.9版本中如何控制消费时长?
0.9的确没有这个参数。你依然只能设置session.timeout.ms来规避
63.max.poll.interval.ms 和 心跳机制 这两个条件是或的关系吗？不满足其中一个，就会Rebalance？能不能一直保持心跳，而不关注max.poll.interval.ms，不让consumer被踢出去？
消息如果在max.poll.interval.ms时间内处理不完就会触发rebalance。社区提供该参数的目的就是为了把这个含义从session.timeout.ms中剥离，因此这是个与rebalance很有关系的参数
64.消费者给协调者踢出后，还会继续保持心跳并重新连上吗？
一旦Coordinator将consumer踢出组，该consumer实例会禁掉心跳并等待前端主线程重新加入组
65.brokder挂了,不会导致订阅主题的分区数发生变化吗,然后重平衡?
broker挂了，分区数不会变啊
65. 从0.10.1.x开始，客户端貌似已经把心跳线程和业务线程分开了，这样的话max.poll.interval.ms还是会影响心跳导致rebanlance吗？另外加入某个broker主分区挂掉，broker重新选组是不是也要引发reblance？
会的。max.poll.interval.ms是rebalance的超时时间。broker端Coordinator挂掉不会引发rebalance
66. 一个group.id内所有topic和分区的消费信息都是放在offset topic的一个分区里吗？
嗯，是的
67.在一个session.timeout.ms周期内，如果consumer重启了，relalance是否就可以避免？
consumer重启了，rebalance就开始了
68.rebalance的时候必须等所有消费者都提交offset吗？如果没有提交，reblance这么保证精准一次的语义
不能保证~
69.开始groupa下只有一个consumer1，只注册在topic1下面。后来groupa下来了另一个consumer2，只注册在topic2下面。会发生rebalance吗？
会的。组成员发生了变更
70.max.poll.interval.ms，在这个时间内不能消费完一次poll的消息，就要让它离开消费者组，感觉是不是有点粗暴的？还有怎么才算是消费完消息，是要提交位移吗？
消费完消息后需要再次调用poll方法才行。
71.heartbeat.interval.ms必须设置为session.timeout.ms以下，通常应设置不高于session.timeout.ms的1/3。请问这样设置的原因是什么呢？
试想如果heartbeat.interval.ms > session.timeout.ms，那么当下次发送心跳时，会话已经过期了，心跳也就没有意义了
72.kafka默认时间10s，这个时间间隔设置长一点是不是能避免由于网络不稳导致的心跳发送不及时问题，这样是不是能更好的避免rebalance？
如果是之前的版本，设置该参数长一点是有意义的。有了max.poll.interval.ms之后，session.timeout.ms就唯一被用于检测failed consumer了。所以还是尽早发现为好吧
73.session.timeout.ms为什么设置在customer端而不是coordinator端？
每个consumer可能设置不同的session.timeout.ms
74.为什么“订阅主题数量发生变化”会引发rebalance?
因为有新的分区需要被分配
75.请问Standalone Consumer 的独立消费者一般什么情况会用到
很多流处理框架的Kafka connector都没有使用consumer group，而是直接使用standalone consumer，因为group机制不好把控
76.Standalone Consumer 的独立消费者 使用跟普通消费者组有什么区别的。
standalone consumer没有rebalance，也没有group提供的负载均衡，你需要自己实现。其他方面（比如位移提交）和group没有太大的不同
77.没有设置 group.id 话，会怎么样，系统会自动生成唯一的一个值吗
group.id是必须要设置的，否则会抛InvalidGroupIdException异常
78.元数据不包含协调者信息吗？为啥还要再请求一次协调者信息 什么设计思路？
不包括，因为你请求元数据的broker可能不是Coordinator，没有Coordinator的信息
79.同一个消费组的客户端都只会连接到一个协调者吗？
是的。每个group都有一个与之对应的coordinator
80.Lead 值是指消费者最新消费消息的位移与分区当前第一条消息的差值。好像这个值应该是越小越好，越小的话就意味着分区里未被消费的消息越少？
lead越小意味着consumer消费的消息越来越接近被删除的边缘，显然是不好的
81.在公司的kafka消费者监控上，经常可以看到lag 为一个负数，比如-3，-109等，想咨询一下，为什么会出现负数呢？
可能出现丢失数据了。lag<0一定要重点关注
82. 要梳理目前线上的 哪些生产者往哪些主题发消息以及哪些消费者消费某些主题。希望能快速获取并梳理出来 .
目前无法获取到集群中生产者的数量信息，因为broker端并没有这方面的记录。消费者的话可以使用kafka-consumer-groups命令来间接获取
83. 使用JConsole连接后怎么就没有kafka.consumer，这块呢？
你连接的是Broker的JMX端口吧，你需要连接consumer的JMX端口
84.除了监控lag外，还想监控消费的延迟时间。比如我想知道消费的当条数据的产生时间和当前最后一条数据的产生时间的差。这种有什么办法吗？
消息里面有创建的时间戳，可以用程序自行计算
85.假设Kafka集群有3台broker，如果想要监控整个集群的指标，应该连接哪个broker，还是任何一个broker都可以？
都可以
86."如果消费者慢到消费的数据被删除，会出现两个后果，1消费者从头消费一遍数据，2从最新消息位移开始消费；这个从头消费一遍数据，也会导致消费的消息丢失",导致这两个后果的条件分别是什么？为什么同样的情况会导致不同的后果
取决于auto.offset.reset的值
earliest : 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，从头开始消费
latest [默认] : 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，消费新产生的该分区下的数据
none : topic各分区都存在已提交的offset时，从offset后开始消费；只要有一个分区不存在已提交的offset，则抛出NoOffsetForPartitionException异常
87.那段获取消费组的lag代码，是会导致新的consumer加入到消费组里，从而引起rebalance的吧？
不会引发lag，因为用的是AdminClient
88.引入 consumer 只是获取位移，可能会引起 rebalance??
不会引入rebalance，因为没有subscribe；
89.consumer.endOffsets(consumedOffsets.keySet()); 这个方法，consumer 能获取到所有分区的位移信息吗？
可以，因为AdminClient的listConsumerGroupOffsets访问所有分区
90.为什么lag值大，lead值就小呢
也不是绝对的相反关系，只是说明大概率情况下如果lag增加了，那么说明consumer消费速度慢了，自然已消费的位移就比较靠近起始位移了
91.是否有方法可以直接监控某个topic的各个消费组的消费进度？
你可以手动写代码实现。用AdminClient的各个API组合实现
92. 三个节点的kafka集群，当min.insync.replicas=1设置为1的时候消费者可以正常消费数据，但是当这个值改为2的时候，消费者就收不到数据了。这是什么问题啊？
其他主要参数：
replica.fetch.max.bytes=10020000
message.max.bytes=10000000
auto.leader.rebalance.enable=false
unclean.leader.election.enable=false
request.required.acks=-1
default.replication.factor=3
message.send.max.retries=5
auto.create.topics.enable=false
可能是因为你的__consumer_offsets主题的副本因子是1，导致位移提交无法写入了，严格来说这也算是一个小bug。不过你可以先确认下，比如这样：
bin/kafka-topics.sh --describe --bootstrap-server localhost:9092 --topic __consumer_offsets
要是2.0之前的版本，使用--zookeeper zk:port替换--bootstrap-server
93.如果某个follower不在ISR中了，kafka如果维持副本数均衡呢？比如设置了副本数为3，其中一个副本不在ISR集合中了，那么就一直少了一个副本吗？前提是这个副本一直没有跟上leader的同步进度！
嗯，就一直少一个副本了
94.生产环境，因磁盘满了，所有broker宕机了，重启集群后，主题中的部分分区中，有1个副本被踢出ISR集合，只剩下leader副本了。
试了以下几种方法都没有自动加入进来：
1、等了3天后还是没有加入到ISR；
2、然后重启kafka集群；
3、用kafka-reassign-partitions.sh命令重新分配分区；
针对此情况，请问一下有什么办法让它自动加入进来？ 或者手工处理加入进来也可以。
有什么命令可以查看follower落后多少吗？
试试到ZooKeeper中手动删除/controller节点。这通常都是因为Controller与ZooKeeper状态不同步导致的。
试试这个命令吧： rmr /controller
确保在业务低峰时刻执行这个命令
95. 假设一个分区有5个副本，Broker的min.insync.replicas设置为2，生产者设置acks=all，这时是有2个副本同步了就可以，还是必须是5个副本都同步，他们是什么关系。
Producer端认为消息已经成功提交的条件是：ISR中所有副本都已经保存了该消息，但producer并没有指定ISR中需要几个副本。这就是min.insync.replicas参数的作用。
正常情况下，如果5个副本都在ISR中，那么它们必须都同步才行，但如果4个副本不在ISR中了，不满足min.insync.replicas了，此时broker会抛出异常给producer，告诉producer这条消息无法正确保存.
96.配置是 unclean.leader.election.enable=false
1个分区有2个副本，r1 和 r2，isr 中只有 r1，r1 所在机器崩溃后，并且日志数据也丢失了，这种情况怎样操作让分区恢复服务？
只能把r2启动起来了，而且有可能出现数据丢失。因为Kafka承诺不丢消息也是有条件的
97. acks=all是保证isr列表中的副本同步，如果长时间的大吞吐量，致使isr中只剩下leader，那acks=all实际起到的效果就是只同步leader一个副本，如果此时leader挂掉，那是不是会丢数据？
也不算丢数据，默认配置下如果ISR为空了，这个分区就不可用了，producer也无法向这个分区发送任何消息了。对于这种情况，Kafka不认为是丢数据
98.ack=all时候，生产者向leader发送完数据，而副本是异步拉取的，那生产者写入线程要一直阻塞等待吗
不会阻塞，你可以认为是不断轮询状态
99.follow副本是何时fetch一次leader的呢，多久fetch一次呢？有配置么？
不停地fetch，然后处理，之后再fetch。具体间隔没法配置
100.请问ISR中的副本一定可以保证和leader副本的一致性吗？如果有一种情况是某个ISR中副本与leader副本的lag在ISR判断的边界值，这时如果leader副本挂了的话，还是会有数据丢失是吗？
ISR中的follower副本非常有可能与leader不一致的。如果leader挂了，其他follower又都没有保存该消息，那么该消息是可能丢失的。如果你要避免这种情况，设置producer端的acks=all吧
101. ISR集合是动态的，如果后面发现被踢出的follower又追上leader，还会重新回归到ISR集合，这个里面有个矛盾的点，把落后的follower踢出去后，我个人的理解，这个follower不就变成僵尸副本了吗？因为它不是任何一个leader的follower了呀，哪里还有机会继续从leader那同步数据，然后再重新回归到ISR集合中去呢？
follower被踢出ISR不代表它有问题了，至少不表示它挂了，可能只是阶段性的落后leader。当追上后还是可以将其重新加入到ISR中的
102. ack=all,是保证ISR中的follower同步还是所有的follower同步，还有消费者是只能消费到ISR中的HW处的offset么？
acks=all保证ISR中的所有副本都要同步
103.在设置ack为1或all的情况下，如果发生网络分区，使得ack的条件不满足，kafka会怎么处理？
目前一旦出现partitioning，Kafka无法正常工作
104.在默认设置下，kafka是AP还是CP？
默认情况下是CP，即先保证一致性。不过还是那句话，CAP理论研究学习可以，用于指导分布式系统实践非常不合适。
CAP理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
105. kafak不会像hdfs那样自己再找个分区备份损坏磁盘副本吗？
目前不会
106.kafka集群同一分区各副本可以分布在不同机柜或者不同机房？
可以的
107.LEO和HW这两个概念不理解
一个分区有3个副本，一个 leader，2个follower。
producer向leader写了10条消息，follower1从leader处拷贝了5条消息，follower2从leader处拷贝了3条消息，
那么leader副本的LEO就是10，HW=3；follower1副本的LEO是5。
108.kafka使用replica.lag.max.time.ms来判断是否保留replica在ISR里，那么问题来了，在吞吐量较高的场景下，replica满足这个时间限制，但是LEO相差比较大，leader这时候挂掉，这个replica被选举为新leader，这个时候是不是有一部分数据丢失了？ 如果问题1确实存在，目前是怎样处理的呢？
是有这种可能，如果你在意这种情况producer端设置acks=all就可以避免了
109.关闭unclean后，有哪些方法可以保证available啊？
增加副本数
110. 如果某一个副本所在的broker挂了，kafka会在另一个broker上面新创建一个partition来补充吗？
不会
111.如果这三个副本所在的broker都挂了，那kafka会不会在一个新的broker上面重新创建一个新的partition来支持读写，还是说，这个partition就不在工作了？
不工作了
112.Kafka 会自动收缩 ISR 集合，将该副本“踢出”ISR。踢出去后副本还会做同步操作吗
会的
113. 如果仅仅以 replica.lag.time.max.ms 决定 follower 是否应该加入 ISR 集合，是否存在这样一种情况，一个 follower 离线了一段时间之后重新上线，然后开始与 leader 同步，此时同步时间间隔在 replica.lag.time.max.ms 内，该 follower 成功加入到 ISR 集合，但是因为长时间失效，导致该 follower 的 LEO 值小于 leader 的 HW，如果此时 leader 宕机，并正好选择该 follower 作为新的 leader，这样是不是就丢消息了？
不会。ISR比较的是follower和leader的LEO，不是和leader的HW比较。
114.producer的config参数中的acks参数，应该就是用来保证消息是否被写入了多个副本的机制之一把，如果开启acks，除非这几个副本的broker都挂掉了，这样是否就会保证ISR不会为空呢？
不能。acks的设置与否与ISR中有几个副本没有关系
115. kafka新增一块磁盘，如何做到数据迁移到新盘上。是这样的，之前磁盘只有一块，用久了磁盘忙了，修改保留数据时间已经不能支撑业务了。于是在不重启机器的情况下，新增了一块盘，然后重启kafka，发现新盘没有数据进来。请问要如何做，可以把数据迁移到新盘上
使用kafka-reassign-partitions脚本可以，具体用法看一下--reassignment-json-file参数
116.replica.lag.time.max.ms配置follower是否处于isr中，那么是否存在，在这个时间段内数据写完leader，follower还没有完全同步leader数据，leader宕机，isr中follower提升为新leader，那这一部分数据是否就丢失呢？该如何避免呢？
不会丢失。还是那句话：Kafka只对已提交消息做持久化保证。如果你设置了最高等级的持久化需求（比如acks=all），那么follower副本没有同步完成前这条消息就不算已提交，也就不算丢失了。
未完成,待整理.............
原文引用:
Kafka核心技术与实战 - 胡夕
