一种突发业务处理方法及装置与流程

本申请涉及数据处理技术领域，尤其涉及一种突发业务处理方法及装置。

背景技术：

随着计算机技术的蓬勃发展，服务器需要处理越来越多的突发业务。比如，实际应用中短时间内大量用户通过客户端向服务器提交众多的业务处理请求，针对这类情形的业务即属于突发业务。正常情况下，服务器处理业务的能力在一定时间内维持在恒定水平，因此，当短时间内出现大量业务处理请求时，将使服务器承受巨大的运算压力，严重时可能导致服务系统出现崩溃。

为了解决突发业务造成处理业务的服务器运算压力过大的问题，现有技术对服务器进行分级设置、分担处理任务。比如，在处理突发业务的场景中，设置用于进行实际业务处理的业务处理服务器和突发业务服务器，先由突发业务服务器将业务处理请求转化为队列，根据业务处理服务器的处理能力，以队列中的先后顺序将业务处理请求提交给业务处理服务器，再由业务处理服务器判断是否能够向业务处理请求分配业务资源，并根据业务资源的分配结果对业务处理请求进行最终处理。

上述方式虽然在一定程度上能够减轻原业务服务器的运算压力，但是，在确定是否能够向业务处理请求分配业务资源之前，需要突发业务服务器先将业务处理请求提交给业务处理服务器，再由业务服务器来决定是否响应该业务处理请求(即是否分配业务资源给相应业务处理请求)，这样使得对业务处理请求进行业务资源分配的流程过于复杂，导致不能及时获知业务处理请求是否获取到业务资源。

技术实现要素：

本申请实施例提供一种突发业务处理方法和装置，用于解决现有技术不能及时获知业务处理请求是否获取到业务资源的问题。

本申请实施例提供一种突发业务处理方法，所述方法包括：

突发业务服务器获取所述突发业务对应的业务资源；

突发业务服务器将获取的所述业务资源加载在突发业务服务器的内存中；

突发业务服务器当接收到针对所述突发业务的各业务处理请求时，根据加载在所述内存中的业务资源，对各所述业务处理请求进行处理。

优选的，所述业务资源包括至少一个权限标识，所述权限标识用于当突发业务服务器向业务处理请求分配所述权限标识后，对所述业务处理请求进行处理；

所述根据加载在所述内存中的业务资源，对各所述业务处理请求进行处理，具体包括：向各所述业务处理请求分配加载在所述内存中的业务资源的所述权限标识，根据所述权限标识的分配结果对各所述业务处理请求进行处理。

优选的，所述向各所述业务处理请求分配加载在所述内存中的业务资源的所述权限标识具体包括：根据各所述业务处理请求的接收顺序，分配加载在所述内存中的业务资源的所述权限标识；和/或，

向各所述业务处理请求随机分配加载在所述内存中的业务资源的所述权限标识。

优选的，所述业务资源还包括所述权限标识数量阈值的信息；

所述向各所述业务处理请求分配加载在所述内存中的业务资源的所述权限标识，根据所述权限标识的分配结果对各所述业务处理请求进行处理，具体包括：针对所接收的每一个业务处理请求执行以下操作：

根据所述业务处理请求确定已经分配的权限标识的数量；

当所述数量小于所述权限标识数量阈值时，向所述业务处理请求分配加载在所述内存中的业务资源的所述权限标识，基于所述权限标识对所述业务处理 请求进行处理。

优选的，当至少有两个并行的突发业务服务器时，所述突发业务服务器获取所述突发业务对应的业务资源具体包括：

并行的突发业务服务器获取与各自处理能力相匹配的所述突发业务对应的业务资源的所述权限标识数量阈值的信息，或者并行的突发业务服务器获取相同的所述突发业务对应的业务资源的所述权限标识数量阈值的信息。

优选的，当突发业务服务器连接业务处理服务器时，所述对所述业务处理请求进行处理具体包括提交所述业务处理请求。

优选的，所述提交所述业务处理请求具体包括通过可靠消息的方式提交所述业务处理请求，所述可靠消息指会被接收端读取的消息。

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

业务处理服务器接收突发业务服务器所提交的所述业务处理请求；

业务处理服务器向所述业务处理请求对应的用户返回突发业务处理入口，所述业务处理入口为触发该突发业务处理入口进行突发业务处理。

