消息处理方法及设备与流程

本发明实施例涉及通信技术领域，尤其涉及一种消息处理方法及设备。

背景技术：

目前，应用程序中的功能项越来越多，很多功能项对应的数据依赖于第三方服务器中的数据。例如，应用程序1中包括红包功能项，红包功能项中的红包数据可以来自打车服务器、外卖服务器等。

在实际应用过程中，终端设备可以向应用服务器请求应用程序中的数据，当终端设备向应用服务器请求应用程序中依赖第三方服务器的功能项(下文简称依赖项)对应的数据时，应用服务器需要向第三方服务器请求获取相应的数据。在现有技术中，当依赖项所依赖的一个或多个服务器出现故障时，应用服务器无法正常向第三方服务器获取数据，则应用服务器会频繁的向第三方服务器发送数据请求，进而可能引起应用服务器由于负载过大而导致的宕机，导致应用服务器对消息处理的可靠性较低。

技术实现要素：

本发明实施例提供一种消息处理方法及设备，提高了应用服务器对消息处理的可靠性。

第一方面，本发明实施例提供一种消息处理方法，应用于应用服务器包括：

获取在预设时段内对线程池中的依赖消息处理请求进行处理的成功率，所述依赖消息处理请求为所述应用服务器依赖第三方服务器处理的请求；

若所述成功率大于预设成功率，则同时对所述线程池中所有的依赖消息处理请求进行处理；

若所述成功率小于预设成功率，则同时对所述线程池中、预设个数的依赖消息处理请求进行处理，所述预设个数小于所述线程池最多可容纳的依赖消息处理请求的个数。

在一种可能的实施方式中，获取在预设时段内对线程池中的依赖消息处理请求进行处理的成功率，包括：

获取在所述预设时段内、根据所述线程池中的依赖消息处理请求向所述第三方服务器发送的请求消息的第一个数；

获取在所述预设时段内接收到所述第三服务器发送的、与所述请求消息对应的成功响应消息的第二个数；

根据所述第一个数和所述第二个数，确定所述成功率。

在另一种可能的实施方式中，同时对所述线程池中、预设个数的依赖消息处理请求进行处理，包括：

按照所述线程池中各依赖消息处理请求的接收时间，确定所述预设个数个依赖消息处理请求；

同时对所述预设个数个依赖消息处理请求进行处理。

在另一种可能的实施方式中，所述方法还包括：

接收终端设备发送的第一依赖消息处理请求；

判断所述线程池中的请求个数是否小于预设阈值；

若是，则将所述第一依赖消息处理请求存放到所述线程池；

若否，则将所述第一依赖消息处理请求暂存在待处理请求队列，并获取所述线程池中包括的请求的个数及所述依赖消息处理请求在所述待处理请求队列中的位置，直至所述线程池中的请求的个数小于预设阈值、且所述依赖消息处理请求位于所述待处理请求队列的队首时，将所述第一依赖消息处理请求存储到所述线程池。

在另一种可能的实施方式中，所述方法还包括：

在所述线程池中确定处理完成的依赖消息处理请求；

将所述处理完成的依赖消息处理请求移出所述线程池；

若所述待处理请求队列中存在依赖消息处理请求，则将位于待处理请求队列队首的依赖消息处理请求存储到所述线程池。

第二方面，本发明实施例提供一种应用服务器，应用于应用服务器包括获取模块和处理模块，其中，

所述获取模块用于，获取在预设时段内对线程池中的依赖消息处理请求进行处理的成功率，所述依赖消息处理请求为所述应用服务器依赖第三方服务器处理的请求；

所述处理模块用于，在所述成功率大于预设成功率时，同时对所述线程池中所有的依赖消息处理请求进行处理；

所述处理模块还用于，在所述成功率小于预设成功率时，同时对所述线程池中、预设个数的依赖消息处理请求进行处理，所述预设个数小于所述线程池最多可容纳的依赖消息处理请求的个数。

在一种可能的实施方式中，所述获取模块具体用于：

