CN116594598A - 业务系统的信息交互方法及装置 - Google Patents

Abstract

本公开实施例公开了一种业务系统的信息交互方法及装置，方法包括：响应于获取到前端的业务请求，按照预设的规则确定所述业务请求的主题，其中，预设的规则指示了不同类型业务请求的主题提取规则，预设的规则基于服务端与前端交互的约定规则确定，约定规则约定了针对不同类型业务请求，前端与服务端产生交互所需的主题内容；基于主题设置锁，并查询是否存在与设置的锁具有相同主题的锁；如果存在，则结束业务请求；如果不存在，则将业务请求发送至服务端。通过对不同的业务请求构建基于主题的锁，提高了幂等性能，降低了阻塞的概率，并且独立于前端和后端的设计，降低了前后端的开发难度和开发成本，增强了幂等设计在任何业务系统的适用性。

Description

业务系统的信息交互方法及装置

技术领域

本公开涉及信息处理技术领域，具体涉及到一种业务系统的信息交互方法及装置。

背景技术

在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。

在为业务系统进行幂等设计时，通过在数据字段增加索引的方式影响数据库性能不适合字段会被频繁更新的场景，并且唯一索引比普通索引在写操作上开销会大很多，因而存在适用性不佳、开发成本高的问题；通过使用临时表查询的方式，虽然不需要创建唯一索引，但是写操作会增加一次select子查询开销，增加sql语法的复杂度，因而会导致业务系统的执行效率不高、且经常出错的情形。

发明内容

本公开的主要目的在于提供一种业务系统的信息交互方法及系统。

为了实现上述目的，根据本公开的第一方面，提供了一种业务系统的信息交互方法，包括：响应于获取到前端的业务请求，按照预设的规则确定所述业务请求的主题，其中，所述预设的规则基于所述服务端与所述前端交互的约定规则确定，所述约定规则约定了针对不同类型业务请求，所述前端与所述服务端产生交互所需的主题内容，并且所述预设的规则指示了不同类型业务请求的主题提取规则；基于所述主题设置锁，并查询是否存在与所述设置的锁具有相同主题信息的锁；如果存在，则结束所述业务请求；如果不存在，则将所述业务请求发送至服务端。

可选地，方法还包括：如果所述主题与所述约定规则约定的与所述服务端产生交互所需的主题内容不一致，则结束所述业务请求。

可选地，基于所述主题设置锁之前，所述方法还包括：如果所述主题与所述约定规则约定的与所述服务端产生交互所需的主题内容一致，则基于所述主题设置锁。

可选地，将所述业务请求发送至所述服务端，由所述服务端执行对应的业务包括：将所述业务请求发送至所述服务端，由所述服务端判断所述业务请求是否被执行过；如果被执行过，则直接释放所述设置的锁；如果未被执行过，则执行所述业务请求，并在执行完毕后释放所述设置的锁。

可选地，方法还包括：在将所述业务请求发送至服务端后，所述设置的锁的状态更改为占用状态；在所述占用状态期间，如果存在与所述设置的锁包含相同主题信息的目标锁，则等待所述设置的锁被释放后，将所述目标锁对应的业务请求发送至所述服务端。

根据本公开的第二方面，提供了一种业务系统的信息交互装置，包括请求处理单元，被配置成响应于获取到前端的业务请求，按照预设的规则确定所述业务请求的主题，得到所述业务请求对应的主题信息；其中，所述预设的规则指示了不同类型业务请求的主题提取规则，所述预设的规则基于所述服务端与所述前端交互的约定规则确定，所述约定规则约定了针对不同类型业务请求，所述前端与所述服务端产生交互所需的主题内容；第一处理单元，被配置成基于所述主题设置锁，是否存在与所述设置的锁具有相同主题的锁；第二处理单元，被配置成如果存在，则结束所述业务请求；如果不存在，则将所述业务请求发送至服务端。

可选地，装置还包括：第三处理单元，被配成如果所述主题与所述约定规则约定的与所述服务端产生交互所需的主题内容不一致，则结束所述业务请求。

