CN111259071B - 一种分布式数据库系统中的并发访问控制方法 - Google Patents

Abstract

本发明公开了一种分布式数据库系统中的并发访问控制方法。本发明使用客户端的时间戳加硬件唯一标识来生成事务号。当只读事务第一次访问某行数据时，读取该行数据最新提交版本，并将该版本事务号记录在客户端，为重复访问提供凭据。当读写事务读取某行数据时，读取该行数据最新提交版本，并在该行所在节点的内存中增加该行的读锁。当读写事务更新某行数据时，将行的当前版本的事务号和更新的内容缓存在客户端。事务提交时，再将这次更新的内容发到对应节点，并根据该行的当前状态来决定更新是否可行，当需要等待或回滚时，根据事务号的次序关系使其中一个事务回滚。本发明避免了在分布式环境下进行代价极高的死锁检测，获得高并发性和高一致性。

Description

一种分布式数据库系统中的并发访问控制方法

技术领域

本发明属于信息领域，具体为一种分布式数据库系统中的并发访问控制方法。

背景技术

由于芯片制造工艺已经接近极限，近年来计算机中央处理器的主频率已经不再提高，而互联网、物联网等技术的快速发展又催生了海量数据处理的业务需求，因此数据处理技术开始向大规模分布式处理方向发展。当前的分布式数据库软件往往架构在成百上千台计算机上，通过局域网或广域网通信进行协作处理数据，并作为一个整体对外提供服务，让上层应用像访问单机数据库一样访问系统。

在分布式数据库中，最难处理的问题是并发访问控制，也就是在有很多事务同时访问数据库时，如何保证数据访问的正确性。在数据库理论中，通常一个可串行化序列被认为是可接受的合法序列，而为了保证并发事务的访问序列可串行化，传统的关系数据库采用二阶段锁协议来保证事务的隔离。简单来说，当事务读取数据时对该行数据加读锁，当事务更新数据时对该行数据加写锁，事务在生命周期内一直持有访问行上的锁，只有当事务提交或回退时才将锁释放。

然而，在分布式环境中，二阶段锁协议难以被直接应用，其原因在于，如果将加锁信息集中在某一个计算机节点上处理，则所有的访问会段集中在这个节点上，使得系统丧失了延展性和高可靠性；而如果将锁信息和数据一样分布在各个节点上，则死锁检测的代价大到无法忍受，因为死锁检测必须在网络通信环境下检查是否有等待成环。

在现今的分布式环境中，数据处理系统往往采取一种乐观的多版本协议。每个事务按照提交顺序被赋予一个递增的时间戳，当事务更新数据库的时候，其更新的行被打上这个时间戳，而事务读取的是小于自己开始时间戳之前的最大时间戳版本的数据。事务的更新在提交阶段才对相应行加上写锁，并在加不上写锁时宣告失败以避免死锁。这种并发控制方法可以避免加读锁，保证了只读事务的正确运行，提高了系统并发度，同时避免了死锁检测。但其问题在于：1)一个递增的时间戳同样会造成系统延展性的瓶颈，因为所有的事务都必须在开始和提交时同步访问这个时间戳生成器；2)当两个事务彼此更新产生死锁条件，即产生如下的序列时：

理论上只需要事务一和事务二中的一个回滚，另一个事务即可以执行成功，但乐观并发协议却有可能造成两个事务互相加不上写锁而同时回滚，使系统的错误率上升。3)在发生写偏斜时，即发生以下的序列时，在多版本并发控制方法下是可以通过的，但却并不是一个合法的可串行化序列：

此时事务一和事务二的访问序列彼此依赖，无法被串行化，破坏了数据库的一致性要求。

发明内容

本发明目的在于提供一种分布式数据库系统中的并发访问控制方法，将本方法应用到分布式数据库环境下，即可以实现高并发的访问性能，同时还可以避免写偏斜，保证数据库系统的高一致性。

