CN111400331B - 一种基于TiDB数据库的处理方法及装置 - Google Patents

Abstract

本申请公开了一种基于TiDB数据库的处理方法及装置，方法包括：接收数据操作请求，所述数据操作请求用于指示对第一数据进行第一操作；依据所述数据操作请求对所述第一数据执行所述第一操作；确定所述第一操作是否执行失败；若是，在应用层面进行所述第一操作的重试。所述基于TiDB数据库的处理方法及装置，在数据操作失败后，可以在应用层面重试第一操作，从而增加了第一操作成功执行的概率，降低了高并发情况下使用TiDB数据库的热点数据更新失败的可能；且由于第一操作的重试在应用层面进行，因此整个过程对于用户是无感知的，从而实现了在用户无感知的情况下数据操作成功率的提升，优化了用户体验。

Description

一种基于TiDB数据库的处理方法及装置

技术领域

本发明涉及数据处理技术，更具体的说，是涉及一种基于TiDB数据库的处理方法及装置。

背景技术

TiDB是一款定位于在线事务处理/在线分析处理的融合型NewSql开源数据库，其中的存储的数据可称为TiDB数据。

TiDB数据库目前已应用在一些金融单位，如银行，但由于一些版本的TiDB数据库仅支持乐观锁(乐观锁在进行数据修改时，认为不存在其它修改该数据的操作，只是在操作的时候判断此期间是否存在别人是否修改了数据，如果别人修改了数据，则乐观锁放弃此操作，执行失败，否则执行操作)，而不支持悲观锁(悲观锁在操作数据时比较悲观，认为别人会同时修改数据，因此操作数据时直接把数据锁住，直到操作完成后才会释放锁，上锁期间其他人不能修改数据)，因此，当TiDB数据库使用了select for update的SQL语句时，TiDB数据库不会重试提交时遇到冲突的事务；在提交时如果检查到冲突(数据被修改)，那么事务会被回滚，造成提交失败。

由于银行系统的数据变化频率非常高，因此同一时间段内对同一数据进行操作的事件出现的概率也很大；而TiDB数据库仅支持乐观锁，因此可能导致许多数据操作的事务在执行时产生冲突，造成事务执行失败成为大概率事件，影响用户的使用体验。

发明内容

有鉴于此，本发明提供如下技术方案：

一种基于TiDB数据库的处理方法，包括：

接收数据操作请求，所述数据操作请求用于指示对第一数据进行第一操作；

依据所述数据操作请求对所述第一数据执行所述第一操作；

确定所述第一操作是否执行失败；

若是，在应用层面进行所述第一操作的重试。

可选的，所述确定所述第一操作是否执行失败，包括：

采用应用层上的Stria流执行引擎扫描检测所述第一操作是否执行失败。

可选的，所述在应用层面进行所述第一操作的重试前，还包括：

确定用于执行所述第一操作的接口中是否包含重试标记；

若存在，执行所述在应用层面进行所述第一操作的重试的步骤。

可选的，所述在应用层面进行所述第一操作的重试，包括：

在所述第一操作执行失败的情况下，在应用层面反复进行所述第一操作的重试的步骤，直至所述第一操作成功。

可选的，还包括：

在检测到所述第一操作的重试次数达到预设的最大重试次数的情况下，则返回操作失败结果，并进行针对所述数据操作请求的事务的回滚。

可选的，还包括：

依据所述第一操作的重试次数确定其执行优先级别。

可选的，所述依据所述第一操作的重试次数确定其执行优先级别，包括：

所述在应用层面进行所述第一操作的重试的过程中，若所述第一操作的重试次数越多，则将其执行优先级设置的越高。

可选的，还包括：

在应用层面进行所述第一操作的重试的过程中，依据所述第一操作的重试次数和所述数据操作请求中的操作类别确定其执行优先级别。

一种基于TiDB数据库的处理装置，包括：

请求接收模块，用于接收数据操作请求，所述数据操作请求用于指示对第一数据进行第一操作；

操作执行模块，用于依据所述数据操作请求对所述第一操作执行所述第一操作；

操作判断模块，用于确定所述第一操作是否执行失败；

