一种自动熔断的消息发送方法、装置及系统与流程

本申请涉及通信技术领域，特别涉及一种自动熔断的消息发送方法、装置及系统。

背景技术：

随着互联网技术的日益发展，用户在电子交易平台进行交易后会产生很多消息，电子交易平台将消息发送给用户，例如邮件通知交易结果，短信息通知付款是否成功，但是如果通过某种渠道短时间内向用户发送大量的消息，容易造成用户通知渠道的阻塞，例如通知渠道为邮箱，用户的邮箱在短时间内接收到大量消息，可能造成邮箱容量溢出或者用户重要的邮件被淹没在大量的通知消息之中，这样会影响用户正常使用邮箱。

在现有技术中，一般在每次发送消息时采用计数的方式统计发送此类消息的数量，如果发送数量超过门限值则取消本次消息的发送。但是，由于消息的目标用户量较大，用户使用的通知渠道多种多样，系统在每一次发送消息时都需要在数据库中进行累加计数的操作，这样数据写入并发量大，影响系统发送消息的处理效率。

技术实现要素：

为了解决现有技术中消息处理系统发送消息的效率不高，并且如果发送的某类消息过多容易造成对用户骚扰的问题，提出了一种自动熔断的消息发送方法、装置及系统可以提高发送消息的效率，并且避免了同类消息对用户的骚扰。

本申请实施例提供了一种自动熔断的消息发送方法，包括，

接收发送消息请求，并得到所述发送消息请求中的特征；

根据所述特征进行黑名单校验；

通过所述黑名单校验后，发送相应消息，并根据所述特征生成本次发送消息的日志。

本申请实施例还提供了一种自动熔断的消息发送方法，包括，

同步消息处理系统的日志；

根据所述日志累计具有相同特征消息的数量；

判断所述数量是否超过数量门限值，若超过则将该特征加入黑名单。

本申请实施例还提供了一种自动熔断的消息处理装置，包括，

接收单元，用于接收发送消息请求，并得到所述发送消息请求中的特征；

校验单元，用于根据所述特征进行黑名单校验；

处理单元，用于当通过所述黑名单校验后，发送相应消息，并根据所述特征生成本次发送消息的日志。

本申请实施例还提供了一种自动熔断的记账装置，包括，

同步单元，用于同步消息处理系统的日志；

计算单元，用于根据所述日志累计具有相同特征消息的数量；

处理单元，用于判断所述数量是否超过数量门限值，若超过则将该特征加入黑名单。

本申请实施例还提供了一种自动熔断的消息处理系统，包括消息处理装置和记账装置，

所述消息处理装置，用于接收发送消息请求，并得到所述发送消息请求中的特征，根据所述特征进行黑名单校验，当通过所述黑名单校验后，发送相应消息，并根据所述特征生成本次发送消息的日志；

所述记账装置，用于同步消息处理系统的日志，根据所述日志累计具有相同特征消息的数量，判断所述数量是否超过数量门限值，若超过则将该特征加入黑名单。

由以上本申请实施例提供的技术方案可见，可以实现对向用户发送的消息进行逻辑控制，如果发送的消息在黑名单中，则不发送该消息，避免了对用户的消息骚扰；并且提高了消息处理系统发送消息的处理速度。

当然实施本申请的任一产品或者方法必不一定需要同时达到以上所述的所有优点。

附图说明

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

图1所示为现有技术中消息发送方法的整体流程图；

图2所示为本申请实施例一种自动熔断的消息发送方法的流程图；

图3所示为本申请实施例一种自动熔断的消息发送方法的流程图；

图4所示为本申请实施例一种自动熔断的消息处理装置的结构示意图；

图5所示为本申请实施例一种自动熔断的记账装置的结构示意图；

图6所示为本申请实施例一种自动熔断的消息处理系统的结构示意图；

图7所示为本申请实施例一种自动熔断的消息处理系统在处理消息时的具体流程图；

图8所示为本申请实施例一种自动熔断的消息处理系统在处理消息时的具体流程图。

具体实施方式

本申请实施例提供一种自动熔断的消息发送方法、装置及系统。

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

如图1所示为现有技术中消息发送方法的整体流程图，在现有技术中将统计消息数量、判断是否发送等步骤都置于消息处理系统中处理，因此造成了消息发送的效率较低的问题。

