签约冲突检测方法及装置与流程

本申请涉及通信领域，尤其涉及一种签约冲突检测方法及装置。

背景技术：

一个软件产品，通常会包含多种产品属性，而软件产品的产品属性，通常用于通过不同的维度描述软件产品的服务能力、产品特性及相关约束等信息。用户可以通过签约软件产品，取得使用授权后，便可以使用该软件产品。

对于某些软件产品，用户在签约时会有很多限制条件，比如一个用户对同一类产品只能签约一次，如果用户签约多次即视为签约冲突，此时可以终止用户的签约流程。然而，不同的软件产品，用户在签约时的限制条件往往不同，因此在针对不同的软件产品进行签约冲突检测时实现较复杂。

技术实现要素：

本申请提出一种签约冲突检测方法，该方法包括：

读取用户待签约产品的产品属性；

读取该用户已签约产品的产品属性；其中，所述产品属性被预先划分为基础属性和可变属性；

基于预配置的与所述待签约产品的基础属性对应的第一类冲突检测规则执行第一阶段的签约冲突检测，以及基于预配置的与所述待签约产品的可变属性对应的第二类冲突检测规则执行第二阶段的签约冲突检测，以确定所述待签约产品的产品属性与所述已签约产品的产品属性是否存在签约冲突。

可选的，所述基于预配置的与所述待签约产品的基础属性对应的第一类 冲突检测规则执行第一阶段的签约冲突检测包括：

读取预设的第一阶段的冲突检测组件；其中，所述第一阶段的冲突检测组件为基于所述第一类冲突检测规则进行组件预封装后得到的组件；

基于所述第一阶段的冲突检测组件针对所述待签约产品的基础属性进行第一阶段的签约冲突检测，以确定所述待签约产品的基础属性与所述已签约产品的基础属性是否存在签约冲突；

当所述待签约产品的任一基础属性与所述已签约产品的基础属性存在签约冲突时，终止所述待签约产品的签约流程。

可选的，所述方法还包括：

当所述待签约产品的产品属性与所述已签约产品的基础属性均不存在签约冲突时，则基于预配置的与所述待签约产品的可变属性对应的第二类冲突检测规则执行第二阶段的签约冲突检测。

可选的，所述基于预配置的与所述待签约产品的可变属性对应的第二类冲突检测规则执行第二阶段的签约冲突检测之前，所述方法还包括：

基于所述待签约产品的基础属性、所述用户的标识以及所述待签约产品的标识生成对应的冲突控制记录；

其中，在针对所述待签约产品进行产品签约时，如果查询到与所述待签约产品的基础属性、所述用户的标识以及所述待签约产品的标识匹配的冲突控制记录，则终止针对所述待签约产品的签约流程。

可选的，所述基于预配置的与所述待签约产品的可变属性对应的第二类冲突检测规则执行第二阶段的签约冲突检测包括：

读取与所述可变属性对应的第二类冲突检测规则；

对读取到的所述第二类冲突检测规则进行组件封装以得到第二阶段的冲突检测组件；

基于所述第二阶段的冲突检测组件针对所述待签约产品的可变属性进行第二阶段的签约冲突检测，以确定所述待签约产品的可变属性与所述已签约产品的可变属性是否存在签约冲突；

当所述待签约产品的任一可变属性与所述已签约产品的可变属性存在签约冲突时，终止所述待签约产品的签约流程。

可选的，所述读取与所述可变属性对应的第二类冲突检测规则之前，所述方法还包括：

针对所述冲突控制记录添加排它锁，以避免所述冲突控制记录被修改。

可选的，所述方法还包括：

当所述待签约产品的可变属性与所述已签约产品的可变属性均不存在签约冲突时，完成针对所述待签约产品的产品签约，并释放为所述冲突控制记录添加的所述排它锁，以及清除所述冲突控制记录。

可选的，所述产品属性基于json格式存储在预设数据库中。

本申请还提出一种签约冲突检测装置，该装置包括：

第一读取模块，用于读取用户待签约产品的产品属性；

第二读取模块，用于读取该用户已签约产品的产品属性；其中，所述产品属性被预先划分为基础属性和可变属性；

检测模块，用于基于预配置的与所述待签约产品的基础属性对应的第一类冲突检测规则执行第一阶段的签约冲突检测，以及基于预配置的与所述待签约产品的可变属性对应的第二类冲突检测规则执行第二阶段的签约冲突检测，以确定所述待签约产品的产品属性与所述已签约产品的产品属性是否存在签约冲突。

可选的，所述检测模块具体用于：

读取预设的第一阶段的冲突检测组件；其中，所述第一阶段的冲突检测组件为基于所述第一类冲突检测规则进行组件预封装后得到的组件；

基于所述第一阶段的冲突检测组件针对所述待签约产品的基础属性进行第一阶段的签约冲突检测，以确定所述待签约产品的基础属性与所述已签约产品的基础属性是否存在签约冲突；

当所述待签约产品的任一基础属性与所述已签约产品的基础属性存在签约冲突时，终止所述待签约产品的签约流程。

可选的，所述检测模块进一步用于：