重试控制模块，用于在所述操作判断模块的判断结果为是的情况下，在应用层面进行所述第一操作的重试。

可选的，所述操作判断模块具体用于：

采用应用层上的Stria流执行引擎扫描检测所述第一操作是否执行失败。

经由上述的技术方案可知，与现有技术相比，本发明实施例公开了一种基于TiDB数据库的处理方法及装置，方法包括：接收数据操作请求，所述数据操作请求用于指示对第一数据进行第一操作；依据所述数据操作请求对所述第一操作执行所述第一操作；确定所述第一操作是否执行失败；若是，在应用层面进行所述第一操作的重试。所述基于TiDB数据库的处理方法及装置，在数据操作失败后，可以在应用层面重试第一操作，从而增加了第一操作成功执行的概率，降低了高并发情况下使用TiDB数据库的热点数据更新失败的可能；且由于第一操作的重试在应用层面进行，因此整个过程对于用户是无感知的，从而实现了在用户无感知的情况下数据操作成功率的提升，优化了用户体验。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本发明实施例公开的一种基于TiDB数据库的处理方法的流程图；

图2为本发明实施例公开的第二种基于TiDB数据库的处理方法的流程图；

图3为本发明实施例公开的第三种基于TiDB数据库的处理方法的流程图；

图4为本发明实施例公开的一种基于TiDB数据库的处理装置的结构示意图；

图5为本发明实施例公开的第二种基于TiDB数据库的处理装置的结构示意图；

图6为本发明实施例公开的第三种基于TiDB数据库的处理装置的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1为本发明实施例公开的一种基于TiDB数据库的处理方法的流程图，参见图1所示，基于TiDB数据库的处理方法可以包括：

步骤101：接收数据操作请求，所述数据操作请求用于指示对第一数据进行第一操作。

其中，所述数据操作请求为针对TiDB数据库中的TiDB数据的操作请求，所述数据操作请求中包含需要进行操作的数据，即上述第一数据，第一数据为TiDB数据；还包括针对第一数据需要执行的操作，即上述第一操作。当然，本申请实施例中，并不对数据操作请求中包含的内容做固定限制，除了第一数据和第一操作，数据操作请求中还可以包括其他与数据操作有关的任何内容。

步骤102：依据所述数据操作请求对所述第一操作执行所述第一操作。

接收到所述数据操作请求后，在数据操作请求合法的情况下，按照系统正常逻辑执行对应的操作，即对上述第一数据执行第一操作。

步骤103：确定所述第一操作是否执行失败，若是，进入步骤104。

执行第一操作的结果有两种，一种是执行成功，一种是执行失败。在执行成功的情况下(对应上述确定结果为否的情况)，系统可按照正常的处理逻辑持续进行后续相关操作；在执行失败的情况下(对应上述确定结果为是的情况)，可依据本申请后续公开的内容进行处理，以提供第一操作能够被成功执行的可能。

步骤104：在应用层面进行所述第一操作的重试。

应用层面的相关操作对于前端用户来说是不可见的，因此在应用层面进行第一操作的重试的过程，对于用户是无感知的。即用户在前端触发提交了一次数据操作请求，如修改配置信息的请求，在TiDB数据库应用层接收到这个修改配置信息的请求后，控制开始进行配置信息的修改，若检测到本次修改没有成功，则可以继续在应用层面进行配置信息修改的重试，继续尝试完成配置信息的修改。

需要强调说明的是，本申请实施例在应用层面采取重试的机制，这里的重试不是类似于用户重新发送请求的重试。如在银行核心系统中，用户重新发送一次请求在系统里属于两笔不同的交易，也会对系统资源造成不必要的浪费，同时也增加了业务出错的风险。因此在本申请实施例中，才会直接在应用层面对第一操作进行重试，即避免了用户层到应用层请求重发的资源开销，也省去了用户反复操作的繁琐。由于是应用层面的重试，对于客户来说仍旧是一次交易(即用户只操作一次)，不会有请求重试的感知。

本实施例中，所述基于TiDB数据库的处理方法，在数据操作失败后，可以在应用层面重试第一操作，从而增加了第一操作成功执行的概率，降低了高并发情况下使用TiDB数据库的热点数据更新失败的可能；且由于第一操作的重试在应用层面进行，因此整个过程对于用户是无感知的，从而实现了在用户无感知的情况下数据操作成功率的提升，优化了用户体验。