优选的，当至少有两个并行的突发业务服务器以及所述并行的突发业务服务器连接负载均衡服务器时，所述负载均衡服务器用于向所述并行的突发业务服务器分配突发业务的业务处理请求，所述方法还包括：

所述负载均衡服务器向所述并行的突发业务服务器分配与各自处理能力相匹配数量的突发业务的业务处理请求，或者所述负载均衡服务器向所述并行的突发业务服务器平均分配相同数量的突发业务的业务处理请求。

优选的，当所述突发业务服务器连接有监测服务器时，所述监测服务器用于监测所述突发业务服务器是否正常工作，所述方法还包括：

所述监测服务器向所述突发业务服务器发送检测信号；

根据预设时间规则，当所述监测服务器收到所述突发业务服务器返回信号时，则确定所述突发业务服务器正常工作；

根据预设时间规则，当所述监测服务器未收到所述突发业务服务器返回信 号时，则确定所述突发业务服务器出现错误，终止突发业务的处理。

优选的，其特征在于，所述突发业务具体包括商品秒杀业务。

本申请实施例还提供一种突发业务处理装置，所述装置包括：

获取单元、加载单元、接收单元和处理单元，其中：

获取单元，用于获取所述突发业务对应的业务资源；

加载单元，用于将获取的所述业务资源加载在突发业务服务器的内存中；

接收单元，用于接收到针对所述突发业务的业务处理请求；

处理单元，用于根据加载在所述内存中的业务资源，对各所述业务处理请求进行处理。

本申请实施例采用的上述至少一个方法或装置能够达到以下有益效果：

由于在接收突发业务的各业务处理请求之前，将业务资源加载在突发业务服务器中，突发业务服务器可以根据加载的业务资源和业务处理请求情况对业务处理请求进行业务资源的分配处理，从而简化了业务资源分配的流程，有助于及时获知业务处理请求是否获取到业务资源，进而可以尽快向发起业务处理请求的用户反馈业务处理请求的响应情况，提高用户体验。此外，由于在对业务处理请求进行资源分配处理之前已加载业务资源到内存，使得业务处理请求能够快速得到处理，提高了业务处理请求的处理效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例1提供的一种突发业务处理方法的具体实现流程示意图；

图2为本申请实施例2提供的一种突发业务处理方法的具体实现流程示意图；

图3为本申请实施例3提供的一种突发业务处理方法的具体实现流程示意图；

图4为本申请实施例4提供的实际应用中商品秒杀的具体流程示意图；

图5为本申请实施例7提供的实际应用中秒杀预加载模块结构示意图；

图6为本申请实施例7提供的一种突发业务处理装置的具体结构示意图。

具体实施方式

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

以下结合附图，详细说明本申请各实施例提供的技术方案。

实施例1

实施例1提供了一种突发业务处理方法。该方法的具体流程示意图如图1所示，包括下述步骤：

步骤101：突发业务服务器获取所述突发业务对应的业务资源。

突发业务服务器是指用于接收和处理用户提交的突发业务的各业务处理请求的服务器；突发业务对应的业务资源是指处理突发业务所需要的业务资源。

为了便于说明，在未做特殊说明的情况下，本申请的各实施例所举的例子均以商品秒杀业务为例。在商品秒杀业务中，处理秒杀请求的秒杀服务器就是所指的突发业务服务器，在这里突发业务对应的业务资源可以包括所秒杀的商品的信息、秒杀开始时间等，也可以包括秒杀服务器中的缓存资源等。

突发业务服务器获取突发业务对应的业务资源的方式也可以包括多种，既可以从存储业务资源的预加载服务器中获取，也可以通过网络获取，甚至还可 以是从突发业务服务器自身的硬盘中获取，这里并不对突发业务服务器获取突发业务对应的业务资源的方式做出限定。在实际应用中，秒杀服务器通常从预加载服务器获取秒杀商品的信息以及秒杀开始时间等信息。

步骤102：突发业务服务器将获取的所述业务资源加载在突发业务服务器的内存中。

突发业务服务器在获取突发业务对应的业务资源之后，将该业务资源加载到内存中。一般来说将业务资源加载到内存中是指把业务资源的数据拷贝到内存中，并且通过为业务资源分配内存表，从而实现进行标记使用，这种方式还可以防止该内存被重复分配。将业务资源加载在内存中之后，当需要使用该业务资源时，中央处理器可以直接从内存中读取，而从内存中读取数据的速度高于从硬盘等寄存器中读取数据的速度，因此将业务资源提前加载在内存中能够加快突发业务服务器处理业务的速度。