当所述待签约产品的产品属性与所述已签约产品的基础属性均不存在签约冲突时，则基于预配置的与所述待签约产品的可变属性对应的第二类冲突检测规则执行第二阶段的签约冲突检测。

可选的，所述装置还包括：

生成模块，用于在检测模块基于预配置的与所述待签约产品的可变属性对应的第二类冲突检测规则执行第二阶段的签约冲突检测之前，基于所述待签约产品的基础属性、所述用户的标识以及所述待签约产品的标识生成对应的冲突控制记录；

终止模块，用于在针对所述待签约产品进行产品签约时，如果查询到与所述待签约产品的基础属性、所述用户的标识以及所述待签约产品的标识匹配的冲突控制记录，则终止针对所述待签约产品的签约流程。

可选的，所述检测模块进一步用于：

读取与所述可变属性对应的第二类冲突检测规则；

对读取到的所述第二类冲突检测规则进行组件封装以得到第二阶段的冲突检测组件；

基于所述第二阶段的冲突检测组件针对所述待签约产品的可变属性进行第二阶段的签约冲突检测，以确定所述待签约产品的可变属性与所述已签约产品的可变属性是否存在签约冲突；

所述终止模块进一步用于：

当所述待签约产品的任一可变属性与所述已签约产品的可变属性存在签约冲突时，终止所述待签约产品的签约流程。

可选的，所述检测模块进一步用于：

在读取与所述可变属性对应的第二类冲突检测规则之前，针对所述冲突控制记录添加排它锁，以避免所述冲突控制记录被修改。

可选的，所述检测模块进一步用于：

当所述待签约产品的可变属性与所述已签约产品的可变属性均不存在签 约冲突时，完成针对所述待签约产品的产品签约，并释放为所述冲突控制记录添加的所述排它锁，以及清除所述冲突控制记录。

可选的，所述产品属性基于json格式存储在预设数据库中。

本申请中，通过将待签约产品的产品属性预先划分为基础属性和可变属性，并基于预配置的与基础属性对应的第一类冲突检测规则针对待签约产品执行第一阶段的签约冲突检测，以及基于预配置的与可变属性对应的第二类冲突检测规则针对待签约产品执行第二阶段的签约冲突检测，来确定待签约产品的产品属性与已签约产品的产品属性是否存在签约冲突，实现了既可以在简单的签约冲突场景中基于基础属性来进行签约冲突检测，又可以在复杂的签约冲突场景中基于可变属性来进行签约冲突检测，从而具有更好的通用性和可扩展性。

附图说明

图1是本申请一实施例提供的一种签约冲突检测方法的流程图；

图2是本申请一实施例提供的第一阶段的签约冲突检测的流程图；

图3是本申请一实施例提供的第二阶段的签约冲突检测的流程图；

图4是本申请一实施例提供的一种签约冲突检测系统的结构图；

图5是本申请一实施例提供的图4所示的签约冲突检测系统进行签约冲突检测的流程图；

图6是本申请一实施例提供的一种签约冲突检测装置的逻辑框图；

图7是本申请一实施例提供的承载所述一种签约冲突检测装置的服务端的硬件结构图。

具体实施方式

产品冲突，通常是指软件产品本身存在约束，导致用户签约产品时会发生签约冲突。例如，以快捷卡产品为例，通常限制一个用户对同一类快捷卡产品 只能签约一次，或者用户在同一个时间段内，对一家机构的同一类快捷卡产品只能一次，如果用户多次签约同一类快捷卡产品，就会发生签约冲突。

对于本身存在约束的软件产品，通常会具有签约冲突控制的需求，通过签约冲突控制，可以避免用户在签约软件产品的过程中，对同一类或者相同的软件产品进行重复签约。

在相关技术中，对软件产品的签约冲突控制，通常是依赖于对软件产品的签约造成影响的产品属性来实现，而影响产品签约的属性通常可以包括很多种；例如，以快捷卡产品为例，影响产品签约的产品属性通常可以包括签约起始时间、签约结束时间、银行机构以及卡号等产品属性。

因此，在相关技术中，在针对软件产品进行签约冲突控制时，通常是通过将对软件产品的签约造成影响的产品属性保存至关系型数据库中，在关系型数据库中建立唯一性索引，并依赖关系型数据自身的字段约束机制，来避免用户重复签约(即当用户签约的产品的属性命中数据库中的唯一性索引，即认为是重复签约)。

然而，由于针对不同的软件产品，对软件产品的签约造成影响的产品属性也彼此不同，因此通过上述方案来进行签约冲突控制时，往往需要调整关系型数据的结构，为软件产品增加新的唯一性索引，或者为不同的产品分别创建不同的冲突控制表。可见，上述技术方案需要对关系型数据的结构进行改造，比较复杂，而且存在不够通用的缺点，很难满足不同的软件产品的签约冲突控制需求。

有鉴于此，本申请提出一种签约冲突检测方法，基于软件产品的共性和个性化的签约冲突控制需求，将待签约产品的产品属性预先划分为基础属性和可变属性，在进行签约冲突控制时，按照两个阶段的签约冲突检测进行处理。在第一阶段，可以基于预配置的与基础属性对应的第一类冲突检测规则针对待签约产品进行签约冲突检测；在第二阶段，可以基于预配置的与可变属性对应的第二类冲突检测规则针对待签约产品进行签约冲突检测；实现了既可以在简单的签约冲突场景中基于基础属性来进行签约冲突检测，又可以 在复杂的签约冲突场景中基于可变属性来进行签约冲突检测，从而具有更好的通用性和可扩展性。

