消息传输方法及系统与流程

文档序号:11949831阅读:372来源:国知局
消息传输方法及系统与流程

本发明涉及计算机技术领域,具体而言,涉及一种消息传输方法及系统。



背景技术:

消息中间件是一套系统(或平台),用于应用程序之间进行通信,系统通过消息传递完成交互,消息中间件应用于如图1所示的应用环境中。如图1所示,消息生产者、消息中间件与消息消费者之间存在数据交互,消息生产者用于发送消息数据至消息中间件,消息消费者用于从消息中间件获取消息数据并交给业务系统使用。通常情况下,消息生产者对应的终端设备称为消息生产端,消息消费者对应的终端设备称为消息消费端,消息中间件对应的终端设备称为消息服务器。

目前,基于如图1所示的消息数据发送机制不够完善,例如,消息生产端向消息服务器发送消息数据,针对同一条消息数据,消息生产端只向消息服务器发送一次,如果消息生产端与消息服务器之间出现网络瞬断,或者消息服务器自身发送故障,都有可能造成消息服务器接收不到该消息,或者消息服务器接收到该消息后没能成功返回接收确认信息,致使消息生产端报错,消息生产端与消息服务器之间传递消息数据的可靠性差。

针对上述提出的现有的消息数据发送机制不够完善的问题,目前尚未提出有效的解决办法。



技术实现要素:

有鉴于此,本发明的目的在于提供一种消息传输方法及系统,以缓解现有的消息数据发送机制不够完善的问题。

第一方面,本发明实施例提供了一种消息传输方法,所述方法包括:消息生产端对当前事务进行处理,在所述当前事务的处理过程中生成需要发送的消息数据;所述消息生产端建立所述当前事务与所述消息数据之间的捆绑提交关系;当所述当前事务提交成功时,所述消息生产端采用定时补偿策略向消息服务器发送所述消息数据。

结合第一方面,本发明实施例提供了第一方面第一种可能的实施方式,其中,所述消息生产端采用定时补偿策略向消息服务器发送所述消息数据,包括:所述消息生产端向消息服务器发送所述消息数据;所述消息生产端检测在预设时间内是否接收到所述消息服务器返回的接收成功标识;若未接收到,则所述消息生产端重复发送所述消息数据,并重复所述检测动作,直至接收到所述接收成功标识。

结合第一方面上述的实施方式,本发明实施例提供了第一方面第二种可能的实施方式,其中,所述方法还包括:消息消费端接收所述消息服务器发送的消息数据;所述消息消费端判断所述消息数据是否为首次接收;若是,则所述消息消费端保存所述消息数据,并向所述消息服务器返回消费成功标识,否则,所述消息消费端直接向所述消息服务器返回消费成功标识。

结合第一方面第二种可能的实施方式,本发明实施例提供了第一方面第三种可能的实施方式,其中,所述消息消费端判断所述消息数据是否为首次接收,包括:所述消息消费端根据所述消息数据的唯一标识在数据库内进行查找,若未查找到与所述唯一标识相同的消息数据,则确定所述消息数据为首次接收,否则,确定所述消息数据为非首次接收。

结合第一方面或第一方面第一种可能的实施方式,本发明实施例提供了第一方面第四种可能的实施方式,其中,所述方法还包括:所述消息消费端根据当前获取的消息数据的序号判断所述当前获取的消息数据是否满足当前的处理顺序,若满足,则对所述当前获取的消息数据进行处理,否则挂起所述当前获取的消息数据,其中,所述当前获取的消息数据的序号与所述消息生产端发送所述当前获取的消息数据的时间顺序一致;所述消息消费端按照预设的扫描策略对挂起的所述消息数据进行扫描,当扫描到满足当前的处理顺序的消息数据时,对扫描到的所述消息数据进行处理。

第二方面,本发明实施例提供了一种消息传输系统,所述系统包括消息生产端、消息服务器和消息消费端;所述消息生产端对当前事务进行处理,在所述当前事务的处理过程中生成需要发送的消息数据;所述消息生产端建立所述当前事务与所述消息数据之间的捆绑提交关系;当所述当前事务提交成功时,所述消息生产端采用定时补偿策略向所述消息服务器发送所述消息数据。

结合第二方面,本发明实施例提供了第二方面第一种可能的实施方式,其中,所述消息生产端包括:发送模块,用于向所述消息服务器发送所述消息数据;检测模块,用于检测在预设时间内是否接收到所述消息服务器返回的接收成功标识;重复模块,用于若所述检测模块未接收到所述接收成功标识,则重复执行所述发送模块和所述检测模块的动作,直至接收到所述接收成功标识。

