互联网电商大厂的分布式事务使用案例
事务的原子性、持久性可确保在一个事务内,更新多条数据都成功/失败。在一个系统内部,我们可以使用数据库事务来保证数据一致性。那如果一笔交易,涉及到跨多个系统、多个数据库的时候,用单一的数据库事务就没办法解决了。
在之前大系统时代,普遍的做法:设计时尽量避免这种跨系统跨数据库的交易。
但现在技术趋势是云原生和微服务,大系统被打散成多个微服务,每个微服务独立部署并拥有自己的数据库,大数据库也被打散成多个小数据库。跨越微服务和数据库的交易就成为普遍情况,不可避免要面对跨系统的数据一致性问题。
如何解决这种跨系统、跨数据库的数据一致性问题?分布式事务。但它可不像数据库事务,在开始和结尾分别加上begin和commit,剩下的问题数据库都可以帮我们搞定。
分布式环境,一个交易将会被分布到不同系统,多个微服务进程内执行计算,在多个数据库中执行数据更新操作,这比数据库事务支持的单进程单数据库场景复杂多。所以,并没有什么分布式事务服务或组件能在分布式环境下,提供接近数据库事务的数据一致性保证。
如何用分布式事务的方法,解决微服务系统中实际面临的分布式数据一致性问题呢?
1 什么是分布式事务
没有一种分布式事务的服务或组件,能简单解决分布式系统下的数据一致性问题。使用分布式事务时,更多情况是,用分布式事务理论指导设计和开发,自行解决数据一致性问题。即要解决分布式一致性问题,须掌握分布式事务实现原理。
即使是数据库事务,它考虑到性能因素,大部分情况下不能也不需要百分之百地实现ACID,所以才有事务隔离级别。
分布式事务也是事务,也需遵从ACID。但实际分布式系统中,因为须兼顾性能、高可用,不可能完全满足ACID。分布式事务实现都是“残血版”事务,相比数据库事务,更加“残血”。
分布式事务的解决方案如:2PC、3PC、TCC、Saga和本地消息表。强、弱项都不一样,适用场景也不一样。2PC和本地消息表较贴近于日常开发的业务系统。
2 2PC:订单与优惠券的数据一致性问题
2PC,二阶段提交。
购物下单时,若使用了优惠券,订单系统、优惠券系统都要更新自己的数据,才能完成“在订单中使用优惠券”的操作。
订单系统需:
- 在“订单优惠券表”中写入订单关联的优惠券数据
- 在“订单表”中写入订单数据
订单系统内两个操作的一致性问题可直接使用DB事务。
促销系统需要操作就比较简单,把刚使用的那张优惠券的状态更新成“已使用”。
需要这两个系统的数据更新操作保持一致,都更新成功/失败。
2PC怎么解决问题
2PC引入一个
事务协调者
来协调订单系统和促销系统,协调者对客户端提供一个完整的“使用优惠券下单”的服务,在这个服务内部,协调者再分别调用订单、促销的相应服务。
二阶段
准备阶段、提交阶段:
准备阶段
协调者分别给订单系统、促销系统发“准备”命令,订单、促销系统收到准备命令后,开始执行准备操作。准备阶段都需要做哪些事儿呢?除了提交数据库事务以外的所有工作,都要在准备阶段完成。如订单系统在准备阶段需完成:
- 在订单库开启一个DB事务
- 在“订单优惠券表”写入这条订单的优惠券记录
- 在“订单表”中写入订单数据
到这里,我们没提交订单DB的事务,最后给事务协调者返回“准备成功”。
同理,促销服务在准备阶段,需在促销库开启一个DB事务,更新优惠券状态,但暂不提交该DB事务,给协调者返回“准备成功”。
协调者收到两个系统“准备成功”的响应后,开始进入第二阶段。等两个系统都准备好,进入
提交阶段
协调者再给这两个系统发“提交”命令,每个系统提交自己的DB事务,然后给协调者返回“提交成功”响应。
协调者收到所有响应后,给客户端返回成功响应,整个分布式事务结束。
该过程的时序图
这都是理想的正常情况
3 异常了怎么办?
还分两个阶段
3.1 准备阶段
若任一步错误或超时,协调者就会给两个系统发送“回滚事务”请求。每个系统在收到请求之后,回滚自己的DB事务,分布式事务执行失败,两个系统的DB事务都回滚了,相关的所有数据回滚到分布式事务执行之前的状态,就像这个分布式事务没有执行一样。
3.1.1 异常情况时序图
若准备阶段成功,则进入
3.2 提交阶段
这就只剩一条路,整个分布式事务只能成功,不能失败。
若该阶段发生如下异常:
网络传输失败
需反复重试,直到提交成功。
宕机
包括两个DB宕机或订单服务、促销服务节点宕机,还是可能出现订单库完成提交,但促销库因宕机自动回滚,导致数据不一致。但因提交的过程很简单,执行很快,出现这种情况的概率很小,所以,从实用角度,2PC实际的数据一致性还是很好的。
实现2PC时,没必要单独启动一个事务协调服务,该协调服务的工作最好和订单服务或优惠券服务放在同一进程,好处是:
- 参与分布式事务的进程更少,故障点就更少,稳定性更好
- 减少远程调用,性能也更好
2PC是一种强一致设计,它可保证原子性、隔离性。只要2PC事务完成,订单库、促销库中的数据一定是一致状态,即都成功/失败。
所以2PC适合那些对数据一致性要求较高场景,如订单优惠券,若一致性保证不好,有可能会被黑产利用,一张优惠券反复使用!
2PC的缺陷
整个事务的执行过程,需阻塞服务端的线程和数据库的会话,所以,2PC在并发场景下的性能不太高。
协调者是个单点,一旦协调者宕机,就会导致订单库或促销库的事务会话一直卡在等待提交阶段,直到事务超时自动回滚。
卡住的这段时间,DB可能会锁住一些数据,服务中会卡住一个数据库连接和线程,这些都会造成系统性能严重下降,甚至整个服务被卡住。
适用场景
所以,只有在需强一致、并发量不大,才考虑2PC。
3 本地消息表:订单与购物车的数据一致性问题
2PC适用场景很窄,更多情况下,只要保证数据最终一致。如购物流程中,用户在购物车选好商品,点击“去结算”按钮,进入订单页面创建一个新订单。这过程,我们的系统做了:
- 订单系统需创建一个新订单,订单关联的商品就是购物车中选择的那些商品
- 创建订单成功后,购物车系统需将订单中的这些商品从购物车删掉
这也是分布式事务问题,创建订单、清空购物车两个数据更新操作需保证都成功/失败。但清空购物车对一致性要求没扣减优惠券那么高,订单创建成功后,晚几s再清空购物车,完全可接受。只要保证经过小延迟后,最终的订单数据和购物车数据保持一致。
3.1 适用场景
分布式最终一致性问题。
3.2 实现思路
订单服务在收到下单请求后,正常使用订单库的事务去更新订单数据。执行这个DB事务过程中,在本地记录一条消息,即一个日志,内容:“清空购物车”。因为这日志记录在本地,不牵涉分布式问题,那这就是普通的单机事务,那我们就能让订单库的事务,来保证记录本地消息和订单库的一致性。完成这步后,就能给客户端返回成功响应。
然后,再用一个异步服务,读取刚记录的清空购物车的本地消息,调用购物车系统的服务清空购物车。购物车清空后,把本地消息的状态更新成已完成。异步清空购物车这个过程,若操作失败,可重试。最终,可保证订单系统和购物车系统它们的数据一致。
这里的本地消息表,可选择:
存在订单库
相对来说,放在订单库更简单
也可用文件的形式,保存在订单服务所在服务器的本地磁盘
RocketMQ提供事务消息,就是本地消息表思想的实现。使用事务消息可达到和本地消息表一样的最终一致性,相比自己实现本地消息表,使用更简单。
本地消息表只满足D(持久性),A(原子性)C(一致性)、I(隔离性)都较差,但
优点突出
实现简单
在单机事务的基础上稍加改造,即可实现分布式事务。
性能非常好
和单机事务的性能几乎无差。在这基础,还提供大部分情况下都能接受的“数据最终一致性”的保证。
所以,本地消息表是更实用的分布式事务实现。即使能接受数据最终一致,本地消息表也不是银弹。
使用前提
异步执行的那部分操作,不能有依赖资源。如下单时,除了要清空购物车,还要锁定库存。
库存系统锁定库存的操作,虽能接受数据最终一致,但锁定库存有前提:库存中得有货。这就不适合本地消息表,不然就会出现用户下单成功后,系统的异步任务去锁定库存时,因为缺货导致锁定失败。这种case就很难处理。
4 总结
对订单和优惠券这种需强一致的分布式事务场景,可采用2PC。优点强一致,但性能和可用性都有缺陷。
本地消息表适用性更广,虽在数据一致性有所牺牲,只满足最终一致性,但有更好性能,实现简单,系统稳定性也很好。
无论是哪种分布式事务方法,其实都是把一个分布式事务,拆分成多个本地事务。本地事务可以用DB事务,那分布式事务就专注于解决如何让这些本地事务保持一致。
遇到分布式一致性问题的时候,也要基于这个思想来考虑问题,再结合实际的情况选择分布式事务实现。
互联网电商大厂的分布式事务使用案例相关推荐
- 互联网电商大厂库存系统设计案例讲解
1 库存扣减 多人同时买一件商品时(假设库存充足),每个人几乎同时下单成功,给人一种并行感觉.但真实情况, 库存只是一个数值,无论是存在mysql数据库还是redis缓存,减值时都要控制顺序,只能串行 ...
- 互联网电商老三巨头在网站推广下逐步退居幕后新三巨头蓄势待发
日前,黄峥借着拼多多公布财报的机会宣布辞任拼多多董事长,一石激起千层浪,这也标志着互联网电商老三巨头正式卸任退居幕后,而"新帅"三巨头整装待发即将带领互联网电商平台在网站推广之下走 ...
- 鸿蒙手机系统还没有开发,华为鸿蒙手机太难了!引发开发者大吐槽:为何没有自己独特风格?-互联网/电商-文章-小虾米...
[华为鸿蒙手机太难了!引发开发者大吐槽:为何没有自己独特风格?]互联网/电商-文章-小虾米 2020-12-27 11:32:02 小虾米帐号:军事科技(tabc) 关注我 举报 来源:q ...
- 抵制羊毛党,图计算“加持”互联网电商风控
本文分享自华为云社区<扒一扒GES如何赋能互联网电商风控>,原文作者:Dr Thunder . 随着大数据时代的到来,互联网电商风控已经从无风控.人工抽取规则为主的简易规则模型发展到当前基 ...
- 《互联网+ 电商平台设计与运营》一一2.4 小结
本节书摘来自异步社区出版社<互联网+ 电商平台设计与运营>一书中的第2章,第2.4节,作者: 郝宪玮 , 卢文隆,更多章节内容可以访问云栖社区"异步社区"公众号查看. ...
- 虽然“互联网电商”导致大量的“线下实体行业”受到冲击,但是“体验行业”永远不会被“互联网电商”影响
我对"体验行业"的定义是:你必须亲身前往,才能享受到服务. 比如你想吃火锅,虽然也可以网上买汤料在家里吃,但就是没有去外面吃,体验更好,味道更棒. 比如你想运动,虽然也可以网上买器 ...
- 有人说,互联网电商把1000个实体店老板赚的钱,让10个互联网电商赚走了
有人说,互联网电商把1000个实体店老板赚的钱,让10个互联网电商赚走了,同时利润也是有原先1000个人分变为现在10个人分,这就是垄断!对于消费者来讲,在同等成本下,养10头猪容易还是养1000头猪 ...
- 浅谈互联网电商平台都有哪些模式
现在互联网模式下的电商平台是繁花齐放.五彩斑斓的,各行各业的,出售电子产品.化妆品.日常生活品.食物.医药品.工业原料等等,在电商的设计本质上并没有千差万别. 常见电商平台的模式包括:B2C.B2B. ...
- Java开源生鲜电商平台-Java分布式以及负载均衡架构与设计详解(源码可下载)
Java开源生鲜电商平台-Java分布式以及负载均衡架构与设计详解(源码可下载) 说明:主要是针对一些中大型的项目需要进行分布式以及负载均衡的架构提一些思路与建议. 面对大量用户访问.高并发请求,海量 ...
最新文章
- ashx session 使用注意要点。
- swing之单选框和复选框
- python监听器_监听器 - python成长中 - 博客园
- 揭秘阿里中台!一文看懂阿里推荐业务的两大利器
- A wizard’s guide to Adversarial Autoencoders: Part 2, Exploring latent space with Adversarial Autoen
- ArrayList迭代修改抛出ConcurrentModificationException
- hadoop3节点hdfs ha,yarn ha配置
- EL : Free Package of October
- IFIX上位机网络测试画面
- box-shadow属性四个值_flex笔记1——flex-direction属性
- 区块链中心化业务必须基于中心化平台吗?
- SPDK/PMDK/VTune Amplifier 2019中国峰会顺利落幕
- 如何用AutoRunner录制IE脚本录制
- C语言-打印菱形三角形等图形
- RK61键盘配置方法
- 什么是虚拟机?虚拟机有什么用?虚拟机的特点?
- 基于STM8的数字温度计设计
- android studio修改app图标
- c语言之圆的周长、面积、圆球的体积--改良版
- aria2搭建(CentOS 7)
热门文章
- 工程计算机制图PDF,工程计算机制图.PDF
- 基于TCP的网络聊天室实现(C语言)
- bulidroot使能Qt5模块中的蓝牙_NFC功能
- 虚拟机如何设置外网ip
- 【性能|优化】TB级flink任务报错分析:Could not compute the container Resource
- 安装STM32Cubemx-6.0.1报错,需要64位java1.8.0_45 (64-bit)JRE
- php利用wsh突破函数禁用执行命令(安全模式同理)
- Google:host配置
- 计算机设计原理教学反思,教学反思——我是电脑小医生
- 小P学区块链(一):区块链到底是什么?该如何去学习