为了达到上述目标，本发明通过以下技术方案进行实现：

一种分布式数据库系统中的并发访问控制方法，该方法使用客户端的时间戳加硬件唯一标识来生成事务号，事务号不需要在节点间进行同步即可以保持全局唯一性，且具有一定程度上的时序性。

数据库中的数据存储为数据加事务号的格式，每行数据被事务更新提交时，事务号也记录在数据中，代表数据的版本。数据可以存储多个版本，对同一行数据，每次事务更新提交时就形成新的版本。

当只读事务第一次访问某行数据时，读取该行数据最新的提交版本，并将该版本的事务号记录在客户端，为重复访问提供凭据。当此事务再次读取该行时，则可继续读取该行该版本的数据。

当读写事务访读取某行数据时，读取该行数据最新的提交版本，并在该行所在的节点的内存中增加该行的读锁。

当读写事务更新某行数据时，将行数据的当前版本的事务号和更新的内容缓存在客户端。事务提交时，再将这次更新的内容发到对应节点，并根据该行的当前状态来决定更新是否可行。

具体而言，被更新的行有以下几种当前状态：

若该行的当前版本仍然是读写事务更新时看到的版本，且读写事务可以加上本行的写锁，更新成功；

若该行的当前版本已经被其他事务修改并已提交，则读写事务更新失败，事务回滚。

若该行上当前存在其它事务的写锁，则读写事务根据自身事务号和加锁事务的事务号的大小关系来决定是等待还是回退。系统可以规定一种等待关系，在本方法中，事务号大的事务被允许等待事务号小的事务，而事务号小的事务不能等待事务号大的事务，反之亦可。

若该行上当前存在其它事务的读锁，此时根据读锁的数目作进一步判断，如果有多于一个的读锁，本读写事务直接回滚。如果只有另一个读写事务的读锁，则通过事务号的比对来决定两者中事务号较小的事务回滚。

读写事务在提交时，如果能加上所有需更新行的写锁，则事务提交成功，否则失败回滚。

本发明解决了在分布式数据库中对并发事务进行访问控制的难题，本发明并不需要额外的硬件设备支持，即可以实现在分布式、高并发的环境下，事务对数据库的访问产生可串行化的序列。同时本协议既可以对只读事务做到不阻塞，提高系统的可用性，又避免了乐观协议中的过度回滚和写倾斜问题，具有很高的实用性意义。

本文明公开了一种并发访问控制方法，本方法区分了只读事务和读写事务，对只读事务不加读锁，而对读写事务读取时加读锁，提交时再加写锁，同时使用非集中式算法产生具有序列特征的事务号，利用事务号的大小关系限定等待关系，从而避免了现有并发协议的问题，在不增加额外硬件成本的前提下，使分布式数据库系统可以同时获得高并发性和高一致性，具有较大的实用意义与价值。

附图说明

图1是方法的应用环境示意图。

图2是只读事务读取数据行的方法流程图。

图3是读写事务读取数据行的方法流程图。

图4是读写事务更新数据行的方法流程图。

具体实施方式

图1给出本方法的应用环境示意图。在现代信息环境中，一个分布式数据库往往可能建立在数个地理上分离的机房中的成百上千台计算机上，并对外提供统一的数据库服务。分布式数据库中的计算机节点通常包含路由节点、管理节点和数据节点等，每个节点都实现整体的部分功能。在数据节点中又往往运用复制技术来提高数据的可用性和可靠性。本发明不涉及这些相关的基础构架和技术，只着眼于如何在各个数据节点之间实现数据的并发访问控制。

当应用访问分布式数据库时，通过网络连接到数据库系统中，并向数据库发起读取或更新请求。图1中所示的是应用服务器与数据库服务分离的典型架构，在实际应用中，应用也可能是和分布式数据库运行在同一节点上，或是运行在更接近终端用户的终端如手机上。为了陈述清晰，本发明将访问数据库的应用统一称之为客户端。

