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

在阿里巴巴，有大量的业务技术研发人员，在业务线的研发人员每天都要遇到各类技术问题，业务线问题往往隐藏在业务和技术结合系统抽象和系统流程中，比如锁的问题，事务问题，缓存问题。通常排查比较麻烦，从浏览器到网络，到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数据库扮演参与者的角色，协调者由另外的应用担当。

问题

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

解决方案

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