在商品秒杀业务中，秒杀服务器获取秒杀对应的业务资源后，会将该业务资源加载到内存中，从而加快秒杀服务器处理秒杀请求的效率。需要说明的是，秒杀服务器还可以通过其他方式来加快处理秒杀请求的效率，例如秒杀服务器可以为该秒杀业务分配特定的缓存。

此外，突发业务服务器还可以将获取的所述业务资源，按照预先设置时间规则，加载在突发业务服务器的内存中。

在商品秒杀业务中，秒杀服务器可以在秒杀开始前的一段时间内(3分钟或者5分钟)将获取的业务资源加载在秒杀服务器的内存中。

步骤103：突发业务服务器当接收到针对所述突发业务的各业务处理请求时，根据加载在所述内存中的业务资源，对各所述业务处理请求进行处理。

突发业务服务器当接收突发业务的多个业务处理请求时，分别获取加载在所述内存中的业务资源，对各所述业务处理请求进行处理。所述对各所述业务处理请求进行处理可以包括向各所述业务处理请求对应的用户返回业务处理的提示信息。

在实际应用中，在秒杀活动开始之后，会有大量用户通过电脑和/或手机等终端向秒杀服务器提交秒杀请求。秒杀服务器根据提前加载在秒杀服务器内存中的所秒杀商品的信息等对秒杀请求进行处理，当秒杀请求成功时，向用户返回秒杀成功的提示信息，当秒杀请求失败时，向用户返回秒杀失败的提示信息。

采用实施例1提供的一种突发业务处理方法，由于在接收突发业务的各业务处理请求之前，将业务资源加载在突发业务服务器中，由突发业务服务器对业务处理请求进行处理，所以突发业务服务器可以向用户快速响应业务资源的分配结果，从而解决了现有技术中业务资源分配的流程复杂，造成用户无法快速获知所提交的业务处理请求是否获得业务资源的问题，提高了用户体验，并且通过这种在突发业务服务器中预加载业务资源的方式，也提高了对业务处理请求的处理效率。

实施例2

在实施例1的步骤101中多次提到突发业务对应的业务资源，其实业务资源除了包括实施例1的步骤101中提到的各种资源之外，还可以包括权限标识，所述权限标识用于当突发业务服务器向业务处理请求分配所述权限标识后，对所述业务处理请求进行处理。这样就构成了本申请的实施例2，参考附图2，实施例2与实施例1相比步骤101变为步骤201同时步骤103变化为步骤203，步骤202与步骤102相同。

步骤201：突发业务服务器获取所述突发业务对应的业务资源，所述业务资源包括至少一个权限标识。

所述权限标识用于当根据业务处理请求获取所述权限标识时，对所述业务处理请求进行处理。在商品秒杀业务中，秒杀服务器通常会接收大量的秒杀请求，但是通常只有部分的秒杀请求能够秒杀成功，秒杀服务器通过分配权限标识的形式标识秒杀成功的秒杀请求，并对这些秒杀请求进行处理

通常突发业务服务器在处理突发业务的业务处理请求时，需要对业务处理 请求的权限标识做出判定，如果业务处理请求拥有权限标识，则突发业务服务器对该业务处理请求进行处理，如果业务处理请求没有权限标识，则突发业务服务器通常不会对该业务处理请求进行处理。

在实际应用中，当秒杀请求获取权限标识后，秒杀服务器通常会向用户返回秒杀成功的提示信息；如果秒杀请求最终未获取权限标识，秒杀服务器可以向提交秒杀请求的用户返回秒杀失败的提示信息，特殊情况下也可以不响应该秒杀请求。

步骤202：突发业务服务器将获取的所述业务资源加载在突发业务服务器的内存中。

在商品秒杀业务中，秒杀服务器将该商品秒杀业务对应的业务资源加载在秒杀服务器的内存中，业务资源中包含有所述权限标识。在实际应用中中权限标识可以是秒杀token(令牌)，也可以是随机字符串等。

步骤203：突发业务服务器当接收到针对所述突发业务的各业务处理请求时，向各所述业务处理请求分配加载在所述内存中的业务资源的所述权限标识，根据所述权限标识的分配结果对各所述业务处理请求进行处理。