可选地，基于所述主题设置锁包括：如果所述主题与所述约定规则约定的与所述服务端产生交互所需的主题内容一致，则基于所述主题设置锁。

根据本公开的第三方面，提供了一种计算机可读存储介质，存储有计算机指令，所述计算机指令用于使所述计算机执行第一方面任意一项实现方式所述的业务系统的信息交互方法。

根据本公开的第四方面，提供了一种电子设备，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的计算机程序，所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器执行第一方面任意一项实现方式所述的方法。

本实施例业务系统的信息交互方法及装置，方法包括：响应于获取到前端的业务请求，按照预设的规则确定所述业务请求的主题，其中，所述预设的规则基于所述服务端与所述前端交互的约定规则确定，所述约定规则约定了针对不同类型业务请求，所述前端与所述服务端产生交互所需的主题内容，并且所述预设的规则指示了不同类型业务请求的主题提取规则；基于所述主题设置锁，并查询是否存在与所述设置的锁具有相同主题的锁；如果存在，则结束所述业务请求；如果不存在，则将所述业务请求发送至服务端。通过对不同的业务请求构建基于主题信息的锁，提高了幂等性能，降低了阻塞的概率，并且独立于前端和后端的设计，降低了前后端的开发难度和开发成本，增强了幂等设计在任何业务系统的适用性。进而解决了相关技术中幂等设计成本高，复杂度高，幂等性能不佳的缺陷。

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

附图说明

图1是根据根据本公开实施例的业务系统的信息交互方法的流程图；

图2是根据本公开实施例的电子设备的示意图。

具体实施方式

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

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

适用于本实施例的系统架构可以包括前端、服务端，本实施例的前端和服务端区分是基于一套软件架构体系前后的顺序的角度上进行描述，app、h5、小程序等和用户交互的可以称呼为前端；统一为前端服务的接口服务等归为后端，也即本实施例中的服务端。

执行本实施例方法的执行主体可以位于服务端，并且独立于服务端的其他业务处理功能模块，在形式上，执行本实施例方法的主体与执行其他业务处理的功能模块可以位于一台服务器内，也可以是位于服务器集群不同的服务器内，在此不做限定，本实施例下述的服务端默认为服务端的其他业务处理功能模块。

执行本实施例方法的执行主体可以抽象为前台的概念，执行主体可以位于服务端，并且独立于服务端的其他业务处理功能模块，前端和后端只需关注业务逻辑的实现，而无需关注幂等的实现，进而无需对前端或者后端的业务逻辑进行更改。

需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本公开。

根据本公开实施例，提供了一种业务系统的信息交互方法，如图1所示，包括如下的步骤101至步骤103：

步骤101：响应于获取到前端的业务请求，按照预设的规则确定所述业务请求的主题信息，得到所述业务请求对应的主题信息；预设的规则指示了不同类型业务请求的主题提取规则，所述预设的规则基于所述服务端与所述前端交互的约定规则确定，所述约定规则约定了针对不同类型业务请求，所述前端与所述服务端产生交互所需的主题内容。

在本实施例中，约定规则由服务端方制定，约定规则约定的内容可以包括服务端能够处理的业务请求是什么，针对能够处理的不同类型业务请求应当提取的主题内容是什么，通过前端触发的业务请求多，以互联网医院为例，业务请求包括支付、问诊下单等等，每种业务请求的目的是不同的，本实施例在约定提取的主题内容时，旨在提取的主题内容具有唯一性，本实施例将业务请求类型分为两类：

一类是业务请求的消息体中具有唯一标识的请求，唯一标识直接存在于请求的消息体中，比如以互联网医院为例，支付后的发出的请求均携带单据号。这一类的业务请求通常具有明确的标识，请求目的通常包括请求查询、更新和删除等，可以将该唯一性标识直接作为约定规则中约定的主题内容。

