请设计一个高校图书馆电子资源预约系统的核心模块（如预约、取消、排队逻辑），需考虑并发用户数（假设开学季峰值1000+并发），如何保证数据一致性？请说明技术选型、关键组件设计及容错机制。
答案
1) 【一句话结论】
高校图书馆电子资源预约系统核心模块设计采用“库存检查-分布式锁-消息队列”三级保障机制，结合Saga分布式事务，通过Redis分布式锁解决资源互斥、MySQL只读事务检查库存、Kafka队列缓冲请求，满足1000+并发下的数据一致性，避免超卖或排队混乱。
2) 【原理/概念讲解】
老师讲解：预约逻辑分三步。第一步，用户请求预约时，先通过MySQL只读事务检查资源库存（SELECT stock FROM resource WHERE id=1;），避免行锁影响并发，若库存>0则继续；若库存不足，直接返回失败。第二步，尝试获取Redis分布式锁（SETNX "lock:resource:1" 1 10;），10秒过期时间防止死锁，成功则继续，失败则将请求入Kafka队列（key为资源ID，value为用户ID）。第三步，更新库存（UPDATE resource SET stock=stock-1 WHERE id=1 AND stock>0;），成功后释放锁（DEL "lock:resource:1"），返回成功；若更新失败（库存已被其他用户减少），则回滚库存（stock+1），释放锁，返回失败。取消逻辑则是从队列中移除对应请求（若在队列中），或通过Saga补偿操作回滚库存（若已预约成功）。高并发下，分布式锁确保同一资源同一时间仅被一个用户处理，队列按FIFO顺序保证预约顺序。分布式事务用Saga模式（每个步骤有补偿操作），确保失败时数据回滚。类比：超市买限量商品，先看货架上有多少（只读查库存），够的话拿个“限量商品”的牌子（分布式锁），拿不到就排个队（Kafka队列），系统按顺序发牌子，拿牌子后拿商品，拿不到就等队里排。
3) 【对比与适用场景】
| 技术组件 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| MySQL只读事务 | 数据库只读事务（隔离级别READ COMMITTED） | 读取数据不锁行，不影响并发，保证数据一致性 | 资源库存检查（只读查询） | 需确保事务隔离级别正确，避免脏读 |
| Redis分布式锁 | 基于SETNX的互斥锁，结合过期时间 | 速度快，可重入，高并发下互斥 | 资源预约互斥（如库存更新前获取锁） | 过期时间需合理（如10-15秒），避免死锁 |
| Kafka消息队列 | 基于日志的持久化队列 | 最终一致性，顺序保证，消息持久化 | 缓冲锁获取失败的预约请求（队列缓冲） | 需消息确认机制（acks=1），防止消息丢失 |
| Saga模式 | 分布式事务补偿操作链 | 最终一致性，每个步骤有回滚操作 | 处理分布式事务（预约成功后更新库存，失败时回滚） | 补偿操作需幂等，避免重复回滚 |
4) 【示例】
伪代码（预约流程）：
用户请求预约资源ID=1：
- 检查库存（只读事务，避免行锁影响并发）：
BEGIN; SELECT stock FROM resource WHERE id=1; COMMIT;// 若stock>0，继续；否则返回失败。 - 尝试获取Redis分布式锁（10秒过期时间，防死锁）：
redis.set("lock:resource:1", "1", ex=10, nx=true);// 成功则继续，失败则返回失败（队列中已有请求）。 - 更新库存（释放行锁，原子操作）：
UPDATE resource SET stock=stock-1 WHERE id=1 AND stock>0;// 更新成功则释放锁（del "lock:resource:1"），返回成功；否则回滚库存（UPDATE resource SET stock=stock+1 WHERE id=1;），释放锁，返回失败。 - 若锁获取失败，将请求入队（Kafka，按FIFO顺序处理）：
kafka.produce("resource-queue", key="resource:1", value={user_id:123, resource_id:1});// 队列消费者按顺序消费，消费后执行Saga补偿操作（如更新库存）。
5) 【面试口播版答案】
面试官您好，针对高校图书馆电子资源预约系统，核心模块设计上，我考虑采用“库存检查-分布式锁-消息队列”三级保障机制，结合Saga分布式事务，重点解决高并发下的数据一致性和排队逻辑。具体来说，用户预约时，先通过MySQL只读事务检查资源库存（避免行锁影响并发），若库存充足则尝试获取Redis分布式锁（10秒过期时间防死锁），成功后更新库存并释放锁；若锁获取失败，则将请求加入Kafka队列，按FIFO顺序由消费者处理。取消时，从队列中移除请求或通过Saga补偿操作回滚库存。技术选型上，资源管理用MySQL（只读事务查库存），锁服务用Redis，队列用Kafka，通过Saga模式实现分布式事务。容错机制包括熔断（如Hystrix处理超时）、降级（库存不足时直接返回失败）、消息重试（队列消息丢失后重试）。这样能保证1000+并发下的数据一致性，避免超卖或排队混乱。
6) 【追问清单】
- 问：如何处理1000+并发下的锁竞争？
答：用Redis分布式锁结合10秒过期时间，避免死锁，同时队列缓冲请求，减少锁获取失败率。 - 问：分布式事务如何保证最终一致性？
答：用Saga模式，每个步骤有补偿操作，确保失败时回滚库存，避免数据不一致。 - 问：队列消息丢失怎么办？
答：Kafka持久化存储，配合消息确认机制（acks=1），确保消息不丢失，消费者重试机制。 - 问：系统扩展性如何？
答：微服务拆分（资源服务、预约服务、队列服务），支持水平扩展，Redis集群、Kafka分区与消费者组提升吞吐。
7) 【常见坑/雷区】
- 忽略库存检查的只读事务：若用行锁检查库存，会导致并发下库存检查阶段也加锁，影响性能，导致超卖。
- 分布式锁未设置过期时间：高并发下可能导致死锁，用户请求一直等待，队列压力过大。
- 队列处理顺序错误：并发下队列消息处理顺序混乱，导致预约顺序错误，违反排队逻辑。
- 分布式事务补偿操作缺失：失败时库存未回滚，导致预约成功后取消失败，数据不一致。
- 忽略网络延迟：高并发下网络延迟导致锁获取失败，队列压力过大，需考虑消息重试和限流策略。