CN116910064A - 一种分布式系统中在线创建表索引方法和系统 - Google Patents

Abstract

本发明公开了一种分布式系统中在线创建表索引方法和系统，服务端接收到客户端的请求后，会启动一个事务状态机，更新的数据首先会被写入日志，保证系统故障时，可以从日志中恢复事务的数据。然后，数据被上传到分布式缓存层。上传成功，事务进行提交，并通知客户端读写操作完成。另外，检查点(checkpointer)服务会异步地将分布式缓存中的数据刷新到持久化存储层。本发明基于分布式全局锁的机制，在不阻塞并发的读写事务(DML)的情况下在线创建表的索引，以及基于日志，实现故障恢复操作，保证在分布式系统中，更新表索引事务的持久化和一致性。同时，基于重试机制，实现事务的异常处理过程。

Description

一种分布式系统中在线创建表索引方法和系统

技术领域

本申请涉及分布式系统中在线创建表索引技术领域，特别是涉及一种分布式系统中在线创建表索引方法和系统。

背景技术

分布式系统(distributedsystem)是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件(特别是操作系统)，而不是硬件。

在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。系统拥有多种通用的物理和逻辑资源，可以动态的分配任务，分散的物理和逻辑资源通过计算机网络实现信息交换。系统中存在一个以全局的方式管理计算机资源的分布式操作系统。通常，对用户来说，分布式系统只有一个模型或范型。在操作系统之上有一层软件中间件(middleware)负责实现这个模型。一个著名的分布式系统的例子是万维网(WorldWideWeb)，在万维网中，所有的一切看起来就好像是一个文档(Web页面)一样。

在现有的分布式系统中，由于网络，时钟同步等问题非常容易产生系统中各节点状态不一致的问题。针对创建表索引这种更改表结构(schema)的操作，这种不一致有可能会造成各节点在某一个时刻具有不同的表结构视图，进而会造成数据损坏等问题。例如在表结构更改过程中，并发的读写操作在一个节点中使用某种表结构进行编码，而在另一个节点中使用不同的表结构进行编码。现有的分布式系统中创建表索引可能造成的状态不一致。

发明内容

基于此，针对上述技术问题，提供一种分布式系统中在线创建表索引方法以解决现有的分布式系统中创建表索引可能造成的状态不一致的问题。

第一方面，一种分布式系统中在线创建表索引方法，所述方法包括：

获取全局写意向锁，协调节点向所有参与节点发起表级别的加锁请求，待所有节点返回加锁结果，并在所有节点都加锁成功后，协调节点执行下一步操作，若发生加锁冲突，则终止本次创建索引的操作；

获取全局写锁，执行锁升级操作，在获取到全局写意向锁之后，协调节点向所有的参与节点发起表级别的加写锁请求，在获取到全局写锁之后，协调节点通过各节点返回的加锁信息，计算事务的提交时间戳；

将新的表索引信息和新的表结构版本号写入第一日志进行持久化，定义所述第一日志类型为PrepareLog；所述第一日志写入成功后，若发生节点故障，在恢复过程中，根据所述第一日志信息继续完成索引的创建过程；

降级全局写锁，创建持久化存储，并更新表中旧数据的索引值；

写入第二日志，所述第二日志类型为PrepareIndexLog，并升级为全局写锁；所述第二日志写入成功后，若发生节点故障，在恢复过程中，根据所述第二日志信息继续完成索引的创建过程；

写入第三日志，所述第三日志类型为CommitLog，并释放全局写锁；所述第三日志写入成功后，若发生节点故障，在恢复过程中，根据所述第三日志信息继续完成索引的创建过程；

写第四日志，所述第四日志类型为CleanLog，标识成功地创建了表索引。

上述方案中，可选地，所述获取全局写意向锁，协调节点向所有参与节点发起表级别的加锁请求，包括：

协调节点向所有参与节点发起表的表级别的加写意向锁请求，待各节点返回加写意向锁结果；所有节点都加锁成功后，协调节点执行下一步操作；

若发生加锁冲突，则终止本次创建索引的操作；

获取全局写锁，执行锁升级操作，在获取到全局写意向锁之后，协调节点向所有的参与节点发起表级别的加写锁请求，在获取到全局写锁之后，协调节点通过各节点返回的加锁信息，计算事务的提交时间戳，具体为：在获取到全局写锁之后，协调节点通过各节点返回的加锁信息，计算目标事务的提交时间戳，所述时间戳的计算采用下述的公式：

Ts＝max(allnode’scommit_ts+1，allnode’sLast_read_ts+1)

