CN109743366B - 一种用于多活场景的资源加锁方法、装置及*** - Google Patents

Abstract

本发明实施例公开了一种用于多活场景的资源加锁方法、装置及***，涉及互联网技术领域，能够降低将非多活场景的业务***改造成支持多活场景的业务***的改造成本。本发明包括：接收服务入口的访问，并确定发出访问的应用集群，其中，在主机房和每一个子机房中，分别部署至少一个应用集群；从主机房的redis集群中获取Spring容器，并从Spring容器中确定代理对象，所述代理对象包括预设的业务资源；获取所确定的代理对象的锁执行器，并通过所述锁执行器对所确定的代理对象加锁；接收到所述应用集群发送的解锁通知后，对被加锁的代理对象进行解锁。本发明适用于多活场景下对唯一性的竞争资源的锁定。

Description

一种用于多活场景的资源加锁方法、装置及***

技术领域

本发明涉及互联网技术领域，尤其涉及一种用于多活场景的资源加锁方法、装置及***。

背景技术

规模越大的互联网公司，就需要建设愈发强大的***来支撑其日常经营的业务，而机房维护也成为大型互联网公司攸关生死的工作之一。

针对不断发生的灾难事故和机房故障，多活体系下的***配置策略，已成为大型互联网公司必须要实施的灾备体系建设。但多活体系下，各数据中心的分布式锁中间件服务之间，一般无法共用网络。因此在多活体系下，多机房中心之间，如何获取***的唯一性资源，成了一大难点。

并且，将非多活场景的业务***改造成支持多活场景的业务***，也需要进行大量代码的重构工作，尤其是对于***的唯一性资源的加锁规则的代码编写，这部分工作即复杂又容易出现多机房中心之间的耦合问题，导致业务改造的人力成本和风险一直居高不下。

发明内容

本发明的实施例提供一种用于多活场景的资源加锁方法、装置及***，能够降低将非多活场景的业务***改造成支持多活场景的业务***的改造成本。

为达到上述目的，本发明的实施例采用如下技术方案：

一种用于多活场景的资源加锁***，所述***划分为主机房设备和子机房设备；

所述主机房设备包括了所述主机房中的至少一个应用集群、所述主机房中的redis集群和所述主机房的Rsf服务中心；

所述子机房设备包括了所述子机房中的至少一个应用集群和所述子机房的Rsf服务中心；

所述子机房中的至少一个应用集群，用于通过所述子机房的Rsf服务中心作为rsf服务路由，向所述主机房发出访问请求；

所述主机房的Rsf服务中心，用于接收所述rsf服务路由发送的访问请求；

所述主机房中的至少一个应用集群，用于直接向所述redis集群发出所述访问请求；

所述主机房中的redis集群，用于根据接收到的访问请求提供Spring容器，所述Spring容器中记录了代理对象，所述代理对象包括预设的业务资源；

所述主机房的Rsf服务中心，用于通过所述代理对象的锁执行器对所确定的代理对象加锁，并接收到所述应用集群发送的解锁通知后，对被加锁的代理对象进行解锁；

其中，所述访问请求用于请求获取锁服务，所述Spring容器中的代理对象与所述访问请求指向的代理对象相互对应。

在主机房，接收服务入口的访问，并确定发出访问的应用集群，其中，在主机房和每一个子机房中，分别部署至少一个应用集群；从主机房的redis集群中获取Spring容器，并从Spring容器中确定代理对象，所述代理对象包括预设的业务资源；获取所确定的代理对象的锁执行器，并通过所述锁执行器对所确定的代理对象加锁；接收到所述应用集群发送的解锁通知后，对被加锁的代理对象进行解锁。

本实施例旨在提供一种多活场景下对***唯一资源进行加锁处理。将***业务与锁管理业务分离，开放接口实现rsf的跨机房锁管理。对竞争性的资源，比如分布式***中的业务***，具体业务场景为利用手机号创建会员时的，很多业务都需要利用手机号，因此一个业务改造时需要对手机号进行加锁，进行锁定管理，不同的机房中，如果需要对同一个资源进行加锁，通过主机房进行加锁。通过本实施例的方案，简化了重复加锁代码，防止错误的使用分布式锁造成的业务异常，业务方更多的将精力放在发掘业务本身。并且这种加锁方式对于***低侵入，无需修改原业务逻辑，从而最大程度降低将非多活场景的业务***改造成支持多活场景的业务***的改造成本。

