mickle 置顶2019-06-151000*1000/(60*60)=277,这个2336MB是怎么换算来的，还有什么要考虑的吗?作者回复: 277MB，乘以8，大致等于2300+Mb（小b）。带宽资源一般用Mbps而不是MBps衡量
2 27
2019-06-15我们曾经也认为用普通硬盘就行，换成普通硬盘导致生产者堵塞写入负载偏高，换成SSD就没事了，我们每天消息数大概50亿。作者回复: 嗯嗯，专栏里面只是给出一个评估的方法。具体还要结合自己的实际情况来调整。通常我们认为SSD的顺序写TPS大约是HDD的4倍。除了纵向扩展使用SSD之外，也可以尝试一下横向扩展，增加更多的broker或HDD分散负载：）
4 17
2019-06-17这个假设是：follower与leader处于不同的broker而实际环境中不推荐单机多broker的架构 摘自老师回复其他同学。
老师这个的意思是不是生产上的架构通常一台服务器上只会有leader或者follow的分区，而不会二者存在一台服务器上，所以根据带宽计算服务器数量时，根据备份数为2，所以就直接✖️3了。作者回复: Leader副本和Follower副本必然在不同的Broker上，而生产环境一般也不推荐将多台Broker混布到同一台服务器上。当然服务器性能强劲的话也未尝不可：）
7
2019-06-17老师，你好，你讲的这几个纬度很好，之前我们搭建一套kafka集群就不知道怎么去衡量，我再问一个相关问题，我个人觉得kafka会出现丢数据情况，比如某个分区的leader挂了，在切换选举到另外副本为leader时，这个副本还没同步之前的leader数据，这样数据就丢了作者回复: 嗯嗯，对于producer而言，如果在乎数据持久性，那么应该设置acks=all，这样当出现你说的这个情况时，producer会被显式通知消息发送失败，从而可以重试。
7
2019-06-17胡老师，您好，我想请问下，我们公司的环境是基于Docker这种微服务架构，那么kafka部署在Docker容器中部署方案是否会有一些不同呢？作者回复: 目前社区对Docker方案支持的并不是太好，主要都是一些第三方公司还有Confluent公司在提供解决方案。在Docker上部署我个人觉得没有太大的不同，只是注意带宽资源吧，因为常见的做法都是买一台性能超强的服务器然后在上面启动多个Docker容器，虽然CPU、RAM、磁盘都能承受，但单机还是受限于带宽的。
6
2019-06-15好了，有了 240Mbps，我们就可以计算 1 小时内处理 1TB 数据所需的服务器数量了。根据这个目标，我们每秒需要处理 2336Mb 的数据， 老师这一段中2334Mb是怎么算出来的，没看懂，能否解释一下，谢谢。作者回复: 1024*1024/3600*8
2 5
2019-06-15有三个问题请教一下老师:
1. 上文提到对于千兆网卡kafka服务器最多使用700M的带宽资源, 这700M的资源是单机使用的还是集群共用的, 为什么不能作为常规使用呢?
2. 文章举例是1小时1T的数据处理目标, 那一秒中是不是1024/3600 = 0.284G = 285M, 请问下文章中的2336M是咋算出来的.
3. 文章中的例子kafka单机要达到240M的读写能力, CPU应该配几核的?作者回复: 1. 这个700Mb只是经验值罢了。另外预留buffer的意思是即使你最好不要让broker常规占用700Mb的资源。一旦碰到峰值流量，很容易将带宽打满。故做了一些资源预留
2. 285M是大B，即字节啊，乘以8之后就是2336Mb。带宽资源一般用Mbps而非MBps衡量
3. 我没有谈及CPU，是因为通常情况下Kafka不太占用CPU，因此没有这方面的最佳实践出来。但有些情况下Kafka broker是很耗CPU的：1. server和client使用了不同的压缩算法；2. server和client版本不一致造成消息格式转换；3. broker端解压缩校验
其中前两个都能规避，第三个目前无法规避。不过相比带宽资源，CPU通常都不是瓶颈 4- 2019-06-15弱弱的问一句老师，“根据这个目标，我们每秒需要处理 2336Mb 的数据，除以 240，约等于 10 台服务器”，机房入口带宽1Gbps,怎么能做到1秒处理2336Mb的数据的
作者回复: 这里是指单机带宽，机房总带宽不可能这么小的。。。
1 4 
2019-06-17老师，partitons的数量和硬盘的数量有匹配关系么？一块盘一个partiton比一块盘多个partiton要快么？是线性的关系么？作者回复: 没有具体的关系。
“一块盘一个partiton比一块盘多个partiton要快么？” 没有实验数据支撑，单纯从分析角度来看我是认同的。当某块磁盘上有太多的分区时引入了很多随机IO拖慢了性能。事实上，阿里的RocketMQ一直宣称当单磁盘超过256分区时Kafka性能不如RocketMQ，原因也在于此。
数据来源：http://jm.taobao.org/2016/04/07/kafka-vs-rocketmq-topic-amout/ 3
2019-06-15您好，我想请教下kafka metric相关的知识，比如kafka produce速率获取等作者回复: kafka producer速率可以监控这个JMX指标：
kafka.producer:type=[consumer|producer|connect]-node-metrics,client-id=([-.\w]+),node-id=([0-9]+) 1 3
2019-06-18老师您好,我们现在用的网络是10Gb,的万兆网.这样主要性能瓶性可会在硬盘IO上,我们配置了24坏的sas 机械盘。
刚才老师主要从容量跟网络性能,评估集群的规模。
我想问一下,怎么从硬盘的IO性能,去评估集群的规模?
还有做6个盘组成一个raid5,比直接用裸盘,性能会有多大的损失?作者回复: RAID-5具体有多少性能损失不好说，但肯定会有的，最好还是以测试结果为准。另外咱们是否可以更多地利用Kafka在软件层面提供的高可靠性来保证数据完整性呢？不用单纯依赖于硬件。
至于评估方法，磁盘要相对复杂一些。毕竟当topic数量很多的时候磁盘不一定都是顺序写。不过你姑且可以做这样的测试：做一个单partition的topic，测试一下该topic对应的TPS，然后用你磁盘的TPS去核算单块磁盘上大概能放多少个partition。 1 2
2019-06-17老师你好，Leader Follower 之间的数据冗余复制会不会占带宽？如果占带宽且有两个以上的follows，岂不是把预留的2/3的带宽全部用掉了。作者回复: 会占带宽的，这也是预留的部分之一，就是给非业务活动留的带宽资源，包括操作系统其他进程消耗的带宽啊。
2- 2019-06-16在生产环境，实时推送过来的数据一份是直接存储到oracle，一份是接收后写入到kafka 对应的topic，storm程序消费后写入到kafka和elasticsearch ，经常会出现当天的oracle存储数据和elasticsearch存储的数据量有差异，有时候能差异率达到15%，胡老师这里面是否有带宽的原因呢？
作者回复: 不一定是带宽这么底层的问题，更像是Storm流处理的不正确导致的。Storm+Kafka要实现端到端的精确一次处理语义可谓是非常的难。事实上， 其他流处理框架也不敢保证百分之百的正确性。
1 2 
2019-06-15老师尽然把我模糊不清的GB和Gb的区别给复习了一遍😂 1 2
2019-10-181亿条消息保存两份，是指一个leader一个副本吧作者回复: 嗯嗯，是的。其实leader也是副本，副本有两类：leader和follower
1
2019-10-13读到本节为止，课程讲的非常好，特别是这一节关于部署集群需要考虑有哪些点，很受益 1- 2019-08-21老师，请问一直报这个错是因为什么：
Error while fetching metadata with correlation id 101 : {test=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
另外，server.properties里面下面这几个参数应该怎么配置：
listeners=PLAINTEXT://:9092
advertised.listeners=PLAINTEXT://:9092
istener.security.protocol.map
老师看到帮忙回复下，困扰一天了展开作者回复: 你的主题test创建出了吗
1 1 
2019-07-16老师希望解答一下，之前也说明了Kafka 机器上没有混布其他服务，为什么常规需要预留2/3，只能跑240Mbps，作者回复: 为follower拉取留一些带宽
1
2019-06-19“根据这个目标，我们每秒需要处理 2336Mb 的数据，除以 240，约等于 10 台服务器， 如果消息还需要额外复制两份，那么总的服务器台数还要乘以 3，即 30 台。
请问一下， 这里说的30台服务器是指 10 个kafka cluster， 每个cluster 有3 brokers? 消息写道leader broker 的topic partition 上， 然后用参数 replication.factor 去做topic的消息备份吗? 多谢！展开作者回复: 是指30台broker的意思：）
1- 2019-06-17老师，如果单机起多个broker是否有可能造成同一个partition的多个副本在一台机器上，损失了容灾能力？
作者回复: 是的，有这个可能。现在的分布式集群都倾向于使用普通性能的机器搭建，因此单台单Broker性价比很高的。
当然我也知道很多公司采购了超强的服务器，然后在上面跑多个实例。这么做的原因是因为机器价格其实很便宜，贵的是IDC机架位（至少在北京是这样），因此两个方案都有自己合理的地方吧。 1