获取在所述预设时段内、根据所述线程池中的依赖消息处理请求向所述第三方服务器发送的请求消息的第一个数；

获取在所述预设时段内接收到所述第三服务器发送的、与所述请求消息对应的成功响应消息的第二个数；

根据所述第一个数和所述第二个数，确定所述成功率。

在另一种可能的实施方式中，所述处理模块具体用于：

按照所述线程池中各依赖消息处理请求的接收时间，确定所述预设个数个依赖消息处理请求；

同时对所述预设个数个依赖消息处理请求进行处理。

在另一种可能的实施方式中，所述应用服务器还包括接收模块、判断模块和存储模块，其中，

所述接收模块用于，接收终端设备发送的第一依赖消息处理请求；

所述判断模块用于，判断所述线程池中的请求个数是否小于预设阈值；

所述存储模块用于，在所述判断模块判断所述线程池中的请求个数小于预设阈值时，将所述第一依赖消息处理请求存放到所述线程池；

所述存储模块还用于，在所述判断模块判断所述线程池中的请求个数大于或等于预设阈值时，将所述第一依赖消息处理请求暂存在待处理请求队列，并获取所述线程池中包括的请求的个数及所述依赖消息处理请求在所述待处理请求队列中的位置，直至所述线程池中的请求的个数小于预设阈值、且所述依赖消息处理请求位于所述待处理请求队列的队首时，将所述第一依赖消息处理请求存储到所述线程池。

在另一种可能的实施方式中，所述应用服务器还包括确定模块，其中，

所述确定模块用于，在所述线程池中确定处理完成的依赖消息处理请求；

所述存储模块还用于，将所述处理完成的依赖消息处理请求移出所述线程池；

所述存储模块还用于，在所述待处理请求队列中存在依赖消息处理请求，将位于待处理请求队列队首的依赖消息处理请求存储到所述线程池。

本发明实施例提供的消息处理方法及设备，在应用服务器中设置线程池，以使应用服务器同时最多只能对线程池中的所有依赖消息处理请求进行处理，这样，当应用服务器在短时段内接收到大量的依赖消息处理请求时，可以有效避免应用服务器宕机。进一步的，在应用服务器对线程池中的依赖消息处理请求进行处理的过程中，应用服务器对根据预设时段内对线程池中的依赖消息处理请求进行处理的成功率，按照不同的方式对线程池中的依赖消息处理请求进行处理，具体的，当成功率大于预设成功率时，则说明依赖的第三方服务器正常，则同时对所述线程池中所有的依赖消息处理请求进行处理，以提高处理效率；当成功率小于预设成功率时，则说明依赖的第三方服务器可能故障，则同时对所述线程池中、预设个数的依赖消息处理请求进行处理，避免应用服务器做大量无用操作、及应用服务器连续向第三方服务器请求数据而导致的宕机。

附图说明

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

图1为本发明实施例提供的消息处理方法的应用场景示意图；

图2为本发明实施例提供的线程池的部署示意图；

图3为本发明实施例提供的消息处理方法的流程示意图；

图4为本发明实施例提供的获取成功率方法的流程示意图；

图5为本发明实施例提供对依赖消息处理请求处理方法的流程示意图；

图6为本发明实施例提供的应用服务器的结构示意图一；

图7为本发明实施例提供的应用服务器的结构示意图二。

具体实施方式

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

图1为本发明实施例提供的消息处理方法的应用场景示意图。请参见图1，包括终端设备101、应用服务器102和至少一个第三方服务器(分别记为103-1至103-N)。终端设备101可以为手机、电脑、电视等设备，在终端设备101中安装有应用程序，该应用程序的页面中包括依赖项，依赖项中的数据依赖于至少一个第三方服务器。应用服务器102为应用程序对应的服务器，应用服务器102可以向终端设备提供应用程序中的数据。应用服务器102可以和各第三方服务器通信，以实现在各第三方服务器中获取依赖项对应的数据，并向终端设备101提供依赖项对应的数据。

在本申请中，在应用服务器102中还设置有线程池。下面，结合图2，对应用服务器102中的线程池进行详细说明。