上述实施例中，所述确定所述第一操作是否执行失败，可以包括：采用应用层上的Stria流执行引擎扫描检测所述第一操作是否执行失败。

本实施例中，银行的核心系统应用本身已有统一的Stria流执行引擎(每个引擎本身是一个事务)，具体实现中，可以在前述Stria流执行引擎的层面对第一操作是否执行失败的情况进行扫描，当发现由于TiDB数据库的乐观锁机制造成的第一操作执行失败的情况下，可以控制第一操作重试。

图2为本发明实施例公开的第二种基于TiDB数据库的处理方法的流程图，参见图2所示，基于TiDB数据库的处理方法可以包括：

步骤201：接收数据操作请求，所述数据操作请求用于指示对第一数据进行第一操作。

步骤202：依据所述数据操作请求对所述第一操作执行所述第一操作。

步骤203：确定所述第一操作是否执行失败，若是，进入步骤204。

步骤204：确定用于执行所述第一操作的接口中是否包含重试标记，若存在，进入步骤205。

在一个实现中，并不是所有执行失败的操作都控制进行重试操作，而是可以根据执行第一操作的接口中是否包含重试标记来确定是否继续执行第一操作的重试。具体实现中，可以根据第一操作的执行接口的接口类型或其执行的第一操作的操作类型对接口信息进行配置，根据需要，对在执行失败后需要进行重试的操作或借口，为其配置重试标记，而对于在执行失败后可能需要其他一些内容的确认的操作或借口，则可以不为其配置重试标记。

步骤205：在应用层面进行所述第一操作的重试。

本实现中，后续在检测到第一操作执行失败后，可以进一步确定执行第一操作的接口中是否配置有重试标记，若存在，再继续进行第一操作的重试。

上述实施例中，所述在应用层面进行所述第一操作的重试，可以包括：在所述第一操作执行失败的情况下，在应用层面反复进行所述第一操作的重试的步骤，直至所述第一操作成功。

在实际应用中，由于请求高并发或其他一些情况，可能导致第一操作执行失败后，重试的结果依然是执行失败，系统继续检测到执行失败，然后继续重试第一操作，该过程可反复执行，即只要检测到第一操作没有执行成功，可反复多次进行第一操作的重试，直至第一操作执行成功的事件被检测到。

基于上述内容，基于TiDB数据库的处理方法还可以包括：在检测到所述第一操作的重试次数达到预设的最大重试次数的情况下，则返回操作失败结果，并进行针对所述数据操作请求的事务的回滚。

本实现中，在执行第一操作的接口中还可以预先配置最大重试次数，使得一直执行失败的第一操作不会被无限制的一直重试执行，进而影响到其他请求的正常处理。所述最大重试次数不宜设置的过大，例如可以为10次。

图3为本发明实施例公开的第三种基于TiDB数据库的处理方法的流程图，如图3所示，基于TiDB数据库的处理方法可以包括：

步骤301：接收数据操作请求，所述数据操作请求用于指示对第一数据进行第一操作。

步骤302：依据所述数据操作请求对所述第一操作执行所述第一操作。

步骤303：确定所述第一操作是否执行失败，若是，进入步骤304。

步骤304：依据所述第一操作的重试次数确定其执行优先级别。

具体的，所述依据所述第一操作的重试次数确定其执行优先级别，可以包括：所述在应用层面进行所述第一操作的重试的过程中，若所述第一操作的重试次数越多，则将其执行优先级设置的越高。

例如，待执行操作队列中包括5个待处理请求，其中4个为第一次申请执行的操作，1个为已经重试过2次，共执行了3次，但3次都执行失败的第一操作，则为了提升第一操作执行成功的可能，可以将第一操作的优先级配置为高，其他4个第一次申请执行的操作的优先级配置为一般，则后续系统处理过程中，会优先执行前述第一操作，以提升其执行成功的可能性。

步骤305：依据所述执行优先级别，在应用层面进行所述第一操作的重试。

