每个代理的总mb/s为：
数据/天=（100×10^6条消息/天）× 0.5mb=每个主题5tb/天
这给了我们每个代理大约58mb/s的速度。假设消息在分区之间平均分配，对于整个集群，我们得到：58mb/s x 3 topics=178mb/s（对于所有集群）。
现在，对于复制，您有：每个主题有一个额外的副本。因此，这将变为58mb/秒/代理传入原始数据+58mb/秒/代理传出复制数据+58mb/秒/代理传入复制数据。
每个代理入口和代理出口的速度分别约为136mb/s和58mb/s。
系统负载将变得非常高，这没有考虑任何流处理。
系统负载可以通过增加代理的数量和将主题分割到更具体的分区来处理。如果您的数据非常重要，那么您可能需要一个不同的（高）复制因子。容错性也是决定复制的一个重要因素。
例如，如果您有非常重要的数据，除了管理分区的n个活动代理（带有副本）之外，您可能需要在不同的区域添加备用跟随者。如果您需要非常低的延迟，那么您可能需要进一步增加分区（通过添加额外的键）。密钥越多，每个分区上的消息就越少。对于低延迟，您可能需要一个新的集群（带有副本），该集群只管理该特定主题，而不需要对其他主题进行额外的计算。如果某个主题不是很重要，那么您可能希望降低该特定主题的复制因子，并对某些数据丢失具有更大的弹性。在构建kafka集群时，支持您的基础结构的机器应该具有相同的能力。这是因为分区是以循环方式完成的，所以您希望每个代理能够处理相同的负载，因此消息的大小无关紧要。
流处理的负载也会产生直接影响。一个好的软件来管理您的Kafka显示器和管理您的流是镜头，我个人喜欢很多，因为它做了一个惊人的工作，处理实时流

据我所知，从kafka获得良好的吞吐量不仅仅取决于集群的大小；还有其他配置也需要考虑。我会尽可能多的分享。
kafka的吞吐量应该与您拥有的磁盘数量成线性可伸缩关系。kafka 0.8中引入的新的多数据目录特性允许kafka的主题在不同的机器上有不同的分区。随着分区数的大幅增加，领导人选举过程的速度也会变慢，这也会影响消费者的再平衡。这是需要考虑的，可能是一个瓶颈。
另一个关键因素可能是磁盘刷新率。由于kafka总是会立即将所有数据写入文件系统，因此将数据刷新到磁盘的频率越高，kafka的“寻道绑定”就越多，吞吐量也就越低。同样，非常低的刷新率可能会导致不同的问题，因为在这种情况下，要刷新的数据量会很大。所以提供一个精确的数字是不太实际的，我认为这就是为什么你不能在Kafka文件中找到这样直接的答案。
还有其他因素。例如消费者的 fetch 大小、压缩、异步生产者的批量大小、套接字缓冲区大小等。
硬件和操作系统也将在这方面发挥关键作用，因为在基于linux的环境中使用kafka是可取的，因为它的pagecache机制用于将数据写入磁盘。请在此处阅读更多信息
在实际调整操作系统以满足您的需求之前，您可能还想看看操作系统刷新行为是如何发挥关键作用的。我相信理解设计理念是关键，它使它在吞吐量和容错方面如此有效。

我发现还有一些有用的资源可以挖掘

https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines
http://blog.liveramp.com/2013/04/08/kafka-0-8-producer-performance-2/
https://grey-boundary.io/load-testing-apache-kafka-on-aws/
https://cwiki.apache.org/confluence/display/kafka/performance+testing

我最近与Kafka共事，以下是我的观察结果。
每个主题被划分为多个分区，并且一个主题的所有分区都分布在kafka代理中；首先，这些方法有助于保存比单个kafka代理容量大的主题，同时也增加了用户的并行性。
为了提高可靠性和容错性，对分区进行了复制，但不会增加使用者的并行性。经验法则是，单个代理只能为每个分区承载一个副本。因此代理数必须大于等于副本数
所有分区都分布在所有可用的代理上，分区的数量可以与代理的数量无关，但分区的数量必须等于一个使用者组中使用者线程的数量（以获得最佳吞吐量）
在决定集群大小时，应牢记您希望在客户机上实现的吞吐量。