突发业务服务器在接收大量业务处理请求时，向这些业务处理请求分配权限标识，可以通过权限标识的分配方式，来控制按照特定方式处理这些业务处理请求。所述对各所述业务处理请求进行处理还可以包括：对每一个业务处理请求来说，当该业务处理请求成功获取所述权限标识时，向该用户返回突发业务的业务处理请求获取所述权限标识成功的提示信息，当该业务处理请求获取所述权限标识失败时，向该用户返回突发业务的业务处理请求获取所述权限标识失败的提示信息。

通常可以根据各所述业务处理请求的接收顺序，分配加载在所述内存中的业务资源的所述权限标识，根据所述权限标识的分配结果对各所述业务处理请求进行处理。根据各所述业务处理请求的接收顺序，分配加载在所述内存中的业务资源的所述权限标识，突发业务服务器判定各所述业务处理请求是否能够 获得权限标识，若某一业务处理请求获取权限标识，对该业务处理请求进行处理。在商品秒杀业务过程中，突发业务服务器根据各个秒杀请求的接收顺序，向秒杀请求分配秒杀token，并根据秒杀token的分配结果对秒杀请求进行处理。

需要说明的是，在实际应用中还可以是，突发业务服务器向各所述业务处理请求随机分配加载在所述内存中的业务资源的所述权限标识，根据所述权限标识的分配结果对各所述业务处理请求进行处理，所述向各所述业务处理请求随机分配加载在所述内存中的业务资源的所述权限标识包括：从各所述业务处理请求中随机抽取部分业务处理请求，然后向所述部分业务处理请求分配权限标识，或以随机的顺序向所接受的全部业务处理请求分配权限标识。

另外，权限标识按接收顺序分配，或者是随机进行分配，或者是这两种分配方式结合，或者是其它的分配方式并不会影响本实施例的技术效果。特别的，在实际应用中可能会由于技术原因无法细分时间粒度，通常会采用接收顺序分配和随机进行分配相结合的方式分配权限标识。例如，在商品秒杀业务中，通常秒杀服务器能够区分，接收时间差为1毫秒以上的秒杀请求的先后顺序，如果两个秒杀请求接收的时间间隔小于1毫秒，秒杀服务器将无法区分这两个秒杀请求的先后顺序，将向这两个业务处理请求随机分配加载权限标识，需要进一步说明的是，所述向这两个业务处理请求随机分配加载权限标识具体为：从这两个业务处理请求中随机抽取一个业务处理请求，向所抽取的业务处理请求分配权限标识，或不考虑这两个业务处理请求的接收顺序，以随机的方式向这两个业务处理请求分配权限标识。

采用实施例2提供的一种突发业务处理方法，当业务资源中包含权限标识时，突发业务服务器按照预设的规则向突发业务的各业务处理请求分配权限标识，这样可以按照该预设规则的方式对各业务处理请求进行处理。

实施例3

在实施例2的步骤201中业务资源还可以包括权限标识数量阈值的信息， 权限标识数量阈值指权限标识数量的最大值。因此就构成了本申请的实施例3，参考附图3，实施例3与实施例2相比步骤201变为步骤301同时步骤203变化为步骤203，步骤302与步骤202相同。

步骤301：突发业务服务器获取所述突发业务对应的业务资源，所述业务资源包括至少一个权限标识和所述权限标识数量阈值的信息。

权限标识数量阈值指权限标识数量的最大值。当业务资源中包含至少一个权限标识，以及所述权限标识数量阈值的信息时，突发业务服务器接收大量的业务处理请求，通过权限标识和权限标识数量阈值控制进行处理的业务处理请求的数量。在实际应用中，通常秒杀活动提供秒杀的商品会有具体数量，这样就会在秒杀服务器中设置权限标识数量阈值，这个权限标识数量阈值通常就是指该秒杀服务器能够提供的该秒杀商品的数量。

特别的，当突发业务的业务处理请求较多时，通常需要至少有两个并行的突发业务服务器来处理，这时候既可以使并行的突发业务服务器获取与各自处理能力相匹配的所述突发业务对应的业务资源的所述权限标识数量阈值的信息，也可以使并行的突发业务服务器获取相同的所述突发业务对应的业务资源的所述权限标识数量阈值的信息。