其中，所述commit_ts表示所述表结构上次更新的提交时间戳；

Last_read_ts表示最近一次读取表结构信息的ts，发生在对所述表的读写操作过程中。

上述方案中，可选地，所述协调节点为发起创建索引事务的节点；

所述参与节点为参与创建索引事务的节点，接收协调节点发送的消息并进行处理，包括在本节点上获取锁，在本地创建新的表结构schema信息，特殊地，协调节点也是参与节点。

上述方案中，可选地，所述第一日志写入成功后，若发生节点故障，在恢复过程中，根据所述第一日志信息继续完成索引的创建过程，包括：

所述第一日志写入成功后，若发生节点故障，根据日志进行事务的恢复操作；日志中存在所述PrepareLog记录，在本地中加表级别的写意向锁，同时，

若协调节点发生故障，在故障重启时，创建新的事务状态机，重新从降级全局写锁阶段重新执行；

若参与节点发生故障，在故障重启时，将节点的状态恢复到所述PrepareIndexLog记录之前的状态；恢复节点上表级别的写意向锁，同时创建本地的旧的表结构信息和新的表结构DitrySchema信息。

上述方案中，可选地，所述降级全局写锁，创建持久化存储，并更新表中旧数据的索引值，具体为：协调节点发起锁降级请求，将所有节点中的写锁降级为写意向锁；同时，所有节点在本地创建新的表结构DirtySchema；

所述协调节点在持久化存储层创建新的索引的持久化存储；

在所有节点中同时将分布式缓存层中的数据刷新到持久化存储层；

所述协调节点从持久化存储层中读取旧数据，将所述旧数据生成新的索引数据，并写入分布式缓存层；所述旧数据生成索引数据后，对缓存层中的索引数据进行强制的同步操作，刷新到持久化存储层中的索引表中，同时将旧数据生成的索引数据从分布式缓存层中踢出。

上述方案中，可选地，所述写入第二日志，所述第二日志类型为PrepareIndexLog，并升级全局写锁；所述第二日志写入成功后，若发生节点故障，在恢复过程中，根据所述第二日志信息继续完成索引的创建过程，包括：

写入第二日志，所述第二日志类型为所述PrepareIndexLog，标识创建表索引事务完成了旧数据的索引值的更新操作；

若系统发生故障，日志中存在所述PrepareIndexLog记录，则故障节点将节点的状态恢复到CommitLog之前状态；

若协调节点发生故障，恢复本地表级别的写锁，同时在本地创建新的表结构DitrySchema信息；创建新的事务状态机，所述事务重新从升级全局写锁阶段重新执行；

若参与节点发生故障，需要恢复本地表级别的写锁，同时在本地创建旧的表结构信息和新的表结构DitrySchema信息。

上述方案中，可选地，所述写入第三日志，所述第三日志类型为CommitLog，并释放全局写锁；所述第三日志写入成功后，若发生节点故障，在恢复过程中，根据所述第三日志信息继续完成索引的创建过程，包括：针对本次创建表索引事务，写入第三日志，所述第三日志类型为CommitLog，标识事务完成了持久化存储层的操作；

若发生故障，日志中存在CommitLog记录，将节点的状态恢复到CleanLog之前的状态；

若协调节点发生故障，在本地创建旧的表结构信息和新的表结构信息，然后，创建新的事务状态机，事务重新从释放全局写锁阶段重新执行；

若参与节点发生故障，本地创建新的表结构信息。

上述方案中，可选地，所述释放全局写锁具体为：

协调节点发起释放锁请求，各个参与节点释放本地表的表级别写锁；

提交新建的表结构信息作为表结构信息，在持有全局写锁的情况下，各节点进行表结构的转换。

上述方案中，可选地，所述写入第四日志，所述第四日志类型为CleanLog，标识成功地创建了表索引，包括：

日志中存在CleanLog记录，故障发生在写CleanLog之后，本次创建表索引事务已经成功完成，没有故障发生，协调节点和参与节点都不需要作任何操作；

日志层根据这条日志，删除日志中关于创建表索引事务的记录。

第二方面，一种分布式系统中在线创建表索引系统，其特征在于，所述系统包括：分布式缓存层、持久化存储层以及日志层；其中，

所述分布式缓存层用于缓存热数据和新写入的数据；

所述持久化存储层用于存储基线数据；

所述分布式缓存层中的冷数据会异步地写入到持久化存储层；所述分布式缓存层和持久化存储层通过检查点服务进行数据的同步和统一；

