面试题答案
一键面试CAP定理含义
- 一致性（Consistency）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。比如银行转账场景，从账户A向账户B转100元，完成后，A账户减少100元，B账户增加100元，所有节点看到的结果应完全一样。
- 可用性（Availability）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。可用性意味着系统需要保证任何一个没有发生故障的节点都能在有限时间内返回合理的响应。例如电商系统，即使部分服务器出现故障，正常的服务器仍要能为用户提供商品查询、下单等服务。
- 分区容错性（Partition Tolerance）：分布式系统在遇到网络分区（网络故障导致节点间通信中断）的情况下，是否还能继续工作。因为在实际生产环境中，网络故障是不可避免的，所以分区容错性是分布式系统必须要考虑的。比如一个跨机房的分布式系统，若机房之间网络出现故障，系统仍要能有相应处理机制维持运行。
对分布式事务数据一致性的影响
- 牺牲一致性：若选择可用性和分区容错性，在网络分区情况下，为保证可用性，不同分区的节点可能会独立处理请求，导致数据暂时不一致。例如在电商库存系统中，不同区域的库存节点在网络分区时各自处理扣减库存操作，可能出现同一商品在不同分区库存数据不一致的情况。
- 牺牲可用性：若选择一致性和分区容错性，当发生网络分区时，为保证一致性，系统可能会暂停服务，等待网络恢复或数据同步完成。如金融系统的转账操作，在网络分区时，为保证转账数据一致性，可能会拒绝新的转账请求，直到网络恢复正常。
- 牺牲分区容错性：在实际分布式系统中，基本不可能完全避免网络分区，所以这种情况较少考虑。
应对策略
- 最终一致性：放弃强一致性，允许数据在一段时间内不一致，但最终会达到一致。例如使用消息队列进行异步处理，在电商下单后，库存扣减、订单状态更新等操作通过消息队列异步执行，在执行过程中数据可能不一致，但最终会达到一致状态。
- 弱一致性：放宽一致性要求，允许部分数据存在不一致情况。比如在一些读多写少的场景，如新闻资讯类应用，对于新发布的新闻，部分用户可能稍晚才能看到最新内容，但这种不一致对用户体验影响较小。
- 使用分布式共识算法：如Paxos、Raft等算法，通过多数派投票等方式保证在分布式环境下数据的一致性。在数据库集群中，使用这些算法可以确保多个节点的数据一致，即使出现部分节点故障或网络分区，仍能通过算法协调达成一致。
实际分布式系统架构案例分析 - 以电商系统为例
- 一致性方面：电商系统对订单数据要求较高一致性，采用分布式事务框架（如Seata）来保证订单创建、库存扣减、支付等操作的一致性。在下单时，通过Seata的AT模式，将多个微服务的操作纳入一个全局事务中，保证要么全部成功，要么全部回滚，确保数据一致性。
- 可用性方面：为提高可用性，电商系统采用负载均衡、多副本、故障转移等技术。例如，使用Nginx作为负载均衡器，将用户请求均匀分配到多个应用服务器上；数据库采用主从复制，当主库出现故障时，从库可以迅速切换为主库继续提供服务。
- 分区容错性方面：在跨机房部署时，当机房之间网络出现分区，采用数据分区的方式，每个机房独立处理本地用户的部分请求。同时，利用分布式缓存（如Redis）进行数据缓存和同步，在网络恢复后，通过缓存的数据一致性机制，逐步同步各机房数据，保证最终一致性。