有几件事要注意。
首先，ebs卷没有1tb的限制。目前，amazon st1的容量可以达到16tb。这些卷是您希望在kafka部署中使用的卷，因为它们针对顺序写入进行了优化，这是kafka最擅长的。
其次，是的——kafka允许多个日志目录。这允许您将存储分散到各个磁盘上，这样就不会使单个磁盘的所有io都负担过重。也就是说，拥有多个日志目录要比拥有一个目录好，特别是在处理大量数据的情况下——但是在处理ebs时，也要记住其他因素。如果您选择较小的st1卷而不是单一的st1卷，这意味着您将拥有较小的突发存储桶和较低的每个卷的iops基线。一旦超过iops基线，您将开始使用存储桶中的iops—请参阅此处的详细信息。监视cloudwatch中的突发平衡非常重要，以确保它不会被例行耗尽，这通常会导致整个集群的速度减慢，代理的请求和响应队列被填满，这可能导致消费者和生产者应用程序发生灾难性故障。
至于raid分条，如果在每个ebs卷上启用它，则所有装入的卷都将位于同一个raid组中，这意味着kafka日志文件将分布在组中的设备上，而不是驻留在单个设备上，其结果是，如果其中一个设备出故障，组中的其他设备将出故障，我也是。不过，这应该比其他设置更具性能。
在kafka 1.0之前，代理上的单个磁盘故障和该代理上的每个磁盘故障在操作上没有区别——这两种情况都会导致代理崩溃。请参阅此处的讨论。
更新：从kafka1.0开始，出现故障的磁盘不会导致代理崩溃（参见文档）。感谢@robinmoffat指出。最终，通过raid-0条带化，您可以用从故障磁盘快速恢复的能力来换取总体io性能。也就是说，一个代理上有一个故障磁盘的所有分区都需要通过条带化重新分配，但是如果没有条带化，则只需要重新分配故障磁盘上的那些分区。