上述现有技术具体包括业务系统向消息处理系统发起发送消息请求，在消息处理系统中对该发送消息请求进行了前置校验、黑名单校验等步骤，其中，黑名单校验是指判断本次发送的消息(渠道+业务信息)是否属于黑名单，如果在黑名单中说明通过所述渠道发送的这种业务信息已经超过门限值，对于用户来说已经构成了影响。当通过了黑名单校验后，需要判断本次要发送的消息加上以前的发送记录是否对用户构成了影响，也就是图中所述的对已发送消息数量的查询以及对该数量的校验；如果通过了上述已发送消息数量的校验后，调用网关发送本次的消息；最后在记账系统中记录本次发送消息，也就是在记账系统中的发送消息记录中加1。

如图2所示为本申请实施例一种自动熔断的消息发送方法的流程图，在该图中描述的是消息处理系统中的工作流程，与现有技术相比较在本申请中的消息处理系统不进行已发送消息的查询、校验、记账等步骤，只是通过验证黑名单的方式实现是否发送消息的判断，简化了消息发送流程，并且通过记账系统对黑名单的操作来完成控制消息发送的目的，减少对用户同类型消息的打扰，避免了通过相同通知渠道向用户发送大量消息，造成用户的通知渠道阻塞的问题。

具体包括步骤201，接收发送消息请求，并得到所述发送消息请求中的特征。

步骤202，根据所述特征进行黑名单校验。

步骤203，通过所述黑名单校验后，发送相应消息，并根据所述特征生成本次发送消息的日志。

作为本申请的一个实施例，所述发送消息请求至少包括：

发送消息的渠道和业务信息；

或，发送消息的目标用户和业务信息。

其中，发送消息的渠道包括目标用户的手机号码、邮件地址和客户端等，其中手机号码用于向用户发送短信息，邮件地址用于向用户发送邮件，客户端用于向用户的客户端发送通知消息，例如向用户智能终端的支付宝客户端发送付款成功的消息。

所述的业务信息包括业务类型，还可以包括业务消息内容等信息，其中，业务消息内容例如为“您的xxxx订单支付成功”、“您的xxx订单的转账成功”，业务类型例如可以为付款成功(或者失败)的消息，转账成功(或者失败)的消息，商品已经发货的通知消息等等，这些业务信息可以通过渠道而确定相应的形式，例如当渠道为手机号码时，业务信息可能只包括简单的文字信息，当渠道为邮件地址时，业务信息可能包括了文字、图片等多媒体的内容。

作为本申请的一个实施例，当所述发送消息的请求中包括目标用户和业务信息时，在得到所述发送消息请求中的特征之中还包括，根据目标用户信息分析得到发送消息的渠道。

其中，当发送消息的请求中不包括渠道时，那么需要包括目标用户，由于一个用户可能具有多种通信的渠道，可能包括手机号码、邮件地址、客户终端等，具体使用哪种渠道发送消息则可以根据多种条件来判断选择，例如如果用户大部分登录操作都是在手机上的客户端进行的，那么通知消息就可以选择为以客户端方式发送，若用户浏览商品等操作都是通过电脑完成的，那么可以选择手机短信方式或者选择邮件方式发送消息，只需要指明要向哪个用户(目标用户)发送消息即可。

作为本申请的一个实施例，根据所述特征进行黑名单校验进一步包括，判断所述特征是否存在于所述黑名单中，如果存在则不发送所述消息。

所述特征至少包括渠道和业务类型，还可以包括已发送消息的时间信息。

作为本申请的一个实施例，所述日志至少包括发送消息的渠道和业务类型。

其中，所述日志中还可以包括发送消息的时间信息，所述日志可以存储于消息处理装置本地。

上述的渠道可以为字母字符串形式或者为数字字符串形式，或者还可以为字母和数字混合构成的字符串，所述业务信息可以为业务类型的代码，该业务类型的代码可以标识业务类型，在发送给用户时转换为具体的文字信息。

通过上述本申请实施例的方法，可以实现对向用户发送的消息进行逻辑控制，如果发送的消息在黑名单中，则不发送该消息，避免了对用户的消息骚扰；并且提高了消息处理系统发送消息的处理速度。