在实际应用中，通常参与秒杀活动的用户较多，因此很多情况下需要至少有两个并行的突发业务服务器来处理秒杀业务，这时候可以使并行的各个秒杀服务器获取与各自处理能力相匹配的权限标识数量阈值的信息，也可以使并行的突发业务服务器获取相同的权限标识数量阈值的信息。例如，有两个并行的秒杀服务器A和B，A秒杀服务器的处理能力为每秒钟处理20个秒杀请求，B秒杀服务器的处理能力为每秒钟处理30个秒杀请求，这时候既可以使A和B秒杀服务器分别获取与各自处理能力相匹配的权限标识数量阈值，也可以使A和B秒杀服务器获取相同的权限标识数量阈值。

步骤302：突发业务服务器将获取的所述业务资源加载在突发业务服务器的内存中。

秒杀服务器在秒杀业务开始之前，将该秒杀业务对应的业务资源加载到秒杀服务器的内存中，在实际应用中如表1所示，一种手机秒杀业务的业务信息。

该手机秒杀业务中，在时间为2015-09-25 10:00:00之前，秒杀服务器将这些业务信息加载到内存中，时间为2015-09-25 10:00:00秒杀开始。

表1：手机秒杀业务的业务信息

针对所接收的每一个业务处理请求执行以下步骤：

步骤303a：根据所述业务处理请求确定已经分配的权限标识的数量。

步骤303b：判断所述数量是否小于所述权限标识数量阈值，若是，则执行步骤303c，若否，则执行步骤303d。

步骤303c：向业务处理请求分配加载在所述内存中的业务资源的所述权限标识，基于所述权限标识对所述业务处理请求进行处理。

特别的，在实际应用中为了使用户尽快获知所提交的业务处理请求的结果，突发业务服务器向该业务处理请求分配权限标识后，还可以向该业务请求对应的用户返回所述突发业务的业务处理请求成功的提示信息。

步骤303d：返回所述突发业务处理失败的提示信息。

以商品秒杀业务为例，由于所秒杀商品的数量有限，因此突发业务服务器获取的业务资源中包含的秒杀token通常会设置为某个数量，权限标识数量阈值也即秒杀token数量阈值是指所秒杀商品的数量。秒杀请求只有获取权限标识才能秒杀成功，而秒杀请求是否能够获取权限标识，是决定于在接收该秒杀请求之前，已经接秒杀请求的数量与权限标识数量阈值大小的比较结果。

突发业务服务器接受某一秒杀请求后，直接根据该秒杀请求的接收顺序，确定该秒杀请求之前已经接受的秒杀请求的数量，并通过该数量和秒杀token数量阈值的比较确定是否向该秒杀请求分配秒杀token。

采用实施例3提供的一种突发业务处理方法，当业务资源中包含权限标识以及权限标识数量阈值的信息时，突发业务服务器在向业务处理请求分配权限标识之前，先确定已经分配的权限标识的数量，然后通过所确定的数量与权限标识数量阈值进行比较，从而判定是否向该业务处理请求分配权限标识，从而使得突发业务服务器能够只处理部分的业务处理请求，特别是在特定的业务场景，例如商品秒杀业务中，通过权限标识和权限标识数量阈值保证了该秒杀业务的有效执行。

实施例4

在实施例3的步骤303c中提到，对所述业务处理请求进行处理。其实，在实际应用中，通过将突发业务服务器与业务处理服务器相连时，由业务处理服务器来处理突发业务，这样就构成了本申请的实施例4。本申请的实施例4与实施例3相比，突发业务服务器与业务处理服务器相连，因此步骤303c变化为步骤403c，并且步骤403c之后多了步骤404、405外，其它步骤均相同。

步骤403c：向业务处理请求分配加载在所述内存中的业务资源的所述权限标识，基于所述权限标识提交所述突发业务的业务处理请求。

在实际应用中，可以采用普通消息模式提交所述业务处理请求，但是有些情况下，为了保证所提交的业务处理请求会被接收端读取，可以通过可靠消息的方式提交业务处理请求，所述可靠消息指会被接收端读取的消息。

步骤404：业务处理服务器接收突发业务服务器所提交的所述突发业务的业务处理请求。

步骤405：业务处理服务器向所述业务处理请求对应的用户返回突发业务处理入口，所述业务处理入口为触发该突发业务处理入口进行突发业务处理。

当获取加载在所述内存中的业务资源的所述权限标识成功之后，突发业务服务器向业务处理服务器提交该突发业务的业务处理请求，业务处理服务器接收突发业务的该业务处理请求，向用户返回业务处理入口，用户通过该业务处理入口进行业务处理。

