这一章主要是说一下，kafka的瓶颈。
1.磁盘的吞吐量
生产者客户端的性能直接受到服务器端磁盘吞吐量的影响。生产者生成的消息必须被提交到服务器保存，大多数客户端在发送消息之后会一直等待，直到至少有一个服务器确认悄息已经成功提交为止。也就是说，磁盘写入速度越快，生成消息的延迟就越低。
2.磁盘的容量
磁盘容量是另一个值得讨论的话题。需要多大的磁盘容量取决于需要保留的消息数量。如果服务器每天会收到 1TB 消息，并且保留7天，那么就需要 7TB 的存储空间，而且还要为其他文件提供至少 10% 的额外空间。除此之外，还需要提供缓冲区，用于应付消息流量的增长和波动。在决定扩展 Kafka 集群规模时，存储容量是一个需要考虑的因素。通过让主题拥有多个分区，集群的总流量可以被均衡到整个集群，而且如果单个broker 无发支撑全部容量，可以让其 broker 提供可用的容量。 存储容量的选择同时受到集群复制策略的影响。
3.内存
除了磁盘性能外，服务器端可用的内存容量是影响客户端性能的主要因素。磁盘性能影响生产者，而内存影响消费者。消费者一般从分区尾部读取消息，如果有生产者存在，就紧跟在生产者后面。在这种情况下，消费者读取的消息会直接存放在系统的页面缓存里，这比从磁盘上重新读取要快得多。运行 Kafka的JVM 需要太大的内存，剩余的系统内存可以用作页面缓存，或者用来缓存正在使用中的日志片段。这也就是为什么不建议把 Kafka 同其他重要的应用程序部署在一起的原因，它们需要共享页面缓存，最终会降低 Kafka 消费者的性能。
4.网络
网络吞吐量决定了 Kafka 能够处理的最大数据流量。它和磁盘存储是制约 Kafka 扩展规模的主要因素。 Kafka 支持多个消费者，造成流入和流出的网络流量不平衡，从而让情况得更加复杂。对于给定的主题，一个生产者可能每秒钟写入1MB 数据，但可能同时有多个消费者瓜分网络流量。其他的操作，如集群复制和镜像也会占用网络流量。如果网络接口出现饱和，那么集群的复制出现延时就在所难免，从而让集群不堪击。当多个生产者同时需要向Kafka写入数据的时候，如果网络流量跟不上就会抛出kafka failed to update metadata after 60000ms异常。