《逆流而上 阿里巴巴技术成长之路》读后记录之二——业务篇

在阿里巴巴,有大量的业务技术研发人员,在业务线的研发人员每天都要遇到各类技术问题,业务线问题往往隐藏在业务和技术结合系统抽象和系统流程中,比如锁的问题,事务问题,缓存问题。通常排查比较麻烦,从浏览器到网络,到web服务器,到服务化应用,到缓存,到存储。希望排查思路和解决方案能够对读者带来启发。

1、幂等控制,分布式锁超时情况和业务重发的并发

背景

对账出现1分钱的差错,那么多出来的1分钱从哪里来的呢?

数据库分析记录

发现用户收益结账在同一天内有两笔交易记录创建时间分别为8:00:23,8:00:29,而修改时间均为8:00:29,正常情况下只有一次的,为什么出现两次呢?分布式锁的超时时间为5s,第一笔记录从创建到修改6s,由此可以分析是分布式锁超时失效后,获得数据库连接,进行提交成功。

过程逆推

  • 由于数据库连接数被占满,流水1创建事务处于等待提交状态
  • 系统A发现交易失败,重试次数不满8次的,立即发起重试,触发生成流水2的请求
  • 5s内数据军被分布式锁拦截,无法提交
  • 经过5s后,系统B的分布式锁失效,此时事务仍在等待未提交
  • 6s时,流水2成功越过数据库查询幂等校验发起事务,此时流水1拿到数据库连接,流水1和流水2两个事务同时提交。
  • 由于数据库未做唯一索引,且支付受理模块打穿下层幂等原则,生成两个TXID,导致两个事务同时提交成功
  • 收益结算重复记账,用户多了一笔收入。

开发人员得出结论:分布式锁在以下条件同时满足的情况下,并发控制会被打穿。
* 上层业务系统层面有重试机制
* 业务请求存在一定时间之后提交成功的情况,例如本例中第一次请求在事务等待6s后获得数据库连接,提交数据成功
* 下游系统缺乏其他有效的幂等控制手段

结论

建议将第三方唯一性的幂等控制方案作为幂等控制的兜底方案,控制好这道幂等防线,这样不论业务如何设计,就万变不离其宗了。

另类解法:分布式一致性

在阿里巴巴的红包系统中,红包的发放操作会涉及两个数据库的事务操作,一个数据库进行预算的扣减,另一个进行红包数据的写入,那么如何保证这两个事务操作的一致性呢?

传统思路

两阶段信息:由事务协调者来保证所有的事务参与者都完成第一阶段的准备工作,如果参与者都准备好了,那么进入第二阶段进行提交,MySQL数据库扮演参与者的角色,协调者由另外的应用担当。

问题

导致数据库压力增大,存在数据库热点问题

解决方案

开发人员设计一个轻量级的一致性消息服务,吧预算扣减成功等诸多业务操作写入数据库中,该消息组件保证事件与业务操作处于同一数据库中,所以仅仅是一次简单的本地事务操作。
在一个成功的红包发放操作中,对于预算端来说,进行了一次预算的扣减,一次事件写入,可能会进行一次事件读取,一次事件更行,对于用户红包数据端,仅需要进行一次红包数据的写入。对于预算扣减的热点数据操作,新的方案并没有放大它。

阅读更多
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/lck5602/article/details/79953831
个人分类: 数据库
上一篇《逆流而上 阿里巴巴技术成长之路》读后记录之一——数据库篇
下一篇centos7安装CDH记录
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