另一类是请求的消息体中不直接具有唯一标识的请求，比如以互联网医院为例，支付前的请求不携带单据号。针对请求的消息体中不具备唯一性标识的请求，约定规则约定提取的主题内容也应当具备唯一性，比如约定提取消息体中的请求主体、被请求的内容（如请求所针对的内容）等作为主题内容中的要素，所有要素的组合能够唯一标识业务请求。示例性地，以互联网医院为例，如果请求是问诊下单请求，则请求主体信息可以是请求人，被请求的内容可以是下单医生的信息，这仅仅是示例性的。这一类的业务请求因为消息体中没有唯一标识，请求的目的通常是数据库插入，可以在约定规则中约定要素作为主题内容。针对无唯一标识的请求幂等设计是最难的，而通过本实施例的方法能够应对两种类型的请求，并且避免业务请求处理错误。

通过预先定义的业务接口接收前端的业务请求，并按照服务端约定对业务请求进行处理。示例性地，当接收到前端发送的业务请求后，从业务请求消息体中进行目标内容的提取得到主题信息，即服务端预先定义业务请求对应的主题构成内容，在提取时按照主题构成内容进行提取，可以理解的是，提取可以解释为读取，即不用必须将读取到的信息抽取出来存储到一定存储空间中，而只需要读取得到响应的信息即可。

进一步地，当制定该约定规则后，本实施例执行主体可以按照约定规则约定的内容执行预设的第一规则，以有针对性的提取不同业务请求的主题信息。预设的第一规则定义了约定规则约定的不同业务请求应当提取的内容是什么，来确定提取当前接收到的业务请求何种主题。

约定规则除了可以约定主题信息提取规则外，约定规则约定的内容还可以包括如何处理前端发送的业务请求规则，本实施例执行主体可以按照约定规则约定的内容执行预设的第二规则，以对业务请求进行直接转发至服务端处理、或者按照本实施例的方法提取主题信息后进一步实现业务请求的过滤或者处理。预设的第二规则定义了根据约定规则约定的业务请求处理方来确定当前接收到业务请求通过哪个方式来处理。如果不直接转发至服务端处理，则可以按照本实施例的方法对业务请求按照约定规则约定的与所述服务端产生交互所需的主题内容进行主题信息提取，而后进行锁设置等步骤。

示例性地，按照约定规则约定的内容执行预设的第二规则在实现时，可以包括响应于获取到前端的业务请求，按照预设的第二规则判断所述业务请求是否不直接转发服务端处理，如果不直接转发服务端处理，则按照预设的规则（即预设的第一规则）确定所述业务请求的主题信息，而后执行设置锁、以及判断业务请求是否需要被执行的步骤。

在实现步骤101时，可以定义业务接口以定义预设的规则、并且定义业务接口实现方法来实现上述预设规则。

通过本可选的实现方式，服务端能处理或者不能处理哪些业务，前端无需关注，只需要根据服务端的规则，为本实施例执行主体制定预设的规则，并由执行主体实现即可，无论前端何种业务请求均能够被处理，对前端无感，前端无需因为后端做出代码层面的改进。并且从服务端规则的维度制定规则，能够保证所有业务请求的规则都是统一的。一旦后端需求改变，也无需对后端的业务逻辑进行改进，后端只需要更改约定规则，进而执行主体可以根据约定规则更改预设的规则并实现即可。

示例性地，如果需要对某种业务请求的处理方式进行更改，可以基于约定规则指示的更改方式，对预设的规则进行修改。对某种业务请求的处理方式进行更改情形包括比如，有的业务请求需要从无幂等性转换为幂等性；或者需要从有幂等性转换为无幂等性，在实现时可以是直接对业务接口定义的第二预设规则进行更改。

示例性地，如果需要对某些业务请求的幂等设计具体内容进行修改，比如同一个业务类型业务请求之前具备幂等性，现在仍然需要具备幂等性，但执行幂等性设计方法时，要求的主题不同，该情形下可以对第二预设规则进行修改，具体可以是对提取主题的内容进行修改，比如，用户注册请求，需要对注册请求幂等设计进行更改，则可以对约定提取的主题内容进行更改，比如需要确定的主题内容由“姓名”、“身份证号”更改为“姓名”、“身份证号”、“空格符”表示，如果业务请求中只包含“姓名”、“身份证号”，则该业务请求将不会被设置锁，进而不会被服务端处理。通过该方式，服务端能够对业务请求进行可控化处理。

