基于消息中间件背压的消息消费的方法和系统与流程

1.本发明属于物联网通信技术领域，具体涉及一种基于消息中间件背压的消息消费的方法和系统。


背景技术：

2.随着互联网技术和物联网技术应用的发展，越来越多的应用场景需要将消息处理推送到第三方中间件以保证应用负载安全，因此消息中间件得到了广泛的应用。但是在现有消息中间件中，若希望保证消息消费的有序行，则需要保证消费端进行单线程消费,只能被一个客户端监听，若在消息处理时间较长的情况下，会出现全局阻塞的情况，这种情况是无法忍受的。而另一种处理方式为创建多队列，通过消息标识来分发到各个消息分区，每个分区对应一个线程消费，这种预配置的方式也存在不好动态扩容的问题，并且如果配置分区过多也可能导致服务器过负载的情况。所以单纯依赖消息中间件并不能很好实现消息单队列串行，多队列并行的处理模式。
3.中国发明专利cn201910938392.9，公开了一种消息队列的动态调度方法及装置，首先建立多组消息队列，按qos级别对所述多组消息队列进行排序，并生成排序列表，接着获取报文的qos级别，根据所述报文的qos级别确定其所属的消息队列，进而对同一消息队列中的报文按时间顺序进行排序，并根据剩余空间对多组所述消息队列进行处理，本发明提高了数据处理的时效性。但是当消息队列过多会导致服务器出现背压现象。
4.中国发明专利cn202010115853.5，公开了一种消息处理方法，装置，计算机设备及存储介质，属于物联网技术领域。所述方法包括：接收消息生产者发送的第一消息；将第一消息存储至目标消息队列对应的消息文件中；获取目标消息队列对应的删除策略；根据所述删除策略，对目标消息队列对应的消息文件进行删除。本技术实施例提供的技术方案中，避免了因文件堆积而造成的文件占用空间太大的问题，节省消息中间件的存储空间，减少了消息中间件的处理开销，有效地避免了因清除缓存而造成的文件丢失，保证了消息消费者充分使用消息；删除策略可动态配置，提高了消息中间件进行文件删除时的灵活性和自由度。但是在增加处理节点时会影响整个运行状态。


技术实现要素：