图2为本发明实施例提供的线程池的部署示意图。请参见图2，包括终端设备101和应用服务器102。在终端设备101中安装有应用程序，在应用程序中包括多个依赖项(分别记为依赖项1-依赖项N)，每一个依赖项中的数据均依赖于至少一个第三方服务器。在应用服务器102中，为每一个依赖项设置有对应的线程池(分别记为线程池1-线程池N)。每一个线程池分别用于存储终端设备向应用服务器发送的、依赖项对应的依赖消息处理请求，例如，线程池1用于存储终端设备发送的、依赖项1对应的依赖消息处理请求，线程池2用于存储终端设备发送的、依赖项2对应的依赖消息处理请求。每一个线程池具有最大存储量，例如，一个线程池的最大存储量可以为1000个依赖消息处理请求等。

在本申请中，在应用服务器102对一个线程池中的依赖消息处理请求进行处理的过程中，当该线程池中的依赖消息处理请求对应的第三方服务器均为正常状态时，应用服务器102可以同时对线程池中的所有赖消息处理请求进行处理。当该线程池中的依赖消息处理请求对应的第三方服务器出现故障时，应用服务器102可以同时对线程池中的一部分依赖消息处理请求进行处理，可选的，该一部分依赖消息处理请求的个数可以为线程池最大可容纳请求个数的10％等，进而避免在第三方服务器故障时，导致应用服务器出现故障，进而提高应用服务器对消息进行处理的可靠性。

需要说明的是，应用服务器对应用程序中任意一个依赖项对应的依赖消息处理请求进行处理的过程相同。下面，以应用服务器对任意一个依赖项对应的依赖消息处理请求进行处理的过程为例，通过具体实施例，对本申请所示的技术方案进行详细说明。下面几个具体的实施例可以相互结合，相同或相似的内容在不同的实施例中不再进行重复描述。

图3为本发明实施例提供的消息处理方法的流程示意图。该方法的执行主体为应用服务器，请参见图3，该方法可以包括：

S301、获取在预设时段内对线程池中的依赖消息处理请求进行处理的成功率，依赖消息处理请求为应用服务器依赖第三方服务器处理的请求。

在本发明实施例中，在线程池中包括一个依赖项对应的多个依赖消息处理请求，该多个依赖消息处理请求为多个终端设备向应用服务器发送的。例如，假设应用程序1中包括红包功能，该红包功能中的数据依赖于第三方服务器，在应用服务器1中设置有与红包功能对应的线程池1，当安装应用程序1的终端设备需要获取红包功能对应的数据时，终端设备向应用服务器发送依赖消息处理请求，则应用服务器1将依赖消息处理请求存储到线程池1中，以使线程池1中的依赖消息处理请求均为用于请求红包功能数据的请求。

在实际应用过程中，当线程池中有依赖消息处理请求时，应用服务器则持续对线程池中的依赖消息处理请求进行处理。应用程序服务器可以周期性的执行图3实施例所示的方法，以确定对线程池中的依赖消息处理请求进行处理的具体方式。可选的，该周期可以为30秒、1分钟等，可以根据实际需要设置该周期。

在应用服务器对线程池中的依赖消息处理请求进行处理的过程中，应用服务器获取在预设时段内对线程池中的依赖消息处理请求进行处理的成功率。可选的，预设时段可以为当前时刻之前预设时长对应的时段，例如，预设时段可以为当前时刻之前的10分钟、当前时刻之前的5分钟等，在实际应用过程中，可以根据实际需要设置预设时段。

由于应用服务器对依赖消息处理请求进行时，需要依赖第三方服务器，当第三方服务器出现故障时，应用服务器无法对依赖消息处理请求进行功能处理。当应用服务器在预设时段内对线程池中的依赖消息处理请求进行处理的成功率大于预设成功率时，则说明第三方服务器正常，当成功率小于预设成功率时，说明第三方服务器故障。该预设成功率可以为60％、70％等，在实际应用过程中，可以根据实际需要设置该预设成功率。

