在消息队列场景下，Kafka 通过哪些机制确保消息在存储层面不丢失，并在集群故障时仍然能够正常读写？请从持久化和高可用两个角度说明。

回答思路

1. 【回答框架 1】Kafka 的持久化依赖分区日志的落盘写入，消息先写入操作系统页缓存并由后台线程刷盘，生产端可设置 acks=all 等待所有副本确认，从根本上降低消息未落盘即被确认的风险。
2. 【回答框架 2】高可用性通过多副本机制实现，每个分区有 leader 和多个 follower，leader 负责读写，follower 同步日志；当 leader 宕机时，控制器会从 ISR 集合中选出新的 leader，ISR 中的副本与 leader 保持同步，保证了故障转移时数据不丢失。
3. 【回答框架 3】Kafka 依赖 ZooKeeper 或 KRaft 模式管理集群元数据和选举，分区副本分布在不同的 broker 上，即使单个 broker 故障，其他副本仍能提供读写服务，从而实现整体高可用。
4. 【回答框架 4】生产者侧的确认机制与消费者侧的位移提交共同影响消息不丢失的最终效果，生产端应设置 retries 和 acks=all，消费端应在消息处理后再提交 offset，避免处理未完成就提交导致数据丢失。
5. 【回答框架 5】持久化与高可用并非绝对，极端情况如所有副本同时宕机仍可能丢失数据，所以实际部署需结合复制因子、ISR 配置和监控进行优化，并接受一定的吞吐与延迟成本。
6. 【关键点 1】持久化核心是日志落盘与生产端 acks=all 配合，保证消息写入多数副本才返回成功。
7. 【关键点 2】高可用基于 leader 选举与 ISR 机制，故障转移由控制器完成，优先选择同步副本。
8. 【关键点 3】消费者处理完成后再提交 offset，可避免由位移提交过早导致的消息丢失。
9. 【关键点 4】复制因子与 ISR 配置需根据可靠性要求权衡，不能盲目提高副本数。
10. 【关键点 5】Kafka 的持久化与高可用不承诺绝对不丢，需要结合监控和运维保障。
11. 【易错点 1】将 Kafka 的副本同步误认为所有副本都实时一致，实际 ISR 只包含同步中的副本，不完全同步的副本不参与 leader 选举。
12. 【易错点 2】混淆持久化与强一致，Kafka 默认不是强一致，生产者确认策略可调整，但高可用与强一致存在权衡。
13. 【易错点 3】忽略消费端 offset 提交时机，先提交后处理会造成消息丢失，这是常见设计缺陷。