如图3所示为本申请实施例一种自动熔断的消息发送方法的流程图，在该图中主要描述了记账系统的工作流程，本方法是通过与消息处理系统分离处理日志的方式来实现提高消息发送效率的目的，在记账系统中的方法与上述图2所示实施例的方法相结合功能完成控制消息发送，以避免通过相同渠道向用户发送过多相同业务类型的信息。

具体包括步骤301，同步消息处理系统的日志。

步骤302，根据所述日志累计具有相同特征消息的数量。

步骤303，判断所述数量是否超过数量门限值，若超过则将该特征加入黑名单。

作为本申请的一个实施例，所述特征至少包括发送消息的渠道和业务类型。

作为本申请的一个实施例，所述特征中还包括已发送消息的时间信息。

作为本申请的一个实施例，在判断所述数量是否超过预定门限值之中还包括，判断在一定时间内所述数量是否超过数量门限值，若超过则将该特征加入黑名单。

其中，如果在一段时间内通过相同的渠道向用户发送相同业务消息的数量超过一定门限值，则认为这种情况属于对用户干扰，例如，在1分钟内通过手机短信息的方式向用户发送支付成功的消息超过了10条，则认为这种情况属于对用户的干扰，如果在1个小时内通过手机短信息的方式向用户发送支付成功的消息超过了10条，则认为这种情况不属于对用户的干扰。

作为本申请的一个实施例，还包括，判断所述黑名单中特征的时间信息，若所述时间信息与当前时间的间隔超过时间门限值，则将所述特征从所述黑名单中删除。

其中，黑名单在时刻保持的更新，当通过某个渠道发送的某类业务信息在一段时间内都没有出现，则说明后续通过这个渠道发送的该类业务信息对于用户来说不构成干扰，因此应当允许这种信息的继续发送，而不是永远屏蔽这种信息的发送。

通过上述实施例的方法，可以通过异步的方式记录发送消息的日志，并在独立于消息处理系统以外的记账系统中对日志进行分析和黑名单的更新，这样在消息处理系统发送消息时只需要判断黑名单即可，这样提高了消息处理系统发送消息的处理效率。

如图4所示为本申请实施例一种自动熔断的消息处理装置的结构示意图，该装置可以利用逻辑电路或者专门的芯片(例如fpga)来组建，或通过现有的高性能计算机实施，其中的一些功能单元可以单独以一个硬件设备实现，或者几个功能单元由一个或者多个硬件设备实现，具体包括：

接收单元401，用于接收发送消息请求，并得到所述发送消息请求中的特征。

校验单元402，用于根据所述特征进行黑名单校验。

处理单元403，用于当通过所述黑名单校验后，发送相应消息，并根据所述特征生成本次发送消息的日志。

作为本申请的一个实施例，所述发送消息请求至少包括：

发送消息的渠道和业务信息；

或，发送消息的目标用户和业务信息。

作为本申请的一个实施例，所述接收单元还用于根据目标用户信息分析得到发送消息的 渠道。

作为本申请的一个实施例，所述校验单元进一步用于判断所述特征是否存在于所述黑名单中，如果存在则不发送所述消息。

如图5所示为本申请实施例一种自动熔断的记账装置的结构示意图，该装置可以利用逻辑电路或者专门的芯片(例如fpga)来组建，或通过现有的高性能计算机实施，其中的一些功能单元可以单独以一个硬件设备实现，或者几个功能单元由一个或者多个硬件设备实现，具体包括：

同步单元501，用于同步消息处理系统的日志。

计算单元502，用于根据所述日志累计具有相同特征消息的数量。

处理单元503，用于判断所述数量是否超过数量门限值，若超过则将该特征加入黑名单。

作为本申请的一个实施例，所述特征至少包括发送消息的渠道和业务类型。

作为本申请的一个实施例，所述特征中还包括已发送消息的时间信息。

作为本申请的一个实施例，所述处理单元进一步用于判断在一定时间内所述数量是否超过数量门限值，若超过则将该特征加入黑名单。

作为本申请的一个实施例，还包括更新单元504，判断所述黑名单中特征的时间信息，若所述时间信息与当前时间的间隔超过时间门限值，则将所述特征从所述黑名单中删除。

