打开我的收藏夹 -- 分布式篇

打开我的收藏夹 -- 分布式篇_第1张图片

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

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


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

二阶段提交,一种强一致性设计:

一荣俱荣,一损俱损。
打开我的收藏夹 -- 分布式篇_第2张图片

打开我的收藏夹 -- 分布式篇_第3张图片

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


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

打开我的收藏夹 -- 分布式篇_第4张图片

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

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

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

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

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


协调者单点故障分析

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

协调者单点故障解决方案

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

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

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

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

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

数据库


3PC

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

打开我的收藏夹 -- 分布式篇_第5张图片

相比于 2PC 有什么升级?

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

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


TCC

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

打开我的收藏夹 -- 分布式篇_第6张图片

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

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


本地消息表

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


消息队列

就是消息队列嘛,这个概念还不熟悉嘛?

打开我的收藏夹 -- 分布式篇_第7张图片

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


最大努力通知

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


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

你可能感兴趣的