分布式数据库对2PC的优化方法是什么
本篇内容主要讲解“分布式数据库对2PC的优化方法是什么”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“分布式数据库对2PC的优化方法是什么”吧!
为浙江等地区用户提供了全套网页设计制作服务,及浙江网站建设行业解决方案。主营业务为成都网站设计、网站制作、浙江网站设计,以传统方式定制建设网站,并提供域名空间备案等一条龙服务,秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求,就会得到认可,从而选择与我们长期合作。这样,我们也可以走得更远!
两阶段提交(2PC)
两阶段提交协议主要有2种,一种是应用层的TCC,比如阿里巴巴的seata就实现了TCC模式,这种模式的特点是每个服务都需要提供try/confirm/cancel这3个实现,这3个实现需要在业务代码中实现,对业务侵入高。
今天我分享的是面向资源的2PC协议,最早由Jim Gray提出,整个事务分为2个阶段,prepare阶段和commit阶段,这2个阶段由协调节点和DB资源管理器协作完成。
这里我们还是以经典的电商系统为例,整个系统分为订单、账户和库存3个服务,我们收到客户的购买请求后,协调节点需要协调订单服务生成订单,账户服务扣减商品款,库存服务扣减商品库存,假如这3个服务的数据库在不同切片上,这个协调过程具体如下:
1.prepare阶段
协调节点向所有服务发送prepare请求,每个服务收到prepare请求后会尝试执行本地事务,但不会真正提交本地事务。这个尝试执行的过程会检查到是否具备执行事务的条件,比如资源是否被锁定等,当所有服务都尝试执行成功后会给协调节点返回一个yes,如下图:
2.commit/rollback阶段
如果prepare阶段所有服务有返回了yes,那么协调节点就会通知各个服务执行commit操作,这时各个服务就会真正的提交本地事务。如下图:
如果prepare阶段有服务返回了no,协调节点就需要通知所有服务进行本地事务回滚。
2PC存在问题
上面我们简单地分析了2PC协议的执行过程,那么2PC有什么问题呢?
1.性能问题
本地事务在prepare阶段锁定资源,比如账户服务要扣减xiaoming这个账户的金额100元,那必须把xiaoming这个账户先锁定。这样如果有其他事务也要修改xiaoming这个账户,就必须等待前面的事务完成。这样就造成了延迟和性能下降。
2.协调节点单点故障
协调节点是单节点的,如果发生故障,整个事务会一直阻塞。比如第一个阶段prepare成功了,但是第二个阶段协调节点发出commit指令之前宕机了,所有服务的数据资源处于锁定状态,后面的事务只能等待。
3.数据不一致
如果第一阶段prepare成功了,但是第二阶段commit的时候,如果协调节点通知库存服务失败了,这样就相当于生成了订单,扣减了账户,但是没有扣减库存。这导致了数据的不一致。
Percolator模型
主流的NewSQL数据库,比如TiDB,是用Percolator模型来解决的。如下官网链接:
https://pingcap.com/blog-cn/percolator-and-txn/
Percolator模型来自于Google论文:
《Large-scale Incremental Processing Using Distributed Transactions and Notifications》
原文可以看下面连接,网上也有好多翻译版的:
https://www.cs.princeton.edu/courses/archive/fall10/cos597B/papers/percolator-osdi10.pdf
Percolator的前提是本地事务的数据库支持多版本并发控制协议,也就是mvcc。现在主流数据库比如MySQL、oracle都是支持的。
a)初始阶段
还是看上面我们提到的经典电商案例,初始阶段,我们假设订单数量是0,账户服务是1000,库存服务是100,客户下了1个订单后,订单服务增加1个订单,账户服务扣除金额100,库存服务扣除商品数量1。各个切片的初始数据如下表:
":"前面的是时间戳或者数据版本,后面是数据值。这3张表中,第一条记录不保存真正的数据,而是保存了指向真正数据的指针,比如订单表中,6这个版本的数据指向了5个版本的数据,订单数量是0。
b)prepare阶段
在prepare阶段,协调节点向每个服务发送了prepare命令,这3张表分别进入了prepare阶段。在prepare阶段,Percolator定义了主锁的概念,每个分布式事务只能有一个服务获得主锁,比如本案例的订单服务,其他服务的锁指向这个主锁的指针,如下表:
prepare阶段,每个服务会写日志,并且根据时间戳记录事务的私有版本,这样其他事务就不能操作这三条数据了。
c)commit阶段
在commit阶段,协调节点只需要跟订单服务通信,因为订单服务拥有primary lock,也就是说协调节点只跟拥有primary lock的切片通信。这时数据如下表:
这时我们注意到除了order服务的锁没有了,而且增加了版本8指向版本7,说明订单服务已经没有私有版本了,但是账户服务和库存服务的私有版本还在。Percolator的独特之处就是在这里,它会启动异步线程来更新账户服务和库存服务。最终数据如下表:
因为协调节点只需要跟获取primary lock的切片进行通信,要么成功要么失败这样就避免了commit时节点不能全部成功导致的数据不一致问题。
而prepare阶段记录了日志,如果某个切片commit失败,可以根据日志进行再次commit,这样就保证了数据最终一致。
如果协调节点宕机了,异步线程可以做资源的释放工作,避免了因单点故障通信失败造成的资源不能释放。
这里我们要注意2点:
primary lock的选择是随机的,比如本例中并不一定会选择订单服务
协调节点发送commit后订单服务先提交成功,这时如果其他事务要读取账户服务和库存服务的2条数据,虽然2条数据上面还有lock,但是查找primary@order.bal发现已提交,所以是可以读取的。
总结
2PC协议有3个问题,性能问题、单点故障和数据不一致。
Percolator模型简化了协调节点和切片的通信流程,让协调节点只跟其中一个primary切片通信,一方面,减少了通信开销,另一方面,避免了因为单点故障,commit阶段部分节点通信失败导致的数据不一致问题。
Percolator在prepare阶段记录了日志,这样即使协调节点故障了,恢复后也可以根据日志来做事务恢复。
Percolator使用异步线程来做资源的释放工作,这样即使协调节点故障了,也不用担心资源得不到释放。
知名的NewSQL数据库TiDB就是参照Percolator模型来对2PC协议进行优化的。
但是我们要知道,2PC的性能问题还是存在的,好在主流的分布式数据库都做了优化,性能损耗只会越来越小。
到此,相信大家对“分布式数据库对2PC的优化方法是什么”有了更深的了解,不妨来实际操作一番吧!这里是创新互联网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!
新闻标题:分布式数据库对2PC的优化方法是什么
文章网址:http://scyanting.com/article/jchhid.html