一种消息队列处理方法、装置及系统与流程

1.本技术涉及信息处理领域，尤其涉及一种消息队列处理方法、装置及系统。

背景技术：

2.目前，电商平台中的秒杀系统通常基于redis数据库、memcached缓存系统或消息队列实现，然而，基于消息队列实现的秒杀系统，则会存在消息队列中消息堆积的问题。

技术实现要素：

3.有鉴于此，本技术提供一种消息队列处理方法、装置及系统，其具体方案如下：
4.一种消息队列处理方法，包括：
5.确定消息队列中每个抢购请求进入所述消息队列的时间信息；
6.基于所述消息队列中每个抢购请求的时间信息确定所述消息队列当前是否存在堆积风险；
7.若确定所述消息队列当前存在堆积风险，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；
8.基于扩容后的队列机器进行消息队列中抢购请求的处理。
9.进一步的，所述基于所述消息队列中每个抢购请求的时间信息确定所述消息队列当前是否存在堆积风险，包括：
10.确定所述消息队列中进入所述消息队列的时间信息满足预设时长的抢购请求的数量；
11.若确定满足预设时长的抢购请求的数量达到预设数量，则确定所述消息队列当前存在堆积风险。
12.进一步的，还包括：
13.若基于扩容后的队列机器进行消息队列中抢购请求的处理，确定所述消息队列存在堆积风险，启动多层校验模式，进行业务限流及流程校验。
14.进一步的，还包括：
15.获得抢购请求；
16.基于所述抢购请求对请求参数进行解密，获得解密后的商品请求信息；
17.基于所述商品请求信息进行抢购活动校验；
18.若所述抢购活动校验通过，将所述抢购请求存储至消息队列。
19.进一步的，还包括：
20.若所述抢购活动校验通过，生成抢购标识，将所述抢购标识输出至发送所述抢购请求的客户端；
21.获得所述客户端基于所述抢购标识输出的下单查询请求；
22.将获得的下单结果反馈至所述客户端。
23.进一步的，获得下单结果，包括：
24.基于扩容后的队列机器将消息队列中的抢购请求发送至业务系统，完成下单；
25.获得所述业务系统反馈的下单结果。
26.一种消息队列处理装置，包括：
27.第一确定单元，用于确定消息队列中每个抢购请求进入所述消息队列的时间信息；
28.第二确定单元，用于基于所述消息队列中每个抢购请求的时间信息确定所述消息队列当前是否存在堆积风险；
29.发送单元，用于在确定所述消息队列当前存在堆积风险时，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；
30.处理单元，用于基于扩容后的队列机器进行消息队列中抢购请求的处理。
31.一种消息队列处理系统，包括：
32.客户端，用于发送抢购请求；
33.消息队列处理装置，用于确定消息队列中每个抢购请求进入所述消息队列的时间信息；基于所述消息队列中每个抢购请求的时间信息确定所述消息队列当前是否存在堆积风险；若确定所述消息队列当前存在堆积风险，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；基于扩容后的队列机器进行消息队列中抢购请求的处理。
34.进一步的，还包括：
35.业务系统，用于获得所述消息队列处理装置发送的抢购请求，生成下单结果，并将所述下单结果反馈至所述消息队列处理装置。
36.进一步的，
37.所述消息队列处理装置包括：特定服务器。
38.从上述技术方案可以看出，本技术公开的消息队列处理方法、装置及系统，确定消息队列中每个抢购请求进入消息队列的时间信息；基于消息队列中每个抢购请求的时间信息确定消息队列当前是否存在堆积风险；若确定消息队列当前存在堆积风险，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；基于扩容后的队列机器进行消息队列中抢购请求的处理。本方案中，若基于消息队列中每个抢购请求进入消息队列的时间信息确定当前存在堆积风险时，进行自动扩容，以避免消息堆积的情况发生，整个过程无需人工干预，减少人工成本。
附图说明
39.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
40.图1为本技术实施例公开的一种消息队列处理方法的流程图；
41.图2为本技术实施例公开的一种消息队列处理方法的流程图；
42.图3为本技术实施例公开的一种消息队列处理方法的流程图；
43.图4为本技术实施例公开的一种消息队列处理方法的完整流程图；
44.图5为本技术实施例公开的一种消息队列处理装置的结构示意图；
45.图6为本技术实施例公开的一种消息队列处理系统的结构示意图。
具体实施方式
46.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
47.本技术公开了一种消息队列处理方法，其流程图如图1所示，包括：
48.步骤s11、确定消息队列中每个抢购请求进入消息队列的时间信息；
49.步骤s12、基于消息队列中每个抢购请求的时间信息确定消息队列当前是否存在堆积风险；
50.步骤s13、若确定消息队列当前存在堆积风险，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；
51.步骤s14、基于扩容后的队列机器进行消息队列中抢购请求的处理。
52.若电商平台中的秒杀系统是基于消息队列实现的，则会存在消息堆积的情况发生。
53.为了避免上述情况的发生，本方案中当确定消息队列存在堆积风险时，进行队列机器数的扩容，以减少消息堆积的状况。
54.当电商平台中有秒杀商品时，需要通过秒杀系统实现消费者对秒杀商品的购买，此时，秒杀系统会接收到多个消费者发送的抢购请求，秒杀系统将接收到的抢购请求存储在秒杀队列中，当抢购请求过多时，就会出现消息队列中消息堆积的情况。其中，秒杀系统即本实施例公开的消息队列处理方法所基于的消息队列处理装置。
55.具体的，确定消息队列中每个抢购请求进入消息队列的时间信息，基于消息队列中每个抢购请求的时间信息确定消息队列当前是否存在堆积风险。
56.消息队列中存储抢购请求时，其至少还存储有抢购请求存储至消息队列的时间信息，基于当前时刻与每个抢购请求存储至消息队列的时间信息之间的差值，可确定每个抢购请求存储至消息队列的时长。
57.确定消息队列中进入消息队列的时间信息满足预设时长的抢购请求的数量；若确定满足预设时长的抢购请求的数量达到预设数量，则确定消息队列当前存在堆积风险。
58.即：当消息队列中存储的某个抢购请求进入消息队列的时长达到预设时长，则可确定该抢购请求为待处理抢购请求，确定消息队列中的待处理抢购请求的数量，即确定消息队列中进入消息队列的时长达到预设时长的抢购请求的数量。
59.当该数量达到预设数量时，可直接确定消息队列当前存在堆积风险，即消息队列中存储时长较长的抢购请求的数量较多，此时，确定存在堆积风险；若消息队列中的待处理抢购请求的数量未达到预设数量，则可确定消息队列当前不存在堆积风险，继续执行抢购流程即可，无需对消息队列执行其他处理。
60.如：某个抢购请求进入消息队列的时长超过5s，则将该抢购请求确定待待处理抢购请求，当进入消息队列的时长超过5s的抢购请求超过50个，则确定当前队列存在堆积风险。
61.若确定消息队列当前存在堆积风险，则需要发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容。
62.基于事件驱动的自动伸缩组件，即kubernets基于事件驱动的自动伸缩组件(kubernets event-driven autoscaling，keda)，keda是一个单一用途的轻量级组件，可添加到任何kubernetes集中，适配范围广，其允许使用external metrics来定义任何事件源的自动伸缩。
63.keda能够根据触发器来自动伸缩scaledobject中定义的deployment或statefulset，keda负责监控事件源，并将数据反馈给kubernets和hpa进行资源的伸缩。
64.其中，扩容机器最大机器数决定于下单接口并发能力，具体的，后端每台服务器会有多个线程去消息队列，线程数由后端下单服务器能承受的并发数去确定，即：线程数*队列机器数≤后端下单接口并发能力，由此可确定扩容的机器数最多可以为多少。
65.其中，后端下单接口并发能力是后端的一个服务，如：后端下单接口并发能力为1秒100的并发请求，而前端2台机器能够承受1秒100的并发请求，则用于处理消息队列中抢购请求的机器最多2台即可，即使再扩容机器也不能提升并发能力。
66.当机器扩容后，能够同时处理的抢购请求数增加，可减缓堆积的发生。则在扩容完成后继续执行抢购请求的处理流程。
67.本实施例公开的消息队列处理方法，确定消息队列中每个抢购请求进入消息队列的时间信息；基于消息队列中每个抢购请求的时间信息确定消息队列当前是否存在堆积风险；若确定消息队列当前存在堆积风险，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；基于扩容后的队列机器进行消息队列中抢购请求的处理。本方案中，若基于消息队列中每个抢购请求进入消息队列的时间信息确定当前存在堆积风险时，进行自动扩容，以避免消息堆积的情况发生，整个过程无需人工干预，减少人工成本。
68.本实施例公开了一种消息队列处理方法，其流程图如图2所示，包括：
69.步骤s21、确定消息队列中每个抢购请求进入消息队列的时间信息；
70.步骤s22、基于消息队列中每个抢购请求的时间信息确定消息队列当前是否存在堆积风险；
71.步骤s23、若确定消息队列当前存在堆积风险，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；
72.步骤s24、基于扩容后的队列机器进行消息队列中抢购请求的处理；
73.步骤s25、若基于扩容后的队列机器进行消息队列中抢购请求的处理时，确定消息队列存在堆积风险，启动多层校验模式，进行业务限流及流程校验。
74.当确定消息队列存在堆积风险时，首先进行机器扩容，以减缓堆积风险的发生，在机器扩容后，基于扩容后的队列机器进行消息队列中抢购请求的处理。
75.在基于扩容后的队列机器进行消息队列中抢购请求的处理的同时，仍会对当前消息队列中每个抢购请求进入消息队列的时间信息进行确定，以便确定当前消息队列是否存在堆积风险。即可定时对消息队列是否存在堆积风险进行判断，或者每接收预设数值的抢购请求，就会判断一次当前消息队列是否存在堆积风险。
76.或者，在执行机器扩容完成后，首先基于扩容后的队列机器进行消息队列中抢购请求的处理，在基于扩容后的队列机器进行消息队列中抢购请求的处理一定时长后，再次
判断消息队列是否仍存在堆积风险。
77.若在机器扩容后，确定消息队列仍然存在堆积风险，则启动多层校验模式，增加业务限流及流程校验的过程，以减少消息队列中的抢购请求。
78.多层校验模式，即在流量较多时用于清洗流量的一种模式，如：黑产大流量不间断请求时，会存在消息队列中消息堆积风险，此时，可启动多层校验模式，以便在多层校验模式下清理部分黑产流量，使得消息队列中的消息数量减少，避免消息队列出现消息堆积的情况。
79.在多层校验模式下，进行业务限流及流程校验，其中，业务限流即根据业务实际情况设定其单位时间内最大可接收的抢购请求，以减少存储至消息队列中的抢购请求的数量；流程校验，即：增加抢购请求对应的用户鉴权和风控的验证，只有验证通过后，才将相应的抢购请求添加至消息队列中。
80.其中，多层校验模式，即在redis数据库中添加一个标识符，定时获取该标识符的数值，以确定多层校验模式是否启动，具体的：当标识符为0时，则未启动多层校验模式，当标识符为1时，则启动多层校验模式。
81.另外，还可增加是否超时的判断，即判断消息队列中的抢购请求是否超时，若确定其超时，则可直接启动多层校验模式；若其未超时，则继续进行后续处理，其后续处理可以为：确定当前是否启动多层校验模式，若未启动多层校验模式，则继续执行后续下单流程；若启动多层校验模式，则执行多层校验中的业务限流及流程校验，当校验通过后，再执行下单流程。
82.在经过多层校验模式后添加至消息队列中的抢购请求，在进行处理时，调用下单接口，向业务系统下单，并获得业务系统反馈的下单结果，将下单结果保存至redis数据库中，以便在客户端轮询其抢购请求的下单结果时，能够将下单结果从redis数据库中调取并反馈至该相应的客户端，通知客户端侧的消费者。
83.本实施例公开的消息队列处理方法，确定消息队列中每个抢购请求进入消息队列的时间信息；基于消息队列中每个抢购请求的时间信息确定消息队列当前是否存在堆积风险；若确定消息队列当前存在堆积风险，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；基于扩容后的队列机器进行消息队列中抢购请求的处理。本方案中，若基于消息队列中每个抢购请求进入消息队列的时间信息确定当前存在堆积风险时，进行自动扩容，以避免消息堆积的情况发生，整个过程无需人工干预，减少人工成本。
84.本实施例公开了一种消息队列处理方法，其流程图如图3所示，包括：
85.步骤s31、获得抢购请求，基于抢购请求对请求参数进行解密，获得解密后的商品请求信息；
86.步骤s32、基于商品请求信息进行抢购活动校验；
87.步骤s33、若抢购活动校验通过，将抢购请求存储至消息队列；
88.步骤s34、确定消息队列中每个抢购请求进入消息队列的时间信息；
89.步骤s35、基于消息队列中每个抢购请求的时间信息确定消息队列当前是否存在堆积风险；
90.步骤s36、若确定消息队列当前存在堆积风险，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；
91.步骤s37、基于扩容后的队列机器进行消息队列中抢购请求的处理。
92.在消息队列处理装置中，若获得客户端发送的抢购请求，首先对该抢购请求进行加解密校验。
93.客户端能够集成指定密钥key，并通过关键字段及时间戳进行加密生成加密串，服务器通过加密串解密获得关键字段及时间戳进行校验，以便服务器基于关键字段及时间戳确定该客户端在指定时间内是否对指定商品连续发出抢购请求，做到防刷，从而避免消息队列中的多个抢购请求为同一个客户端输出的。
94.服务器通过加密串解密获得的关键字段至少包括：活动标识、用户标识、商品属性标识sku等信息，时间戳即抢购请求输出的时间。其中，关键字段及时间戳即本实施例所涉及的商品请求信息。
95.对商品请求信息进行校验，可具体为：判断该商品请求信息中的活动标识对应的活动是否开始，和/或，判断该商品请求信息中的商品属性标识sku对应的商品是否在活动中，和/或，判断该商品请求信息中的商品属性标识sku对应的商品的库存是否足够等，其中，活动信息可通过定时任务从数据库中获取。
96.另外，对商品请求信息进行校验还可以包括：确定商品请求信息中的参数是否缺失。
97.只有当上述校验通过后，才会将该抢购请求存储至消息队列中，等待处理。若校验未通过，则生成已结束的状态码，并将该已结束的状态码发送至客户端，以使客户端明确当前抢购请求的校验未通过。上述校验的过程即用户鉴权的过程。
98.进一步的，在校验通过，将抢购请求存储至消息队列的同时，还会生成抢购标识，将抢购标识输出至发送抢购请求的客户端，获得客户端基于抢购标识输出的下单查询请求，将获得的下单结果反馈至客户端。
99.生成的抢购标识req_id是当前抢购请求的唯一标识，用于表示该抢购请求，客户端需基于该抢购标识定时轮询服务器，以查询本次抢购请求是否成功。
100.在生成抢购标识后，将抢购标识发送至客户端，同时发送至客户端的还包括处理中的状态码，以使客户端明确当前抢购请求的标识以及该抢购当前处理状态为处理中。
101.客户端在收到该抢购标识后，会定时基于该抢购标识进行轮训，以查询该请求的当前状态；服务器在确定抢购请求的校验通过后，将其存储至消息队列，之后，服务器对消息队列中的多个抢购请求进行处理，基于抢购请求依次向业务系统下单，并获得业务系统基于抢购请求的下单结果。
102.若服务器确定下单结果为下单成功，则将下单成功的信息发送至客户端，以便客户端完成支付，若服务器确定下单结果为下单未成功，则将下单未成功的信息发送至客户端，以便消费者知悉。
103.因此，本实施例公开的消息队列处理方法的完整流程图如图4所示。
104.其中，服务器即本实施例所公开的消息队列处理方法所基于的消息队列处理装置，消息队列处理装置基于服务器实现，该服务器可以为特定服务器，该特定服务器可以为：nginx服务器。
105.nginx服务器因epoll模型天然支持高并发，承接同样大流量nginx服务器会比java服务器优势明显，一台nginx服务器可充当几台java服务器使用，因此，本实施例公开
的消息队列处理方法可采用nginx服务器直连消息队列的方式，以节约机器成本，提高系统的整体性能。
106.本实施例公开的消息队列处理方法，确定消息队列中每个抢购请求进入消息队列的时间信息；基于消息队列中每个抢购请求的时间信息确定消息队列当前是否存在堆积风险；若确定消息队列当前存在堆积风险，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；基于扩容后的队列机器进行消息队列中抢购请求的处理。本方案中，若基于消息队列中每个抢购请求进入消息队列的时间信息确定当前存在堆积风险时，进行自动扩容，以避免消息堆积的情况发生，整个过程无需人工干预，减少人工成本。
107.本实施例公开了一种消息队列处理装置，其结构示意图如图5所示，包括：
108.第一确定单元51，第二确定单元52，发送单元53及处理单元54。
109.第一确定单元51用于确定消息队列中每个抢购请求进入消息队列的时间信息；
110.第二确定单元52用于基于消息队列中每个抢购请求的时间信息确定消息队列当前是否存在堆积风险；
111.发送单元53用于在确定消息队列当前存在堆积风险时，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；
112.处理单元54用于基于扩容后的队列机器进行消息队列中抢购请求的处理。
113.进一步的，第二确定单元用于：
114.确定消息队列中进入消息队列的时间信息满足预设时长的抢购请求的数量；若确定满足预设时长的抢购请求的数量达到预设数量，则确定消息队列当前存在堆积风险。
115.进一步的，本实施例公开的消息队列处理装置还可以包括：
116.启动单元，用于在基于扩容后的队列机器进行消息队列中抢购请求的处理时，确定消息队列存在堆积风险，启动多层校验模式，进行业务限流及流程校验。
117.进一步的，本实施例公开的消息队列处理装置还可以包括：
118.校验单元，用于获得抢购请求；基于抢购请求对请求参数进行解密，获得解密后的商品请求信息；基于商品请求信息进行抢购活动校验；若抢购活动校验通过，将抢购请求存储至消息队列。
119.进一步的，本实施例公开的消息队列处理装置还可以包括：
120.传输单元，用于在确定抢购活动校验通过，生成抢购标识，将抢购标识输出至发送抢购请求的客户端；获得客户端基于抢购标识输出的下单查询请求；将获得的下单结果反馈至客户端。
121.进一步的，传输单元用于：
122.基于扩容后的队列机器将消息队列中的抢购请求发送至业务系统，完成下单；获得业务系统反馈的下单结果。
123.本实施例公开的消息队列处理装置是基于上述实施例公开的消息队列处理方法实现的，在此不再赘述。
124.本实施例公开的消息队列处理装置，确定消息队列中每个抢购请求进入消息队列的时间信息；基于消息队列中每个抢购请求的时间信息确定消息队列当前是否存在堆积风险；若确定消息队列当前存在堆积风险，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；基于扩容后的队列机器进行消息队列中抢购请求的处理。本方案中，
若基于消息队列中每个抢购请求进入消息队列的时间信息确定当前存在堆积风险时，进行自动扩容，以避免消息堆积的情况发生，整个过程无需人工干预，减少人工成本。
125.本实施例公开了一种消息队列处理系统，其结构示意图如图6所示，包括：
126.客户端61及消息队列处理装置62。
127.客户端61用于发送抢购请求；
128.消息队列处理装置62用于确定消息队列中每个抢购请求进入消息队列的时间信息；基于消息队列中每个抢购请求的时间信息确定消息队列当前是否存在堆积风险；若确定消息队列当前存在堆积风险，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；基于扩容后的队列机器进行消息队列中抢购请求的处理。
129.进一步的，本实施例公开的消息队列处理系统，还可以包括：
130.业务系统，用于获得消息队列处理装置发送的抢购请求，生成下单结果，并将下单结果反馈至消息队列处理装置。
131.本实施例公开的消息队列处理系统是基于上述实施例公开的消息队列处理方法实现的，在此不再赘述。
132.本实施例公开的消息队列处理系统，确定消息队列中每个抢购请求进入消息队列的时间信息；基于消息队列中每个抢购请求的时间信息确定消息队列当前是否存在堆积风险；若确定消息队列当前存在堆积风险，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；基于扩容后的队列机器进行消息队列中抢购请求的处理。本方案中，若基于消息队列中每个抢购请求进入消息队列的时间信息确定当前存在堆积风险时，进行自动扩容，以避免消息堆积的情况发生，整个过程无需人工干预，减少人工成本。
133.本实施例公开了一种电子设备，包括：
134.处理器及存储器。
135.处理器用于确定消息队列中每个抢购请求进入消息队列的时间信息；基于消息队列中每个抢购请求的时间信息确定消息队列当前是否存在堆积风险；若确定消息队列当前存在堆积风险，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；基于扩容后的队列机器进行消息队列中抢购请求的处理；
136.存储器用于存储处理器执行上述处理过程的程序。
137.本技术公开的电子设备，确定消息队列中每个抢购请求进入消息队列的时间信息；基于消息队列中每个抢购请求的时间信息确定消息队列当前是否存在堆积风险；若确定消息队列当前存在堆积风险，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；基于扩容后的队列机器进行消息队列中抢购请求的处理。本方案中，若基于消息队列中每个抢购请求进入消息队列的时间信息确定当前存在堆积风险时，进行自动扩容，以避免消息堆积的情况发生，整个过程无需人工干预，减少人工成本。
138.本技术实施例还提供了一种可读存储介质，其上存储有计算机程序，所述计算机程序被处理器加载并执行，实现上述消息队列处理方法的各步骤，具体实现过程可以参照上述实施例相应部分的描述，本实施例不做赘述。
139.本技术还提出了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该电子设备执行
上述消息队列处理方法方面或消息队列处理装置方面的各种可选实现方式中所提供方法，具体实现过程可以参照上述相应实施例的描述，不做赘述。
140.本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
141.专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
142.结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。
143.对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本技术。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本技术的精神或范围的情况下，在其它实施例中实现。因此，本技术将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