S302、若成功率大于预设成功率，则同时对线程池中所有的依赖消息处理请求进行处理。

当成功率大于预设成功率时，说明第三方服务器正常，则应用服务器可以同时对线程池中所有的依赖消息处理请求进行处理。可选的，在应用服务器同时对线程池中所有的依赖消息处理请求进行处理的过程中，应用服务器可以在不同的时间片段对不同的依赖消息处理请求进行处理，该时间片段的时长通常较短。例如，假设线程池中有100个依赖消息处理请求，分别记为依赖消息处理请求1-依赖消息处理请求100，则应用服务器可以在时间片段1对依赖消息处理请求1处理，在时间片段2对依赖消息处理请求2处理，依次类推，在时间片段100对依赖消息处理请求100处理；在执行完一轮之后，在时间片段101再继续对依赖消息处理请求1处理，在时间片段102继续对依赖消息处理请求2处理，直至依赖消息处理请求被处理完成。

在该过程中，通过设置线程池，使得应用服务器同时最多只能对线程池中的所有依赖消息处理请求进行处理，这样，当应用服务器在短时段内接收到大量的依赖消息处理请求时，可以有效避免应用服务器宕机。

S303、若成功率小于预设成功率，则同时对线程池中、预设个数的依赖消息处理请求进行处理，预设个数小于线程池最多可容纳的依赖消息处理请求的个数。

当成功率大于预设成功率时，说明第三方服务器可能出现故障，为了避免应用服务器连续向第三方服务器请求数据而出现故障，则应用服务器可以同时对线程池中、预设个数的依赖消息处理请求进行处理，预设个数小于线程池最多可容纳的依赖消息处理请求的个数。可选的，该预设个数可以为线程池最多可容纳的依赖消息处理请求的个数的1％、5％、10％等，例如，假设线程池最多可容纳1000个依赖消息处理请求，则该预设个数可以为10个、15个等。在实际应用过程中，可以根据实际需要设置该预设个数的大小。

可选的，应用服务器可以按照线程池中各依赖消息处理请求的接收时间，确定预设个数个依赖消息处理请求，并同时对预设个数个依赖消息处理请求进行处理。可选的，可以对接收时间最早的预设个数个依赖消息处理请求进行处理。

在上述过程中，应用服务器通过对线程池中的一部分依赖消息处理请求进行处理，不但可以避免应用服务器做过多的无用操作，还可以避免应用服务器连续向第三方服务器请求数据而导致的宕机，进一步的，应用服务器还可以根据对该部分依赖消息处理请求进行处理的结果，判断第三方服务器是否恢复正常，在第三方服务器恢复正常时，则可以同时对线程池中的所有依赖消息处理请求进行处理。

本发明实施例提供的消息处理方法，在应用服务器中设置线程池，以使应用服务器同时最多只能对线程池中的所有依赖消息处理请求进行处理，这样，当应用服务器在短时段内接收到大量的依赖消息处理请求时，可以有效避免应用服务器宕机。进一步的，在应用服务器对线程池中的依赖消息处理请求进行处理的过程中，应用服务器对根据预设时段内对线程池中的依赖消息处理请求进行处理的成功率，按照不同的方式对线程池中的依赖消息处理请求进行处理，具体的，当成功率大于预设成功率时，则说明依赖的第三方服务器正常，则同时对所述线程池中所有的依赖消息处理请求进行处理，以提高处理效率；当成功率小于预设成功率时，则说明依赖的第三方服务器可能故障，则同时对所述线程池中、预设个数的依赖消息处理请求进行处理，避免应用服务器做大量无用操作、及应用服务器连续向第三方服务器请求数据而导致的宕机。

在图3所示实施例的基础上，可选的，可以通过如下可行的实现方式获取在预设时段内对线程池中的依赖消息处理请求进行处理的成功率(图3所示实施例中的S301)。具体的，请参见图4所示的实施例。

图4为本发明实施例提供的获取成功率方法的流程示意图。请参见图4，该方法可以包括：