由此可见，本申请实施例中，对于第一操作的重试，不仅仅是简单的对第一操作进行重复执行，可以在每次重试的过程中，对重试失败的操作或事务进行标记或记录，对于重试失败次数多的操作或事务，提升其优先级来保证其成功的可能性。

当然，上述实现仅是一种示例，在其他实现中，确定操作或事务的优先级，也可以为：在应用层面进行所述第一操作的重试的过程中，依据所述第一操作的重试次数和所述数据操作请求中的操作类别确定其执行优先级别。

由于操作和事务本身具有多种类别，不同类型的操作或事务依据业务系统需求所能够实现的功能也不相同，由于实现内容的不同，导致其重要程度不同，因此系统为不同类型操作或事务配置的优先级别也不同。

具体实现中，可以单独依据所述第一操作的重试次数或所述数据操作请求中的操作类别确定其执行优先级别，也可以同时结合两者，即第一操作的重试次数和数据操作请求中的操作类别，来确定第一操作的优先级别。

在一个具体实现中，银行的核心交易系统是面向接口开发的，由Stria流执行引擎统一执行接口服务，接口对应配置在Stria管理的数据库表中，在原有的表结构基础上，增加RERTY_FLAG重试标记和RETRY_TIMES最大重试次数两个字段，每个接口在由Stria引擎执行的时候，当发生不能对记录加锁操作的异常(该异常具体信息为can not retry selectforupdate statement)时，判断接口配置中的RETRY_FLAG是否为Y(即重试标记)，如果为Y，则新开启一个事务重新执行接口交易请求，如果在RETRY_TIMES重试次数内仍然失败，则回滚事务返回失败，这样就完成了交易重试的功能，并降低了因乐观锁导致的交易失败率。同时，当失败时，可以对该请求报文中特殊字段以及重试次数进行记录，当失败后再次进行重试时，会根据重试次数进行排序，来使得重试多次依旧不成功的请求获得更多成功的机会。在重试的过程中，接口无返回，对调用方来讲除了耗时增加无其他感知。

对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

上述本发明公开的实施例中详细描述了方法，对于本发明的方法可采用多种形式的装置实现，因此本发明还公开了一种装置，下面给出具体的实施例进行详细说明。

图4为本发明实施例公开的一种基于TiDB数据库的处理装置的结构示意图，参见图4所示，基于TiDB数据库的处理装置40可以包括：

请求接收模块401，用于接收数据操作请求，所述数据操作请求用于指示对第一数据进行第一操作。

操作执行模块402，用于依据所述数据操作请求对所述第一操作执行所述第一操作。

操作判断模块403，用于确定所述第一操作是否执行失败。

重试控制模块404，用于在所述操作判断模块的判断结果为是的情况下，在应用层面进行所述第一操作的重试。

本实施例中，所述基于TiDB数据库的处理装置，在数据操作失败后，可以在应用层面重试第一操作，从而增加了第一操作成功执行的概率，降低了高并发情况下使用TiDB数据库的热点数据更新失败的可能；且由于第一操作的重试在应用层面进行，因此整个过程对于用户是无感知的，从而实现了在用户无感知的情况下数据操作成功率的提升，优化了用户体验。

上述实施例中，所述操作判断模块403具体可用于：采用应用层上的Stria流执行引擎扫描检测所述第一操作是否执行失败。

本实施例中，银行的核心系统应用本身已有统一的Stria流执行引擎(每个引擎本身是一个事务)，具体实现中，可以在前述Stria流执行引擎的层面对第一操作是否执行失败的情况进行扫描，当发现由于TiDB数据库的乐观锁机制造成的第一操作执行失败的情况下，可以控制第一操作重试。

图5为本发明实施例公开的第二种基于TiDB数据库的处理装置的结构示意图，如图5所示，基于TiDB数据库的处理装置50可以包括：

请求接收模块401，用于接收数据操作请求，所述数据操作请求用于指示对第一数据进行第一操作。

操作执行模块402，用于依据所述数据操作请求对所述第一操作执行所述第一操作。

操作判断模块403，用于确定所述第一操作是否执行失败。

重试判断模块501，用于在操作判断模块403的判断结果为是的情况下，确定用于执行所述第一操作的接口中是否包含重试标记。

