面试题答案
一键面试1. BASE理论与分布式事务处理模型对比
- BASE理论：
- 优点：强调可用性、软状态和最终一致性，能适应高并发、大规模的场景，允许系统在短期内存在不一致，提升系统整体性能和可用性。
- 缺点：无法保证强一致性，不适用于对数据一致性要求极高，如涉及资金等关键业务场景。
- 2PC（两阶段提交）：
- 优点：简单直观，能保证强一致性，在大多数情况下可以确保事务要么全部提交，要么全部回滚。
- 缺点：单点问题，协调者故障会导致整个事务阻塞；同步阻塞问题，参与者在等待协调者指令期间处于阻塞状态，降低系统并发性能；数据不一致风险，在第二阶段部分参与者故障时可能出现数据不一致。
- 3PC（三阶段提交）：
- 优点：相较于2PC，减少了单点故障导致的阻塞问题，引入预提交阶段，使参与者有机会在正式提交前进行资源释放等操作，提高了系统的容错性。
- 缺点：实现复杂，增加了网络通信开销，由于多了一个阶段，整体性能有所下降，仍然存在数据不一致风险，只是概率相对2PC有所降低。
- TCC（Try - Confirm - Cancel）：
- 优点：对资源的锁定时间短，能提升系统并发性能，适用于对并发要求高的场景，业务可根据自身逻辑灵活实现补偿机制。
- 缺点：开发成本高，需要业务开发者手动实现Try、Confirm、Cancel三个操作，并且对业务侵入性强，同时如果Cancel操作出现问题，可能导致数据不一致。
2. 电商订单系统设计思路
- 订单创建阶段：
- 采用TCC模式，Try阶段预占库存、冻结资金等资源，此阶段只进行资源的预留，不真正执行扣减等操作，这样可以在短时间内释放资源，提高并发性能。Confirm阶段在订单确认时，真正扣减库存、支付资金等。若出现异常，进入Cancel阶段，释放之前预占的资源。
- 订单支付阶段：
- 对于支付金额等对一致性要求极高的操作，可采用2PC模式。因为涉及资金，必须保证强一致性。由支付中心作为协调者，各个参与支付的系统（如银行系统、第三方支付平台等）作为参与者。第一阶段询问各参与者能否完成支付，第二阶段根据第一阶段结果决定提交或回滚支付操作。
- 订单状态更新及物流信息同步阶段：
- 这部分对一致性要求相对没那么高，且并发量较大，可采用BASE理论。订单状态先允许短暂不一致，通过异步消息队列进行状态更新和物流信息同步。例如订单支付成功后，先将订单状态标记为“支付成功待发货”，通过消息队列异步通知仓库发货并更新订单状态到“已发货”，最终达到数据的最终一致性。
3. 关键技术点
- 消息队列：使用可靠的消息队列，如Kafka、RabbitMQ等，确保消息不丢失，保证异步操作的可靠性。消息队列可以削峰填谷，提高系统的稳定性和并发处理能力。
- 分布式锁：在TCC的Try阶段，为防止并发操作导致资源预占冲突，可使用分布式锁，如基于Redis的分布式锁，保证同一时间只有一个事务能预占资源。
- 日志记录：对于2PC和TCC操作，记录详细的操作日志，以便在出现故障时进行故障恢复和数据一致性校验。日志可以采用分布式日志系统，如Elasticsearch + Logstash + Kibana（ELK）组合，方便查询和分析。
- 补偿机制：完善TCC的Cancel操作和BASE理论下异步操作的补偿机制。当出现异常导致数据不一致时，能够通过补偿机制恢复数据一致性。例如订单支付成功但发货失败，通过补偿机制重新发起发货操作或回滚支付。
- 监控与预警：建立系统监控体系，实时监测分布式事务的执行状态、系统性能指标等。当出现异常（如事务超时、数据不一致等）时及时预警，以便运维人员快速处理。