作为本实施例一种可选的实现方式，如果所述主题信息与所述约定规则约定的与所述服务端产生交互所需的主题内容不一致，则结束所述业务请求。

在本可选的实现方式中，约定规则除了可以约定提取哪些维度信息作为主题信息以外，还可以进一步约定哪些信息需要一致性验证，进而基于预设的规则（即预设的第一规则）来实现。

示例性地，如果约定规则约定了提取订单号信息，并且只对订单号为1002的请求进行处理，那么可以提取订单号信息，如果订单号信息提取到的1001，验证1001和1002的一致性，订单号1001与1002不一致，则不对该业务请求处理，直接结束该请求，不再设置锁；而如果约定需要一致性验证的信息是一致的，那么可以继续设置锁，通过本方式保证了业务请求的合法性，并且该方式使后端具备业务请求的控制能力。

作为本实施例一种可选的实现方式，基于所述主题设置锁之前，所述方法还包括：如果所述主题与所述约定规则约定的与所述服务端产生交互所需的主题内容一致，则基于所述主题设置锁。

在本可选的实现方式中，由前服务能处理或者不能处理哪些业务，前端无需关注，可随时按需无任何限制的发送业务请求，执行主体提取业务请求中的主题，并按照预设的规则进行判断该主题是否约定规则约定的主题内容，如果不是，则代表业务请求不由服务端处理，通过该方式降低了服务端的处理量。

步骤102：基于所述主题信息设置锁，并查询是否存在与所述设置的锁具有相同主题信息的锁。

在本实施例中，当确定主题信息后，基于主题信息设置锁的内容，其中锁的内容除了包含主题信息外，还包含锁的时间信息，如waitTime 、lesaseTime、timeUnit。在设置完成后，可以从缓存或者MQ队列中查找是否存在包含相同主题信息的锁，缓存或者MQ队列中包括正在占用的锁、以及未被占用按时间排队等待被处理的锁、还可以从锁的历史记录中查询是否有包含相同主题的锁，如果有则证明相同的业务请求被处理过，其中，当业务请求被处理成功后，业务请求对应的锁被记录，形成锁的历史记录。

进一步地，在实际运行过程中，存在业务请求被处理异常的情形，如果业务请求被处理异常，则记录响应的异常信息，进入异常处理流程中以自动进行业务逻辑补偿，如果补偿失败，则应当允许该业务请求重新被处理。在自动进行业务逻辑补偿时，通过预定的执行方式尽最大可能完成全量业务逻辑补偿，并发出告警信息（比如：系统网络堵塞、服务器负载过大等），以使运维者知悉。如果业务逻辑自动补偿失败，则进行人工干预，对于上述业务逻辑补偿成功，则将业务请求对应的锁进行记录。

对于被处理失败的业务请求，没有锁的记录信息，当再次获取到相同的业务请求后可以再次执行该业务请求。

步骤103：如果存在，则结束所述业务请求；如果不存在，则将所述业务请求发送至服务端。

在本实施例中，在设置完成后，一旦当前存在占用锁、缓存队列或者消息队列中存在相同主题信息未被占用的锁、或者历史锁信息中存在相同主题的锁，则结束当前业务；如果未被占用、缓存队列或者消息队列中不存在具有相同主题且未被占用的锁、或者历史锁信息中不存在相同主题的锁，则将业务请求发送至服务端，由服务端对业务请求进行响应。

本实施例能够对不同的业务请求构建基于主题信息的细粒度锁，提高了幂等系统的处理性能，并且独立于前端和后端的设计，降低了前后端的开发难度和开发成本，并且增强了幂等设计在任何业务系统的适用性。并且本实施例采用了基于主题的锁，使阻塞的概率极低，提高了业务处理能力。

作为本实施例一种可选的实现方式，将所述业务请求发送至所述服务端，由所述服务端执行对应的业务包括：将所述业务请求发送至所述服务端，由所述服务端判断所述业务请求是否被执行过；如果被执行过，则直接释放所述设置的锁；如果未被执行过，则执行所述业务请求，并在执行完毕后释放所述设置的锁。