如图6所示为本申请实施例一种自动熔断的消息处理系统的结构示意图，在该图中包括了上述图4和图5所示实施例中的消息处理装置和记账装置，其中：

消息处理装置601，用于接收发送消息请求，并得到所述发送消息请求中的特征，根据所述特征进行黑名单校验，当通过所述黑名单校验后，发送相应消息，并根据所述特征生成本次发送消息的日志；

记账装置602，用于同步消息处理系统的日志，根据所述日志累计具有相同特征消息的数量，判断所述数量是否超过数量门限值，若超过则将该特征加入黑名单。

在本实施例中的系统可以具备上述装置中的各个功能单元或者附加的功能单元，在此不再赘述。

如图7所示为本申请实施例一种自动熔断的消息处理系统在处理消息时的具体流程图，在该图中的消息处理装置、记账装置均可以由一个或者几个计算机实现，或者由专用的芯片形成，其中包括的日志、黑名单等可以由数据库实现，可以位于任意的位置，例如日志与消息处理装置在同一台计算机中，或者分开位于不同的计算机中。

在本图中具体包括步骤701，业务系统向消息处理装置提出发送消息请求。

在本步骤中，业务系统可以例如为支付交易系统，或者为转账系统，或者为收款系统， 在本实施例中以支付交易系统为例进行说明，在支付交易系统发送的发送消息请求中至少包括了用户信息和业务类型，其中的业务类型指明要发送的消息属于哪类业务，例如支付完成消息、支付失败消息、转账完成消息、转账失败消息等等，还可以包括业务消息内容，例如用户id+支付完成消息+某笔支付完成消息，或者包括发送渠道+业务类型+业务消息内容，例如手机号码和支付完成消息某笔支付完成消息。

所述的发送消息请求具体可以包括发送用户信息(渠道)+业务类型编码+组装消息内容需要的一些参数。消息处理装置根据业务类型编码，获取该业务类型编码对应的消息模板，将用户传入的参数内容替换模板中的一些可替换的变量，组装成最终发送给用户的消息内容。

步骤702，消息处理装置对上述发送消息请求进行前置校验。

在本步骤中主要验证发送消息请求的格式是否符合要求，例如用户id的格式是否正确，某笔支付完成消息的格式是否正确，请求发送的消息的业务类型是否存在等。

步骤703，获得所述发送消息请求中的特征。

在本步骤中，如果发送消息请求中是用户id和支付完成消息(业务类型)，则需要从该请求中提取用户id，根据该用户id匹配合适的发送渠道，例如在用户信息中保存了2种消息发送的渠道，分别为手机号码和邮件地址，根据用户的偏好或者根据历史消息发送的渠道，选择其中的一种作为消息发送的渠道，在本例中选择手机号码为发送消息的渠道，该特征中至少包括了消息发送的渠道(手机号码)和支付完成消息。

如果发送消息请求中包括的是消息发送渠道和业务类型，则直接得到了该发送消息请求中的特征，该特征中至少包括了消息发送的渠道(手机号码)和支付完成消息。

步骤704，对所述特征进行黑名单校验。

在本步骤的黑名单中包括了多个特征，将接收到的发送消息请求中的特征与黑名单中的多个特征进行比较，如果有相同的则说明黑名单的校验失败，否则说明黑名单校验通过，如果校验失败，则不发送支付完成消息，在本实施例中通过黑名单校验，就可以完成发送支付完成消息。

步骤705，消息处理装置调用网关等通信装置以指定的渠道发送支付完成消息，并生成本次发送消息的日志。

在本步骤中，网关等通信设备与消息处理装置可以为一体，也可以为分别独立的装置，在此不作限定。

生成本次发送消息的日志中至少包括了本次发送消息的渠道和业务类型，其中业务类型例如为支付成功消息、转账成功消息、转账失败消息、卖家已经发货消息等等，在其它实施 例中，日志中还可以包括发送消息的时间(用于后面根据时间判断是否进入黑名单)，业务消息内容等。

所述日志可以存储于消息处理装置中。

至此，消息处理装置中的消息处理流程结束。

步骤706，记账装置同步所述消息处理装置中的日志。