下面通过具体实施例并结合具体的应用场景对本申请进行描述。

请参考图1，图1是本申请一实施例提供的一种签约冲突检测方法，应用于服务端，所述方法执行以下步骤：

步骤101，读取用户待签约产品的产品属性；

步骤102，读取该用户已签约产品的产品属性；其中，所述产品属性被预先划分为基础属性和可变属性；

步骤103，基于预配置的与所述待签约产品的基础属性对应的第一类冲突检测规则执行第一阶段的签约冲突检测，以及基于预配置的与所述待签约产品的可变属性对应的第二类冲突检测规则执行第二阶段的签约冲突检测，以确定所述待签约产品的产品属性与所述已签约产品的产品属性是否存在签约冲突。

上述服务端包括面向软件产品提供签约冲突检测服务的服务器、服务器集群或者基于服务器集群构建的云平台。例如，上述服务端可以是软件产品的签约服务器。

上述产品属性包括对软件产品的签约造成影响的产品属性，可以基于软件产品的共性和个性化需求，划分为基础属性和可变属性。

其中，基础属性，为行业内的通用属性，通常包括在软件产品定义时确认的属性，这类属性通常不会发生变化，可以称之为产品级属性；例如，产品名称等。

可变属性，为非通用属性，通常包括与产品相关的的比较个性化和特有的属性，可以由开发人员进行自定义。这类属性通常是在产品签约时才能确认的属性，可以称之为合约级属性；例如，签约时间段、签约渠道等。

在实际应用中，无论是基础属性，还是可变属性，均可以由软件产品的开发者预设置对应的冲突检测规则，从而用户在签约软件产品时，服务端可以基 于该软件产品的开发者预设置的冲突检测规则，来进行签约冲突检测，以避免用户重复签约同一类或者相同的软件产品。

在本例中，服务端可以在本地预设一个数据库，用于存储不同的软件产品的产品属性。其中，该数据库可以是关系型数据库。

对于关系型数据库来说，通常会具有一定的字段约束机制，因此服务端可以利用关系型数据库自身的字段约束机制，避免将软件产品的使用者自定义的非标准的产品属性写入到数据库中。

服务端在将不同的软件产品(包括用户已签约和未签约的软件产品)的产品属性存入该数据库时，由于软件产品的产品属性往往具有很多种，而且不同的软件产品的产品属性通常会存在一定的差异，因此对于软件产品的产品属性来说，很难在关系型数据库中用结构化的数据为每一个属性定义一个字段进行描述和存储。

针对这种情况，在本实施例示出的一种实施方式中，在将不同的软件产品的产品属性存入预设的关系型数据库时，可以将json格式作为该数据库的默认存储格式，基于json格式将不同的软件产品的产品属性中的基础属性和可变属性，以大字段的形式分别进行存储，从而可以不必在关系型数据库中为每一个属性分别定义一个字段进行描述，以降低软件产品的产品属性存储的复杂度。

其中，json格式的基本存储架构在本实施例中不再进行详述，本领域技术人员在将本申请的技术方案付诸实施时，可以参考相关技术中的记载。

另外，上述数据库除了可以用于存储不同的软件产品的产品属性以外，还可以用于存储软件产品的开发者为产品属性预配置的冲突检测规则。服务端在将产品属性存入数据库时，可以将开发者为该产品属性预配置的冲突检测规则也存储至数据库，并在数据库中保存二者之间的对应关系。

上述冲突检测规则，可以包括软件产品的开发人员为软件产品预配置的签约约束规则，可以包括第一类冲突检测规则和第二类冲突检测规则。

其中，第一类冲突检测规则是指由开发人员针对上述基础属性预配置的冲突检测规则。第二类冲突检测规则是指由开发人员针对上述可变属性预配置的冲突检测规则。

例如，以在针对快捷卡产品进行冲突检测的应用场景为例，在该应用场景中，上述基础属性可以为快捷卡卡号，可变属性可以为签约时间段或者签约渠道为例，上述第一类冲突检测规则可以是开发人员为产品名称预配置的“同一个用户针对同一个卡号只能签约一次”的冲突检测规则；上述第二类冲突检测规则可以是开发人员为签约时间段预配置的“同一个签约时间段只能签约一次”、“签约时间段不能存在交集”或“签约渠道不能存在互斥”的冲突检测规则。

在本例中，当用户签约一个软件产品时，服务端可以从上述数据库中读取该软件产品的产品属性，以及该用户已签约的软件产品的产品属性。

当服务端读取到用户待签约的软件产品，以及该用户已经签约的软件产品后，可以基于上述数据库中存储的由开发人员预配置的冲突检测规则，对用户待签约的该软件产品进行两个阶段的签约冲突检测，以确定该用户待签约的软件产品的产品属性与该用户已签约的软件产品的产品属性是否存在签约冲突。