附图说明

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

图1为本发明实施例提供的一种***架构实例的示意图；

图2为本发明实施例提供的方法流程示意图；

图3、4、5、6为本发明实施例提供的具体实例的流程示意图；

图7为本发明实施例提供的装置结构示意图。

具体实施方式

为使本领域技术人员更好地理解本发明的技术方案，下面结合附图和具体实施方式对本发明作进一步详细描述。下文中将详细描述本发明的实施方式，所述实施方式的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的任一单元和全部组合。本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样定义，不会用理想化或过于正式的含义来解释。

本实施例中的方法流程，具体可以在一种如图1所示的用于多活场景的资源加锁***上执行，所述***主要部署在分布式场景中，按照地理位置，具体可以划分为主机房和子机房，按照部署机房的划分，可以将***中的各个设备划分为主机房设备和子机房设备。

其中，所述主机房设备包括了所述主机房中的至少一个应用集群、所述主机房中的redis集群和所述主机房的Rsf服务中心。所述子机房设备包括了所述子机房中的至少一个应用集群和所述子机房的Rsf服务中心。

应用集群具体实现为由多台服务器设备组成的服务器集群，在实际应用中，应用集群主要作为运行业务***的硬件设备。

redis集群和Rsf服务中心也都可以实现为一台现有市面上能够采购到的服务器设备，或者是实现为由多台服务器设备组成的集群***，redis集群和Rsf(远程服务框架)服务中心的架设，可以基于目前已公开并被广泛使用的技术(例如：苏宁远程服务框架(RSF)，用于解决***间的服务调用问题，提供一种透明的、高性能的RPC服务调用方案，可以实现每天的服务调用次数在200亿左右，是被使用最广泛的技术组件)，本实施例中不再赘述。

本发明实施例提供一种用于多活场景的资源加锁方法，如图2所示，包括：

S101、接收服务入口的访问，并确定发出访问的应用集群。

其中，在主机房和每一个子机房中，分别部署至少一个应用集群。

在本实施例中，如图1所示的，服务入口可以理解为获取锁服务的入口，子机房的应用集群通过子机房的Rsf服务中心路由(routing，是指分组从源到目的地时，决定端到端路径的网络范围的进程)主机房，从而接入服务入口。

不论是主机房中的应用集群还是子机房中的应用集群，都可以向主机房中的redis集群发送访问请求，访问请求用于请求获取锁服务，所述Spring容器中的代理对象与所述访问请求指向的代理对象相互对应。

S102、从主机房的redis集群中获取Spring容器，并从Spring容器中确定代理对象。

其中，所述代理对象包括预设的业务资源。

具体的，Spring容器启动后，存储在redis集群中，以便于用于多活场景的资源加锁***快速读取锁执行器，用于多活场景的资源加锁***主要为分布式***。

如图5所示的，在启动Spring容器后，扫描锁的注解类，并加载被扫描锁的配置。根据被扫描锁的注解类生成代理对象，并将所生成的代理对象存入Spring容器。例如：在实际应用中，如图3所示的组件架构，业务方可以通过规则创建器，创建一系列加锁规则和加锁行为动作封装成加锁策略，锁管理器拿到加锁策略调用对应的锁执行器进行加锁解锁逻辑。其中：

锁管理器用于提供生成代理对象方法，管理会话id，使用锁执行器进行加锁，解锁操作。

锁执行器为实际操作锁的对象，如基于redis的锁执行器，zookeeper锁执行器等，默认实现了跨机房RSF锁执行器，基于redis锁执行器。