为了保证应用正确性，客户端在访问数据库时，以事务为一个基本单位，一个事务可能会先后执行几条到几十条查询或更新语句，每条语句会访问几行到几十行数据库中的数据。在分布式数据库中，这些数据是分布在各个节点上的，一个事务可能需要先后访问多个节点上的数据行。为了提高性能，数据库中的事务访问都是在并发情况下进行的，因此多个事务可能在同一行上产生交错的访问序列。

事务在访问数据行时的序列如果可以被等价为一个串行化序列，则认为数据库的并发控制方法是正确的。要保证这一约束，即意味着不同事务对同一行数据的读/写行为或是写/写行为必须满足严格的先后顺序，但对只读事务，只要保证其读到的数据是已提交数据，理论上都是可以接受的。因此本方法要求事务在开始之初先声明其是只读事务还是读写事务，并对于两者执行不同的逻辑，以提高系统吞吐率。

在本发明中，每个读写事务在启动时，在客户端先生成一个唯一的事务号。事务号的高位是客户端的当前时间戳，低位是该客户端所在计算机的一个基于硬件的唯一标识，这个唯一标识可以是网卡MAC地址，或是CPU的硬件编号。时间戳可以保证事务号在本计算机生命周期内唯一，硬件标识可以保证事务号在所有计算机之间唯一。同时时间戳在高位，可以大体上保证开始时间较小的事务拥有较小的事务号，尽管客户端之间的时钟漂移会造成一些微小的误差。

数据库中的行都由两部分组成：数据部分和事务部分。其中数据部分是数据内容，而事务部分存放将数据更新成这个版本的事务号。对于同一行数据，在数据库中可保存多个不同的版本，当空间不足时，系统按一定规则进行旧版本回收。具体的行版本管理算法和回收策略，不是本专利的内容，且在数据库技术领域已经有成熟实现，在此不再展开。

为了提高并发度，本发明要求事务在启动时就决定自己是只读事务还是读写事务。对于绝大部分应用而言，事务都是可以事先决定自身的业务逻辑的。如果事务中间的业务逻辑存在分支，且部分分支路线上存在更新逻辑，则统一当成读写事务处理。读写事务可能会被堵塞或回滚，但只读事务一定会执行成功。

图2给出了只读事务访问数据行的逻辑。只读事务在访问数据行时，先查找客户端缓存中是否有此行的访问记录，如果有，则使用访问记录中的事务号，去查找该行相对应的版本数据；如果没有，只读事务会访问该行的最新提交的版本数据，并将该版本对应的事务号记录在客户端中，以保证下次访问时访问相同的行数据。

在本发明中，只读事务避免了对读数据行的过程中加锁，而采用了和多版本并发控制协议相似的、通过读历史版本来使事务可以无条件运行成功。这种行为会极大节省内存中的锁开销，并提高只读事务的并发度。为了保证事务在生命周期中访问的数据是一致的，本发明将只读事务访问过的行的事务号缓存在客户端，并在下次访问同一行时访问相同的版本。由于一般一个事务的生命周期中访问的行数目是有限的，这种策略会略微增加客户端计算机的内存开销，但避免了生成全局统一的时间戳，对系统的吞吐率有很大的提高。

图3给出了读写事务读取数据行的逻辑。与只读事务不同，读写事务一定只访问数据行的最新版本。当读写事务访问一行时，对行加上内存化的读锁。如果此时发现该数据行上有写锁，则事务进入等待。否则读取该行数据最新的提交版本，并在该行所在的节点的内存中增加该行的读锁。内存化的锁表结构在数据库领域同样是成熟技术，此处不再赘述。

读写事务在更新数据行时，并不直接更新到行上，而是把行上的事务号和将要更新的后项记录在客户端中。图4给出了读写事务在提交时更新数据行的逻辑。客户端首先将更新请求发送到数据所在的节点上，节点首先比较数据行的当前版本事务号是否与更新时的事务号一致，如果事务号不一致，则说明在这个事务的更新和提交动作之间，有另外一个读写事务更新本行成功，此时本事务无条件回滚。

