极客时间kafka专栏评论区笔记

1. kafka如何做压力测试，它的参考主要指标是什么，比如QPS,最大连接数，延迟等等 作者回复：Kafka提供了命令行脚本可以执行producer和consumer的性能测试，主要指标还是TPS，延时
2. kafka扩容如何做到平滑扩容，不影响原业务 作者回复：增加broker很简单，也不会对现有业务有影响。关键是做好迁移计划——比如避开业务高峰时刻，如果迁移对业务影响最小
3. 有没有好的kafka版本升级的方案呢，现在kafka已经部署到生产环境了，升级的话，需要直接推倒重做吗？ 作者回复：不需要,可以按照官网的步骤逐步进行rollIng upgrade就可以。我们平时也是这么干的的。当然要和公司内的使用方约定好升级方案和时间，至少避开业务高峰时段吧。
4. 如何阅读kafka源码 作者回复：从自上而下的角度去理解 Kafka，竟然发现了很多之前学习过程中忽略掉的东西。 更特别地是，我发现这种学习方法能够帮助我维持较长时间的学习兴趣，不会阶段性地产生厌烦情绪。特别是在了解 Apache Kafka 整个发展历史的过程中我愉快地学到了很多运营大型开源软件社区的知识和经验，可谓是技术之外的一大收获。
5. kafka消费模式 作者回复：Kafka不能推送消息给consumer。Consumer只能不断地轮训去获取消息。从Kafka流向consumer的唯一方式就是通过poll。另外维持一个长连接去轮训的开销通常也没有你想的那么大，特别是Kafka用的是Linux上的epoll，性能还不错，至少比select好。Kafka不是PUSH模型，而是PULL模型，即follower副本不断地从leader处拉取消息
6. kafka为什么不像mysql那样提供follower副本读服务 作者回复：kafka之所以不提供follower副本读服务主要是为了避免处理一致性问题才这么设计的；因为mysql一般部署在不同的机器上一台机器读写会遇到瓶颈，Kafka中的领导者副本一般均匀分布在不同的broker中，已经起到了负载的作用。即：同一个topic的已经通过分区的形式负载到不同的broker上了，读写的时候针对的领导者副本，但是量相比mysql一个还实例少太多，个人觉得没有必要在提供度读服务了。（如果量大还可以使用更多的副本，让每一个副本本身都不太大）
7. 如何学习分布式系统 作者回复：如果想学分布式系统，推荐《Designing Data-Intensive Applications》，多看几遍~~
8. kafka对线上服务器内存会有要求么 作者回复：尽量大一点，最好10GB+以上的
9. 创建一个topic，partition的副本数设置为多少合适，从哪些方面考虑呢？老师会在后面讲到吗？ 作者回复：通过实测TPS和你的SLA共同决定
10. “不能让 Kafka 服务器常规性使用这么多资源，故通常要再额外预留出 2/3 的资源”，请问预留这三分之二的带宽是出于什么考虑呢？ 作者回复：一般是为副本同步之用；对kafka而言带宽最先成为瓶颈
11. kafka 的分区数量的设置需要参考每秒传输的字节数计算吗 作者回复：通常不必这么细粒度。网上有一些分区制定的建议，我觉得这个粗粒度的方法就很好，值得一试： 1. 首先你要确定你业务的SLA，比如说你希望你的producer TPS是10万条消息/秒，假设是T1 2. 在你的真实环境中创建一个单分区的topic测试一下TPS，假设是T2 3. 你需要的分区数大致可以等于T1 / T2
12. 能讲讲kafka的性能测试脚本怎么使用吗？ 作者回复：直接敲命令有参数提示，可以详细看下。另外我的建议是：kafka-producer-perf-test脚本还不错，kafka-consumer-perf-test有点难用
13. 老师说的无脑配置给kafka jvm heap 6G大小，这应该也看机器的吧，现在机器的内存也越来越大，我们这的机器都是64G 内存，配了16G的heap，老师觉得可以优化吗 作者回复：虽然无脑推荐6GB，但绝不是无脑推荐>6GB。一个16GB的堆Full GC一次要花多长时间啊，所以我觉得6GB可以是一个初始值，你可以实时监控堆上的live data大小，根据这个值调整heap size。只是因为大内存就直接调整到16GB，个人觉得不可取。另外堆越小留给页缓存的空间也就越大，这对Kafka是好事啊。
14. 老师，怎么能限制消费者的消费速度，或者限制消费带宽啊 作者回复：这是我之前写的，可以参考下：https://www.cnblogs.com/huxi2b/p/8609453.html
15. 胡老师，在本课程最后留的问题，又成功的引起了我的注意，我曾经因为kafka假死，不知原因为何，而尝试过设置Broker的内存为（32G/256G），然而进程假死更加频繁（后面检测是那个版本存在线程死锁）。后来还是设置为16G了。当然我这真真的是无脑设置。我也看到了评论了胡老师的建议，很值得参考。另外，胡老师在这节课里，讲到了页缓存，我想请问一下这个页缓存它存在的意义和作用，以及它在整个过程中的机制又是怎样的呢？ 作者回复：页缓存属于磁盘缓存（Disk cache）的一种，主要是为了改善系统性能。重复访问磁盘上的磁盘块是常见的操作，把它们保存在内存中可以避免昂贵的磁盘IO操作。既然叫页缓存，它是根据页（page）来组织的内存结构。每一页包含了很多磁盘上的块数据。Linux使用Radix树实现页缓存，主要是加速特定页的查找速度。另外一般使用LRU策略来淘汰过期页数据。总之它是一个完全由内核来管理的磁盘缓存，用户应用程序通常是无感知的。 如果要详细了解page cache，可以参见《Understanding the Linux Kernel》一书的第15章
16. 最近环境中有一台3G堆内存的节点在某个topic handle request的时候一直OOM，调整到5G重启后恢复正常，很想知道如何评判堆内存大小设置的标准。 作者回复: 没有通用的标准，只有一个最佳实践值：6GB。最好还是监控一下实时的堆大小，特别是GC之后的live data大小，通常将heapsize设置成其1.5~2倍就足以了
17. 老师请教一个问题，我们设置了过期时间3小时，但是客户端还是会消费到昨天的昨天的消息，这个如何查找原因呢 作者回复: 你要有多个日志段文件消息删除才可能生效。只有一个日志段文件是没用的。
18. 如果broker设置的是消息留存7天，而topic A设置的是留存10天，那么实际应该是留存10天吧 作者回复: 是的
19. 在关于consumer group这篇的讲解中，有一位读者讲述了自己的读书笔记