结合第二方面上述的实施方式,本发明实施例提供了第二方面第二种可能的实施方式,其中,所述消息消费端接收所述消息服务器发送的消息数据;所述消息消费端判断所述消息数据是否为首次接收;若是,则所述消息消费端保存所述消息数据,并向所述消息服务器返回消费成功标识,否则,所述消息消费端直接向所述消息服务器返回消费成功标识。

结合第二方面第二种可能的实施方式,本发明实施例提供了第二方面第三种可能的实施方式,其中,所述消息消费包括:查找模块,用于根据所述消息数据的唯一标识在数据库内进行查找;确定模块,用于若所述查找模块未查找到与所述唯一标识相同的消息数据,则确定所述消息数据为首次接收,否则,确定所述消息数据为非首次接收。

结合第二方面或第二方面第一种可能的实施方式,本发明实施例提供了第二方面第四种可能的实施方式,其中,所述消息消费端根据当前获取的消息数据的序号判断所述当前获取的消息数据是否满足当前的处理顺序,若满足,则对所述当前获取的消息数据进行处理,否则挂起所述当前获取的消息数据,其中,所述当前获取的消息数据的序号与所述消息生产端发送所述当前获取的消息数据的时间顺序一致;所述消息消费端按照预设的扫描策略对挂起的所述消息数据进行扫描,当扫描到满足当前的处理顺序的消息数据时,对扫描到的所述消息数据进行处理。

本发明实施例中,消息生产端首先对当前事务进行处理,在当前事务的处理过程中生成需要发送的消息数据,消息生产端然后建立当前事务与消息数据之间的捆绑提交关系,最后,在当前事务处理成功时,消息生产端采用定时补偿策略向消息服务器发送消息数据。由于本发明实施例中消息生产端采用定时补偿策略向消息服务器发送消息数据,即重复多次向消息服务器发送消息数据,因此与现有技术相比,通过本实施例中的消息传输方法及系统能够缓解现有的消息数据发送机制不够完善的问题,尤其能够缓解消息生产端与消息服务器之间传递消息数据的可靠性差的问题,提高消息生产端与消息服务器之间传递消息数据的可靠性。

为使本发明的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。

附图说明

为了更清楚地说明本发明实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本发明的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。

图1示出了本发明实施例所提供的现有技术中的消息中间件的应用环境示意图;

图2示出了本发明实施例所提供的消息传输方法的第一种流程示意图;

图3示出了本发明实施例所提供的消息传输方法的第二种流程示意图;

图4示出了本发明实施例所提供的消息传输方法的第三种流程示意图;

图5示出了本发明实施例所提供的消息传输系统的组成示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围,而是仅仅表示本发明的选定实施例。基于本发明的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本发明保护的范围。

考虑到现有的消息数据发送机制不够完善的问题,本发明提供了消息传输方法及系统,下面结合实施例进行详细描述。

图2示出了本发明实施例所提供的消息传输方法的第一种流程示意图,如图2所示,本发明实施例中的方法包括以下步骤。

步骤S202,消息生产端对当前事务进行处理,在当前事务的处理过程中生成需要发送的消息数据。

消息生产端在处理当前事务的过程中,能够生成需要发送的消息数据,该消息数据可以是程序函数的返回值,也可以是其他消息数据。

步骤S204,消息生产端建立当前事务与消息数据之间的捆绑提交关系。

本步骤中,为了保证当前事务与消息数据之间的一致性,即为了保证当前事务提交成功时发送消息数据,当前事务提交失败时不发送消息数据,需要建立当前事务与消息数据之间的捆绑提交关系。考虑到数据库事务本身的一致性,本步骤中,消息生产端建立当前事务与消息数据之间的捆绑提交关系,包括:消息生产端在当前事务提交时,将当前事务和消息数据一同写入数据库内。通过该一起写入数据库的动作,能够利用数据库事务本身的一致性防止当前事务提交成功但消息数据未发送的情况,以及防止当前事务提交失败然而消息数据误发送的情况。

步骤S206,当上述当前事务提交成功时,消息生产端采用定时补偿策略向消息服务器发送消息数据。

考虑到通过重复发送机制能够提高消息生产端与消息服务器之间消息数据传输的可靠性,因此本步骤中消息生产端采用定时补偿策略向消息服务器发送消息数据。

