微服务和分布式
-
微服务 是一种软件架构风格，它将应用程序拆分成一系列小型、独立的服务，每个服务专注于单一功能，彼此通过轻量级通信机制（如 API）进行交互。微服务通常是松耦合的，可以独立开发、部署和扩展。
-
分布式系统 是指一组独立的计算机（或节点）通过网络协同工作，共同完成任务。这些节点没有共享内存，依靠消息传递来通信。分布式系统的目标通常是提高性能、可靠性或容错能力。
-
微服务但非分布式：一个电商系统被拆分为"订单服务"和"支付服务"，但它们都运行在同一台服务器上。
-
分布式但非微服务：一个单体应用部署在多台服务器上，通过负载均衡分担流量。
-
微服务+分布式：一个电商系统的"订单服务"运行在服务器 A 上，"支付服务"运行在服务器 B 上，它们通过 API 通信。
CAP
Base理论
BASE 理论本质上是 CAP 定理中 AP 的一种实践指导原则，告诉开发者如何通过基本可用、软状态和最终一致性来应对分区和故障。
示例一
- 场景：系统包括订单服务、库存服务、支付服务，用 Nacos 作为注册中心。订单服务下单时需要调用库存服务扣减库存。
- 网络分区发生：库存服务的 3 个实例（A、B、C）中，C 与 A、B 网络断开（分区）。
- AP 选择（基于 BASE）
- 基本可用：订单服务继续接受用户下单请求（保证 A）。如果库存服务 C 不可用，订单服务调用 A 或 B，或者降级（记录订单，稍后扣库存）。
- 软状态：分区期间，实例 C 的库存数据未更新（显示 100 件），A 和 B 已扣到 90 件。
- 最终一致性：分区恢复后，系统通过消息队列（比如 Kafka）或日志重放，将 C 的库存同步到 90 件。
示例二
分布式事务
XA模式
AT模式
TCC模式
需要自己写代码完成逻辑
MQ分布式事务
接口幂等性
幂等性是一个数学概念，用在接口上：用在接口上就可以理解为：同一个接口，多次发出同一个请求，请求的结果是一致的。
在系统的运行中，可能会出现这样的问题：
- 用户在填写某些form表单时，保存按钮不小心快速点了两次，表中竟然产生了两条重复的数据，只是 id 不一样。
- 开发人员在项目中为了解决接口超时问题，通常会引入了重试机制。第一次请求接口超时了，请求方没能及时获取返回结果（此时有可能已经成功了），于是会对该请求重试几次，这样也会产生重复的数据。
- mq 消费者在读取消息时，有时候会读取到重复消息，也会产生重复的数据。
方案一
请求接口之前，需要先获取一个唯一的 token，再带着这个 token 去完成业务操作，服务端根据这个 token 是否存在，来判断是否是重复的请求。
方案二
直接在数据库上加锁的做法性能不够友好，可以使用分布式锁的方式，目前最流行的分布式锁实现是通过 Redis，具体实现一般都是使用 Redission 框架。