所述日志层负责持久化事务的请求信息。

本发明至少具有以下有益效果：

本发明基于对现有技术问题的进一步分析和研究，认识到现有的分布式系统中创建表索引可能造成的状态不一致的问题。本申请通过获取全局写意向锁，协调节点向所有参与节点发起表级别的加锁请求，待所有节点返回加锁结果，并在所有节点都加锁成功后，协调节点执行下一步操作，若发生加锁冲突，则终止本次创建索引的操作；获取全局写锁，执行锁升级操作，在获取到全局写意向锁之后，协调节点向所有的参与节点发起表级别的加写锁请求，在获取到全局写锁之后，协调节点通过各节点返回的加锁信息，计算事务的提交时间戳；将新的表索引信息和新的表结构版本号写入第一日志进行持久化，定义所述第一日志类型为PrepareLog；所述第一日志写入成功后，若发生节点故障，在恢复过程中，根据所述第一日志信息继续完成索引的创建过程；降级全局写锁，创建持久化存储，并更新表中旧数据的索引值；写入第二日志，所述第二日志类型为PrepareIndexLog，并升级全局写锁；所述第二日志写入成功后，若发生节点故障，在恢复过程中，根据所述第二日志信息继续完成索引的创建过程；写入第三日志，所述第三日志类型为CommitLog，并释放全局写锁；所述第三日志写入成功后，若发生节点故障，在恢复过程中，根据所述第三日志信息继续完成索引的创建过程；释放全局写锁，写第四日志，所述第四日志类型为CleanLog，标识成功地创建了表索引。基于分布式全局锁的机制，在不阻塞并发的读写事务(DML)的情况下在线创建表的索引，以及基于日志，实现故障恢复操作，保证在分布式系统中，更新表索引事务的持久化和一致性。同时，基于重试机制，实现事务的异常处理过程。

附图说明

图1为本发明一个实施例提供的分布式系统中在线创建表索引方法的流程示意图；

图2为本发明一个实施例提供的分布式系统中在线创建表索引方法的系统中基本数据流向图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的分布式系统中在线创建表索引方法，如图1所示，包括以下步骤：

获取全局写意向锁，协调节点向所有参与节点发起表级别的加锁请求，待所有节点返回加锁结果，并在所有节点都加锁成功后，协调节点执行下一步操作，若发生加锁冲突，则终止本次创建索引的操作；

获取全局写锁，执行锁升级操作，在获取到全局写意向锁之后，协调节点向所有的参与节点发起表级别的加写锁请求，在获取到全局写锁之后，协调节点通过各节点返回的加锁信息，计算事务的提交时间戳；

将新的表索引信息和新的表结构版本号写入第一日志进行持久化，定义所述第一日志类型为PrepareLog；所述第一日志写入成功后，若发生节点故障，在恢复过程中，根据所述第一日志信息继续完成索引的创建过程；

降级全局写锁，创建持久化存储，并更新表中旧数据的索引值；

写入第二日志，所述第二日志类型为PrepareIndexLog，并升级为全局写锁；所述第二日志写入成功后，若发生节点故障，在恢复过程中，根据所述第二日志信息继续完成索引的创建过程；

写入第三日志，所述第三日志类型为CommitLog，并释放全局写锁；所述第三日志写入成功后，若发生节点故障，在恢复过程中，根据所述第三日志信息继续完成索引的创建过程；

写第四日志，所述第四日志类型为CleanLog，标识成功地创建了表索引。

在一个实施例中，所述获取全局写意向锁，协调节点向所有参与节点发起表级别的加锁请求，包括：

协调节点向所有参与节点发起表的表级别的加写意向锁请求，待各节点返回加写意向锁结果；所有节点都加锁成功后，协调节点执行下一步操作；

若发生加锁冲突，则终止本次创建索引的操作；

获取全局写锁，执行锁升级操作，在获取到全局写意向锁之后，协调节点向所有的参与节点发起表级别的加写锁请求，在获取到全局写锁之后，协调节点通过各节点返回的加锁信息，计算事务的提交时间戳，具体为：在获取到全局写锁之后，协调节点通过各节点返回的加锁信息，计算目标事务的提交时间戳，所述时间戳的计算采用下述的公式：

Ts＝max(allnode’scommit_ts+1，allnode’sLast_read_ts+1)

其中，所述commit_ts表示所述表结构上次更新的提交时间戳；

Last_read_ts表示最近一次读取表结构信息的ts，发生在对所述表的读写操作过程中。