加锁策略包含细化加锁规则，一些加锁基本参数，被加锁对象等，每个被加锁对象都需要一个策略。具体包含两种策略：注解加锁策略，针对整个对象；以及，方法加锁策略，针对指定方法。使用注解加锁时使用的是注解加锁策略，编程式加锁使用的是方法加锁策略。以注解加锁策略，针对整个对象的策略为例，如图4所示的，其中，RuleCreator表示规则创建器，值为beanname，referParamIndex表示规则创建依赖的参数位置，从0开始计算，referAttribute表示如果依赖对参数内的属性，可以设置属性值。此外注解中还可以根据具体属性进行个性化定制，这些具体属性包括：mLdcLock主机房锁，设置为true，到主机房加锁；releaseLockRetryCount释放锁重试次数；releaseLockRetryWaitTime释放锁重试等待时间；releaseLockByProxy是否让代理释放锁；excutor自定义锁执行器。

加锁规则包含加锁的key,锁过期时间以及加锁失败抛出的异常等，同时加锁前后提供行为动作接口，方便业务在加锁前后操作业务。

行为动作指的是定义加锁前后业务操作和逻辑。

规则创建器：一般需要业务自己实现，定义业务加锁规则，锁管理器通过该规则创建器，给业务按特定规则加锁。默认提供字符串规则创建器。

需要说明的是，Spring容器和Springbean是一个JAVA领域中的公知概念，Spring容器是Spring的核心，一切Springbean都存储在Spring容器内，并由其通过IoC技术管理。Spring容器也就是一个bean工厂(BeanFactory)。应用中bean的实例化，获取，销毁等都是由这个bean工厂管理的。一个Spring容器就是某个实现了ApplicationContext接口的类的实例。也就是说，从代码层面，Spring容器其实就是一个ApplicationContext。

S103、获取所确定的代理对象的锁执行器，并通过所述锁执行器对所确定的代理对象加锁。

S104、接收到所述应用集群发送的解锁通知后，对被加锁的代理对象进行解锁。

举例来说，如图6所示的，应用集群接入服务入口后，获取Spring容器中的代理对象；进一步获取代理对象中的锁执行器；之后依据本次锁服务生成唯一回话ID；在拿到指定的锁执行器后进行加锁；若加锁成功则执行代理对象的具体业务，此时该业务的资源已被加锁，只有获取本次锁服务的应用集群可以使用；业务执行完成后即可以通知主机房解锁。

在本实施例中，为了使各个机房获取的锁具有唯一性，将获取锁服务定义为竞争服务，其他子机房通过rsf服务路由至主机房获取锁，主机房服务直接访问redis获取锁。其中，竞争服务指的是：各个数据中心相互操作同一个数据，为了保证数据一致性，需要在同一个数据中心进行控制，例如库存的扣减、用户注册。

在此基础上，若为子机房中的应用集群的访问过程，则S101具体实现为：通过rsf服务路由发出的访问请求。根据所述rsf服务路由确定发出所述访问请求的应用集群和所述应用集群所在的子机房。

若为主机房中的应用集群的访问过程，则S101具体实现为：接收到应用集群直接发出的访问请求，并确定所述直接发出访问请求的应用集群在所述主机房中。

本实施例旨在提供一种多活场景下对***唯一资源进行加锁处理。将***业务与锁管理业务分离，开放接口实现rsf的跨机房锁管理。对竞争性的资源，比如：会员中心注册会员业务，用户注册时手机号、昵称、用户名等信息，必须全局唯一，此时需要用到分布式锁。但多活场景下，机房集群是独立部署且网络隔离的，中间是通过专线进行网络交互。无法直接通过分布式锁中间件的api直接获取锁。本实施例中，可以轻松实现跨机房的锁管理功能(包括锁获取和锁释放)而不需要过多的关注细节的锁管理和网络通讯实现。通过本实施例的方案，简化了重复加锁代码，防止错误的使用分布式锁造成的业务异常，业务方更多的将精力放在发掘业务本身。并且这种加锁方式对于***低侵入，无需修改原业务逻辑，针对业务方法直接加锁,同时不失去对锁的灵活控制。并且通过全局唯一会话id,支持异步释放锁。

本发明实施例提供一种用于多活场景的资源加锁装置，该装置可以运行在如图1所示的主机房中的redis集群上，或者主机房中的一种用于从redis集群中提取数据的设备比如主机房的Rsf服务中心。如图7所示的所述装置大致包括：

