Apache Kudu 是通过哪些机制来达成数据的一致性与高可用性的？
考察说明
考查对 Kudu 底层存储架构和复制协议的理解，以判断是否掌握其一致性保证与故障恢复原理。
回答思路
- 【回答框架 1】Kudu 的一致性主要依赖 Raft 共识算法。每个 Tablet 的多个副本构成一个 Raft 组，所有写请求必须经过 Leader，并由多数派（例如 3 副本中的 2 个）确认提交后才返回成功，从而保证线性一致性和强一致读。
- 【回答框架 2】高可用性通过副本机制和自动恢复实现。当 Leader 失效时，Raft 会触发选举，存活副本中日志最新者成为新 Leader；Follower 故障也不影响多数派可用。Kudu 还支持通过管理工具或自动重平衡触发副本修复，恢复副本数。
- 【回答框架 3】底层使用列式存储、主键有序的 MemRowSet 与 DiskRowSet，结合 WAL（预写日志）保证持久性。写入先追加 WAL 并复制至多数派，再修改内存，崩溃时可通过 WAL 恢复未落盘数据。
- 【回答框架 4】读路径上，Kudu 提供快照读和强一致读；默认快照读可能读到稍旧但已提交的数据，强一致读则从 Leader 读取并确保可见最新提交。两者结合事务时间戳机制避免读到未提交或部分复制数据。
- 【关键点 1】Kudu 通过 Raft 多数派提交实现强一致写。
- 【关键点 2】Leader 故障时通过 Raft 选举自动切换，保证可用性。
- 【关键点 3】WAL 与列式存储结合确保持久性和崩溃恢复。
- 【关键点 4】强一致读需从 Leader 读取，快照读则允许从副本读取已提交快照。
- 【易错点 1】不要把 Kudu 的一致性等同于所有读都保证线性一致，默认快照读可能非实时。
- 【易错点 2】不要认为副本数越多可用性越高，多数派要求下写入需多数在线，过多副本会降低写吞吐。
- 【易错点 3】不要忽略 WAL 和 MemRowSet 的关系，崩溃恢复依赖 WAL 重放。