其中，上述两个阶段可以包括第一阶段和第二阶段。

在第一阶段中，服务端可以基于预配置的与产品属性中的基础属性对应的第一类冲突检测规则针对待签约产品进行签约冲突检测。由于第一阶段的签约冲突检测，是基于基础属性对应的冲突检测规则来进行的，而基础属性是同一类软件产品中的共性产品属性，通常不会发生变化，因此第一阶段的签约冲突检测可以适用于简单的签约冲突场景中的签约冲突检测。

在第二阶段中，服务端可以基于预配置的与可变属性对应的第二类冲突检测规则针对待签约产品进行签约冲突检测。由于第二阶段的签约冲突检测，是基于可变属性对应的冲突检测规则来进行的，而可变属性对于同一类软件产品也可能会各不相同，因此第二阶段的签约冲突检测可以适用于复杂的签 约冲突场景中的签约冲突检测，可以为满足不同的软件产品的个性化的冲突检测需求。

以下通过具体的实施例，对第一阶段以及第二阶段的签约冲突检测过程进行描述。

请参见图2，图2为示出的第一阶段的签约冲突检测的流程图，包括以下执行步骤：

步骤201，读取预设的第一阶段的冲突检测组件；其中，所述第一阶段的冲突检测组件为基于所述第一类冲突检测规则进行组件预封装后得到的组件；

在本例中，服务端在启动第一阶段的冲突检测之前，首先可以判断数据库中是否存储了与用户待签约的软件产品的产品属性对应的冲突检测规则(包括第一类冲突检测规则和第二类冲突检测规则)，如果数据库中未存储针对该软件产品的任何冲突检测规则，则表明该软件产品自身可能并不存在签约约束，因此在这种情况下，服务端可以基于用户的签约信息继续执行后续的签约流程即可。

相反，如果数据库中存储了上述第一类冲突检测规则，此时服务端可以基于该第一类冲突检测规则针对用户待签约的软件产品进行第一阶段的签约冲突检测。

当然，如果数据库中未存储上述第一类冲突检测规则，而存储了上述第二类冲突检测规则，此时服务端可以跳过第一阶段的签约冲突检测，直接开启针对用户待签约的软件产品进行第二阶段的签约冲突检测。

在本例中，当服务端开启了第一阶段的签约冲突检测后，首先可以读取预设的第一阶段的冲突检测组件。

其中，第一阶段的冲突检测组件，可以称之为基础属性冲突检测组件。由于同一类软件产品的基础属性通常为共性产品属性，不会发生变化，因此在第一阶段的冲突检测开启之前，服务端可以从数据库中读取与基础属性对应的第一类冲突检测规则进行组件预封装，针对数据库中预配置了第一类冲突检测规则的基础属性分别封装出第一阶段的冲突检测组件，以便服务端在 开启了第一阶段的冲突检测后，可以直接读取已有的第一阶段的冲突检测组件针对待签约的软件产品的基础属性进行签约冲突检测。

当然，对于数据库中并未存储对应的冲突检测规则的基础属性，此时可以不进行特别处理。

需要说明的是，对冲突检测规则进行组件封装，是指将冲突检测规则转换为对应的处理逻辑(比如执行代码)，然后将处理逻辑封装成对应的模块化的组件的过程。

步骤202，基于所述第一阶段的冲突检测组件针对所述待签约产品的基础属性进行第一阶段的签约冲突检测，以确定所述待签约产品的基础属性与所述已签约产品的基础属性是否存在签约冲突；

在本例中，当服务端读取到第一阶段的冲突检测组件时，可以继续从数据库中读取用户待签约的软件产品的基础属性，然后执行第一阶段的冲突检测组件，针对该待签约的软件产品的基础属性分别进行签约冲突检测，来确定用户待签约的该软件产品的基础属性与用户已签约的软件产品的基础属性之间是否存在签约冲突。

如果用户待签约的该软件产品的基础属性与用户已签约的软件产品的基础属性之间，满足该第一冲突检测组件中封装的冲突检测规则，则表明用户待签约的该软件产品的基础属性与用户已签约的软件产品的基础属性之间存在签约冲突。

例如，以该待签约的软件产品为快捷卡产品、基础属性为快捷卡卡号为例，上述第一类冲突检测规则可以是开发人员为快捷卡卡号预配置的“同一个用户针对同一个卡号只能签约一次”的冲突检测规则，上述第一阶段的冲突检测组件可以是基于该冲突检测规则进行组件封装后得到的组件。

服务端在执行该组件针对用户待签约的该快捷卡产品进行签约冲突检测时，可以将该待签约的快捷卡的卡号，与该用户已签约过的快捷卡的卡号分别进行匹配。当该待签约的快捷卡的卡号与任一该用户已签约过的快捷卡的卡号匹配时，此时该待签约的快捷卡的卡号与该用户已签约的快捷卡的卡号满足上述冲 突检测规则，服务端可以确定该待签约的快捷卡的卡号与该用户已签约的快捷卡的卡号存在签约冲突。

步骤203，当所述待签约产品的任一基础属性与所述已签约产品的基础属性存在签约冲突时，终止所述待签约产品的签约流程。

