没有合适的资源?快使用搜索试试~ 我知道了~
本文从案例开始,我们团队曾经遇到过一个非常严重的线上事故,在一次 DBA 完成单台数据库线上补丁后,系统偶尔会出现异常报警,我们的开发工程师很快就定位到了数据库异常问题。 具体情况是这样的,当玩家购买道具之后,扣除通宝时出现了异常。这种异常在正常情况下发生之后,应该是整个购买操作都需要撤销,然而这次异常的严重性就是在于玩家购买道具成功后,没有扣除通宝。 究其原因是由于购买的道具更新的是游戏数据库,而通宝是在用户账户中心数据库,在一次购买道具时,存在同时操作两个数据库的情况,属于一种分布式事务。而我们的工程师在完成玩家获得道具和扣除余额的操作时,没有做到事务的一致性,即在扣除通宝失败时,应该回滚已经购买的游戏道具。 从这个案例中,我想你应该意识到了分布式事务的重要性。
资源推荐
资源详情
资源评论
电商系统的分布式事务调优
今天的分享也是从案例开始。我们团队曾经遇到过一个非常严重的线上事故,在一次 DBA
完成单台数据库线上补丁后,系统偶尔会出现异常报警,我们的开发工程师很快就定位到了
数据库异常问题。
具体情况是这样的,当玩家购买道具之后,扣除通宝时出现了异常。这种异常在正常情况下
发生之后,应该是整个购买操作都需要撤销,然而这次异常的严重性就是在于玩家购买道具
成功后,没有扣除通宝。
究其原因是由于购买的道具更新的是游戏数据库,而通宝是在用户账户中心数据库,在一次
购买道具时,存在同时操作两个数据库的情况,属于一种分布式事务。而我们的工程师在完
成玩家获得道具和扣除余额的操作时,没有做到事务的一致性,即在扣除通宝失败时,应该
回滚已经购买的游戏道具。
从这个案例中,我想你应该意识到了分布式事务的重要性。
如今,大部分公司的服务基本都实现了微服务化,首先是业务需求,为了解耦业务;其次是
为了减少业务与业务之间的相互影响。
电商系统亦是如此,大部分公司的电商系统都是分为了不同服务模块,例如商品模块、订单
模块、库存模块等等。事实上,分解服务是一把双刃剑,可以带来一些开发、性能以及运维
上的优势,但同时也会增加业务开发的逻辑复杂度。其中最为突出的就是分布式事务了。
通常,存在分布式事务的服务架构部署有以下两种:同服务不同数据库,不同服务不同数据
库。我们以商城为例,用图示说明下这两种部署:
资源评论
AE86Jag
- 粉丝: 43
- 资源: 18
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功