分布式系统中数据库的事务如何处理?

来源:互联网 发布:linux删除用户密码 编辑:程序博客网 时间:2024/04/29 10:05

1、数据库拆分有垂直和水平两种方式

数据库垂直拆分会带来的影响:

a、单机的ACID保证被打破。数据到了多机后,原来单机中通过事务进行处理逻辑会有很大影响,要么放弃原来的单机事务,修改实现,要么引入分布式事务。

b、一些join操作会变得比较困难,因为数据可能已经在两个数据库中了。

c、靠外键去进行约束的场景会受到影响。

水平拆分会带来的影响:

a、同样有可能ACID被打破。

b、同样有可能join操作被影响。

c、靠外键去进行约束的场景会有影响。

d、依赖单库的自增序列生成唯一ID会受影响。

e、针对单个逻辑意义上的表的查询就要跨库了。


2、单机变成多机后,事务如何处理

a、分布式事务模型与规范


上图显示AP和RM时候一定需要的,而事务管理器TM是我们额外引入的,之所以要引入事务管理器,因为在分布式系统中,两台机器理论上无法达到一致的状态,需要引入一个单点进行协调,事务管理器控制着全局事务,管理事务的生命周期,并协调资源。

b、两阶段提交

two phase commitment protocol (2pc)两阶段提交协议,是相对于单库的事务提交方式来说的,在单库上完成相应的数据操作后,就会直接提交或者回滚,而在分布式系统中,在提交之前增加了准备阶段。





实际中,由于事务管理器自身稳定性,可用性,以及网络通信中可能产生的问题,出现情况会比较复杂,此外,事务管理器在多个资源之间进行协调,它自身要进行很多日志记录的工作。使两个阶段提交协议使用分布式事务开销增大。因此,在进行垂直和水平拆分后,要想清楚是否一定要引入两个阶段分布式事务,必要情况才建议使用。


c、大型网站一致性的基础理论---CAP/BASE
C:consistency:一致性,是当数据写入成功后,所有的节点都会同时看到这个数据。

A:availability:可用性,无论成功或失败,每个请求都收到一个反馈,重点是系统一定要有响应。

P:partition-tolerance分区容忍,也就是在系统一部分出现问题时,系统仍能继续工作。


3、比两阶段提交更轻量一些的Paxos协议

Paxos协议有一个前提就是有一个可靠的通信环境(就是不存在拜占庭将军问题),也就是消息都是准确的,没有被篡改。

首先把议员角色分为Proposer、Acceptor、Learners,议员可以身兼数职。

Proposer:提出议案者

Acceptors:收到议案后进行判断的角色,Acceptors收到议案后要选择是否接受议案,若议案获得多数acceptors接受,则该议案被批准(chosen)

Learners:只能“学习”被批准的议案,相当于对通过的议案进行观察的角色、

Proposal:议案,有Proposer提出,被Acceptors批准或否决

Value:决议,议案的内容,每个议案都是有一个{编号,决议}对组成。

决议(value)只有被proposers提出后才能被批准(未经批准的决议是“议案proposal”)

在Paxos中,一次只能批准(chosen)一个value

Learners只能获得被批准(chosen)的value。

4、多级的sequence问题与处理

当转为水平分库时,原来单库中的sequence以及自增id的做法需要改变。

mysql中,提供Auto Increament字段的支持,这样很容易实现一个自增的不重复的id的序列。在分库分表后,这就成了一个难题。下面从两个方向考虑和解决:唯一性、连续性

如果只是考虑id的唯一性的话,可以参考UUID的生成方式,或者根据自己的业务(不同维度的标识,例如ip,机器名,时间等)来生成唯一的id,这样生成的id虽然保证了唯一性,但是整个分布式系统的连续性不好。

连续性是指在整个分布式环境生成的id连续性,在单机环境中,其实就是一个单点来完成这个任务,在分布式系统中,可以用一个独立的系统来完成这个工作。

这里提供一个方案:就是把所有id都集中放在一个地方进行管理,对每个id序列独立管理,每台机器使用id都从这个id生成器上取。

但有几个问题需要解决:性能问题:每次都远程取id会有资源浪费,改进方案是一次取一段id,然后缓存在本地,如果应用取了一段id,正使用时宕机了,那么一些id号就浪费不可用了。

生成器的稳定性问题。id生成器作为一个无状态的集群存在,其可用性要靠整个集群来保证。

存储问题:



上面是在底层使用一个独立的存储来记录每个id序列当前的最大值,并控制并发更新,这样id生成器逻辑就很简单。



上面是直接把id生成器舍掉,把相关的逻辑放到需要生成id的应用本身就可以了。

5、分库查询

我们现在采用的是corbar分库,并没有把表进行拆分,是根据entityid%128进行路由,这样得到的值是唯一的。所以分页是没有问题的。这是用数据量还不是很大的时候。




0 0
原创粉丝点击