在第一阶段的签约冲突检测过程中，如果服务端通过执行第一阶段的冲突检测组件，检测出用户待签约的软件产品的任意一个基础属性与该用户已签约的软件产品的基础属性存在签约冲突时，服务端可以直接终止本次签约流程。在这种情况下，服务端可以向用户的签约客户端发送一个通知消息，以通知用户本次签约由于签约冲突而终止。

步骤204，当所述待签约产品的产品属性与所述已签约产品的基础属性均不存在签约冲突时，则基于所述待签约产品的基础属性、所述用户的标识以及所述待签约产品的标识生成对应的冲突控制记录。

如果在第一阶段的签约冲突检测过程中，服务端检测出用户待签约的软件产品的基础属性与该用户已签约的软件产品的基础属性均不存在签约冲突时，此时第一阶段的签约冲突检测未检测到签约冲突，服务端还可以继续进行第二阶段的签约冲突检测。

其中，在继续进行第二阶段的签约冲突检测之前，由于还需要继续执行第二阶段的签约冲突检测，此时整个签约过程尚未完成，因此在这种情况下，服务端还可以基于该待签约产品的基础属性、该用户的id(比如用户名)以及该待签约产品的id生成一条对应的冲突控制记录。

该冲突控制记录仍然可以保存在上述数据库中，用于避免用户在签约过程中进行重复签约，当签约完成后服务端可以对该冲突控制记录自动进行清理。

在实际应用中，服务端在针对待签约的软件产品进行产品签约时，可以根据待签约产品的基础属性、该用户的id以及该待签约产品的id在数据库中匹配冲突控制记录，如果匹配到对应的冲突控制记录，表明该用户当前正在进行产品签约中(即冲突检测尚未完成)，在这种情况下，服务端可以立 即终止本次签约流程，以避免用户在签约的过程中重复的进行签约。

步骤205，基于预配置的与所述待签约产品的可变属性对应的第二类冲突检测规则执行第二阶段的签约冲突检测。

当服务端生成了上述冲突控制记录后，可以继续进行第二阶段的签约冲突检测。

请参见图3，图3为示出的第二阶段的签约冲突检测的流程图，其中，第二阶段的签约冲突检测在第一阶段的签约冲突检测未检测到签约冲突时启动，包括以下执行步骤：

步骤301，读取与所述可变属性对应的第二类冲突检测规则；

在本例中，服务端在启动第二阶段的签约冲突检测后，首先可以针对第一阶段的冲突检测完成后生成的冲突控制记录添加排它锁，其中为上述冲突控制记录添加排它锁后，该冲突控制记录将只能由与第二阶段的冲突检测对应的进程进行读取和修改，因此通过这种方式，可以在第二阶段的签约冲突检测的过程中，确保上述冲突控制记录不被其它进程所修改，可以避免由于上述冲突控制记录被修改而导致的用户在签约过程中重复签约的问题。

当服务端为上述签约冲突记录添加排它锁后，服务端可以判断数据库中是否存储了与用户待签约的软件产品的可变属性对应的第二类冲突检测规则，如果数据库中未存储与该软件产品的可变属性对应的任何冲突检测规则，则表明开发人员仅对该软件产品的基础属性预配置了对应的签约约束，因此在这种情况下，服务端可以结束针对该软件产品的签约冲突检测，基于用户的签约信息继续执行后续的签约流程。

当然，如果数据库中存储了与待签约的软件产品的可变属性对应的第二类冲突检测规则，此时服务端可以从数据库中读取上述第二类冲突检测规则。

其中，第二阶段的冲突检测组件，可以称之为可变属性冲突检测组件。由于可变属性通常为非共性产品属性(可能为开发人员个性化定制的产品属性)，对于同一类软件产品来说也可能会各不相同，因此开发人员为同一类软件产品的可变属性预配置的冲突检测规则，则也可能互不相同。

在这种情况下，如果服务端仍然采用在第一阶段的签约冲突检测时的组件预封装机制，对第二类冲突检测规则进行组件预封装，那么预封装得到的第二阶段的冲突组件，可能会由于组件中封装的冲突检测规则与开发人员实际配置的冲突检测规则不相同，而导致组件无法执行或者错误执行。

因此，服务端在启动第二阶段的签约冲突检测后，第二阶段的冲突检测组件可以不再采用第一阶段的签约冲突检测时的组件预封装机制，而是采用灵活配置的可插拔机制，可以基于开发人员预配置的第二类冲突检测规则“临时”进行组件封装得到第二阶段的冲突检测组件。

步骤302，对读取到的所述第二类冲突检测规则进行组件封装以得到第二阶段的冲突检测组件；

在本例中，在基于开发人员预配置的第二类冲突检测规则“临时”进行组件封装，得到的第二阶段的冲突检测组件，可以由若干不同的原子属性冲突检测组件组成。

其中，原子属性冲突检测组件为可插拔组件，每一个原子属性冲突检测组件可以分别对应待签约的软件产品的一个可变属性。对于不同的待签约的软件产品来说，在第二阶段的签约冲突检测组件中包含的原子属性冲突检测组件可以各不相同。