5.本发明针对现有技术的不足，提供基于消息中间件背压的消息消费的方法和系统，该方法采用了动态创建队列并主动拉取消息的模式，既能保证当前场景要求，也能起到背压的处理方式，保证了应用容器运行的负载安全。
6.为了实现上述目的，本发明采用了以下技术方案：一种基于消息中间件背压的消息消费的系统，包括：注册中心、接入网关和消息处理节点。所述注册中心，用于负责监听消息处理节点运行状态，节点异常时负责故障转移工作触发。所述接入网关，用于通过网关接口发起队列创建工作与发起监听线程创建工作。所述消息处理节点，用于负责消息处理工作以及缓存处理。
7.一种基于消息中间件背压的消息消费的方法，使用上述系统，包括：（1）设备接入；（2）消息处理；（3）消息节点异常处理。
8.本发明的进一步说明，所述设备接入具体为：步骤11）设备接入到接入网关并判断连接情况；步骤12）接入网关根据缓存的节点接入设备数据负载，发出请求；步骤13）消息处理节点接收到接入网关的请求后，根据设备唯一标识动态创建队列；步骤14）将该队列接入消息处理节点内置的监听池；步骤15）将监听池中的节点信息缓存到分布式缓存中。
9.本发明的进一步说明，所述消息处理具体为：步骤21）消息处理节点启动时，根据配置文件配置的消费任务池大小创建一个任务处理线程池，并且会创建一个全局的监听池，而后启动消息拉取线程；步骤22）根据任务处理线程池是否有余量，启动消息拉取程序；步骤23）根据监听池中的队列数据，循环拉取池中队列的数据；步骤24）先根据当前循环到的队列，判断缓存中该队列的处理锁是否被锁定，如果被锁定则表名该消息正在被任务线程处理，不继续拉取队列数据，结束当前队列拉取流程重新回到步骤23）；若该队列未被锁，则执行步骤25）；步骤25）尝试拉取数据，如果能获取到数据，则执行步骤26）；若无法获取到数据，则重新回到步骤23），往下一个队列执行；步骤26）在缓存中锁上该队列，并获取一个任务线程处理消息；然后回到步骤22）继续判断是否有余量；步骤27）任务处理线程处理完消息之后，解锁该队列。
10.本发明的进一步说明，所述消息节点异常处理具体为：步骤31）注册中心探测到某消息节点异常离线，则主动向接入网关推送故障处理申请；步骤32）接入网关接受到请求后，通过缓存获取到异常节点分配的队列列表，然后删除该节点缓存中的关系，并开始执行故障转移工作；步骤33）重新调用无节点分配的队列监听创建接口，根据接入网关负载均衡策略重新下发到正常的消息处理节点中，重新在缓存中生成节点与队列的关系，完成监听迁移工作。
11.本发明的进一步说明，所述动态创建队列在必要时可以先删除队列再创建。
12.本发明具有以下有益效果：1、本发明内部实现了解决背压的机制，不会因为瞬时的指令爆发导致服务器崩溃。
13.2、本发明动态创建动态监听，不需要进行额外的配置工作。
14.3、本发明具备异常处理方案，节点异常时，服务会自动将监听节点的队列进行迁移，不需要人工触发。
附图说明
15.图1为接入流程图。
16.图2为消息处理流程图。
17.图3为异常处理流程图。
具体实施方式
18.下面结合附图对本发明作进一步说明。
19.实施例1：一种基于消息中间件背压的消息消费的系统，包括：注册中心、接入网关和消息处理节点；所述注册中心，用于负责监听消息处理节点运行状态，节点异常时负责故障转移工作触发；所述接入网关，用于通过网关接口发起队列创建工作与发起监听线程创建工作；所述消息处理节点，用于负责消息处理工作以及缓存处理。
20.实施例2：使用实施例1的所述系统，实现基于消息中间件背压的消息消费的方法，包括：（1）设备接入；具体工作流程如图1所示：步骤11）设备接入到接入网关并判断连接情况；步骤12）接入网关根据缓存的节点接入设备数据负载，发出请求；步骤13）消息处理节点接收到接入网关的请求后，根据设备唯一标识动态创建队列；步骤14）将该队列接入消息处理节点内置的监听池；步骤15）将监听池中的节点信息缓存到分布式缓存中。
21.（2）消息处理；具体工作流程如图2所示：步骤21）消息处理节点启动时，根据配置文件配置的消费任务池大小创建一个任务处理线程池，并且会创建一个全局的监听池，而后启动消息拉取线程；步骤22）根据任务处理线程池是否有余量，启动消息拉取程序；步骤23）根据监听池中的队列数据，循环拉取池中队列的数据；步骤24）先根据当前循环到的队列，判断缓存中该队列的处理锁是否被锁定，如果被锁定则表名该消息正在被任务线程处理，不继续拉取队列数据，结束当前队列拉取流程重新回到步骤23）；若该队列未被锁，则执行步骤25）；步骤25）尝试拉取数据，如果能获取到数据，则执行步骤26）；若无法获取到数据，则重新回到步骤23），往下一个队列执行；步骤26）在缓存中锁上该队列，并获取一个任务线程处理消息；然后回到步骤22）继续判断是否有余量；步骤27）任务处理线程处理完消息之后，解锁该队列。
22.（3）消息节点异常处理；具体工作流程如图3所示：步骤31）注册中心探测到某消息节点异常离线，则主动向接入网关推送故障处理
申请；步骤32）接入网关接受到请求后，通过缓存获取到异常节点分配的队列列表，然后删除该节点缓存中的关系，并开始执行故障转移工作；步骤33）重新调用无节点分配的队列监听创建接口，根据接入网关负载均衡策略重新下发到正常的消息处理节点中，重新在缓存中生成节点与队列的关系，完成监听迁移工作。
23.在上述实施例中，所述动态创建队列在必要时可以先删除队列再创建。
24.以上实施例仅为本发明的示例性实施例，不用于限制本发明，本发明的保护范围由权利要求书限定。本领域人员可以在本发明的实质和保护范围内，对本发明做出各种修改或等同替换，这种修改或等同替换也应视为落在本发明的保护范围内。