S401、获取在预设时段内、根据线程池中的依赖消息处理请求向第三方服务器发送的请求消息的第一个数。

由于依赖消息处理请求依赖于第三方服务器，因此，当应用服务器对线程池中的依赖消息处理请求进行处理的过程中，应用服务器需要向第三方服务器发送请求消息。

S402、获取在预设时段内接收到第三服务器发送的、与请求消息对应的成功响应消息的第二个数。

S403、根据第一个数和第二个数，确定成功率。

可选的，可以将第二个数和第一个数的比值确定为该成功率。

在图4所示的实施例中，通过第一个数和第二个数的比值，可以准确的确定出预设时段内应用服务器对线程池中的依赖消息处理请求进行处理的成功率。

在上述任意一个实施例的基础上，在应用服务器接收到终端设备发送的依赖消息处理请求时，应用服务器根据依赖消息处理请求对应的线程池中的请求个数，对依赖消息处理请求进行不同的操作。下面，结合图5所示的实施例，以应用服务器对终端设备发送的第一依赖消息处理请求的处理过程为例，对应用服务器对依赖消息处理请求进行处理的过程进行详细说明。

图5为本发明实施例提供对依赖消息处理请求处理方法的流程示意图。请参见图5，该方法可以包括：

S501、接收终端设备发送的第一依赖消息处理请求。

S502、判断线程池中的请求个数是否小于预设阈值。

若是，则执行S503。若否，则执行S504-S505。

可选的，该预设阈值可以为线程池中最多可容纳的依赖消息处理请求的个数。

S503、将第一依赖消息处理请求存放到线程池。

当线程池中的请求个数是否小于预设阈值时，说明线程池中存在未使用的存储空间，则可以直接将第一依赖消息处理请求存放到线程池。

S504、将第一依赖消息处理请求暂存在待处理请求队列。

当线程池中的请求个数是否大于或等于预设阈值时，说明线程池中不存在未使用的存储空间，无法直接向线程池中存储该第一依赖消息处理请求。此时，可以将第一依赖消息处理请求暂存在待处理请求队列中。

S505、获取线程池中包括的请求的个数及依赖消息处理请求在待处理请求队列中的位置，直至线程池中的请求的个数小于预设阈值、且依赖消息处理请求位于待处理请求队列的队首时，将第一依赖消息处理请求存储到线程池。

在实际应用过程中，由于应用服务器在不停的对线程池中的依赖消息处理请求进行处理，当线程池中的依赖消息处理请求被处理完成之后，将处理完成的依赖消息处理请求移出线程池，此时，若所述待处理请求队列中存在依赖消息处理请求，则将位于待处理请求队列队首的依赖消息处理请求存储到所述线程池。

在应用服务器将第一依赖消息处理请求暂存在待处理请求队列之后，根据应用服务器对线程池中的依赖消息的处理情况，对第一依赖消息处理请求在待处理请求队列中的位置进行更新。应用服务器实时获取线程池中包括的请求的个数及依赖消息处理请求在待处理请求队列中的位置，直至线程池中的请求的个数小于预设阈值、且依赖消息处理请求位于待处理请求队列的队首时，则将第一依赖消息处理请求存储到线程池。

通过上述方法，可以保证线程池中最多包括预设阈值个依赖消息处理请求，并且可以保证有序的对接收到的依赖消息处理请求进行处理。

下面，通过具体实施例，对上述方法实施例所示的技术方案进行详细说明。

示例性的，假设终端设备中安装有应用程序1，应用程序1对应的服务器为应用服务器，应用程序1中包括红包数据，该红包数据来自于打车服务器(第三方服务器)。

在实际应用过程中，当用户需要在终端设备中查看应用程序1中的红包数据时，用户在终端设备中输入相应的查看指令，以使终端设备向应用服务器发送处理请求1，该处理请求1用于请求获取应用程序1中的红包数据。