在一个实施例中，所述协调节点为发起创建索引事务的节点；

所述参与节点为参与创建索引事务的节点，接收协调节点发送的消息并进行处理，包括在本节点上获取锁，在本地创建新的表结构schema信息，特殊地，协调节点也是参与节点。

在一个实施例中，所述第一日志写入成功后，若发生节点故障，在恢复过程中，根据所述第一日志信息继续完成索引的创建过程，包括：

所述第一日志写入成功后，若发生节点故障，根据日志进行事务的恢复操作；日志中存在所述PrepareLog记录，在本地中加表级别的写意向锁，同时，

若协调节点发生故障，在故障重启时，创建新的事务状态机，重新从降级全局写锁阶段重新执行；

若参与节点发生故障，在故障重启时，将节点的状态恢复到所述PrepareIndexLog记录之前的状态；恢复节点上表级别的写意向锁，同时创建本地的旧的表结构信息和新的表结构DitrySchema信息。

在一个实施例中，所述降级全局写锁，创建持久化存储，并更新表中旧数据的索引值，具体为：协调节点发起锁降级请求，将所有节点中的写锁降级为写意向锁；同时，所有节点在本地创建新的表结构DirtySchema；

所述协调节点在持久化存储层创建新的索引的持久化存储；

在所有节点中同时将分布式缓存层中的数据刷新到持久化存储层；

所述协调节点从持久化存储层中读取旧数据，将所述旧数据生成新的索引数据，并写入分布式缓存层；所述旧数据生成索引数据后，对分布式缓存层中的索引数据进行强制的同步操作，刷新到持久化存储层中的索引表中，同时将旧数据生成的索引数据从分布式缓存层中踢出。

在一个实施例中，所述写入第二日志，所述第二日志类型为PrepareIndexLog，并升级全局写锁；所述第二日志写入成功后，若发生节点故障，在恢复过程中，根据所述第二日志信息继续完成索引的创建过程，包括：

写入第二日志，所述第二日志类型为所述PrepareIndexLog，标识创建表索引事务完成了旧数据的索引值的更新操作；

若系统发生故障，日志中存在所述PrepareIndexLog记录，则故障节点将节点的状态恢复到CommitLog之前状态；

若协调节点发生故障，恢复本地表级别的写锁，同时在本地创建新的表结构DitrySchema信息；创建新的事务状态机，所述事务重新从升级全局写锁阶段重新执行；

若参与节点发生故障，需要恢复本地表级别的写锁，同时在本地创建旧的表结构信息和新的表结构DitrySchema信息。

在一个实施例中，所述写入第三日志，所述第三日志类型为CommitLog，并释放全局写锁；所述第三日志写入成功后，若发生节点故障，在恢复过程中，根据所述第三日志信息继续完成索引的创建过程，包括：针对本次创建表索引事务，写入第三日志，所述第三日志类型为CommitLog，标识事务完成了持久化存储层的操作；

若发生故障，日志中存在CommitLog记录，将节点的状态恢复到CleanLog之前的状态；

若协调节点发生故障，在本地创建旧的表结构信息和新的表结构信息，然后，创建新的事务状态机，事务重新从释放全局写锁阶段重新执行；

若参与节点发生故障，本地创建新的表结构信息。

在一个实施例中，所述释放全局写锁具体为：

协调节点发起释放锁请求，各个参与节点释放本地表的表级别写锁；

提交新建的表结构信息作为表结构信息，在持有全局写锁的情况下，各节点进行表结构的转换。

在一个实施例中，所述写入第四日志，所述第四日志类型为CleanLog，标识成功地创建了表索引，包括：

日志中存在CleanLog记录，故障发生在写CleanLog之后，本次创建表索引事务已经成功完成，没有故障发生，协调节点和参与节点都不需要作任何操作；

日志层根据这条日志，删除日志中关于创建表索引事务的记录。上述分布式系统中在线创建表索引方法中，提出了分布式系统中，基于分布式全局锁的机制，在不阻塞并发的读写事务(DML)的情况下在线创建表的索引，以及基于日志，实现故障恢复操作，保证在分布式系统中，更新表索引事务的持久化和一致性。同时，基于重试机制，实现事务的异常处理过程。

在一个实施例中，如图2所示，系统由分布式缓存层，持久化存储层，以及日志层构成。其中，分布式缓存层缓存的是热数据和新写入的数据；持久化存储层存储的是基线数据；分布式缓存层中的数据会异步地写入到持久化存储层；分布式缓存层和持久化存储层通过检查点(checkpointer)服务进行数据的同步和统一；日志层负责持久化事务的请求信息。保证在系统发生故障时，事务可以被正确地恢复或者回滚。