技术特征：

1.一种消息队列处理方法，其特征在于，包括：确定消息队列中每个抢购请求进入所述消息队列的时间信息；基于所述消息队列中每个抢购请求的时间信息确定所述消息队列当前是否存在堆积风险；若确定所述消息队列当前存在堆积风险，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；基于扩容后的队列机器进行消息队列中抢购请求的处理。2.根据权利要求1所述的方法，其特征在于，所述基于所述消息队列中每个抢购请求的时间信息确定所述消息队列当前是否存在堆积风险，包括：确定所述消息队列中进入所述消息队列的时间信息满足预设时长的抢购请求的数量；若确定满足预设时长的抢购请求的数量达到预设数量，则确定所述消息队列当前存在堆积风险。3.根据权利要求1所述的方法，其特征在于，还包括：若基于扩容后的队列机器进行消息队列中抢购请求的处理，确定所述消息队列存在堆积风险，启动多层校验模式，进行业务限流及流程校验。4.根据权利要求1所述的方法，其特征在于，还包括：获得抢购请求；基于所述抢购请求对请求参数进行解密，获得解密后的商品请求信息；基于所述商品请求信息进行抢购活动校验；若所述抢购活动校验通过，将所述抢购请求存储至消息队列。5.根据权利要求4所述的方法，其特征在于，还包括：若所述抢购活动校验通过，生成抢购标识，将所述抢购标识输出至发送所述抢购请求的客户端；获得所述客户端基于所述抢购标识输出的下单查询请求；将获得的下单结果反馈至所述客户端。6.根据权利要求5所述的方法，其特征在于，获得下单结果，包括：基于扩容后的队列机器将消息队列中的抢购请求发送至业务系统，完成下单；获得所述业务系统反馈的下单结果。7.一种消息队列处理装置，其特征在于，包括：第一确定单元，用于确定消息队列中每个抢购请求进入所述消息队列的时间信息；第二确定单元，用于基于所述消息队列中每个抢购请求的时间信息确定所述消息队列当前是否存在堆积风险；发送单元，用于在确定所述消息队列当前存在堆积风险时，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；处理单元，用于基于扩容后的队列机器进行消息队列中抢购请求的处理。8.一种消息队列处理系统，其特征在于，包括：客户端，用于发送抢购请求；消息队列处理装置，用于确定消息队列中每个抢购请求进入所述消息队列的时间信息；基于所述消息队列中每个抢购请求的时间信息确定所述消息队列当前是否存在堆积风
险；若确定所述消息队列当前存在堆积风险，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；基于扩容后的队列机器进行消息队列中抢购请求的处理。9.根据权利要求8所述的系统，其特征在于，还包括：业务系统，用于获得所述消息队列处理装置发送的抢购请求，生成下单结果，并将所述下单结果反馈至所述消息队列处理装置。10.根据权利要求8所述的系统，其特征在于，所述消息队列处理装置包括：特定服务器。

技术总结

本申请公开了一种消息队列处理方法、装置及系统，确定消息队列中每个抢购请求进入消息队列的时间信息；基于消息队列中每个抢购请求的时间信息确定消息队列当前是否存在堆积风险；若确定消息队列当前存在堆积风险，发送扩容事件至基于事件驱动的自动伸缩组件，进行队列机器数的扩容；基于扩容后的队列机器进行消息队列中抢购请求的处理。本方案中，若基于消息队列中每个抢购请求进入消息队列的时间信息确定当前存在堆积风险时，进行自动扩容，以避免消息堆积的情况发生，整个过程无需人工干预，减少人工成本。减少人工成本。减少人工成本。