[发明专利]一种解决并发批量更新数据库而引起死锁问题的方法

说明书

本发明公开一种解决并发批量更新数据库而引起死锁问题的方法，其由事务管理器、事务执行集合和事务等待队列组件组成；事务管理器是事务的协调者，负责将事务从事务等待队列中取出并执行；事务执行集合是正在执行事务的数据集合，正在执行事务的数据间无任何交集，相互独立；事务等待队列是用于存放事务及事务数据的、拥有有限长度的有序队列，若提交的事务数据与正在执行的事务数据发生碰撞，设定一个分数和超时时间，存入事务等待队列中，分数用于设定等待事务的执行优先级，分数越高得到优先执行的机会越高，设定超时时间用于事务长时间未能得到执行而主动放弃执行机会的一种策略。以上组件的引入正是为了避免正在执行的事务间发生数据碰撞，数据存在交集，而引发死锁问题。

技术领域

本发明涉及互联网信息技术数据处理技术领域，具体涉及一种解决并发批量更新数据库而引起死锁问题的方法。

背景技术

在互联网电商环境下，大量用户同时抢购商品是一种常态，为了提高系统的快速响应能力，系统通常会对商品库存执行批量更新操作，以此提升用户体验。使用InnoDB存储引擎的数据库管理系统为了保证数据的一致性，在执行更新的过程中采用行锁策略，这就为执行批量更新导致死锁埋下了隐患。具体过程如下，有A(1,3,4)、B(3,1,5)两个事务同时执行，A事务首先获得id＝1的行锁执行更新，B事务获得id＝3的行锁执行更新，这时A事务请求id＝3的行锁，但该锁被B事务持有，A事务只能等待该锁的释放，与此同时B事务请求获得id＝1的行锁，同样的，该锁被A事务持有，B事务只能等待该锁的释放，造成AB两事务相互等待的死锁现象，各自都无法继续对后续数据执行更新，无法提交事务。

为了解决批量更新的死锁问题，目前业界提出了若干方法，一是将执行批量更新的SQL语句拆分成单个SQL语句循环执行，这种方法会造成更新效率的降低，违背了批量更新的初衷，同时循环执行单SQL并不能解决死锁问题；二是在执行批量更新之前先对数据进行排序，还是以AB事务为例，排序后A事务的更新顺序为(1,3,4)，B事务更新顺序为(1,3,5)，AB事务同时执行，首先A事务获得id＝1的行锁，执行更新，于此同时B事务请求获得id＝1的行锁，但该锁由于被A持有，只能等待A事务更新完所有数据以后释放锁才能请求成功，B事务才得以更新和提交，该方法依然未能彻底解决死锁问题，只是降低了死锁的概率，若AB两事务的更新顺序分别为(1,3,4)、(3,4,5)，死锁问题必然会发生；三是使用主键更新，在未创建索引的数据表执行批量更新时，InnoDB会直接使用表锁而非行锁，执行效率大大降低，若存在索引则锁住索引，因此为了最小化锁的范围，使用主键索引最为合适，实际上上述案例分析正是基于主键索引而言的；四是缩小事务作用范围，在执行数据查询和逻辑处理时避免开启事务，只有等待数据准备好以后再开启事务，这样可以避免因长事务问题而引起超时回滚，降低事务作用时间可降低因数据碰撞而引起死锁的概率，但这非彻底解决死锁问题。

发明内容

针对现有技术中由于正在执行的事务间发生数据碰撞，数据存在交集，而引发死锁问题，本发明提供一种解决并发批量更新数据库而引起死锁问题的方法，实现各事务的数据之间相互独立，相互间不存在重复的部分，事务间彼此互不影响，可高效完成事务的提交工作。

具体技术方案如下：

一种解决并发批量更新数据库而引起死锁问题的方法由事务管理器、事务执行集合和事务等待队列组件完成，

事务管理器是事务的协调者，负责将事务从事务等待队列中取出并执行；

事务执行集合是正在执行事务的数据集合，正在执行事务的数据间无任何交集，各自相互独立；

事务等待队列是一种用于存放事务及事务数据的、拥有有限长度的有序队列，若提交的事务数据与正在执行的事务数据发生碰撞，给事务指定一个分数和超时时间，然后存入事务等待队列中；分数用于设定等待事务的执行优先级，分数越高也有机会得到优先执行的机会；超时时间用于若事务等待的时间超过设定的超时时间，事务仍然未得到执行而主动放弃执行机会，快速响应请求失败的一种策略。