本步骤中,消息生产端采用定时补偿策略向消息服务器发送消息数据,具体包括:(a1)消息生产端向消息服务器发送消息数据,(a2)消息生产端检测在预设时间内是否接收到消息服务器返回的接收成功标识,(a3)若未接收到,则消息生产端重复发送该消息数据,并重复该检测动作,直至接收到接收成功标识。

上述接收成功标识可以是固定的信号指令,如“接收成功”。一种优选的实施例中,该接收成功标识还包括与其对应的消息数据的唯一标识符,该唯一标识符能够由消息生产端定义。例如,某条消息数据,消息生产端定义其唯一标识符为0005,消息生产端将该条消息数据发送至消息服务器,消息服务器接收到该条消息数据后,向消息生产端返回的接收成功标识可以是“成功接收消息数据0005”。

本发明实施例中,消息生产端首先对当前事务进行处理,在当前事务的处理过程中生成需要发送的消息数据,消息生产端然后建立当前事务与消息数据之间的捆绑提交关系,最后,在当前事务处理成功时,消息生产端采用定时补偿策略向消息服务器发送消息数据。由于本发明实施例中消息生产端采用定时补偿策略向消息服务器发送消息数据,即重复多次向消息服务器发送消息数据,因此与现有技术相比,通过本实施例中的消息传输方法能够缓解现有的消息数据发送机制不够完善的问题,尤其能够缓解消息生产端与消息服务器之间传递消息数据的可靠性差的问题,提高消息生产端与消息服务器之间传递消息数据的可靠性。

现有技术中,消息服务器在接收到消息生产端发送的消息数据后,以队列或者其他形式将该消息数据发送至消息消费端,消息消费端接收到消息服务器发送的消息数据后,对该消息数据进行消费,即进行处理,当消息消费端对消息数据消费成功时,消息消费端向消息服务器返回消费成功标识,以使消息服务器继续向消息消费端发送下一消息数据。基于该种消息服务器与消息消费端之间的消息数据收发机制,若消息消费端由于故障等原因长时间没能对消息数据消费成功,则消息消费端将一直不会向消息服务器返回消费成功标识,致使消息服务器无法发送下一消息数据,致使消息服务器内的消息数据积压或阻塞。

考虑到上述的由于消息消费端长时间没能对消息数据消费成功,导致消息服务器内的消息数据积压或阻塞的问题,图3示出了本发明实施例所提供的消息传输方法的第二种流程示意图,如图3所示,本实施例中的方法还包括以下步骤:

步骤S302,消息消费端接收消息服务器发送的消息数据。

步骤S304,消息消费端判断该消息数据是否为首次接收。

本步骤中,消息消费端判断该消息数据是否为首次接收,包括:消息消费端根据该消息数据的唯一标识在数据库内进行查找,若未查找到与该唯一标识相同的消息数据,则确定该消息数据为首次接收,否则,确定该消息数据为非首次接收。

具体地,消息数据的唯一标识能够由消息生产端定义,消息生产端对消息数据定义唯一标识后,消息生产端将该消息数据发送至消息服务器,消息服务器采用队列的形式将该消息数据发送至消息消费端。当消息消费端接收到消息数据后,获取该消息数据的唯一标识,并根据该唯一标识在数据库内进行查找,若查找到与该唯一标识相同的消息数据,说明该条消息数据之前已经保存过,也就是该条消息数据不是首次接收,若没有查找到与该唯一标识相同的消息数据,说明该条消息数据之前没有保存过,也就是该条消息数据是首次接收,其中,消息消费端将接收到的消息数据保存在数据库内。

步骤S306,若是,则消息消费端保存该消息数据,并向消息服务器返回消费成功标识,否则,消息消费端直接向消息服务器返回消费成功标识。

消息消费端在接收到消息数据后,先将接收到的消息数据进行保存,并向消息服务器返回消费成功标识,然后再对保存的消息数据进行消费。一种优选的实施例中,消费成功标识包括与其对应的消息数据的唯一标识符,该唯一标识符能够由消息生产端定义。例如,某条消息数据,消息生产端定义其唯一标识符为0000X,消息服务器将该条消息数据发送至消息消费端,消息消费端接收到该条消息数据后进行保存,并向消息服务器返回内容为“成功消费消息数据0000X”的消费成功标识。

与现有技术相比,上述步骤S306中,消息消费端保存该消息数据后,不进行消费,直接向消息服务器返回消费成功标识,能够保证消息服务器在接收到消费成功标识后,继续发送下一个消息数据,从而缓解消息服务器内的消息数据积压或阻塞的问题。

