面试题答案
一键面试基于BASE理论的设计方面
- 基本可用（Basically Available）
- 降级处理：当系统出现高负载等情况时，对一些非核心功能进行降级，比如延迟展示库存变化的历史记录等，保证核心的库存查询和扣减功能可用。例如在促销活动期间，暂时关闭库存流水的实时展示。
- 柔性可用：允许部分地区或部分用户在一定时间内体验到稍微延迟或简化的服务。比如在网络较差的偏远地区，库存更新可能延迟几秒钟，但基本的下单操作仍可进行。
- 软状态（Soft State）
- 引入中间状态：库存修改操作提交后，先进入“处理中”的软状态，而不是立即更新到最终状态。在这个过程中，系统可以进行一些异步的校验和处理。例如下单扣库存，先标记库存为“预扣”，等待后续确认。
- 数据副本：在不同节点保存库存数据副本，副本之间的数据可能存在短暂不一致。如主节点修改库存后，异步同步给从节点，在同步完成前，从节点库存数据处于软状态。
- 最终一致性（Eventual Consistency）
- 异步同步机制：使用消息队列等技术，将库存修改操作异步发送给相关节点进行同步。例如使用Kafka，主库存节点将库存变更消息发送到Kafka，其他副本节点从Kafka消费消息来更新库存，最终达到一致。
- 定期对账：定期对不同节点的库存数据进行核对，发现不一致时进行修复。可以每天凌晨业务低谷期，对各节点库存进行全量比对，修正差异。
可用性、分区容错性和一致性之间关系的权衡
- 优先保证分区容错性：在分布式系统中，网络分区是不可避免的，所以要优先保证分区容错性。即使出现网络分区，各个分区内的库存系统仍能独立运行，不会导致整个系统崩溃。例如不同数据中心之间网络断开，每个数据中心内的库存服务继续为本地用户提供服务。
- 可用性与一致性的权衡：
- 高可用场景：在电商活动期间，为了保证大量用户能正常下单，优先保证可用性。允许库存数据在短时间内存在不一致，比如用户A在一个分区看到库存有10件，下单成功，但用户B在另一个分区短时间内仍可能看到库存10件。通过后续的最终一致性机制来修正库存数据。
- 一致性需求高场景：在库存盘点等对数据准确性要求极高的场景下，适当牺牲可用性。例如在每月库存盘点时，暂停部分库存修改操作，集中精力保证各节点库存数据一致性，确保盘点结果准确。