在针对不同的软件产品进行第二阶段的签约冲突检测时，服务端可以通过设置冲突检测引擎组件，由冲突检测引擎组件来协调运行不同的原子属性冲突组件，针对不同的软件产品的可变属性执行不同的原子属性冲突组件，从而实现差异化的冲突检测，可以为不同的软件产品提供个性化的冲突检测组件，以满足复杂的冲突场景中的冲突控制需求。

例如，假设软件产品a的可变属性包括原子属性1、原子属性2和原子属性3(原子属性是计算机领域的常用用于，表示所有可变属性中不可分割的单一属性)，组件封装生成的原子属性冲突组件包括组件1、组件2和组件3。

软件产品b的可变属性包括原子属性4、原子属性5和原子属性6组件封装生成的原子属性冲突组件包括组件1、组件2和组件3，组件封装生成的原子属性冲突组件包括组件4、组件5和组件6。

对于组件1～组件6，服务端可以均存储在数据库中，在针对产品a进行第二阶段的签约冲突检测时，冲突检测引擎组件可以协调运行组件1、组件2和组件3对产品a进行签约冲突检测；在针对产品b进行第二阶段的签约冲突检测时，冲突检测引擎组件可以协调运行组件4、组件5和组件6对产品a进行签约冲突检测；从而，可以针对产品a和产品b进行差异化的冲突检测，可以为产品a和产品b分别提供个性化的冲突检测组件。

可见，通过这种方式，可以为不同的软件产品灵活的配置原子属性检测组件，可以为不同的软件产品提供可插拔的冲突检测组件；同时，通过冲突检测引擎组件的协调，在第二阶段的签约冲突检测中，可以针对不同的软件产品可以分别执行不同的原子属性组件，从而可以满足开发人员对签约冲突检测个性化定制的需求。

步骤303，基于所述第二阶段的冲突检测组件针对所述待签约产品的可变属性进行第二阶段的签约冲突检测，以确定所述待签约产品的可变属性与所述已签约产品的可变属性是否存在签约冲突；

在本例中，当服务端基于读取到的第二类冲突检测规则进行“临时”的组件封装，针对数据库中预配置了第二类冲突检测规则的可变属性分别封装出对应的原子属性冲突检测组件后，可以继续从数据库中读取用户待签约的软件产品的可变属性，然后执行封装得到的各原子属性冲突检测组件对待签约的软件产品的可变属性分别进行签约冲突检测，来确定用户待签约的该软件产品的可变属性与用户已签约的软件产品的可变属性之间是否存在签约冲突。

如果用户待签约的该软件产品的可变属性与用户已签约的软件产品的可变属性之间，满足原子属性冲突检测规则中封装的冲突检测规则，则表明用户待签约的该软件产品的可变属性与用户已签约的软件产品的可变属性之间 存在签约冲突。

例如，以该待签约的软件产品为快捷卡产品、可变属性为快捷卡的签约时间段为例，上述第二类冲突检测规则可以是开发人员为快捷卡的签约事件端预配置的“签约时间段不能存在交集”的冲突检测规则，上述第一阶段的冲突检测组件可以是基于该冲突检测规则进行组件封装后得到的原子属性冲突检测组件。

服务端在执行该组件针对用户待签约的该快捷卡产品进行签约冲突检测时，可以将该待签约的快捷卡的签约时间段，与该用户已签约过的快捷卡的签约事件段分别进行匹配。当该待签约的快捷卡的签约时间段与任一该用户已签约过的快捷卡的签约时间段存在交集时，此时该待签约的快捷卡的签约时间段与该用户已签约的快捷卡的签约时间段满足上述冲突检测规则，服务端可以确定该待签约的快捷卡的签约时间段与该用户已签约的快捷卡的签约时间段存在签约冲突。

步骤304，当所述待签约产品的任一可变属性与所述已签约产品的可变属性存在签约冲突时，终止所述待签约产品的签约流程。

在第二阶段的签约冲突检测过程中，如果服务端通过执行封装得到的各原子属性冲突检测组件，检测出用户待签约的软件产品的任意一个可变属性与该用户已签约的软件产品的可变属性存在签约冲突时，服务端可以直接终止本次签约流程。在这种情况下，服务端可以向用户的签约客户端发送一个通知消息，以通知用户本次签约由于签约冲突而终止。

当然，如果在第二阶段的签约冲突检测过程中，服务端检测出用户待签约的软件产品的可变属性与该用户已签约的软件产品的可变属性均不存在签约冲突时，此时第二阶段的签约冲突检测未检测到签约冲突，服务端可以根据用户的签约信息执行后续的签约流程完成签约。

在本例中，当服务端针对用户待签约的软件产品完成第二阶段的签约冲突检测后，可以释放为已经生成的冲突控制记录添加的排它锁，然后清除该冲突控制记录。

其中，在清除该冲突控制记录时，服务端可以通过为冲突控制记录设置状态，并通过定时清理任务来完成清理。

例如，服务端可以在本地启动一个定时清理任务，周期性的对数据库中保存的冲突控制记录进行扫描，清除其中已完成状态的冲突控制记录。当服务端针对用户的待签约的软件产品的产品属性完成两阶段的冲突检测后，可以将冲突控制记录的状态更改为已完成状态，从而当上述定时清理任务扫描到该已完成状态的冲突控制记录后，可以对其进行清除。