消息服务器向消息消费端发送消息数据,如果消息服务器没有接收到消息消费端返回的消费成功标识,则消息服务器将再次发送该条消息数据,基于此,消息消费端存在同一条消息数据接收保存两次的情况,由于消息消费端对于相同的消息数据保存多次,因此消息消费端可能存在消息数据重复处理的情况。现有技术中,在使用消息服务器时,消息消费端需做业务的幂等性校验,即对标识相同的消息数据仅做一次处理,从而防止消息服务器重复发送消息数据造成的业务重复处理。

本实施例中,通过上述步骤S304和步骤S306,若消息数据为首次接收,则消息消费端保存该消息数据并返回消费成功标识,若消息数据不是首次接收,则消息消费端不再进行保存,而是直接返回消费成功标识,也就是,消息消费端对于同一条消息数据只保存一次,因此当消息消费端在进行消息处理时,对于每条消息数据仅会处理一次,因此通过上述步骤S304和步骤S306,消息消费端无需再进行幂等性校验就能够防止消息重复处理。

现有技术中,消息生产端将消息数据发送至消息服务器,消息服务器接收到这些消息数据后,将这些消息数据以队列的形式发送至消息消费端进行处理。正常情况下,消息生产端发送消息数据的时间顺序应当和消息消费端处理消息数据的时间顺序一致,从而保证先发送的消息数据先处理,后发送的消息数据后处理,保证消息数据处理(消费)的顺序性。然而,由于消息服务器故障、网络故障等原因,消息消费端接收消息数据的顺序与消息生产端发送消息数据的顺序很难保证一致,从而使消息数据的处理乱序。

考虑到消息数据的处理乱序的问题,图4示出了本发明实施例所提供的消息传输方法的第三种流程示意图,如图4所示,本实施例中的方法还包括以下步骤:

步骤S402,消息消费端根据当前获取的消息数据的序号判断该当前获取的消息数据是否满足当前的处理顺序,若满足,则对该当前获取的消息数据进行处理,否则挂起该当前获取的消息数据,其中,当前获取的消息数据的序号与消息生产端发送该当前获取的消息数据的时间顺序一致。

消息数据的序号能够由消息生产端在发送消息数据的时候定义,如消息生产端将第一个发送的消息数据的序号定义为1,将第二个发送的消息数据的序号定义为2,将第三个发送的消息数据的序号定义为3。消息消费端接收到消息数据后,获取该消息数据的序号,根据获取的消息数据的序号判断当前获取的消息数据是否满足当前的处理顺序,比如,消息消费端将上一个处理过的消息数据的序号与获取的消息数据的序号进行比较,判断获取的消息数据的序号在顺序上是否位于上一个处理过的消息数据的序号之后一位,如果是,确定当前获取的消息数据满足当前的处理顺序。

以第一个发送的消息数据的序号为1,第二个发送的消息数据的序号为2,第三个发送的消息数据的序号为3为例,假设消息消费端当前获取的消息数据的序号为3,消息消费端上一个处理过的消息数据的序号为1,则消息消费端当前获取的消息数据的序号在顺序上不位于上一个处理过的消息数据的序号之后一位,因此当前获取的消息数据不满足当前的处理顺序,消息消费端挂起该消息数据。

假设消息消费端当前获取的消息数据的序号为2,消息消费端上一个处理过的消息数据的序号为1,则当前获取的消息数据满足当前的处理顺序,消息消费端对该消息数据进行处理。

步骤S404,消息消费端按照预设的扫描策略对挂起的消息数据进行扫描,当扫描到满足当前的处理顺序的消息数据时,对扫描到的消息数据进行处理。

每当消息消费端处理完一个消息数据时,都对挂起的消息数据进行扫描,若扫描到满足当前的处理顺序的消息数据时,对扫描到的消息数据进行处理。比如,当消息消费端处理完序号为5的消息数据时,消息消费端对挂起的消息数据进行扫描,若扫描到序号为6的消息数据,则消息消费端对扫描到的消息数据进行处理,否则,消息消费端继续获取下一个消息数据,并继续根据下一个消息数据的序号判断下一个消息数据是否满足当前的处理顺序。

与现有技术相比,通过上述步骤S502和步骤S504,对消息数据定义与发送的时间顺序相一致的序号,根据消息数据的序号选择对消息数据处理或者不处理,能够保证消息处理的有序性。

综上,本实施例中的方法,不依赖于现有的开源分布式消息服务器的各种保障机制,在避免消息服务器本身的缺陷的基础上,能够保证消息数据的可靠性、防重复性和有序性,消息处理过程对业务使用方更加透明,业务逻辑处理更加便捷,业务不需关心使用消息数据带来的不可靠,重复和乱序的问题。

