面试题答案
一键面试1. 数据库层面
- 使用强一致性的数据库：如关系型数据库（如MySQL的InnoDB存储引擎），其本身提供了事务机制来保证ACID特性。
- 设置合适的事务隔离级别：
- 可串行化（Serializable）：最高的隔离级别，通过强制事务串行执行，避免了脏读、幻读和不可重复读等问题。但性能较低，因为所有事务只能依次执行。在高并发场景下，可能会导致大量的锁等待，影响系统性能。
- 可重复读（Repeatable Read）：InnoDB默认的隔离级别。它通过使用MVCC（多版本并发控制）机制，在一个事务内多次读取同一数据时，返回的是首次读取时的数据版本，从而避免了不可重复读和脏读问题。对于幻读，InnoDB通过间隙锁（Next-Key Lock）机制，锁住数据范围，防止新数据插入导致幻读。该级别在保证一致性的同时，性能相对较高，适合高并发场景。
2. 分布式事务处理
- 两阶段提交（2PC）：引入协调者（Coordinator）角色，第一阶段，协调者向所有参与者发送准备（Prepare）消息，参与者执行事务操作并记录日志，但不提交。如果所有参与者都准备成功，第二阶段，协调者发送提交（Commit）消息，参与者正式提交事务；若有任何一个参与者准备失败，协调者发送回滚（Rollback）消息，所有参与者回滚事务。缺点是单点故障问题（协调者故障会导致事务阻塞）以及性能问题（涉及多次网络通信）。
- 三阶段提交（3PC）：在2PC基础上增加了预提交（PreCommit）阶段，引入超时机制，减少了单点故障导致的事务阻塞问题，但仍然存在性能开销大的问题。
- TCC（Try - Confirm - Cancel）：将事务分为三个操作。Try阶段，资源预留，检查业务可行性；Confirm阶段，确认提交，执行真正的业务操作；Cancel阶段，取消操作，释放预留资源。TCC适用于对性能要求高、业务逻辑可补偿的场景。
3. 缓存策略
- 读写策略：采用读写分离策略，读操作优先从缓存读取数据，写操作在更新数据库后，同步更新缓存。对于一致性要求极高的数据，可以在写操作时，先让缓存失效，读操作时再从数据库加载并更新缓存。
- 缓存一致性协议：如使用分布式缓存一致性协议（如Redis Cluster的Gossip协议）来保证缓存数据在多个节点之间的一致性。
4. 锁机制
- 悲观锁：在数据访问前，先获取锁，锁住相关数据，直到事务结束才释放锁。在数据库层面，可以使用
SELECT... FOR UPDATE语句来实现悲观锁。这种方式能有效避免并发问题，但会降低系统并发性能，因为其他事务需要等待锁释放。 - 乐观锁：假设数据一般情况下不会发生冲突，在更新数据时，先检查数据是否被其他事务修改。在数据库层面，可以通过版本号机制（如增加一个
version字段）或时间戳来实现。当事务更新数据时，比较当前版本号与数据库中的版本号，如果一致则更新数据并递增版本号，否则回滚事务。乐观锁适用于读多写少的场景，能提高系统并发性能。
5. 应用层优化
- 队列削峰：使用消息队列（如Kafka、RabbitMQ）将高并发的下单请求进行缓冲和削峰，避免瞬间大量请求直接冲击数据库。订单服务从队列中依次获取请求进行处理，保证了数据库操作的有序性，降低了并发冲突的概率。
- 数据分片：根据订单ID或用户ID等维度，将订单数据进行分片存储，不同的分片由不同的数据库节点处理。这样可以分散并发压力，提高系统的处理能力。同时，在处理跨分片事务时，需要结合分布式事务处理机制来保证数据一致性。