从下单场景谈谈分布式理论:TCC/BASE/2PC/3PC
柔性事务TCC
TCC:Try-Confirm-Cancel
Try阶段:完成所有的业务检查,预留(锁定)业务资源
Confirm阶段:确认执行业务操作,
Cancel阶段: 业务最终失败,或者部分业务资源锁定失败,释放已锁定的资源
以常见的下单时使用优惠券的场景为例,涉及三个应用:订单服务、库存服务、优惠券服务:
1、用户提交下单请求 2、锁定商品库存 3、锁定优惠券 4、订单落库
Try阶段(用户下单):
依次同步调用锁定商品库存、锁定优惠券
Confirm阶段(用户支付完成):
更新订单状态为已支付
调用库存扣减、优惠券核销。可通过本地任务表或消息队列保证最终处理成功。
Cancel阶段:
场景一:锁定商品库存成功,锁定优惠券业务处理失败。整个业务操作失败,释放前一步锁定的商品库存。
场景二:库存和优惠券都锁定成功了,但是订单超时未支付自动关闭,或者用户主动取消。释放对应的库存和优惠券。
TCC使用了加锁粒度较小的柔性事务。如上面的流程,锁定库存、锁定优惠券、订单落库三个操作,并没有遵循ACID的原则包在一个大的事务中整体进行原子性的提交。而是变成各自独立应用处理的小事务分开处理。因此也无法保证在同一时刻各个数据源的数据是对应的(强一致性),某些时刻会出现锁定了库存但是订单还没有落库。TCC追求的是最终一致性,根据业务最终的成功与否,变更参与者的最终状态和业务状态一致。
看到这,了解分布式中BASE理论的会想起软状态和最终一致性,TCC算是BASE理论的一种体现。
BASE理论
BASE:Basically Available(基本可用),Soft state(软状态),和 Eventually consistent(最终一致性)
基本可用:保证核心功能可用。牺牲边缘功能和部分响应时间。比如电商中,核心业务为下单,物流查询、商品评论可适当降级处理。
软状态:因为延迟等因素导致的各个节点在某时刻不一致的状态。
最终一致:最终保持各个节点的数据一致。如上述场景。
2PC和3PC
然后我们又听到2PC的概念,也是分为两阶段,先预留资源再提交,这不和TCC一样吗。的确,二者的两阶段提交的思想确实是一样的。
2PC和TCC的两阶段补偿的区别
但我们说的2PC指的是基于XA规范的两阶段提交。而XA规范定义的DTP分布式事务模型中TM和RM的交互。
DTP分布式事务模型中的三个角色:AP(应用程序)、TM(事务管理器)、RM(资源管理器)
由此总结
2PC是针对是资源层面的(这里的资源包括数据库、消息队列等)事务操作,他的协调者和参与者分别是事务管理器和资源管理器。关注的是多个数据源和数据副本之间的同步,为了保证强一致性,在整个两阶段包在一个大事务中,会一直持有资源的锁。典型的例子如Mysql的先写Redo日志再写BinLog就是两阶段的提交。而像Springboot开发者只需要加个@Transactional注解即可,无需关心两阶段提交的细节。
TCC是针对业务应用程序层的,协调者是应用程序,参与者也是应用程序。关注的是应用之间数据的协调。对应的锁定释放逻辑包括幂等逻辑都需要开发者实现。
3PC
但是两阶段提交是完美的么,答案是否定的。
这里我们先不分什么TCC的两阶段提交还是基于XA的2PC了,再去想想刚才的下单场景有什么问题:
假如锁定了库存之后,应用或者说协调者崩溃了,后续的工作都没完成。前期被锁定的库存没有人来释放了,最终一致性出现问题了。
3PC即是在这种背景下产生的
3PC中增加了超时机制,来避免上述资源状态永远无法实现最终一致的问题,然而超时了到底应该是回滚释放还是提交确认呢?
先看看三个阶段干了什么
阶段1:查询资源是否可用,注意只查询不锁定。所有参与者都可提交再进行下一段,降低预留资源时才发现部分参与者不可提交产生回滚的概率。
阶段2:锁定资源
阶段3:提交确认
参与者收到PreCommit后返回超时,释放预留资源,使整个事务在进入阶段3之前完全回滚。
参与者收到DoCommit后返回超时,仍然提交确认。因为能进到阶段3说明协调者已经完成了阶段2对所有参与者的资源预留锁定。虽然大概率整个事务会成功,但如此毕竟不是完全严谨的,脑裂问题仍然存在,仍然会出现某个参与者提交其他参与者返回失败这样数据不一致的问题。
脑裂问题:协调者就是分布式/集群中的大脑,脑裂即协调者(领导者)的作用失效了。比如崩溃了,或者出现了多个协调者,使得参与者的行为没有被统一调度而出现不一致的情况。
针对上述问题,Paxos算法提供了解决方案,每次处理经过分布式节点中的参与者投票决议是否允许提交,得到超过半数投票者的同意后提交。对Paxos的细节本文不做赘述了。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Soloπ:支付宝开源的Android专项测试工具
1.前言 近年来,随着移动互联网的蓬勃发展,移动测试技术也取得了长足的进步,从早期基于测试脚本的单机自动化,到录制回放、图像识别、云测平台等测试技术贴合实际业务需求深度应用和创新,测试效率从而一次又一次被提升。 本文主要介绍支付宝在移动端上实现的一套无线化、非侵入、免 Root 的 Android 专项测试方案 Soloπ。直接操控手机,即可实现自动化的功能、性能、兼容性、以及稳定性测试等工作。 1.1 移动测试 1.0 时代 移动测试 1.0 时代,也可以称之为探索期。由于厌倦了日复一日的手工操作,如何提升测试效率成为了移动测试领域最重要的课题,在此期间,除了 Monkey、UiAutomator、Instruments 等官方提供的工具,业界还涌现了一批优秀的开源自动化测试工具/框架,在自动化驱动能力的基础之上,不仅可以实现基本功能的验证,还可以结合性能采集方案、遍历算法等实现各类专项测试的自动化。在这个阶段,自动化测试的常见形态是在单机或本地少数几台 PC 上部署测试环境,再利用 Jenkins 等工具实现持续集成。 1.2 移动测试 2.0 时代 伴随着测试技术的持续发展、又得...
- 下一篇
QPS 提升60%,揭秘阿里巴巴轻量级开源 Web 服务器 Tengine 负载均衡算法
前言 在阿里七层流量入口接入层(Application Gateway)场景下, Nginx 官方的Smooth Weighted Round-Robin( SWRR )负载均衡算法已经无法再完美施展它的技能。 Tengine 通过实现新的负载均衡算法Virtual Node Smooth Weighted Round-Robin(VNSWRR )不仅优雅的解决了 SWRR 算法的缺陷,而且QPS处理能力相对于 Nginx 官方的 SWRR 算法提升了60%左右。 问题 接入层 Tengine 通过自研的动态 upstream 模块实现动态服务发现,即运行时动态感知后端应用机器扩缩容、权重调整和健康检查等信息。同时该功能可以做很多事情,比如用户可通过调整后端应用某台机器的权重从而达到线上真实引流压测目的。然而,这些操作在 Nginx 原生 SWRR 算法下却可能引起不可逆转的血案。 • 在接入层(Application Gateway)场景下, Nginx 的负载均衡算法 SWRR 会导致权重被调高机器的QPS瞬间暴涨,如上图App2-host-A机器当权重调整为2时,某一时刻流量会集...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Red5直播服务器,属于Java语言的直播服务器
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS关闭SELinux安全模块
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- CentOS7安装Docker,走上虚拟化容器引擎之路