分布式核心问题总结

一、幂等性

1. 所谓幂等就是一次或多次操作同一个资源，所产生的影响均一致。
2. 产生问题的原因：网络阻塞和延迟、用户重复操作
3. 一锁 二判 三更新

• 三步严格控制顺序，确保加锁成功后进行数据查询和判断，幂等性判断通过后再更新，更新结束后释放锁。
• 一锁这个过程，建议使用Redis实现分布式锁，因为他是非阻塞的高效率的互斥锁。非常适合在幂等控制场景中。
• 二判这个过程，如果有操作流水，建议基于操作流水做幂等，并将幂等号作为唯一性约束，确保唯一性。如果没有流水，那么基于状态机也是可以的。
• 但是不管怎么样，数据库的唯一性约束都要加好，这是系统的最后一道防线。万一前面的锁失效了，这里也能控制得住不会产生脏数据
• 三更新，进行数据的更新，将数据进行持久化。
• 操作完成之后，释放锁，结束整个流程。
• 例如：订单下单扣除库存，首先按商品id维度去做锁；然后每一个请求带有requesId，让requestId做为库存记录入库到库存流水表，并做为唯一索引约束，同时也是幂等性判断的依据；最后锁和判断都通过后则更新数据入库，释放锁。

扩展：如何设计一个接口？该从哪些方面考虑？

• 幂等性：以上
• 稳定性和可用性：如果存在高并发场景，需要对接口做限流及友好性提示。
• 安全性：是否涉及隐私数据，对数据进行加密传输
• 可扩展和可维护性：针对业务的需要，应考虑采用适当的设计模式，方便以后扩展
• ACID事务属性：

二、分布式事务一致性

• 多个微服务之间的操作要么一起成功，要么一起失败
• 事务的四个特性为原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持续性（Durability）,简称为ACID

1、Read Uncommited（读取未提交内容）

读未提交，顾名思义，就是一个事务可以读取另一个未提交事务的数据。但是，读未提交产生了脏读，采用读提交可以解决脏读问题

2、Read Commited（读取提交内容）

读提交，顾名思义，就是一个事务要等另一个事务提交后才能读取数据。读提交，若有事务对数据进行更新（UPDATE）操作时，读操作事务要等待这个更新操作事务提交后才能读取数据，可以解决脏读问题。但在这个事例中，出现了一个事务范围内两个相同的查询却返回了不同数据，这就是不可重复读。但是，读提交两次查询会产生不同的查询结果，就会造成不可重复读问题，采用重复读可以解决此问题。

3、Repeatable Read（重复读）

重复读，就是在开始读取数据（事务开启）时，不再允许修改操作。重复读可以解决不可重复读问题。应该明白的一点就是，不可重复读对应的是修改，即UPDATE操作。但是可能还会有幻读问题。因为幻读问题对应的是插入INSERT操作，而不是UPDATE操作。采用Serializable可以解决幻读问题

4、Serializable（可串行化）

串行化（ Serializable)是最严格的事务隔离级別。它要求所有事务都被串行执行，即事务只能一个接一个地进行处理，不能并发执行。可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率低下，比较耗数据库性能，一般不使用。

• 解决方案

1. 2PC（两阶段提交）、3PC（三阶段提交）；-》两阶段提交协议包括预提交和提交两个阶段，而三阶段提交协议包括准备、提交和回滚三个阶段。三阶段提交在解决了部分阻塞等待问题的同时，引入了可能的单点故障
2. TCC方案；（CC要求每个分支事务实现三个操作：预处理Try、确认 Confirm、撤销Cancel-》分布式事务解决方案之TCC_tcc事务-CSDN博客）
3. 本地消息表；
4. 可靠消息最终一致性方案；
5. 最大努力通知方案；

扩展：MySQL如何保证事务四大特性？

1、原子性是通过Undo Log（回滚日志）来保证的。InnoDB使用日志（Undo Log）来记录事务的操作，包括事务开始、修改数据和事务提交等。如果十五执行失败或者回滚，InnoDB可以使用日志来撤销已经执行的操作，确保 事物的原子性

2、持久性是通过Redo Log（重做日志）来保证的。在事务提交之前，InnoDB会将事物的修改操作先写入事务日志（Redo Log），然后再将数据写入磁盘。即使在系统崩溃或者断电的情况下，InnoDBb还是可以通过重放事务日志来恢复数据，确保事务的持久性

3、隔离性是通过MVCC（多版本并发控制）和锁机制来保证的

4、一致性是通过各种约束，如主键、外键、唯一约束等，加上事务的持久性、原子性和隔离性来保证的