本方案中，在创建表索引过程中，不会阻塞并发的读写操作。为了更好地说明该过程对表中数据的处理以及对并发DML操作的影响，针对数据流在系统中的流向进行简要地描述，服务端接收到客户端的请求后，会启动一个事务状态机，更新的数据首先会被写入日志，保证系统故障时，可以从日志中恢复事务的数据。然后，数据被上传到分布式缓存层。上传成功，事务进行提交，并通知客户端读写操作完成。另外，检查点(checkpointer)服务会异步地将分布式缓存中的数据刷新到持久化存储层。

在一个实施例中，在创建表索引的过程中，主要涉及到两方面的工作：一个是创建新的表结构(schema)信息。一个是将表中旧数据生成对应的新的索引数据。本方案中，针对这些工作，涉及到如下几方面的术语：

锁类型：本方案中，应用到两种类型的锁，全局写意向锁(WI)和全局写锁(WL)。其中，全局写意向锁用于阻塞对同一张表并发的表结构更改操作(DDL)。全局写锁用于阻塞对这张表的并发的读写操作(DML)。

系统节点类型：在该分布式系统中，各个节点处于同等地位，也就是说，可以在系统中的任何节点上发起创建表索引的请求。在创建表索引过程中，根据各节点所承担的任务的不同，可以将系统中的节点分为两种类型，

协调节点：发起创建索引事务的节点。

参与节点：参与创建索引事务的节点，接收协调节点发送的消息并进行处理，包括在本节点上获取锁，在本地创建新的表结构(schema)信息等。特殊地，协调节点也是参与节点。

表中数据类型：表中的数据，根据写入时间相对于新的表结构(schema)的版本号的大小，可以分为两类：

旧数据：写入时间小于新的表结构的版本号。

新数据：写入时间大于新的表结构的版本号。

在一个实施例中，正常流程包括以下步骤：

获取全局写意向锁：协调节点向所有参与节点发起该表的表级别的加锁请求，然后等待各节点返回加锁结果。只有在所有节点都加锁成功后，协调节点才会执行下一步操作。在这个过程中，如果发生加锁冲突，说明已经有事务正在对该表进行更新表结构的操作，则终止本次创建索引的操作。

获取全局写锁：执行锁升级操作。在获取到全局写意向锁之后，协调节点向所有的参与节点发起表级别的加写锁请求。在获取到全局写锁之后，协调节点通过各节点返回的加锁信息，计算该事务的提交时间戳(commit timestamp)。该时间戳的计算采用下述的公式：

Ts＝max(allnode’scommit_ts+1,allnode’slast_read_ts+1)

其中，commit_ts表示该表结构(schema)上次更新的提交时间戳。Last_read_ts表示最近一次读取该表结构(schema)信息的ts，其发生在对该表的读写操作过程中。

上述公式，确保了即使在系统中各节点时钟不同步的情况下，也可以得到正确的，具有顺序性的时间戳。

在请求全局写锁的过程中，如果发生了加锁冲突，则会阻塞该事务，直到可以获取到写锁。

这个时间戳具有两个作用，一个是作为新的表结构(schema)的版本号。一个是作为一个时间节点，来区分发生在该表上的读写操作(DML)。对于小于该时间戳的事务，其操作已经提交，结果已经更新到表中。对于大于该时间戳的事务，其在更新过程中，不仅要更新已有的索引信息，还要更新新建的索引数据，也就是所谓的“双写”操作。这样，就保证了在不阻塞并发读写操作(DML)的同时，实现对该表的创建索引的操作。

写入日志：将新的表索引信息和新的表结构(schema)版本号写入日志系统以进行持久化。定义该日志类型为PrepareLog。

该日志写入成功后，如果系统发生节点故障，在恢复过程中，可以根据该日志信息继续完成索引的创建过程。这就保证了即使发生系统故障，也可以完成索引的创建。

降级全局写锁：协调节点发起锁降级请求，将所有节点中的写锁降级为写意向锁。同时，所有节点在本地创建新的表结构(schema)，这里称该表结构为DirtySchema。在持有全局写锁的情况下，系统中各个节点创建了新的表结构，这种机制就保证了系统的状态一致性。

在这个时间点后，并发的读写操作(DML)可以正常地执行，不仅需要将数据写入到已有的索引表中，同时，还需要根据新的表结构信息写入到新建的索引表中。

