聊聊分布式事务

愿打开此篇对你有所帮助。

好久没有写这个系列了哈。

前面几篇《打开我的收藏夹》文都让我受益匪浅，在此我还是想说一句：都是自己当初收藏的，就不要吃灰了，逐渐放空掉自己的收藏夹未必不是一件好事。

CAP 理论

C：强一致性，所有子节点数据时刻保持一致 A：整体可用 P：分区容错性，允许部分失败

至少要保证 P 吧，CA 不一定兼得的。

BASE 理论

basically available，基本可用。 优先满足 AP，以最终一致性取代强一致性。

我寻思着这俩不是集群吗？

关于缓存那些的可以翻我的redis专栏，一致性哈希我要再写一篇。

题外话

我一直追崇一个技术点不仅要理解其原理，还需要知道这个技术点解决了哪些痛点，这些痛点又是由什么引发的？这个技术还未诞生的时候是如何解决的？ 也就是整体的演进过程，历史脉络。 比如为何需要HTTP？HTTP0.9为何需要演进到HTTP1.0？ 进而又向1.1、2演进到最新要将Google开发的基于UDP的QUIC协议应用到HTTP3中。 搞懂这些来龙去脉相信你不仅仅对HTTP会有更深层次的理解，对网络也会有更加深刻的认识。当然也不是说一样东西一来就得全盘理清，有些东西还是比较复杂的，只是说我们要往这个方向去学。 这也是我一直觉得很重要的一个学习思想，知其然知其所以然，会让大家更好的理解很多东西。

这里的“我”指敖丙，我觉得他这段话非常之有道理，以后我要把这种做法贯彻到底！

分布式事务

（本分支图片来源于：面试官问我知道的分布式事务，我一口气说了六种）

2PC

二阶段提交，一种强一致性设计：

一荣俱荣，一损俱损。

在这里插入图片描述

在这里插入图片描述

第一阶段的协调者有超时机制，假设因为网络原因没有收到某参与者的响应或某参与者挂了，那么超时后就会判断事务失败，向所有参与者发送回滚命令。

眼尖的小伙伴多看两眼，就能看出一个问题来。我先不公布，拿张图挡一下，要自己想的就先别划下去。

有没有想过，协调者故障，或者事务失败了呢？

协调者压力可是很大的哦，因为它要为身后那些数据库撑起一片天哈。

如果协调者事务失败，这里有两种情况。

第一种是第二阶段执行的是回滚事务操作，那么答案是不断重试，直到所有参与者都回滚了，不然那些在第一阶段准备成功的参与者会一直阻塞着。

第二种是第二阶段执行的是提交事务操作，那么答案也是不断重试，因为有可能一些参与者的事务已经提交成功了，到最后真的不行只能人工介入处理。

协调者单点故障分析

Switch 协调者挂的时间：
	case 发布准备命令前{
		挂吧，事务还没开始，去修复它
	};
	case 发布准备命令后{
		锁定了资源的事务参与者将可能陷入阻塞，因为资源被锁定了嘛
	}
	case 发送回滚事务命令前{
		同上
	}
	case 发送回滚事务命令后{
		很大概率没事儿，但是出现网络分区就有可能会有些参与者收不到命令阻塞
	}
	case 发送提交事务命令前{
		好了，全死了
	}
	case 发送提交事务命令后{
		同上上
	}
	default{
	}
}

协调者单点故障解决方案

了解一下主从嘛。通过选举赶紧的再来一个协调者顶上去。

还是对上面进行一个划分处理哈：

Switch 协调者挂的时间：
	case 发布准备命令前{
		没事，小意思
	};
	case 发布准备命令后{
		每个参与者自身的状态只有自己和协调者知道
		这时候就需要日志了，不然新协调者哪里知道谁OK不OK啊
	}
	case 发送回滚事务命令前{
		同上
	}
	case 发送回滚事务命令后{
		同上
	}
	case 发送提交事务命令前{
		这个好办，统统滚回去吧
	}
	case 发送提交事务命令后{
		同上上
	}
	default{
	}
}

2PC 是一种尽量保证强一致性的分布式事务，因此它是同步阻塞的，而同步阻塞就导致长久的资源锁定问题，总体而言效率低，并且存在单点故障问题，在极端条件下存在数据不一致的风险。

但是也不能说人家就没用是吧，那不是还有个场景必须要强一致性嘛，那个ACID的那个。

数据库

3PC

相比于 2PC 增加了预提交阶段。

在这里插入图片描述

相比于 2PC 有什么升级？

1、准备阶段的变更成不会直接执行事务，而是会先去询问此时的参与者是否有条件接这个事务。因此性能会差一些，而且绝大部分的情况下资源应该都是可用的。 2、预提交阶段的引入起到了一个统一状态的作用，如果是等待预提交命令超时，那该干啥就干啥了，反正本来啥也没干。

3PC 通过预提交阶段可以减少故障恢复时候的复杂性，但是不能保证数据一致，除非挂了的那个参与者恢复。

TCC

2PC 和 3PC 都是数据库层面的，而 TCC（Try - Confirm - Cancel） 是业务层面的分布式事务。

在这里插入图片描述

TCC模型有个事务管理者的角色，用来记录TCC全局事务状态并提交或者回滚事务。

相对于 2PC、3PC ，TCC 适用的范围更大，但是开发量也更大，毕竟都在业务上实现，而且有时候你会发现这三个方法还真不好写。不过也因为是在业务上实现的，所以TCC可以跨数据库、跨不同的业务系统来实现事务。

本地消息表

本地消息表其实就是利用了 各系统本地的事务来实现分布式事务。 本地消息表顾名思义就是会有一张存放本地消息的表，一般都是放在数据库中，然后在执行业务的时候 将业务的执行和将消息放入消息表中的操作放在同一个事务中，这样就能保证消息放入本地表中业务肯定是执行成功的。 然后再去调用下一个操作，如果下一个操作调用成功了好说，消息表的消息状态可以直接改成已成功。 如果调用失败也没事，会有 后台任务定时去读取本地消息表，筛选出还未成功的消息再调用对应的服务，服务更新成功了再变更消息的状态。 这时候有可能消息对应的操作不成功，因此也需要重试，重试就得保证对应服务的方法是幂等的，而且一般重试会有最大次数，超过最大次数可以记录下报警让人工处理。 可以看到本地消息表其实实现的是最终一致性，容忍了数据暂时不一致的情况。

消息队列

就是消息队列嘛，这个概念还不熟悉嘛？

在这里插入图片描述

半消息不是说一半消息，而是这个消息对消费者来说不可见。

最大努力通知

举个很常见的例子，我给你发了个QQ消息，你一直不去点，你一打开QQ就可以看到我有条消息等着你去处理，这既是最大努力通知。 或者，想一下 epoll 的 LT 模式。

哎，八篇到这儿就捋出这点来，不知道是我菜还是当时眼光不太好。