在本步骤中，记账装置定时读取消息处理装置的日志，并在本地进行记账处理，此处的记账处理是指后面的分析、计算等工作。

步骤707，计算具有相同特征的日志数量。

在本步骤中，记账装置根据记录的多条日志，将渠道和业务类型相同的日志进行累加，如下表1所示为同步的日志表格，在该表格中分别记录了每一次发送消息的渠道和业务类型。

表1

在该表格中第一条日志和第三条日志的渠道和业务类型相同，第四条日志的渠道与第一条的渠道相同，但是业务类型不同，通过该表格其它行的数据(表格中未示)累计通过手机号码短信息方式发送的支付成功消息有100条记录。

步骤708，判断计算的数量是否大于数量门限值。

在本步骤中，如果计算的数量大于数量门限值，则进入步骤709，否则结束记账的流程。

在本例中，预设的数量门限值为99条，根据前述的计算数量100条，则说明通过手机号码短信息的方式发送支付成功消息已经过多，对用户来说可能已经构成干扰。

步骤709，在黑名单中记录该特征。

上述特征为手机号码和支付成功消息，将该特征加入黑名单列表中。所述的黑名单可以保存于消息处理装置或者记账装置。

如图8所示为本申请实施例一种自动熔断的消息处理系统在处理消息时的具体流程图，本实施例的步骤801至步骤805与图7所示实施例中步骤701至步骤705基本相同，不同之 处在于，在步骤805中，消息处理装置生成本次发送消息的日志时，在日志中除了包括渠道和业务类型外，还包括发送消息的时间信息。

步骤806，记账装置同步所述消息处理装置中的日志。

步骤807，计算在一时间范围内具有相同特征的日志数量。

在本步骤中，根据日志中发送消息的时间信息和预设的时间范围计算具有相同特征的日志数量，例如，时间范围为1小时，计算1小时内具有相同特征的日志数量为100。

步骤808，判断计算的数量是否大于数量门限值。

在本步骤中，如果计算的数量超过了数量门限值，则进入步骤809，否则结束记账的流程。

类似于图7的实施例，数量门限值为99条，步骤807中计算得到的1个小时内具有相同特征的日志数量为100条，判断结果超过了数量门限值，进入步骤809。

步骤809，在黑名单中记录该特征。

在本步骤中，记账装置记录特征时还记录有创建该特征的时间信息，在消息处理装置进行黑名单校验的步骤中，消息处理装置根据创建时间信息过滤掉已经过期的特征，或者通过下面步骤810进行黑名单的更新。在本例中，黑名单位于消息处理装置中。

步骤810，记账装置计算黑名单中特征存在的时间长度，如果超过时间门限值，则将该特征从黑名单中删除。

具体的，以一预定的周期计算当前时间与黑名单中特征的时间信息的差值，如果超过时间门限值，则将所述特征从黑名单中删除，否则继续保留黑名单中的特征。也就是说，如果有一段时间没有再通过某个渠道给用户发送某种业务信息，那么这种渠道发送的业务信息已经不构成对用户的骚扰，那么可以恢复这种方式的业务信息发送。

通过对黑名单的更新，可以控制向用户发送业务消息的行为，以免对用户造成干扰。

通过上述本申请实施例中的方法及装置，通过分离消息处理和黑名单更新的流程，可以极大的提高系统发送业务消息的效率，并且控制这些业务消息不会对用户造成骚扰。

对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(programmablelogicdevice,pld)(例如现场可编程门阵列(fieldprogrammablegatearray，fpga))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集 成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片2。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logiccompiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(hardwaredescriptionlanguage，hdl)，而hdl也并非仅有一种，而是有许多种，如abel(advancedbooleanexpressionlanguage)、ahdl(alterahardwaredescriptionlanguage)、confluence、cupl(cornelluniversityprogramminglanguage)、hdcal、jhdl(javahardwaredescriptionlanguage)、lava、lola、myhdl、palasm、rhdl(rubyhardwaredescriptionlanguage)等，目前最普遍使用的是vhdl(very-high-speedintegratedcircuithardwaredescriptionlanguage)与verilog2。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit，asic)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc625d、atmelat91sam、microchippic18f26k20以及siliconelabsc8051f320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以 是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络pc、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。