可见，在以上实施例中，通过针对用户待签约的软件产品进行第一阶段的签约冲突检测以及第一阶段的签约冲突检测，即可以适用简单的签约冲突场景，基于软件产品的基础属性进行签约冲突检测，也可以适用复杂的签约冲突场景，基于由开发人员个性化定制的可变属性进行签约冲突检测，从而具有更好的通用性和可扩展性。

请参见图4，图4是本申请一实施例提供的一种与上述方法实施例对应的签约冲突检测系统的结构图。

该系统包括冲突控制协调组件、冲突控制配置组件、基础属性冲突检测组件、可变属性冲突检测引擎组件、若干原子属性检测组件以及控制记录清理组件；其中：

冲突控制协调组件，作为整个系统的协调器，可以通过加载冲突控制配置组件管理的数据库中存储的产品属性以及由开发人员预配置的冲突检测规则等冲突控制参数，对其他各组件进行任务编排、排它锁控制、更新冲突控制记录的状态等操作，来协调基础属性冲突检测组件、可变属性冲突检测引擎组件以及控制记录清理组件的运行。

冲突控制配置组件，管理服务端本地的数据库中，存储的产品属性以及由开发人员预配置的冲突检测规则等冲突控制参数。可以提供管理界面，作为统一的数据访问节点，为其它组件提供数据访问接口。当然，在分布式系统中，冲突控制配置组件也可以支持广播机制，可以将数据库中存储的冲突控制参数主动推送至分布式集群中其它各组件所在的设备，以达到控制组件 运行的目的。

基础属性冲突检测组件，该组件为第一阶段的冲突检测组件，根据从数据库中读取到的与基础属性对应的第一类冲突检测规则进行组件预封装后得到。该组件为通用组件，满足同一类型产品的共性需求。

可变属性冲突检测引擎组件，该组件为第二阶段的冲突检测的入口，用于针对开发人员为可变属性预配置的冲突检测规则进行组件封装，得到原子属性冲突检测组件。同时，用于协调执行各原子属性冲突检测组件的运行。在针对不同的软件产品进行第二阶段的签约冲突检测时，可变属性冲突检测引擎组件可以通过协调针对不同的软件产品执行不同的原子属性冲突检测组件。

原子属性冲突检测组件，为可插拔组件，该组件是否执行由可变属性冲突检测引擎组件来进行协调。对于不同的待签约的软件产品，可以包含不同的原子属性冲突检测组件，每一个原子属性冲突检测组件可以分别对应一个由开发人员自定义的可变属性，从而针对不同的软件产品可以定制不同的原子属性冲突检测组件，使得系统具有定制和可扩展的能力。

控制记录清理组件，用于启动定时清理任务，定时对已完成状态的冲突控制记录进行清除。

请参见图5，图5为示出的上述系统进行签约冲突检测的流程图。

在初始状态下，当用户签约一个软件产品时，冲突控制协调组件可以通过冲突控制配置组件提供的数据访问接口，从数据库中读取该软件产品的产品属性，并判断该软件产品的产品属性是否由开发人员预配置了对应的冲突检测规则，来确定该软件产品是否需要进行签约冲突检测。

如果该软件产品的产品属性已由开发人员预配置了对应的冲突检测规则，此时该软件产品需要进行签约冲突检测，冲突控制协调组件可以唤醒基础属性冲突检测组件，来驱动第一阶段的签约冲突检测，

当基础属性冲突检测组件被唤醒后，可以通过冲突控制配置组件提供的数据访问接口，从数据库中读取基础属性，其中读取的基础属性可以包括用 户待签约的该软件产品的基础属性，以及该用户已签约的软件产品的基础属性。

当基础属性冲突检测组件读取到基础属性后，可以通过执行组件针对待签约的该软件产品的基础属性进行第一阶段的签约冲突检测，以确定该待签约的软件产品的基础属性与该用户已签约的软件产品的基础属性是否存在签约冲突；如果不存在签约冲突，生成一条对应冲突控制记录。如果存在签约冲突，此时可以终止当前的签约流程。

当第一阶段的签约冲突检测完成后，冲突控制协调组件可以读取基础属性冲突检测组件的冲突检测结果，基于第一阶段的签约冲突检测的结果来判断是否继续进行第二阶段的签约冲突检测。

如果第一阶段的签约冲突检测未检测到签约冲突，此时继续进行第二阶段的签约冲突检测。冲突控制协调组件可以为第一阶段的签约冲突检测生成的冲突控制记录添加排它锁，以避免该冲突控制记录被修改。

当为冲突控制记录添加排它锁后，冲突控制协调组件可以唤醒可变属性冲突检测引擎组件，来驱动第二阶段的签约冲突检测。

当可变属性冲突检测引擎组件被唤醒后，可以通过冲突控制配置组件提供的数据访问接口，从数据库中读取该用户已签约的软件产品的可变属性、用户待签约的软件产品的可变属性，以及由开发人员为该待签约的软件产品的可变属性预配置的冲突检测规则。

