江苏龙网

  1. 主页 > 生活百科 > >

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

流量架构

分布式事务以及分布式锁是分布式中难点,分布式事务一篇文章可能写不完,我的习惯时从基本概念出发,一步一步开始介绍,前面会先梳理事务中一些基本概念,对基本概念十分清楚的话可以直接看"一致性讨论"以及后面的部分 。予己方便总结回顾、与他交流分享 。
什么是分布式事务在日常生活中,很多事要么全部做,要么全部不做,不能只做一部分,不然就会产生其他复杂的问题,很多人喜欢举转账的例子,对于同一个账号,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便无法正常运行 。


推荐阅读


上一篇：照片只修不调都白扯，调色靠蒙没有用

下一篇：滴滴司机是什么工作单位？