重试控制模块404，用于在所述重试判断模块501的判断结果为存在的情况下，在应用层面进行所述第一操作的重试。

本实现中，后续在检测到第一操作执行失败后，可以进一步确定执行第一操作的接口中是否配置有重试标记，若存在，再继续进行第一操作的重试。

上述实施例中，所述重试控制模块404具体可用于：在所述第一操作执行失败的情况下，在应用层面反复进行所述第一操作的重试的步骤，直至所述第一操作成功。

基于上述内容，基于TiDB数据库的处理装置还可以包括重试次数管理模块，用于在检测到所述第一操作的重试次数达到预设的最大重试次数的情况下，则返回操作失败结果，并进行针对所述数据操作请求的事务的回滚。

图6为本发明实施例公开的第三种基于TiDB数据库的处理装置的结构示意图，如图6所示，基于TiDB数据库的处理装置60可以包括：

请求接收模块401，用于接收数据操作请求，所述数据操作请求用于指示对第一数据进行第一操作。

操作执行模块402，用于依据所述数据操作请求对所述第一操作执行所述第一操作。

操作判断模块403，用于确定所述第一操作是否执行失败。

优先级确定模块601，用于在操作判断模块403的判断结果为是的情况下，依据所述第一操作的重试次数确定其执行优先级别。

具体的，所述重试控制模块404具体可用于：所述在应用层面进行所述第一操作的重试的过程中，若所述第一操作的重试次数越多，则将其执行优先级设置的越高。

重试控制模块404，用于依据所述执行优先级别，在应用层面进行所述第一操作的重试。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (8)

1.一种基于TiDB数据库的处理方法，其特征在于，包括：

接收数据操作请求，所述数据操作请求用于指示对第一数据进行第一操作；

依据所述数据操作请求对所述第一数据执行所述第一操作；

确定所述第一操作是否执行失败；

若是，在应用层面进行所述第一操作的重试；

所述确定所述第一操作是否执行失败，包括：

采用应用层上的Stria流执行引擎扫描检测所述第一操作是否执行失败。

2.根据权利要求1所述的基于TiDB数据库的处理方法，其特征在于，所述在应用层面进行所述第一操作的重试前，还包括：

确定用于执行所述第一操作的接口中是否包含重试标记；

若存在，执行所述在应用层面进行所述第一操作的重试的步骤。

3.根据权利要求1所述的基于TiDB数据库的处理方法，其特征在于，所述在应用层面进行所述第一操作的重试，包括：

在所述第一操作执行失败的情况下，在应用层面反复进行所述第一操作的重试的步骤，直至所述第一操作成功。

4.根据权利要求3所述的基于TiDB数据库的处理方法，其特征在于，还包括：

在检测到所述第一操作的重试次数达到预设的最大重试次数的情况下，则返回操作失败结果，并进行针对所述数据操作请求的事务的回滚。

5.根据权利要求1所述的基于TiDB数据库的处理方法，其特征在于，还包括：

依据所述第一操作的重试次数确定其执行优先级别。

6.根据权利要求5所述的基于TiDB数据库的处理方法，其特征在于，所述依据所述第一操作的重试次数确定其执行优先级别，包括：

所述在应用层面进行所述第一操作的重试的过程中，若所述第一操作的重试次数越多，则将其执行优先级设置的越高。

7.根据权利要求1所述的基于TiDB数据库的处理方法，其特征在于，还包括：

在应用层面进行所述第一操作的重试的过程中，依据所述第一操作的重试次数和所述数据操作请求中的操作类别确定其执行优先级别。

8.一种基于TiDB数据库的处理装置，其特征在于，包括：

请求接收模块，用于接收数据操作请求，所述数据操作请求用于指示对第一数据进行第一操作；

操作执行模块，用于依据所述数据操作请求对所述第一操作执行所述第一操作；

操作判断模块，用于确定所述第一操作是否执行失败；

重试控制模块，用于在所述操作判断模块的判断结果为是的情况下，在应用层面进行所述第一操作的重试；

所述操作判断模块具体用于：

采用应用层上的Stria流执行引擎扫描检测所述第一操作是否执行失败。

Images