当读取到上述信息后，可变属性冲突检测引擎组件可以根据读取到的该待签约的软件产品的可变属性，以及对应的冲突检测规则，依次进行组件封装得到若干原子属性冲突检测组件，然后执行封装得到的原子属性冲突检测组件，针对该待签约的软件产品的可变属性进行签约冲突检测，以确定该待签约的软件产品的可变属性与该用户已签约的软件产品的可变属性是否存在签约冲突。如果存在签约冲突，此时可以直接终止当前的签约流程。

当第二阶段的签约冲突检测完成后，冲突控制协调组件可以将冲突控制记录的状态修改为已完成状态，同时释放该冲突控制记录的排它锁。

控制记录清理组件，可以定时从数据库中读取已完成状态的冲突控制记录，当读取到已完成状态的冲突控制记录后，可以对该冲突控制记录进行清除，从而确保在第二阶段的签约冲突检测完成后，及清除冲突控制记录。

在以上各实施例中，通过基于软件产品的共性和个性化的签约冲突控制需求，将待签约产品的产品属性预先划分为基础属性和可变属性，在进行签约冲突控制时，按照两个阶段的签约冲突检测进行处理。在第一阶段，可以基于预配置的与基础属性对应的第一类冲突检测规则针对待签约产品进行签约冲突检测；在第二阶段，可以基于预配置的与可变属性对应的第二类冲突检测规则针对待签约产品进行签约冲突检测；实现了既可以在简单的签约冲突场景中基于基础属性来进行签约冲突检测，又可以在复杂的签约冲突场景中基于可变属性来进行签约冲突检测，从而具有更好的通用性和扩展性。

与上述方法实施例相对应，本申请还提供了装置的实施例。

请参见图6，本申请提出一种签约冲突检测装置60，应用于服务端；其中，请参见图7，作为承载所述签约冲突检测装置60的服务端所涉及的硬件架构中，通常包括cpu、内存、非易失性存储器、网络接口以及内部总线等；以软件实现为例，所述签约冲突检测装置60通常可以理解为加载在内存中的计算机程序，通过cpu运行之后形成的软硬件相结合的逻辑装置，所述装置60包括：

第一读取模块601，用于读取用户待签约产品的产品属性；

第二读取模块602，用于读取该用户已签约产品的产品属性；其中，所述产品属性被预先划分为基础属性和可变属性；

检测模块603，用于基于预配置的与所述待签约产品的基础属性对应的第一类冲突检测规则执行第一阶段的签约冲突检测，以及基于预配置的与所述待签约产品的可变属性对应的第二类冲突检测规则执行第二阶段的签约冲突检测，以确定所述待签约产品的产品属性与所述已签约产品的产品属性是否存在签约冲突。

在本例中，所述检测模块603具体用于：

读取预设的第一阶段的冲突检测组件；其中，所述第一阶段的冲突检测组件为基于所述第一类冲突检测规则进行组件预封装后得到的组件；

基于所述第一阶段的冲突检测组件针对所述待签约产品的基础属性进行第一阶段的签约冲突检测，以确定所述待签约产品的基础属性与所述已签约产品的基础属性是否存在签约冲突；

当所述待签约产品的任一基础属性与所述已签约产品的基础属性存在签约冲突时，终止所述待签约产品的签约流程。

在本例中，所述装置60还包括：

生成模块604，用于在所述待签约产品的基础属性与所述已签约产品的基础属性均不存在签约冲突时，基于所述待签约产品的基础属性、所述用户的标识以及所述待签约产品的标识生成对应的冲突控制记录；

终止模块605，用于在检测模块针对所述待签约产品进行第一阶段的签约冲突检测之前，如果查询到与所述待签约产品的基础属性、所述用户的标识以及所述待签约产品的标识匹配的冲突控制记录，则终止针对所述待签约产品的签约流程。

在本例中，所述检测模块603进一步用于：

当所述待签约产品的产品属性与所述已签约产品的基础属性均不存在签约冲突时，则基于预配置的与所述待签约产品的可变属性对应的第二类冲突检测规则执行第二阶段的签约冲突检测。

在本例中，所述检测模块603进一步用于：

读取与所述可变属性对应的第二类冲突检测规则；

对读取到的所述第二类冲突检测规则进行组件封装以得到第二阶段的冲突检测组件；

基于所述第二阶段的冲突检测组件针对所述待签约产品的可变属性进行第二阶段的签约冲突检测，以确定所述待签约产品的可变属性与所述已签约产品的可变属性是否存在签约冲突；

所述终止模块605进一步用于：

当所述待签约产品的任一可变属性与所述已签约产品的可变属性存在签约冲突时，终止所述待签约产品的签约流程。

在本例中，所述检测模块603进一步用于：

在读取与所述可变属性对应的第二类冲突检测规则之前，针对所述冲突控制记录添加排它锁，以避免所述冲突控制记录被修改。

在本例中，所述检测模块603进一步用于：

当所述待签约产品的可变属性与所述已签约产品的可变属性均不存在签约冲突时，完成针对所述待签约产品的产品签约，并释放为所述冲突控制记录添加的所述排它锁，以及清除所述冲突控制记录。

在本例中，所述产品属性基于json格式存储在预设数据库中。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。