访问管理模块，用于接收服务入口的访问，并确定发出访问的应用集群，其中，在主机房和每一个子机房中，分别部署至少一个应用集群。

锁提取模块，用于从主机房的redis集群中获取Spring容器，并从Spring容器中确定代理对象，所述代理对象包括预设的业务资源。

加锁模块，用于获取所确定的代理对象的锁执行器，并通过所述锁执行器对所确定的代理对象加锁。

解锁模块，用于接收到所述应用集群发送的解锁通知后，对被加锁的代理对象进行解锁。

其中，所述访问管理模块，具体用于：通过rsf服务路由发出的访问请求。根据所述rsf服务路由确定发出所述访问请求的应用集群和所述应用集群所在的子机房。

所述访问请求用于请求获取锁服务，所述Spring容器中的代理对象与所述访问请求指向的代理对象相互对应。

所述访问管理模块，还用于：接收到应用集群直接发出的访问请求，并确定所述直接发出访问请求的应用集群在所述主机房中。

进一步的，还包括：

锁管理模块，用于启动Spring容器后，扫描锁的注解类，并加载被扫描锁的配置。根据被扫描锁的注解类生成代理对象，并将所生成的代理对象存入Spring容器。

本实施例旨在提供一种多活场景下对***唯一资源进行加锁处理。将***业务与锁管理业务分离，开放接口实现rsf的跨机房锁管理。对竞争性的资源，比如分布式***中的业务***，具体业务场景为利用手机号创建会员时的，很多业务都需要利用手机号，因此一个业务改造时需要对手机号进行加锁，进行锁定管理，不同的机房中，如果需要对同一个资源进行加锁，通过主机房进行加锁。通过本实施例的方案，简化了重复加锁代码，防止错误的使用分布式锁造成的业务异常，业务方更多的将精力放在发掘业务本身。并且这种加锁方式对于***低侵入，无需修改原业务逻辑，针对业务方法直接加锁,同时不失去对锁的灵活控制。并且通过全局唯一会话id,支持异步释放锁。

本发明实施例提供一种如图1所示的用于多活场景的资源加锁***。所述***划分为主机房设备和子机房设备。

所述主机房设备包括了所述主机房中的至少一个应用集群、所述主机房中的redis集群和所述主机房的Rsf服务中心；

所述子机房设备包括了所述子机房中的至少一个应用集群和所述子机房的Rsf服务中心；

所述子机房中的至少一个应用集群，用于通过所述子机房的Rsf服务中心作为rsf服务路由，向所述主机房发出访问请求；

所述主机房的Rsf服务中心，用于接收所述rsf服务路由发送的访问请求；

所述主机房中的至少一个应用集群，用于直接向所述redis集群发出所述访问请求；

所述主机房中的redis集群，用于根据接收到的访问请求提供Spring容器，所述Spring容器中记录了代理对象，所述代理对象包括预设的业务资源；

所述主机房的Rsf服务中心，用于通过所述代理对象的锁执行器对所确定的代理对象加锁，并接收到所述应用集群发送的解锁通知后，对被加锁的代理对象进行解锁；

其中，所述访问请求用于请求获取锁服务，所述Spring容器中的代理对象与所述访问请求指向的代理对象相互对应。

本实施例旨在提供一种多活场景下对***唯一资源进行加锁处理。将***业务与锁管理业务分离，开放接口实现rsf的跨机房锁管理。对竞争性的资源，比如分布式***中的业务***，具体业务场景为利用手机号创建会员时的，很多业务都需要利用手机号，因此一个业务改造时需要对手机号进行加锁，进行锁定管理，不同的机房中，如果需要对同一个资源进行加锁，通过主机房进行加锁。通过本实施例的方案，简化了重复加锁代码，防止错误的使用分布式锁造成的业务异常，业务方更多的将精力放在发掘业务本身。并且这种加锁方式对于***低侵入，无需修改原业务逻辑，针对业务方法直接加锁,同时不失去对锁的灵活控制。并且通过全局唯一会话id,支持异步释放锁。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims (8)

1.一种用于多活场景的资源加锁方法，其特征在于，包括：

