请解释 Apache Kudu 是如何利用其副本机制来增强系统的容错能力和数据可用性的？

回答思路

1. 【回答框架 1】Kudu 采用 Raft 共识算法来管理表分片的副本，每个 Tablet 由一组副本组成，其中一个是 Leader，其余是 Follower。写操作必须先由 Leader 写入预写日志并复制到多数派副本（quorum）后才返回成功，读操作可以从 Leader 或具有最新数据的 Follower 进行，这提供了强一致性和高可用性。
2. 【回答框架 2】容错性体现在少数派副本（小于 quorum）故障时，系统仍能正常工作。例如，对于 3 个副本的 Tablet，允许 1 个副本故障；对于 5 个副本，允许 2 个故障。Leader 故障时，Raft 会触发选举，Follower 在超时后发起投票，选出新的 Leader，期间服务可能短暂不可用，但不会丢失已提交的数据。
3. 【回答框架 3】数据可用性方面，Kudu 通过副本在故障转移时提供连续的数据访问。只要多数派存活，读写操作就能继续。此外，Kudu 支持通过增加副本因子（replication factor）来提高可用性，但会增加存储和网络开销，需要在一致性和成本之间权衡。
4. 【回答框架 4】副本的放置策略也影响可用性，Kudu 可以跨机架、跨数据中心分布副本，以容忍机架或数据中心级别的故障，但跨数据中心复制会增加写延迟，需根据业务需求配置。
5. 【关键点 1】Raft 确保多数派提交，少数派故障不影响服务。
6. 【关键点 2】Leader 故障自动选举，数据不丢失。
7. 【关键点 3】副本因子决定了容错数量，3 副本容忍 1 故障，5 副本容忍 2 故障。
8. 【关键点 4】跨机架/数据中心放置提升可用性，但增加延迟。
9. 【易错点 1】误认为副本数越多越好，忽略磁盘和网络开销。
10. 【易错点 2】将 Raft 的强一致性与最终一致性混淆。
11. 【易错点 3】忽略 Leader 选举期间短暂的不可用窗口。