在商品秒杀业务中，结合附图4所示，用户通过客户端向秒杀服务器提交秒杀请求，秒杀服务器根据提前加载在内存中的秒杀token以及秒杀token数量阈值的信息，根据接收秒杀请求的顺序分配秒杀token。当秒杀服务器向某一秒杀请求分配秒杀token之后，向业务处理服务器发送该秒杀业务的业务处理请求，业务处理服务器通过该秒杀业务的业务处理请求开启正常的购买程序，向用户返回该商品的业务处理入口，用户通过该业务处理入口进行所秒杀商品的购买。

采用实施例4提供的一种突发业务处理方法，通过将突发业务服务器和业务处理服务器相连接，业务处理服务器接收突发业务服务器所提交的突发业务的业务处理请求，开启突发业务的正常处理。

实施例5

在实施例1的步骤103中提到突发业务服务器当接收到针对所述突发业务的各业务处理请求时，其实在实施例中还可以包含负载均衡服务器和多个并行的突发业务服务器，并且由负载均衡服务器向多个并行的突发业务服务器分配突发业务的处理请求，因此就构成了本发明的实施例5，本申请的实施例5与实施例1相比，除在步骤103之前多了步骤1031外，其它步骤均相同。

步骤1031：所述负载均衡服务器向所述并行的突发业务服务器分配与各自处理能力相匹配数量的突发业务的业务处理请求，或者所述负载均衡服务器向所述并行的突发业务服务器平均分配相同数量的突发业务的业务处理请求。

当负载均衡服务器连接多个并行的突发业务服务器时，可以根据突发业务服务器处理能力的不同分配突发业务请求，也可以平均分配突发业务处理请求。

在实际的商品秒杀业务中，并行的秒杀服务器通常会连接着负载均衡服务器，通过负载均衡服务器向秒杀服务器来分配秒杀请求。一般在各并行的秒杀服务器处理能力相差不大的情况下，负载均衡服务器会采用平均分配的方式向各并行的秒杀服务器分配秒杀请求，有的时候，各个秒杀服务器之间处理能力相差较大，负载均衡服务器可以根据它们各自的处理能力分配秒杀请求，在这里并不对分配秒杀请求的方式做出限定。

采用实施例5提供的一种突发业务处理方法，当包含有负载均衡服务器时，通过负载均衡服务器向多个并行的突发业务服务器分配突发业务处理请求，能够更好的发挥多个并行的突发业务服务器各自的处理能力。

实施例6

上述所有实施例已经能够完成对突发业务的处理，实施例中还可以将突发业务服务器连接监测服务器，所述监测服务器用于监测突发业务服务器是否出现错误，这就构成了本申请的实施例6。本申请的实施例6与实施例1相比，除多了步骤601a、601b、601c外，其它步骤均相同。

步骤601a：所述监测服务器向所述突发业务服务器发送检测信号。

步骤601b：当所述突发业务服务器正常工作时，向所述突发业务服务器返回信号。

步骤601c：当所述突发业务服务器出现错误时，终止接收突发业务的处理请求。

在实际应用之，当突发业务服务器在短时间内接收大量的突发业务时，容易导致突发业务服务器出现错误。因此，可以将突发业务服务器连接监测服务器，用于监测突发业务服务器是否出现错误，这些错误包括发热等原因导致的机器故障，也包括压力过大等原因导致的计算速度缓慢，甚至还可以包括网络不稳定等原因造成的故障。

在实际应用中，监测服务器可以采用心跳检测的方式对突发业务服务器进 行检测，也就是每隔一段时间(可以设置为2秒或者5秒)向突发业务服务器发送检测信号，如果突发业务服务器正常工作，则在接收到检测信号之后向检测服务器发送返回信号。当监测服务器在预设时间内没有收到返回信号时，则判断突发业务服务器出现错误，这时候可以终止该突发业务服务器对突发业务的处理。

采用实施例6提供的一种突发业务处理方法，将突发业务服务器连接监测服务器，监测服务器可以通过心跳检测的方式，向突发业务服务器发送监检测息，根据检测消息的返回结果，监测突发业务服务器在工作中是否出现错误，进一步保证了突发业务服务器的正常工作。

实施例7

