看了下大家的评论，好多都在纠结2336Mb，作为开发人员而且是要学习Kafka的开发人员，竟然连bit和byte都没搞清楚，唉.....，难道大家都没注意你们家里的实际宽带速度和购买的套餐速度差异很大嘛，就是计算单位不同呀！！！ 最后，还是膜拜胡老师！

疑惑Kafka为什么没用已经实现了Reactor模式的netty网络应用框架，搜了下原因，一个是追求性能，一个是不想太多依赖。 https://www.quora.com/Why-did-Kafka-developers-prefer-to-implement-their-own-socket-server-instead-of-using-Netty-Does-that-help-with-performance-Does-Kafka-implement-such-features-already

老师，tps不是应该包括ttl？从客户端发送请求到服务端处理完成返回，文中为什么说tps小而ttl大呢？

精彩，看书看不懂的地方，老师都解释的很清楚明了，赞！！

谢谢老师！整个专栏让我收获满满，项目中需要，准备在实践中学习

auto.create.topics.enable： 不能自立为王 unclean.leader.election.enable： 宁缺毋滥 auto.leader.rebalance.enable：江山不易改 log.retention.{hours|minutes|ms} ：数据寿命 hours=168 log.rentention.bytes: 祖宅大小 -1 表示没限制 message.max.bytes: 祖宅大门宽度，默认 1000012=976KB

之前遇到过的一个问题跟大家分享一下，原因描述不正确的地方还请大佬指正： log cleaner线程挂掉还有可能导致消费端出现：Marking Coordinator Dead！ 原因大概如下： log cleaner线程挂掉之后会导致磁盘上位移主题的文件越来越多（当然，大部分是过期数据，只是依旧存在），broker内存中会维护offsetMap，从名字上看这个map就是维护消费进度的，而这个map和位移主题的文件有关联，文件越来越多会导致offsetMap越来越大，甚至导致offsetMap构建失败（为什么会失败没有搞明白），offsetMap构建失败之后broker不会承认自己是coordinator。 消费者组找coordinator的逻辑很简单：abs(consumer_groupName.hashCode) % __consumer_offset.partition.num对应的partition所在的broker就是这个group的coordinate，一旦这个broker的offsetMap构建失败，那么这个broker就不承认自己是这个group的coordinate，这个group的消费就无法继续进行，会出现Marking Coordinator Dead错误。 此时需要删除过期的位移主题的文件（根据文件名很容易确定哪个是最新的），重启broker。重启过程中需要关注log cleaner是否会再次挂掉。 PS：上述问题在broker重启和正常运行中都有可能遇到。

课后思考及问题 最重要的就是夯实技术基本功。 Stay focused and work hard！ 真正的实践一定要包含你自己的思考和验证，而且要与真实业务相绑定。 不贰过。 看似平谈无奇，不过真正能做的也是凤毛麟角。 不过听老师这么讲，自己反而更加有信心了，从入行到现在也在持续的学习，不过受限于基本功和脑回沟再加上没有高人指点，难免不会磕磕碰碰。现在发现付费学习，也许真是最高效的一种方式，经验眼界层次很容易上来，当然，能将多少转化为自己的就看自己的专注度和持久性啦！ 感谢老师的分享，让我感觉到自己不是愚蠢得很而是功夫下的不够很。

“在实际工作中进行学习，往往是学得最快、掌握得也最扎实的学习方法”这句话再赞同不过了。多谢老师！！

胡大的文章为我们接下来的项目选型贡献很大，真心感谢。