创建持久化存储：协调节点在持久化存储层创建新的索引的持久化存储。

更新表中旧数据的索引值：在该系统中，旧数据会存在于两个位置，一个是分布式缓存层，也就是该表中的热数据以及在创建索引之前新写入但是还没有同步到持久化存储层的数据。一个是持久化存储层，也就是表中的基线数据。

为了避免数据的重复操作，先将分布式缓存层和持久化存储层进行一个同步操作，也就是将分布式缓存层中的数据刷新到持久化存储层，从而保证持久化存储层包括全量的旧数据，同时也简化了数据的处理流程。该操作会在系统中的所有节点中同时进行。

在同步完旧数据后，协调节点从持久化存储层中读取旧数据，然后将其生成新的索引数据，并写入分布式缓存层。这里，如果并发的读写事务在执行“双写”操作的过程中已经写入了相同键值的索引数据，则直接将这条旧数据生成的索引数据丢弃，保证了索引数据的正确性。

对旧数据生成索引数据后，对缓存层中的索引数据进行强制的同步操作，将其同步刷新到持久化存储层中的索引表中，同时将旧数据生成的索引数据从分布式缓存层中踢出。该操作保证了分布式缓存层中的数据要新于持久化存储层中的数据(也就是分布式缓存层中的数据的提交时间戳大于持久化存储层中该数据的提交时间戳)，进而保证后续的事务不会读取到错误的索引数据。

写入日志：针对本次创建表索引操作，写入一条日志，定义该日志类型为PrepareIndexLog，标识该创建表索引事务完成了旧数据的索引值的更新操作。如果系统发生故障，各节点可以从该日志处进行恢复。

升级全局写锁：协调节点发起锁升级请求，将所有节点中的写意向锁升级为写锁。同样，如果发生加锁冲突，会阻塞该事务，直到可以获取到该写锁。

获取到全局写锁后，会阻塞针对该表的并发的读写(DML)操作，但是阻塞的时间非常短。该全局写锁保证了系统中各个节点处于一个一致性的状态中。

写入日志：针对本次创建表索引事务，写入一条日志，定义该日志类型为CommitLog，标识该事务完成了持久化存储层的操作。如果发生故障，各节点可以根据该日志，恢复到对应的状态。

释放全局写锁：协调节点发起释放锁请求，各个参与节点释放本地该表的表级别写锁。同时，提交新建的表结构(DirtySchema)信息作为表结构信息，使得新建的表结构(schema)信息对外可见。

同样，在持有全局写锁的情况下，系统各节点进行表结构的转换，保证了系统表结构对外的一致性。

这样，后续的读写事务就会读取到新的表结构信息，进而就会根据新的表结构信息进行相应的操作。

写入日志：针对本次创建表索引事务，写入一条日志，定义该日志类型为CleanLog，标识成功地创建了表索引。后续，日志层会根据这条日志，删除日志中关于该创建表索引事务的记录。

在一个实施例中，恢复流程包括：该系统中的日志层，保证了系统在发生节点故障时，会根据日志进行事务的恢复操作。节点根据不同的日志信息，重做相应的操作，实现故障之后节点状态的恢复。这里的状态，包括锁的状态以及本地表结构(schema)信息。针对不同的日志类型，可以分为下述几种情况：

在一个实施例中，没有日志记录：如果协调节点发生故障，在故障重启时，由于没有日志记录，则认为没有发生过创建表索引操作。参与节点中有可能会残留孤儿锁。但是，系统中的孤儿锁检测机制会自动释放该孤儿锁。

如果参与节点发生故障，在故障重启时，由于没有日志记录，不需要进行额外的操作。系统中的重试机制会使得协调节点重新发送相应的请求，保证事务会继续进行。

在一个实施例中，日志中存在PrepareLog记录：说明故障发生时，系统中至少持有的是全局写意向锁，换句话说，系统需要恢复到持有全局写意向锁的状态。因此，故障节点在恢复过程，需要直接在本地中加表级别的写意向锁。同时，

如果协调节点发生故障，在故障重启时，需要创建新的事务状态机，然后重新从降级全局写锁阶段重新执行。

如果参与节点发生故障，在故障重启时，只需要将节点的状态恢复到PrepareIndexLog记录之前的状态。也就是，恢复该节点上表级别的写意向锁，同时创建本地的旧的表结构信息和新的表结构(DitrySchema)信息。

说明：由于操作的幂等性，在故障重启恢复的过程中，即使多次执行了同一个操作，其最终的结果和状态是保持不变的。