在实际的商品秒杀业务中，秒杀服务器通常会在秒杀开始之前，预加载一些处理模块，通过这些预加载的处理模块来提高该秒杀服务器的处理效率，如图5所示的秒杀预加载模块。如表2所示为实际应用中一种预加载模块的信息。

在表2的各预加载模块的信息中，

秒杀预加载模块70b：该模块主要有两个功能：1、秒杀商品的预加载触发2、按照设定的秒杀规则将秒杀token分配给秒杀服务器。

其中秒杀商品的预加载触发：秒杀预加载模块会定期(可以为30秒或50秒一次)进行轮训“秒杀商品表”判断在接下来的几分钟(可以为3分钟)内是否有商品秒杀活动。如果有，则触发预加载策略触发模块进行秒杀商品的秒杀token分配。

以上表1的手机秒杀业务为例，在时间点为2015-09-25 09：57：00时，秒杀预加载模块就会触发对XX手机秒杀的预加载策略触发模块。

预加载策略触发模块：按照预设的规则将秒杀token进行向各秒杀服务器进行分配，其中预设的规则通常有相面两种：

平均分配：每台秒杀服务器都分配相同的商品。假设一共有20台秒杀服务器，那么就会每台服务器分配到5个秒杀token。

按照系统压力分配：按照当前的系统压力进行分配秒杀token。假设一共有20台秒杀服务器，但其中有一台CPU消耗已经偏高，那么会分配token给这一台4个token；另外一台CPU消耗偏低，会分配6个token。最后，这些分配信息会推送到秒杀服务器。秒杀服务器在下一个模块会进行内存加载。

表2：实际应用中通常使用的各预加载模块的信息

秒杀token抢占模块70b：

以上面的例子为准，我们将100个商品平均分配到20台应用服务上，每台秒杀应用服务器都会分配得到5个秒杀商品的秒杀token。

按照秒杀商品预加载模块推送过来的信息，每台秒杀服务器都会分配到5 个秒杀token。对于每台秒杀服务器：采用线程安全的队列模式，生成一个长度为5的安全队列。

接收到预加载信息推送后，应用服务器会在内存中生成一个线程安全的队列对象，队列的长度为5。

在开始秒杀时，所有的线程都会尝试从这个队列中获取对象。每当某个线程获取到对象，队列的长度会自然的减1，直至减到0为止。

对于最开始的5个线程，他们是可以从这个队列中获取到对象的。对于这5个用户线程，触发下一模块的异步下单操作。

对于之后的其它线程，他们无法从队列中获取token对象，因此会直接返回失败。提示用户秒杀失败。

秒杀商品异步下单模块70c:

为了防止秒杀的商品数量过多，以至于同一时间对秒杀商品的下单造成对预算量过大，采用异步可靠消息的方式进行下单。

秒杀服务器将用户信息、商品信息、秒杀token信息通过可靠消息发送到业务处理服务器，然后向用户返回秒杀成功的提示信息。

业务处理服务器读取可靠消息，并获取到用户信息、商品信息、秒杀token信息。通过异步线程将这些信息组装成真正的商品下单信息，完成秒杀商品的购买。

基于相同的发明构思，实施例7提供了一种突发业务处理装置。如图6所示，该装置700包括：获取单元701、加载单元702、接收单元703和处理单元704，其中：

获取单元，用于获取所述突发业务对应的业务资源；

加载单元，用于将获取的所述业务资源加载在突发业务服务器的内存中；

接收单元，用于接收到针对所述突发业务的业务处理请求；

处理单元，用于根据加载在所述内存中的业务资源，对各所述业务处理请求进行处理。所述对各所述业务处理请求进行处理可以包括向各所述业务处理 请求对应的用户返回业务处理的提示信息。

以商品秒杀业务为例，当秒杀服务器判定用户秒杀成功后，向业务处理服务器提交该用户的秒杀业务的业务处理请求，业务处理服务器通过该秒杀业务的业务处理请求开启秒杀商品的购买服务，并向用户返回秒杀商品购买的入口，用户通过该入口进行所秒杀商品的购买。

采用实施例7提供的一种突发业务处理装置，由于该装置根据加载在加载单元中的业务资源，对各所述业务处理请求进行处理，所以简化了对突发业务的处理过程，该装置可以快速的向用户返回业务处理请求获取业务资源是否成功的结果，同时业务资源在该装置上进行预加载也提高了对业务处理请求的处理效率。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个 流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。