亿级流量架构之分布式事务思路及方法

分布式事务以及分布式锁是分布式中难点,分布式事务一篇文章可能写不完,我的习惯时从基本概念出发,一步一步开始介绍,前面会先梳理事务中一些基本概念,对基本概念十分清楚的话可以直接看"一致性讨论"以及后面的部分。予己方便总结回顾、与他交流分享。

什么是分布式事务

在日常生活中,很多事要么全部做,要么全部不做,不能只做一部分,不然就会产生其他复杂的问题,很多人喜欢举转账的例子,对于同一个账号,A在湖北往出转500,B在广东取钱500,那么A转出去之后要将A账号的钱数目扣除,B账号数目增加: 事务 = (A账号扣除500,B账号增加500)

看到没,像这样多个步骤放在一起,就是事务,要么都执行,要么都不执行,如果我们的数据存储在多个数据库中,也就是存在跨库调用,由于网络具有不安全性以及延时性,如何保证事务分布式执行呢?如果执行到一半断电又该如何处理?在讲解分布式事务之前先简单回顾事务的一些特点,俗称 ACID ,下面逐一讲解:

原子性(Atomic)

在化学中,分子构成的物质,分子是保持化学特性的最小单位,如 H2O,CO2H2O,CO2 等,由原子构成的物质,原子保持物质特性,像 FeFe 啥的,意思就是不可分割,再分成质子中子啥的就不是我们认为的物质了,这儿的原子性也是这个道理,就是事务不可以再拆分,例如上面的事务,看着可以是由两个过程组成的事务,但是你拆开就不是我们认为该有的过程,所以,事务不可再分,具有原子性。

一致性（Consistency）

一致性也很好理解,对于上面的两个账户,如果银行想知道自己这儿被存了多少钱,那么这个事务执行前,A账号有500块,B账号没有钱,银行账户总共500块,事务执行后A账号没有钱,B账号有500块,也就是这个500块是一定的,不可能出现A账号有500块,B账号也有500块, 那就数据不一致了,这样的话,说明事务中某些步骤执行出现了问题,产生中间数据,那么就不一致。

在分布式中,对于一个结果,多处同时查询,得出的结果应该是一致的。

隔离性（Isolation）

一个事务在未完成时，另一个事务不会影响到它,也就是如果B还给C转账1000,记为事务2:

事务1 = (A账号扣除500,B账号增加500)

事务2 = (B账号扣除1000,C账号增加1000)

这两个事务之间不会产生影响,也就是不会发生A转出的500块到达C账号这种情况。

持久性（Durability）

持久化,一般是意味着将数据写入磁盘,不会轻易改变的意思,这儿是事务提交之后,会影响到数据库,不会丢失。这也就意味着,随着系统越来越庞大，我们为了提高可用性、维护性、吞吐量等等技术指标，就算改善原有架构，业务计算的问题解决后，数据库还是会成为整个系统中的瓶颈。

一致性的讨论

ACID本质而言都是为了保护数据的一致性,而数据数据持久化时会触发数据库操作,造成效率低小,所以围绕一致性(效率)产生了一些讨论,分别是强一致性、弱一致性、最终一致性。

强一致性

任何一次读都能读到某个数据的最近一次写的数据。系统中的所有进程，看到的操作顺序，都和全局时钟下的顺序一致。简言之，在任意时刻，所有节点中的数据是一样的,这就要求数据一有改变就写到数据库。

弱一致性

数据更新后，不要求及时写会数据库以及同步到所有节点,也就是这时候数据与真实数据可能有一些出入,对于架构而言,如果能容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性。

最终一致性

不保证在任意时刻任意节点上的同一份数据都是相同的，也就是有些节点数据可能是准确的,有的可能是不准确的, 但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。简单说，就是在一段时间后，节点间的数据会最终达到一致状态。

三种一致性中,强一致性数据更加可靠,但是由于时时刻刻要求所有数据库保持数据一致,所以效率低下,数据没有统一完,请求就没法得到响应,高并发场景下,体验不太好,所以在实际使用中,根据不同的业务选择是一致性也不同,购物时账号付钱肯定是强一致性,但是商品库存数据就不一定非要强一致性,至于商品下面的评论啥的,甚至可以选择弱一致性。

分库分表

前面讲过集群的AKF拆分原则( Redis集群拆分原则之AKF ),大概意思是硬件性能是由上限的,当硬件没法支撑请求流量时,可以将流量分发到不同的服务器上,AKF拆分之Y轴、Z轴拆分是业务拆分与数据拆分,那也就会涉及到将数据库中的数据拆分存储在不同的地方,这就叫分库分表,不同类型数据存储在不同数据库中做多机存储和负载,这样一来,传统的事务机制ACID便无法正常运行。

分库分表内容是数据切分（Sharding），以及切分后对数据的定位、整合。具体来说, 数据切分就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库性能问题，从而达到提升数据库操作性能的目的。

数据切分根据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分。

垂直拆分

垂直切分常见有垂直分库和垂直分表两种,两种含义类似。

垂直分库就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库。如图：

本文转载自网络，原文链接：https://www.toutiao.com/a6932273943143383564/
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！