在一个实施例中，日志中存在PrepareIndexLog记录，说明故障发生在写入PrepareIndexLog和写入CommitLog之间的某一个阶段。则，故障节点需要将该节点的状态恢复到CommitLog之前状态。

如果协调节点发生故障，首先恢复本地表级别的写锁，同时在本地创建新的表结构(DitrySchema)信息。然后，创建新的事务状态机，该事务重新从升级全局写锁阶段重新执行。

如果参与节点发生故障，需要恢复本地表级别的写锁，同时在本地创建旧的表结构信息和新的表结构(DitrySchema)信息。

在一个实施例中，日志中存在CommitLog记录，说明故障发生在写入CommitLog和写入CleanLog之间的某一个阶段。所以，故障节点需要将该节点的状态恢复到CleanLog之前的状态。

如果协调节点发生故障，首先在本地创建旧的表结构信息和新的表结构(DirtySchema)信息。然后，创建新的事务状态机，该事务重新从释放全局写锁阶段重新执行。

如果参与节点发生故障，只需要本地创建新的表结构信息。

在一个实施例中，日志中存在CleanLog记录，说明故障发生在写CleanLog之后，这时候就认为本次创建表索引事务已经成功完成，没有故障发生。协调节点和参与节点都不需要作任何操作。

应理解的是，虽然图1的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，提供了一种分布式系统中在线创建表索引系统，包括以下程序模块：一种分布式系统中在线创建表索引系统，其特征在于，所述系统包括：分布式缓存层、持久化存储层以及日志层；其中，

所述分布式缓存层用于缓存热数据和新写入的数据；

所述持久化存储层用于存储基线数据；

所述分布式缓存层中的数据会异步地写入到持久化存储层；所述分布式缓存层和持久化存储层通过检查点服务进行数据的同步和统一；

所述日志层负责持久化事务的请求信息。

关于分布式系统中在线创建表索引系统的具体限定可以参见上文中对于分布式系统中在线创建表索引方法的限定，在此不再赘述。上述分布式系统中在线创建表索引系统中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种分布式系统中在线创建表索引方法，其特征在于，所述方法包括：

获取全局写意向锁，协调节点向所有参与节点发起表级别的加锁请求，待所有节点返回加锁结果，并在所有节点都加锁成功后，协调节点执行下一步操作，若发生加锁冲突，则终止本次创建索引的操作；

获取全局写锁，执行锁升级操作，在获取到全局写意向锁之后，协调节点向所有的参与节点发起表级别的加写锁请求，在获取到全局写锁之后，协调节点通过各节点返回的加锁信息，计算事务的提交时间戳；

将新的表索引信息和新的表结构版本号写入第一日志进行持久化，定义所述第一日志类型为PrepareLog；所述第一日志写入成功后，若发生节点故障，在恢复过程中，根据所述第一日志信息继续完成索引的创建过程；

降级全局写锁，创建持久化存储，并更新表中旧数据的索引值；

写入第二日志，所述第二日志类型为PrepareIndexLog，并升级为全局写锁；所述第二日志写入成功后，若发生节点故障，在恢复过程中，根据所述第二日志信息继续完成索引的创建过程；

写入第三日志，所述第三日志类型为CommitLog，并释放全局写锁；所述第三日志写入成功后，若发生节点故障，在恢复过程中，根据所述第三日志信息继续完成索引的创建过程；

写第四日志，所述第四日志类型为CleanLog，标识成功地创建了表索引。

2.根据权利要求1所述的方法，其特征在于，所述获取全局写意向锁，协调节点向所有参与节点发起表级别的加锁请求，包括：

协调节点向所有参与节点发起表的表级别的加写意向锁请求，待各节点返回加写意向锁结果；所有节点都加锁成功后，协调节点执行下一步操作；

若发生加锁冲突，则终止本次创建索引的操作；

获取全局写锁，执行锁升级操作，在获取到全局写意向锁之后，协调节点向所有的参与节点发起表级别的加写锁请求，在获取到全局写锁之后，协调节点通过各节点返回的加锁信息，计算事务的提交时间戳，具体为：在获取到全局写锁之后，协调节点通过各节点返回的加锁信息，计算目标事务的提交时间戳，所述时间戳的计算采用下述的公式：

Ts＝max(allnode’scommit_ts+1，allnode’sLast_read_ts+1)其中，所述commit_ts表示所述表结构上次更新的提交时间戳；

Last_read_ts表示最近一次读取表结构信息的ts，发生在对所述表的读写操作过程中。