在应用服务器接收到处理请求1之后，应用程序判断处理请求1对应的线程池中的请求个数大于100个(预设阈值)，则应用程序将处理请求1存放到待处理请求队列中。假设在一段时长之后，处理请求1被更新到待处理请求队列的队首，在此之后，若线程池1中的又一个请求被处理完成，则可以将处理请求1存储到线程池1中。

在应用服务器对线程池1中的请求进行处理的过程中，应用服务器需要向打车服务器获取相关数据，以实现对线程池1中的请求进行处理。

假设当前时刻为1点20分，在1点20分之前，应用服务器对线程池1中的100个请求进行同时处理。在1点20分时，应用服务器获取在1点10分至1点20分之内、对线程池1中的请求进行处理的成功率。

假设在1点20分获取得到的成功率为30％，小于预设成功率(假设为80％)，则判断打车服务器可能出现故障，则应用服务器暂停对100个请求中的90个请求进行处理，应用服务器仅对线程池中的10个请求进行同时处理，以避免应用服务器做过多的无用操作、及避免应用服务器向打车服务器连续发送大量请求而导致宕机。

在1点25分时，假设应用服务器获取到的成功率为90％，大于预设成功率(假设为80％)，则判断打车服务器正常，则应用服务器对线程池1中的100个请求进行同时处理，进而提高对请求进行处理的效率。

图6为本发明实施例提供的应用服务器的结构示意图一。请参见图6，该应用服务器可以包括获取模块11和处理模块12，其中，

所述获取模块11用于，获取在预设时段内对线程池中的依赖消息处理请求进行处理的成功率，所述依赖消息处理请求为所述应用服务器依赖第三方服务器处理的请求；

所述处理模块12用于，在所述成功率大于预设成功率时，同时对所述线程池中所有的依赖消息处理请求进行处理；

所述处理模块12还用于，在所述成功率小于预设成功率时，同时对所述线程池中、预设个数的依赖消息处理请求进行处理，所述预设个数小于所述线程池最多可容纳的依赖消息处理请求的个数。

本发明实施例提供的应用服务器可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种可能的实时方式中，所述获取模块11具体用于：

获取在所述预设时段内、根据所述线程池中的依赖消息处理请求向所述第三方服务器发送的请求消息的第一个数；

获取在所述预设时段内接收到所述第三服务器发送的、与所述请求消息对应的成功响应消息的第二个数；

根据所述第一个数和所述第二个数，确定所述成功率。

在另一种可能的实时方式中，所述处理模块12具体用于：

按照所述线程池中各依赖消息处理请求的接收时间，确定所述预设个数个依赖消息处理请求；

同时对所述预设个数个依赖消息处理请求进行处理。

图7为本发明实施例提供的应用服务器的结构示意图二。在图6所示实施的基础上，请参见图7，所述应用服务器还包括接收模块13、判断模块14和存储模块15，其中，

所述接收模块13用于，接收终端设备发送的第一依赖消息处理请求；

所述判断模块14用于，判断所述线程池中的请求个数是否小于预设阈值；

所述存储模块15用于，在所述判断模块14判断所述线程池中的请求个数小于预设阈值时，将所述第一依赖消息处理请求存放到所述线程池；

所述存储模块15还用于，在所述判断模块14判断所述线程池中的请求个数大于或等于预设阈值时，将所述第一依赖消息处理请求暂存在待处理请求队列，并获取所述线程池中包括的请求的个数及所述依赖消息处理请求在所述待处理请求队列中的位置，直至所述线程池中的请求的个数小于预设阈值、且所述依赖消息处理请求位于所述待处理请求队列的队首时，将所述第一依赖消息处理请求存储到所述线程池。

在另一种可能的实时方式中，所述应用服务器还包括确定模块16，其中，

所述确定模块16用于，在所述线程池中确定处理完成的依赖消息处理请求；

所述存储模块15还用于，将所述处理完成的依赖消息处理请求移出所述线程池；

所述存储模块15还用于，在所述待处理请求队列中存在依赖消息处理请求，将位于待处理请求队列队首的依赖消息处理请求存储到所述线程池。

本发明实施例提供的应用服务器可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。