如果事务号一致，此时读写事务尝试对本行加写锁，如果写锁加成功即可将行的数据部分和事务部分更新成本事务更新的后项和事务号，更新动作完成。如果读写事务对所有需要更新的数据都操作成功，则事务提交。事务提交并不需要再对数据行进行操作，只要通知相应的结点事务提交成功，将日志写入即可。

如果读写事务在加写锁时，发现行上有另一事务的写锁，则通过事务号的比对来决定是否允许本事务等待。本方法规定，只允许事务号较大的事务(在加写锁时)等待事务号较小的事务(的写锁)，不允许事务号较小的事务(在加写锁时)等待事务号较大的事务(的写锁)。如果后一种情况发生，则此读写事务应当立即回滚。

当读写事务在加写锁时，发现行上有读锁，此时根据读锁的数目作进一步判断，如果有多于一个的读锁，本读写事务直接回滚。如果只有另一个读写事务的读锁，则通过事务号的比对来决定两者中的一个事务回滚。同上面的规定一样，当发生事务的写锁要等待(另一事务的)读锁时，两者中事务号较小的回滚。

只要在系统中所有的事务都遵循以上规则，就不会发生死锁等待，同时也避免了在全局的分布式环境下进行代价极大的死锁检测。

在理论上，此方法有一定概率在并未真正形成死锁条件下，让某个读写事务白白回滚。但由于在本方法中，事务发生导致等待的回滚只会发生在提交阶段，此概率在时间尺度上被极大缩小了。再者，一个设计良好的应用系统，应当有能力避免在同一行上发生过多的读写冲突，从而使系统正常运行。

Claims (1)

1.一种分布式数据库系统中的并发访问控制方法，其特征在于该方法使用客户端的时间戳加硬件唯一标识来生成事务号，事务号不需要在节点间进行同步即能够保持全局唯一性，且具有时序性；

当只读事务第一次访问某行数据时，读取该行数据最新的提交版本，并将该版本的事务号记录在客户端，为重复访问提供凭据；当此事务再次读取该行时，则可继续读取该行该版本的数据；

当读写事务访读取某行数据时，读取该行数据最新的提交版本，并在该行所在的节点的内存中增加该行的读锁；

当读写事务更新某行数据时，将行的当前版本的事务号和更新的内容缓存在客户端；事务提交时，再将这次更新的内容发到对应节点，并根据该行的当前状态来决定更新是否可行；

所述的根据该行的当前状态来决定更新是否可行，具体如下：

若数据行的当前版本事务号与更新时的事务号一致，即该行的当前版本仍然是读写事务更新时看到的版本；此时读写事务尝试对本行加写锁，如果写锁加成功即可将行的数据部分和事务部分更新成本事务更新的后项和事务号，更新动作完成；如果读写事务对所有需要更新的数据都操作成功，则事务提交；事务提交并不需要再对数据行进行操作，只要通知相应的结点事务提交成功，将日志写入即可；

若数据行的当前版本事务号与更新时的事务号不一致，则说明在这个事务的更新和提交动作之间，有另外一个读写事务更新本行成功，即当前版本已经被其他事务修改并已提交，此时本事务无条件回滚，读写事务更新失败；

若该行上当前存在其它事务的写锁，则读写事务根据自身事务号和加锁事务的事务号的大小关系来决定是否允许本事务等待；等待关系规则如下：只允许事务号较大的事务等待事务号较小的事务，不允许事务号较小的事务等待事务号较大的事务，如果后一种情况发生，则此读写事务应当立即回滚；

若该行上当前存在其它事务的读锁，此时根据读锁的数目作进一步判断，如果有多于一个的读锁，本读写事务直接回滚；如果只有另一个读写事务的读锁，则通过事务号的比对来决定两者中事务号较小的事务回滚。

Images