3.根据权利要求2所述的方法，其特征在于，所述协调节点为发起创建索引事务的节点；

所述参与节点为参与创建索引事务的节点，接收协调节点发送的消息并进行处理，包括在本节点上获取锁，在本地创建新的表结构schema信息，特殊地，协调节点也是参与节点。

4.根据权利要求1所述的方法，其特征在于，所述第一日志写入成功后，若发生节点故障，在恢复过程中，根据所述第一日志信息继续完成索引的创建过程，包括：

所述第一日志写入成功后，若发生节点故障，根据日志进行事务的恢复操作；日志中存在所述PrepareLog记录，在本地中加表级别的写意向锁，同时，

若协调节点发生故障，在故障重启时，创建新的事务状态机，重新从降级全局写锁阶段重新执行；

若参与节点发生故障，在故障重启时，将节点的状态恢复到所述PrepareIndexLog记录之前的状态；恢复节点上表级别的写意向锁，同时创建本地的旧的表结构信息和新的表结构DitrySchema信息。

5.根据权利要求1所述的方法，其特征在于，所述降级全局写锁，创建持久化存储，并更新表中旧数据的索引值，具体为：协调节点发起锁降级请求，将所有节点中的写锁降级为写意向锁；同时，所有节点在本地创建新的表结构DirtySchema；

所述协调节点在持久化存储层创建新的索引的持久化存储；

在所有节点中同时将分布式缓存层中的数据刷新到持久化存储层；

所述协调节点从持久化存储层中读取旧数据，将所述旧数据生成新的索引数据，并写入分布式缓存层；所述旧数据生成索引数据后，对缓存层中的索引数据进行强制的同步操作，刷新到持久化存储层中的索引表中，同时将旧数据生成的索引数据从分布式缓存层中踢出。

6.根据权利要求1所述的方法，其特征在于，所述写入第二日志，所述第二日志类型为PrepareIndexLog，并升级全局写锁；所述第二日志写入成功后，若发生节点故障，在恢复过程中，根据所述第二日志信息继续完成索引的创建过程，包括：

写入第二日志，所述第二日志类型为所述PrepareIndexLog，标识创建表索引事务完成了旧数据的索引值的更新操作；

若系统发生故障，日志中存在所述PrepareIndexLog记录，则故障节点将节点的状态恢复到CommitLog之前状态；

若协调节点发生故障，恢复本地表级别的写锁，同时在本地创建新的表结构DitrySchema信息；创建新的事务状态机，所述事务重新从升级全局写锁阶段重新执行；

若参与节点发生故障，需要恢复本地表级别的写锁，同时在本地创建旧的表结构信息和新的表结构DitrySchema信息。

7.根据权利要求1所述的方法，其特征在于，所述写入第三日志，所述第三日志类型为CommitLog，并释放全局写锁；所述第三日志写入成功后，若发生节点故障，在恢复过程中，根据所述第三日志信息继续完成索引的创建过程，包括：针对本次创建表索引事务，写入第三日志，所述第三日志类型为CommitLog，标识事务完成了持久化存储层的操作；

若发生故障，日志中存在CommitLog记录，将节点的状态恢复到CleanLog之前的状态；

若协调节点发生故障，在本地创建旧的表结构信息和新的表结构信息，然后，创建新的事务状态机，事务重新从释放全局写锁阶段重新执行；

若参与节点发生故障，本地创建新的表结构信息。

8.根据权利要求1所述的方法，其特征在于，所述释放全局写锁具体为：

协调节点发起释放锁请求，各个参与节点释放本地表的表级别写锁；

提交新建的表结构信息作为表结构信息，在持有全局写锁的情况下，各节点进行表结构的转换。

9.根据权利要求1所述的方法，其特征在于，所述写入第四日志，所述第四日志类型为CleanLog，标识成功地创建了表索引，包括：

日志中存在CleanLog记录，故障发生在写CleanLog之后，本次创建表索引事务已经成功完成，没有故障发生，协调节点和参与节点都不需要作任何操作；

日志层根据这条日志，删除日志中关于创建表索引事务的记录。

10.一种分布式系统中在线创建表索引系统，其特征在于，所述系统包括：分布式缓存层、持久化存储层以及日志层；其中，

所述分布式缓存层用于缓存热数据和新写入的数据；

所述持久化存储层用于存储基线数据；

所述分布式缓存层中的数据会异步地写入到持久化存储层；所述分布式缓存层和持久化存储层通过检查点服务进行数据的同步和统一；

所述日志层负责持久化事务的请求信息。