与上述的消息传输方法对应,本发明实施例还提供了一种消息传输系统。图5示出了本发明实施例所提供的消息传输系统的组成示意图,如图5所示,该系统包括消息生产端51、消息服务器52和消息消费端53;

消息生产端51对当前事务进行处理,在当前事务的处理过程中生成需要发送的消息数据;

消息生产端51建立当前事务与消息数据之间的捆绑提交关系;

当该当前事务提交成功时,消息生产端51采用定时补偿策略向消息服务器52发送消息数据。

本实施例中,消息生产端51包括:发送模块,用于向消息服务器52发送消息数据;检测模块,用于检测在预设时间内是否接收到消息服务器52返回的接收成功标识;重复模块,用于若检测模块未接收到接收成功标识,则重复执行发送模块和检测模块的动作,直至接收到接收成功标识。

本发明实施例中,消息生产端首先对当前事务进行处理,在当前事务的处理过程中生成需要发送的消息数据,消息生产端然后建立当前事务与消息数据之间的捆绑提交关系,最后,在当前事务处理成功时,消息生产端采用定时补偿策略向消息服务器发送消息数据。由于本发明实施例中消息生产端采用定时补偿策略向消息服务器发送消息数据,即重复多次向消息服务器发送消息数据,因此与现有技术相比,通过本实施例中的消息传输系统能够缓解现有的消息数据发送机制不够完善的问题,尤其能够缓解消息生产端与消息服务器之间传递消息数据的可靠性差的问题,提高消息生产端与消息服务器之间传递消息数据的可靠性。

考虑到现有的由于消息消费端长时间没能对消息数据消费成功,导致消息服务器内的消息数据积压或阻塞的问题,本实施例中,消息消费端53接收消息服务器52发送的消息数据,消息消费端53判断该消息数据是否为首次接收,若是,则消息消费端53保存该消息数据,并向消息服务器52返回消费成功标识,否则,消息消费端53直接向消息服务器52返回消费成功标识。

其中,消息消费端53包括:查找模块,用于根据消息数据的唯一标识在数据库内进行查找,确定模块,用于若查找模块未查找到与唯一标识相同的消息数据,则确定消息数据为首次接收,否则,确定消息数据为非首次接收。

与现有技术相比,本实施例中,消息消费端53保存该消息数据后,不进行消费,直接向消息服务器52返回消费成功标识,能够保证消息服务器52在接收到消费成功标识后,继续发送下一个消息数据,从而缓解消息服务器52内的消息数据积压或阻塞的问题。

与现有技术相比,本实施例中,消息消费端53对于同一条消息数据只保存一次,因此当消息消费端53在进行消息处理时,对于每条消息数据仅会处理一次,消息消费端53无需再进行幂等性校验就能够防止消息重复处理。

考虑到消息数据的处理乱序的问题,本实施例中,消息消费端53根据当前获取的消息数据的序号判断当前获取的消息数据是否满足当前的处理顺序,若满足,则对当前获取的消息数据进行处理,否则挂起当前获取的消息数据,其中,当前获取的消息数据的序号与消息生产端发送该当前获取的消息数据的时间顺序一致;消息消费端53按照预设的扫描策略对挂起的消息数据进行扫描,当扫描到满足当前的处理顺序的消息数据时,对扫描到的消息数据进行处理。

与现有技术相比,本实施例中,对消息数据定义与发送的时间顺序相一致的序号,根据消息数据的序号选择对消息数据处理或者不处理,能够保证消息处理的有序性。

本发明实施例所提供的装置可以为设备上的特定硬件或者安装于设备上的软件或固件等。本发明实施例所提供的装置,其实现原理及产生的技术效果和前述方法实施例相同,为简要描述,装置实施例部分未提及之处,可参考前述方法实施例中相应内容。所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,前述描述的系统、装置和单元的具体工作过程,均可以参考上述方法实施例中的对应过程,在此不再赘述。

在本发明所提供的实施例中,应该理解到,所揭露装置和方法,可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,又例如,多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外,在本发明提供的实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释,此外,术语“第一”、“第二”、“第三”等仅用于区分描述,而不能理解为指示或暗示相对重要性。

最后应说明的是:以上所述实施例,仅为本发明的具体实施方式,用以说明本发明的技术方案,而非对其限制,本发明的保护范围并不局限于此,尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化,或者对其中部分技术特征进行等同替换;而这些修改、变化或者替换,并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围。都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应所述以权利要求的保护范围为准。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1