Consumer Group ：Kafka提供的可扩展且具有容错性的消息者机制。 1、重要特征： A：组内可以有多个消费者实例（Consumer Instance）。 B：消费者组的唯一标识被称为Group ID，组内的消费者共享这个公共的ID。 C：消费者组订阅主题，主题的每个分区只能被组内的一个消费者消费 D：消费者组机制，同时实现了消息队列模型和发布/订阅模型。 2、重要问题： A：消费组中的实例与分区的关系： 消费者组中的实例个数，最好与订阅主题的分区数相同，否则多出的实例只会被闲置。一个分区只能被一个消费者实例订阅。 B：消费者组的位移管理方式： （1）对于Consumer Group而言，位移是一组KV对，Key是分区，V对应Consumer消费该分区的最新位移。 （2）Kafka的老版本消费者组的位移保存在Zookeeper中，好处是Kafka减少了Kafka Broker端状态保存开销。但ZK是一个分布式的协调框架，不适合进行频繁的写更新，这种大吞吐量的写操作极大的拖慢了Zookeeper集群的性能。 （3）Kafka的新版本采用了将位移保存在Kafka内部主题的方法。 C：消费者组的重平衡： （1）重平衡：本质上是一种协议，规定了消费者组下的每个消费者如何达成一致，来分配订阅topic下的每个分区。 （2）触发条件： a，组成员数发生变更 b，订阅主题数发生变更 c，定阅主题分区数发生变更 （3）影响： Rebalance 的设计是要求所有consumer实例共同参与，全部重新分配所有用分区。并且Rebalance的过程比较缓慢，这个过程消息消费会中止。

1. 怎么保证kafka consumer 仅有一次消费 作者回答：每个Consumer消费完数据后需要暂存下offset，考虑到一个分区的数据只会被一个当前组下的一个Consumer消费，那么有仨种情况要处理： 1、继续消费时，那么可以判断后续poll到的offset和自己保存的值的大小，只消费不小于的消息 2、处理最后一个消息时，这时候可以仿照TCP的最后一次挥手中的CLOSE_WAIT状态，设定一个超时时间——这需要结合日常的业务场景，至少要取最大传输时延的2倍，因为大多数情况下消息是不断到达的，所以这个时间设定稍微久远一点也是可以的。 3、前两种都是成功消费的情况，如果消费失败导致位移更新失败，那么这个机制就没有任何生效的意义了，这时候重复消费就不可避免了。