在本可选的实现方式中，发送至服务端后，服务端可以判断该请求对应的业务是否被处理过，如果未被处理过则进行业务处理。比如，对身份证号1111姓名为张三的用户进行注册的业务请求被发送至服务端后，服务端判断该业务请求是否被执行过，如果未被执行过则执行注册动作，并在执行完毕后，释放设置的锁；否则直接释放对应设置的锁。

对于因为各种漏洞，比如执行主体执行本实施例方法存在了漏洞而导致相同业务请求未被过滤，在此基础上通过本可选的实现方式，服务端进行二次判断，避免重复执行，保护服务端的计算能力。通过本可选的实现方式，提高了幂等性能，并且将重复执行错误率降到了最低。

进一步地，在服务端执行完毕后，可以增设额外的补偿机制，基于不同主题获取不同业务请求，而后判断业务请求的执行是否正确，如果执行不正确比如对于未付款成功，但执行支付成功的业务请求，则进行回滚，并可以给出告警信息。

作为本实施例一种可选的实现方式，所述方法还包括：在将所述业务请求发送至服务端后，所述设置的锁的状态更改为占用状态；在所述占用状态期间，如果存在与所述设置的锁包含相同主题信息的目标锁，则等待所述设置的锁被释放后，将所述目标锁对应的业务请求发送至所述服务端，以由服务端判断是否执行过与目标锁相同的锁所指向的业务请求。

在本可选的实现方式中，实际场景中存在如下情形，比如不同业务请求被设置了相同主题内容的锁，即出现了加锁异常，对于该情形可以由异常处理功能模块进行处理，并且与此同对异常的锁进行释放。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

根据本公开实施例，还提供了一种业务系统的信息交互装置，请求处理单元，被配置成响应于获取到前端的业务请求，按照预设的规则确定所述业务请求的主题，得到所述业务请求对应的主题信息；其中，所述预设的规则指示了不同类型业务请求的主题提取规则，所述预设的规则基于所述服务端与所述前端交互的约定规则确定，所述约定规则约定了针对不同类型业务请求，所述前端与所述服务端产生交互所需的主题内容；第一处理单元，被配置成基于所述主题设置锁，是否存在与所述设置的锁具有相同主题的锁；第二处理单元，被配置成如果存在，则结束所述业务请求；如果不存在，则将所述业务请求发送至服务端。

作为本实施例一种可选的实现方式，装置还包括：第三处理单元，被配成如果所述主题与所述约定规则约定的与所述服务端产生交互所需的主题内容不一致，则结束所述业务请求。

作为本实施例一种可选的实现方式，基于所述主题设置锁包括：如果所述主题与所述约定规则约定的与所述服务端产生交互所需的主题内容一致，则基于所述主题设置锁。

本公开实施例提供了一种电子设备，如图2所示，该电子设备包括一个或多个处理器21以及存储器22，图2中以一个处理器21为例。

该控制器还可以包括：输入装置23和输出装置24。

处理器21、存储器22、输入装置23和输出装置24可以通过总线或者其他方式连接，图2中以通过总线连接为例。

处理器21可以为中央处理器（CentralProcessingUnit，CPU）。处理器21还可以为其他通用处理器、数字信号处理器（DigitalSignalProcessor，DSP）、专用集成电路（ApplicationSpecificIntegratedCircuit，ASIC）、现场可编程门阵列（Field-ProgrammableGateArray，FPGA）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等芯片，或者上述各类芯片的组合。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器22作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序、非暂态计算机可执行程序以及模块，如本公开实施例中的控制方法对应的程序指令/模块。处理器21通过运行存储在存储器22中的非暂态软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例的方法。

存储器22可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据服务器操作的处理装置的使用所创建的数据等。此外，存储器22可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施例中，存储器22可选包括相对于处理器21远程设置的存储器，这些远程存储器可以通过网络连接至网络连接装置。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置23可接收输入的数字或字符信息，以及产生与服务器的处理装置的用户设置以及功能控制有关的键信号输入。输出装置24可包括显示屏等显示设备。