接收服务入口的访问，并确定发出访问的应用集群，其中，在主机房和每一个子机房中，分别部署至少一个应用集群；

从主机房的redis集群中获取Spring容器，并从Spring容器中确定代理对象，所述代理对象包括预设的业务资源；

获取所确定的代理对象的锁执行器，并通过所述锁执行器对所确定的代理对象加锁；其中，由主机房的Rsf服务中心通过所述代理对象的锁执行器，对所确定的代理对象加锁，并接收到所述应用集群发送的解锁通知后，对被加锁的代理对象进行解锁；

所述访问请求用于请求获取锁服务，所述Spring容器中的代理对象与所述访问请求指向的代理对象相互对应。

2.根据权利要求1所述的方法，其特征在于，所述接收服务入口的访问，并确定发出访问的应用集群，包括：

通过rsf服务路由发出的访问请求；

根据所述rsf服务路由确定发出所述访问请求的应用集群和所述应用集群所在的子机房。

3.根据权利要求1所述的方法，其特征在于，所述接收服务入口的访问，并确定发出访问的应用集群，包括：

接收到应用集群直接发出的访问请求，并确定所述直接发出访问请求的应用集群在所述主机房中。

4.根据权利要求1所述的方法，其特征在于，还包括：

启动Spring容器后，扫描锁的注解类，并加载被扫描锁的配置；

根据被扫描锁的注解类生成代理对象，并将所生成的代理对象存入Spring容器。

5.一种用于多活场景的资源加锁装置，其特征在于，包括：

访问管理模块，用于接收服务入口的访问，并确定发出访问的应用集群，其中，在主机房和每一个子机房中，分别部署至少一个应用集群；

锁提取模块，用于从主机房的redis集群中获取Spring容器，并从Spring容器中确定代理对象，所述代理对象包括预设的业务资源；

加锁模块，用于获取所确定的代理对象的锁执行器，并通过所述锁执行器对所确定的代理对象加锁，其中，由主机房的Rsf服务中心通过所述代理对象的锁执行器，对所确定的代理对象加锁，并接收到所述应用集群发送的解锁通知后，对被加锁的代理对象进行解锁；

所述访问管理模块，具体用于：通过rsf服务路由发出的访问请求；根据所述rsf服务路由确定发出所述访问请求的应用集群和所述应用集群所在的子机房；

所述访问请求用于请求获取锁服务，所述Spring容器中的代理对象与所述访问请求指向的代理对象相互对应。

6.根据权利要求5所述的装置，其特征在于，所述访问管理模块，还用于：接收到应用集群直接发出的访问请求，并确定所述直接发出访问请求的应用集群在所述主机房中。

7.根据权利要求5所述的装置，其特征在于，还包括：

锁管理模块，用于启动Spring容器后，扫描锁的注解类，并加载被扫描锁的配置；根据被扫描锁的注解类生成代理对象，并将所生成的代理对象存入Spring容器。

8.一种用于多活场景的资源加锁***，其特征在于，所述***划分为主机房设备和子机房设备；

所述主机房设备包括了所述主机房中的至少一个应用集群、所述主机房中的redis集群和所述主机房的Rsf服务中心；

所述子机房设备包括了所述子机房中的至少一个应用集群和所述子机房的Rsf服务中心；

所述子机房中的至少一个应用集群，用于通过所述子机房的Rsf服务中心作为rsf服务路由，向所述主机房发出访问请求；

所述主机房的Rsf服务中心，用于接收所述rsf服务路由发送的访问请求；

所述主机房中的至少一个应用集群，用于直接向所述redis集群发出所述访问请求；

所述主机房中的redis集群，用于根据接收到的访问请求提供Spring容器，所述Spring容器中记录了代理对象，所述代理对象包括预设的业务资源；

所述主机房的Rsf服务中心，用于通过所述代理对象的锁执行器对所确定的代理对象加锁，并接收到所述应用集群发送的解锁通知后，对被加锁的代理对象进行解锁；

其中，所述访问请求用于请求获取锁服务，所述Spring容器中的代理对象与所述访问请求指向的代理对象相互对应。

Images