AWS confluent quickstart使用 4 个 512GB EBS 块设备和 RAID-0 条带化配置 Kafka log.dirs，以获得更高的吞吐量，并且还有助于绕过块设备的 1TB 限制，而无需预置 IOPS。我刚刚了解到丢失 RAID-0 组中的块设备会导致该组中的所有其他设备发生故障，有人可以帮助澄清这一点
现在Kafka允许多个目录下log.dirs，我们可以将每个块设备挂载在不同的挂载点下，并将它们配置为下的目录列表log.dirs吗？
如果这是可能的（我猜是这样），权衡是什么？
有几点需要注意。
首先，EBS 卷没有 1TB 的限制。目前，Amazon st1 卷可高达 16TB。这些是您希望在 Kafka 部署中使用的卷类型，因为它们针对顺序写入进行了优化，这是 Kafka 最擅长的。
其次，是的——Kafka 允许多个日志目录。这允许您跨磁盘分布存储，这样您就不会用所有 io 使单个磁盘负担过重。也就是说，拥有多个日志目录比拥有一个目录要好，尤其是在处理大量数据时——但在处理 EBS 时，还需要牢记其他因素。如果您选择更小的 st1 卷而不是单一的 st1 卷，这意味着您将拥有更小的突发存储桶和更低的每卷 iops 基线。超过 iops 基线后，您将开始使用存储桶中的 iops -请参阅此处的详细信息. 监控 CloudWatch 中的突增余额非常重要，以确保它不会经常耗尽，这通常会导致整个集群变慢，并且代理的请求和响应队列填满，这可能导致消费者和生产者应用程序发生灾难性故障。
至于 RAID 条带化，如果您在每个 EBS 卷上启用它，所有挂载的卷都将位于同一个 RAID 组中，这意味着 Kafka 日志文件将分布在组中的设备上，而不是驻留在单个设备上，其结果是，如果其中一个设备发生故障，组中的其他设备也会发生故障。但是，这应该比其他设置更高效。
在 Kafka 1.0 之前，代理上的单个磁盘发生故障与该代理上的每个磁盘发生故障之间没有操作差异——两者都会导致代理关闭。请参阅此处的讨论。
更新：从 Kafka 1.0 开始，故障磁盘不会关闭代理（请参阅文档）。感谢@RobinMoffat 指出。最终，通过 RAID-0 条带化，您可以用从故障磁盘中快速恢复的能力换取整体 io 性能。也就是说，需要使用条带化重新分配具有单个故障磁盘的代理上的所有分区，但如果没有条带化，则仅需要重新分配故障磁盘上的那些分区。