一个或者多个模块存储在存储器22中，当被一个或者多个处理器21执行时，执行如图1所示的方法。

本领域技术人员可以理解，实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成的程序，可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述方法的实施例的流程。其中，存储介质可为磁碟、光盘、只读存储记忆体（Read-OnlyMemory，ROM）、随机存储记忆体（RandomAccessMemory，RAM）、快闪存储器（FlashMemory）、硬盘（HardDiskDrive，缩写：HDD）或固态硬盘（Solid-StateDrive，SSD)等；存储介质还可以包括上述种类的存储器的组合。

虽然结合附图描述了本公开的实施方式，但是本领域技术人员可以在不脱离本公开的精神和范围的情况下作出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。

Claims (10)

1.一种业务系统的信息交互方法，其特征在于，包括：

响应于获取到前端的业务请求，按照预设的规则确定所述业务请求的主题，其中，所述预设的规则指示了不同类型业务请求的主题提取规则，所述预设的规则基于服务端与所述前端交互的约定规则确定，所述约定规则约定了针对不同类型业务请求，所述前端与所述服务端产生交互所需的主题内容；

基于所述主题设置锁，并查询是否存在与所述设置的锁具有相同主题的锁；

如果存在，则结束所述业务请求；如果不存在，则将所述业务请求发送至所述服务端。

2.根据权利要求1所述的业务系统的信息交互方法，其特征在于，所述方法还包括：

如果所述主题与所述约定规则约定的与所述服务端产生交互所需的主题内容不一致，则结束所述业务请求。

3.根据权利要求2所述的业务系统的信息交互方法，其特征在于，基于所述主题设置锁包括：

如果所述主题与所述约定规则约定的与所述服务端产生交互所需的主题内容一致，则基于所述主题设置锁。

4.根据权利要求1所述的业务系统的信息交互方法，其特征在于，将所述业务请求发送至所述服务端，由所述服务端执行对应的业务包括：

将所述业务请求发送至所述服务端，由所述服务端判断所述业务请求是否被执行过；

如果被执行过，则直接释放所述设置的锁；

如果未被执行过，则执行所述业务请求，并在执行完毕后释放所述设置的锁。

5.根据权利要求1所述的业务系统的信息交互方法，其特征在于，所述方法还包括：

在将所述业务请求发送至所述服务端后，所述设置的锁的状态更改为占用状态；

在所述占用状态期间，如果存在与所述设置的锁包含相同主题的目标锁，则等待所述设置的锁被释放后，将所述目标锁对应的业务请求发送至所述服务端。

6.一种业务系统的信息交互装置，其特征在于，包括：

请求处理单元，被配置成响应于获取到前端的业务请求，按照预设的规则确定所述业务请求的主题，得到所述业务请求对应的主题信息；其中，所述预设的规则指示了不同类型业务请求的主题提取规则，所述预设的规则基于服务端与所述前端交互的约定规则确定，所述约定规则约定了针对不同类型业务请求，所述前端与所述服务端产生交互所需的主题内容；

第一处理单元，被配置成基于所述主题设置锁，是否存在与所述设置的锁具有相同主题的锁；

第二处理单元，被配置成如果存在，则结束所述业务请求；如果不存在，则将所述业务请求发送至所述服务端。

7.根据权利要求6所述的业务系统的信息交互装置，其特征在于，装置还包括：

第三处理单元，被配成如果所述主题与所述约定规则约定的与所述服务端产生交互所需的主题内容不一致，则结束所述业务请求。

8.根据权利要求6所述的业务系统的信息交互装置，其特征在于，基于所述主题设置锁包括：

如果所述主题与所述约定规则约定的与所述服务端产生交互所需的主题内容一致，则基于所述主题设置锁。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，所述计算机指令用于使所述计算机执行权利要求1-5任意一项所述的业务系统的信息交互方法。

10.一种电子设备，其特征在于，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的计算机程序，所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器执行权利要求1-5任意一项所述的业务系统的信息交互方法。