CN111786875A - 基于分布式架构的数据处理方法及装置 - Google Patents
基于分布式架构的数据处理方法及装置 Download PDFInfo
- Publication number
- CN111786875A CN111786875A CN202010525038.6A CN202010525038A CN111786875A CN 111786875 A CN111786875 A CN 111786875A CN 202010525038 A CN202010525038 A CN 202010525038A CN 111786875 A CN111786875 A CN 111786875A
- Authority
- CN
- China
- Prior art keywords
- message
- service
- processing result
- processing
- task pool
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本发明实施例提供一种基于分布式架构的数据处理方法及装置,所述方法包括:通过消息服务端接收消息生产端发送的第一消息并获取第一消息的类型,若第一消息为事件类,消息服务端在消息生产端成功完成第一消息的业务处理后,将第一消息发送至消息消费端,并在消息消费端完成第一消息的业务处理后,将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。本发明实施例通过建立独立的消息服务端来完成消息的数据处理服务,而不需要依赖每个业务服务系统分别构建自身的消息系统,从而降低了分布式架构中业务系统和消息系统之间的耦合性,同时根据消息的类型进行数据处理,保证了分布式架构中消息生产端和消息消费端数据的一致性。
Description
技术领域
本发明涉及互联网技术领域,尤其涉及一种基于分布式架构的数据处理方法及装置。
背景技术
在互联网环境下,应用系统总会面对数据量的增长而带来的系统压力,为了缓解系统的压力目前大多互联网企业普遍采用分布式系统架构。然而,分布式系统架构中每个服务之间都是独立的体系,他们彼此之间不在同一个数据库环境中,假如消息生产端服务执行成功了,消息消费端服务执行却失败了,而消息生产端的数据此时已经提交,导致消息生产端和消息消费端数据不同步的问题。
为解决分布式场景中业务服务之间的数据同步,现有技术中采用基于XA协议的全局事务或通过一致性消息的方式来达到服务之间的数据同步,但是基于XA协议的全局事务需要资源的全局锁定,在互联网应用中数据量并发量大的场景下会导致性能较差,并且各个业务服务都需要支持XA协议资源,代码耦合性高;而通过一致性消息的方式来达到服务之间的数据同步都是基于MQ中间件产品ActiveMQ、RabbitMQ、RocketMQ等相应的中间件产品来实现,需要通过网络进行通讯,这样就会引入了数据传输的不确定性,导致消息的发送和投递不可靠,从而无法实现消息发送的一致性。
因此,如何提出一种方法,能够保证分布式架构中消息生产端和消息消费端数据的一致性,同时降低分布式架构中业务系统和消息系统之间的耦合性,成为亟待解决的问题。
发明内容
针对现有技术中的缺陷,本发明实施例提供一种基于分布式架构的数据处理方法及装置。
第一方面,本发明实施例提供一种基于分布式架构的数据处理方法,用于各业务系统的消息服务,包括:
消息服务端接收分布式架构消息生产端发送的第一消息,并将所述第一消息存储至消息任务池;其中,所述第一消息中包含有第一消息的类型;
若所述第一消息的类型为事件类,消息服务端接收消息生产端发送的第一处理结果,并根据第一处理结果对第一消息进行数据处理,具体包括:
若所述第一处理结果为消息生产端成功完成第一消息的业务处理,则消息服务端将第一消息发送至消息消费端;消息消费端接收第一消息后,若成功完成第一消息的业务处理,则向消息服务端发送第二处理结果;消息服务端接收到第二处理结果后,将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。
优选地,还包括:若所述第一消息的类型为通知类,消息服务端将第一消息发送给消息消费端,并将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。
优选地,还包括:若所述第一处理结果为消息生产端放弃完成第一消息的业务处理,则消息服务端删除消息任务池中的第一消息。
优选地,所述消息服务端接收分布式架构消息生产端发送的第一消息,并将所述第一消息存储至消息任务池,具体包括:
消息服务端接收分布式架构消息生产端发送的第一消息,将第一消息状态设置为预发送,然后将第一消息存储至消息任务池。
优选地,所述若所述第一消息的类型为通知类,消息服务端将第一消息发送给消息消费端,并将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息,具体包括:
若所述第一消息的类型为通知类,消息服务端将消息任务池中的第一消息状态由预发送修改为未发送;
消息服务端将状态为未发送的第一消息发送给消息消费端,然后将消息任务池中的第一消息状态由未发送修改为已发送;
消息服务端将状态为已发送的第一消息迁移至历史日志库,以及删除消息任务池中状态为已发送的第一消息。
优选地,所述若所述第一处理结果为消息生产端成功完成第一消息的业务处理,则消息服务端将第一消息发送至消息消费端;消息消费端接收第一消息后,若成功完成第一消息的业务处理,则向消息服务端发送第二处理结果;消息服务端接收到第二处理结果后,将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息,具体包括:
若所述第一处理结果为消息生产端成功完成第一消息的业务处理,消息服务端将消息任务池中的第一消息状态由预发送修改为未发送,并将第一消息发送至消息消费端;
消息消费端接收第一消息后,若成功完成第一消息的业务处理,则向消息服务端发送第二处理结果;
消息服务端接收到第二处理结果后,将消息任务池中的第一消息状态由未发送修改为已发送,并将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。
优选地,还包括:若第一消息的创建时间超过第一阈值,且其状态为预发送,则消息服务端通过消息生产端接口获取第一处理结果;若消息服务端未获取到第一处理结果,则以第一时间间隔规则向消息生产端重发第一消息,若消息服务端仍未接收到第一处理结果,则将第一消息标记为已死亡。
优选地,还包括:若消息服务端在发送第一消息至消息消费端后,在第一预设时间段内没有接收到第二处理结果,则以第一时间间隔规则向消息消费端重复发送第一消息,若消息服务端仍未接收到第二处理结果,则将第一消息标记为已死亡。
第二方面,本发明实施例提供一种基于分布式架构的数据处理装置,用于各业务系统的消息服务,包括:
消息服务单元,用于消息服务端接收分布式架构消息生产端发送的第一消息,并将所述第一消息存储至消息任务池;
消息处理单元,用于若所述第一消息的类型为事件类,消息服务端接收消息生产端发送的第一处理结果,并根据第一处理结果对第一消息进行数据处理,具体包括:
若所述第一处理结果为消息生产端成功完成第一消息的业务处理,则消息服务端将第一消息发送至消息消费端;消息消费端接收第一消息后,若成功完成第一消息的业务处理,则向消息服务端发送第二处理结果;消息服务端接收到第二处理结果后,将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。
第三方面,本发明实施例提供一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现如上所述第一方面基于分布式架构的数据处理方法的各个步骤。
第四方面,本发明实施例提供一种非暂态计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现如上所述第一方面基于分布式架构的数据处理方法的各个步骤。
本发明实施例提供的基于分布式架构的数据处理方法及装置,通过消息服务端接收消息生产端发送的第一消息并获取第一消息的类型,若第一消息为事件类,则消息服务端在消息生产端成功完成第一消息的业务处理后,将第一消息发送至消息消费端,并在消息消费端完成第一消息的业务处理后,将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。本发明实施例通过建立独立的消息服务端来完成消息的数据处理服务,而不需要依赖每个业务服务系统分别构建自身的消息系统,从而降低了分布式架构中业务系统和消息系统之间的耦合性,同时根据消息的类型进行数据处理,保证了分布式架构中消息生产端和消息消费端数据的一致性。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例中基于分布式架构的数据处理方法的流程示意图;
图2为本发明实施例中基于分布式架构的数据处理装置的结构示意图;
图3为本发明实施例中电子设备的实体结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
图1为本发明实施例中基于分布式架构的数据处理方法的流程示意图,如图1所示,本发明实施例提供的一种基于分布式架构的数据处理方法,用于各业务系统的消息服务,包括:
步骤110、消息服务端接收分布式架构消息生产端发送的第一消息,并将所述第一消息存储至消息任务池;其中,所述第一消息中包含有第一消息的类型。
具体地,消息服务端为消息生产端和消息消费端提供相应的统一标准的功能接口,包括了消息创建、消息推送、消息配置、消息查询,消息人工补发,消息日志、消息监控等相关功能,本发明实施例采用的是互联网的微服务架构,所有模块的功能点都是统一调用消息服务端的接口来完成。
传统技术方案中各个业务服务都是按照自身的方式来管理和构建自身的消息服务系统,但当根据业务需求需要增加一种新的消息类型,各个服务系统都需要增加相应的对接方案,工作量高后期维护成本大,可扩展性和可维护性差,同时由于各业务服务之间与消息的通道都是各自对接,当消息通道发生改变时,所有与其连接的服务都需要改变,灵活性差;而且有新的服务系统接入时,消息功能可复用性低。
然而,本发明实施例中消息服务端完全独立存在运行,不需要侵入业务系统也不需要依赖业务系统,并且也不影响业务系统的功能及代码侵入,业务系统只需要关注业务本身,从而实现将消息功能跟业务功能进行解耦。
分布式架构中包含消息生产端和消息消费端,若要保证消息生产端的消息准确传递至消息消费端,本发明实施例通过消息服务端接收消息生产端发送的第一消息,并将所述第一消息存储至消息任务池,也就是第一消息生成后会进入消息任务池,同时系统会对任务池中的消息任务数据进行监控,监控消息的状态如已被消费或者未被消费等;其中,所述第一消息中包含有第一消息的类型,如第一消息的类型为事件类消息或者通知类消息。
步骤120、若所述第一消息的类型为事件类,消息服务端接收消息生产端发送的第一处理结果,并根据第一处理结果对第一消息进行数据处理,具体包括:
若所述第一处理结果为消息生产端成功完成第一消息的业务处理,则消息服务端将第一消息发送至消息消费端;消息消费端接收第一消息后,若成功完成第一消息的业务处理,则向消息服务端发送第二处理结果;消息服务端接收到第二处理结果后,将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。
具体地,本发明实施例将第一消息的类型分为两类,通知类消息和事件类消息。通知类消息是满足日常业务对接的第三方如短信,邮件,微信,app推送等等;事件类消息是为了解决平台内部各个服务之间的数据同步,即确保消息生产端和消息消费端两端之间的数据同步和一致性。
若第一消息的类型为事件类,消息服务端需要接收消息生产端发送的第一处理结果,用来判断是否对第一消息进行业务处理。若消息生产端确认对对第一消息执行业务处理,则消息生产端会向消息服务端发送第一处理结果如“成功”。
消息服务端在接收到“成功”的第一处理结果后,会向消息消费端发送第一消息,用来告知消息消费端需要对第一消息进行业务处理,若消息消费端成功完成第一消息的业务处理,则会向消息服务端发送第二处理结果,用来告知消息服务端其已完成第一消息的业务处理。
消息服务端接收到第二处理结果后,确认消息消费端已成功完成数据处理,则将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。
传统技术方案中,在分布式部署的环境下,主动方应用,消息中间件,被动方应用都在各自不同的物理环境下,需要通过网络进行通讯,这样就会引入了数据传输的不确定性,导致消息的发送和投递不可靠。在以上流程中每个环节中都有可能存在网络故障,发生了故障以后就会导致主动方应用和被动方应用之间数据不同步。所以要保证主动方应用和被动方应用之间的数据同步,前提是要保证两边的消息一致性。本发明实施例中通过消息服务端来确认消息生产端发送的第一消息是否100%投递到消息消费端,并且确认第一消息是否被消息消费端成功执行业务处理,保证了消息生产端和消息消费端两端之间的数据同步和一致性。
本发明实施例提供的基于分布式架构的数据处理方法,通过消息服务端接收消息生产端发送的第一消息并获取第一消息的类型,若第一消息为事件类,则消息服务端在消息生产端成功完成第一消息的业务处理后,将第一消息发送至消息消费端,并在消息消费端完成第一消息的业务处理后,将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。本发明实施例通过建立独立的消息服务端来完成消息的数据处理服务,而不需要依赖每个业务服务系统分别构建自身的消息系统,从而降低了分布式架构中业务系统和消息系统之间的耦合性,同时根据消息的类型进行数据处理,保证了分布式架构中消息生产端和消息消费端数据的一致性。
基于上述实施例的内容,作为一种可选实施例,所述方法还包括:若所述第一消息的类型为通知类,消息服务端将第一消息发送给消息消费端,并将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。
具体地,通知类消息是满足日常业务对接的第三方如短信,邮件,微信,app推送等等,这类消息仅仅只是对客户做通知提醒,没有数据一致性的要求,因此该消息只要发出后就可认为此消息已经消费成功。所以当消息服务端将通知类的第一消息推送给消息消费端后,此类消息的周期就已经结束,第一消息的数据从消息任务池迁移到历史日志库中,并且删除消息任务池中的第一消息。本发明实施例根据通知类消息的实际需求,当消息服务端将通知类的第一消息推送给消息消费端后,认为此类消息的周期就已经结束,而不需要像事件类消息一样需要确认是否对其进行业务处理,简化了消息处理流程,节约了资源。
本发明实施例提供的基于分布式架构的数据处理方法,通过判断第一消息的类型为通知类时,消息服务端将第一消息发送给消息消费端,并将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息,从而能够根据消息的类型需求对数据进行处理,不仅实现了消息被成功消费,而且简化了消息处理流程,节约了资源。
基于上述实施例的内容,作为一种可选实施例,所述方法还包括:若所述第一处理结果为消息生产端放弃完成第一消息的业务处理,则消息服务端删除消息任务池中的第一消息。
具体地,若第一消息的类型为事件类,消息服务端需要接收消息生产端发送的第一处理结果,用来判断是否对第一消息进行业务处理。若消息生产端放弃对第一消息执行业务处理,则消息生产端会向消息服务端发送第一处理结果如“失败”,那么所述第一消息的任务流程结束。
本发明实施例提供的基于分布式架构的数据处理方法,通过判断第一处理结果为消息生产端放弃完成第一消息的业务处理,则消息服务端删除消息任务池中的第一消息,从而能够根据消息生产端的确认结果对第一消息进行业务处理,实现数据处理满足消息生产端的实际需求,使得数据处理更灵活。
基于上述实施例的内容,作为一种可选实施例,所述消息服务端接收分布式架构消息生产端发送的第一消息,并将所述第一消息存储至消息任务池,具体包括:
消息服务端接收分布式架构消息生产端发送的第一消息,将第一消息状态设置为预发送,然后将第一消息存储至消息任务池。
具体地,通过消息服务端接收消息生产端发送的第一消息,将第一消息状态设置为预发送,然后将所述第一消息存储至消息任务池,消息服务端会对消息任务池中“预发送”状态的数据进行监控。
本发明实施例提供的基于分布式架构的数据处理方法,通过将消息任务池中的第一消息状态设置为预发送,使得消息状态得到直观展现,便于对消息进行管理和监控。
基于上述实施例的内容,作为一种可选实施例,所述若所述第一消息的类型为通知类,消息服务端将第一消息发送给消息消费端,并将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息,具体包括:
若所述第一消息的类型为通知类,消息服务端将消息任务池中的第一消息状态由预发送修改为未发送;
消息服务端将状态为未发送的第一消息发送给消息消费端,然后将消息任务池中的第一消息状态由未发送修改为已发送;
消息服务端将状态为已发送的第一消息迁移至历史日志库,以及删除消息任务池中状态为已发送的第一消息。
具体地,若第一消息的类型为通知类,则只需将第一消息发送至消息消费端,就可认为第一消息已被成功消费,即第一消息的流程结束。因此,若第一消息的类型为通知类,消息服务端将消息任务池中的第一消息状态由预发送修改为未发送,消息服务端同样也会对消息任务池中“未发送”状态的数据进行监控。
消息服务端会将监控状态为“未发送”的第一消息发送给消息消费端,然后将消息任务池中发送给消息消费端的第一消息状态由“未发送”修改为“已发送”。
对于状态为“已发送”的消息,消息服务端认为该消息已被成功消费,则消息服务端会将状态为“已发送”的第一消息迁移至历史日志库,以及删除消息任务池中状态为已发送的第一消息,结束消息任务流程。
本发明实施例提供的基于分布式架构的数据处理方法,消息服务端将通知类的第一消息发送给消息消费端,并将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息,从而能够根据消息的类型需求对数据进行处理,不仅实现了消息被成功消费,而且简化了消息处理流程,节约了资源。
基于上述实施例的内容,作为一种可选实施例,所述若所述第一处理结果为消息生产端成功完成第一消息的业务处理,则消息服务端将第一消息发送至消息消费端;消息消费端接收第一消息后,若成功完成第一消息的业务处理,则向消息服务端发送第二处理结果;消息服务端接收到第二处理结果后,将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息,具体包括:
若所述第一处理结果为消息生产端成功完成第一消息的业务处理,消息服务端将消息任务池中的第一消息状态由预发送修改为未发送,并将第一消息发送至消息消费端;
消息消费端接收第一消息后,若成功完成第一消息的业务处理,则向消息服务端发送第二处理结果;
消息服务端接收到第二处理结果后,将消息任务池中的第一消息状态由未发送修改为已发送,并将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。
具体地,若第一消息的类型为事件类,消息服务端需要接收消息生产端发送的第一处理结果,用来判断是否对第一消息进行业务处理。若消息生产端确认对对第一消息执行业务处理,则消息生产端会向消息服务端发送第一处理结果如“成功”,并将第一消息状态由“预发送”修改为“未发送”。
消息服务端监控消息任务池中状态为“未发送”的第一消息,并将“未发送”的第一消息发送给消息消费端,用来告知消息消费端需要对第一消息进行业务处理。
若消息消费端成功完成第一消息的业务处理,则会向消息服务端发送第二处理结果,用来告知消息服务端其已完成第一消息的业务处理。
消息服务端接收到第二处理结果后,确认消息消费端已成功完成数据处理,会将消息任务池中的第一消息状态由“未发送”修改为“已发送”,状态为“已发送”的第一消息表示该消息已被成功消费,流程结束,则消息服务端将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。
本发明实施例提供的基于分布式架构的数据处理方法,通过消息服务端来确认消息生产端发送的第一消息是否100%投递到消息消费端,并且确认第一消息是否被消息消费端成功执行业务处理,保证了消息生产端和消息消费端两端之间的数据同步和一致性。
基于上述实施例的内容,作为一种可选实施例,所述方法还包括:若第一消息的创建时间超过第一阈值,且其状态为预发送,则消息服务端通过消息生产端接口获取第一处理结果;若消息服务端未获取到第一处理结果,则以第一时间间隔规则向消息生产端重发第一消息,若消息服务端仍未接收到第一处理结果,则将第一消息标记为已死亡。
具体地,当消息生产端已完成是否对第一消息进行业务处理的确认,但是消息服务端没有收到消息生产端发送的确认结果即第一处理结果,此时消息任务池中第一消息会一直处于“预发送”状态,如果此消息没有正常处理的话,会导致生产者和消费者之间的数据不一致。
因此,本发明实施例通过监控消息任务池中的“预发送”任务,会每隔一段时间如60秒扫描一次消息任务池,将消息任务池中的创建时间超过第一阈值如180秒的第一消息,状态为“预发送”且未死亡,并以创建时间顺序的方式取出一定数量的消息数据如前6000条。通过消息关联配置获取消息生产端确认接口,然后通过消息ID请求相应的接口确认消息是否发送。如果成功则修改消息状态为“未发送”,如果失败则记录重发次数,当重发次数超过第一时间间隔如同一个消息多次发送的时间间隔分为5段,第一段间隔为0秒,第二段为60秒,第三段为120秒,第四段为300秒,第五段为900秒。当消息经过这5段的时间总共为23分钟,消息任务都没有成功被消费,那么就认为消息生产端存在业务数据或者是服务器等一系列问题,则停止继续在对此任务做无效请求,修改消息为已死亡,需要相关人员解决问题后,再进入管理消息任务池监控页面中,进行手工补发次条消息。可以理解的是,相关人员可以通过消息监控web页面查看死亡消息并做相应的处理。
需要说明的是,消息服务端向消息生产端重发第一消息时,首先判断消息重发次数,如果重发次数大于上限如5次,则直接标记此消息任务为已死亡;再次判断是否达到发送消息的第一时间间隔规则,如果已达到则将消息进行补发,如果未达到则继续扫描下一条消息。
当消息服务端无法接收消息生产端发送的第一消息流程,或者消息服务端接收第一消息后,无法向消息生产端确认是否对其进行业务处理时,则认为消息生产端调用消息服务端接口失败,则业务放弃流程直接终止。本发明实施例采用微服务架构,可以横向扩展多台集群来确保服务单元的可靠性。
本发明实施例提供的基于分布式架构的数据处理方法,通过对超过第一阈值创建时间的第一消息,按照第一时间间隔规则进行重发,可以防止由于故障导致消息生产端已经确认业务处理时而消息消费端没有执行任务的情况,从而可以保证消息生产端和消息消费端之间数据的一致性。
基于上述实施例的内容,作为一种可选实施例,所述方法还包括:若消息服务端在发送第一消息至消息消费端后,在第一预设时间段内没有接收到第二处理结果,则以第一时间间隔规则向消息消费端重复发送第一消息,若消息服务端仍未接收到第二处理结果,则将第一消息标记为已死亡。
具体地,当消息服务端在发送第一消息至消息消费端后,在第一预设时间段内没有接收到第二处理结果,则可能认为存在两个方面的故障,第一方面是消息消费端没有收到第一消息,第二方面是消息消费端收到第一消息并成功完成业务处理,但在返回确认消息即第二处理结果的时候异常,导致第一消息任务还处于“未发送”状态;
如果是第一方面问题,消息服务端会根据第一时间间隔规则在后续不同的时间段再向消息消费端进行发送如发送5次,如果发完5次后消息还没有被成功消费,就认为消息消费端存在故障或流程逻辑问题,为了防止过多无效请求浪费服务器资源,会将此消息标记为“已死亡”,可以在web页面的任务池监控数据列表中看到已死亡数据,并通知相关人员排查问题修复好消费者后在手动补发此消息。
如果是第二方面问题,消息消费端在业务逻辑上需要做重复请求处理,如果消息消费端做了此处理后,后续的重复消息推送其实是无效的,当消息服务端“未发送”消息重新发送超过如5次后,会标记为已死亡,后续不会重复推送无效消息数据。
本发明实施例整个过程不需要人工干预,自动完成。当消息因某种因素没有投递成功时,本发明实施例会依据一定的逻辑进行自动补偿,也提供了相应的后台页面进行人工补发。
本发明实施例提供的基于分布式架构的数据处理方法,通过判断消息服务端在第一预设时间段内没有接收到第二处理结果,则以第一时间间隔规则向消息消费端重复发送第一消息,从而可以避免重复推送无效消息数据,节约了服务器资源。
图2为本发明实施例中基于分布式架构的数据处理装置的结构示意图,如图2所示,本发明实施例提供的一种基于分布式架构的数据处理装置,用于各业务系统的消息服务,包括:
消息服务单元210,用于消息服务端接收分布式架构消息生产端发送的第一消息,并将所述第一消息存储至消息任务池。
具体地,消息服务端为消息生产端和消息消费端提供相应的统一标准的功能接口,包括了消息创建、消息推送、消息配置、消息查询,消息人工补发,消息日志、消息监控等相关功能,本发明实施例采用的是互联网的微服务架构,所有模块的功能点都是统一调用消息服务端的接口来完成。
分布式架构中包含消息生产端和消息消费端,若要保证消息生产端的消息准确传递至消息消费端,消息服务单元210通过消息服务端接收消息生产端发送的第一消息,并将所述第一消息存储至消息任务池,也就是第一消息生成后会进入消息任务池,同时系统会对任务池中的消息任务数据进行监控,监控消息的状态如已被消费或者未被消费等;其中,所述第一消息中包含有第一消息的类型,如第一消息的类型为事件类消息或者通知类消息。
消息处理单元220,用于若所述第一消息的类型为事件类,消息服务端接收消息生产端发送的第一处理结果,并根据第一处理结果对第一消息进行数据处理,具体包括:
若所述第一处理结果为消息生产端成功完成第一消息的业务处理,则消息服务端将第一消息发送至消息消费端;消息消费端接收第一消息后,若成功完成第一消息的业务处理,则向消息服务端发送第二处理结果;消息服务端接收到第二处理结果后,将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。
具体地,本发明实施例将第一消息的类型分为两类,通知类消息和事件类消息。通知类消息是满足日常业务对接的第三方如短信,邮件,微信,app推送等等;事件类消息是为了解决平台内部各个服务之间的数据同步,即确保消息生产端和消息消费端两端之间的数据同步和一致性。
消息处理单元220若判断第一消息的类型为事件类,消息服务端需要接收消息生产端发送的第一处理结果,用来判断是否对第一消息进行业务处理。若消息生产端确认对对第一消息执行业务处理,则消息生产端会向消息服务端发送第一处理结果如“成功”。
消息服务端在接收到“成功”的第一处理结果后,会向消息消费端发送第一消息,用来告知消息消费端需要对第一消息进行业务处理,若消息消费端成功完成第一消息的业务处理,则会向消息服务端发送第二处理结果,用来告知消息服务端其已完成第一消息的业务处理。
消息服务端接收到第二处理结果后,确认消息消费端已成功完成数据处理,则将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。
需要说明的是,本发明实施例中消息服务端包括消息创建、消息推送、消息配置、消息查询、消息人工补发、消息日志、消息监控等相关功能,可以通过在消息服务端下创建多个子单元来执行上述功能,如消息管理单元,消息监控单元,以及消息调度单元,具体为:
(1)消息管理单元:包含消息任务池监控,消息任务日志,消息模板配置,消息关联配置。管理单元的整个过程全部为web页面化配置,不需要人为修改代码,修改后配置实时生效。
其中,消息任务池监控用于当消息任务被成功消费后离开任务池进入历史日志。当消息没有被成功消费并且该条消息处理已经达到上限,则消息状态会被标记为已死亡,管理员在任务池中看到已死亡消息后,可以手工补发并或找相应的业务人员处理。并且死亡的消息会根据配置通过短信或邮件通知相应的开发或管理人员。
消息任务日志跟消息任务池监控页面一致,主要是作为消息历史日志的保存,方便开发人员和管理人员排查问题。消息成功被消费后会从消息任务池区域迁移到消息历史日志区域。相关人员可以查看消息详情和人工重新补发消息。
消息模板配置:消息类型主要分为两类,通知类和事件类。;通知类消息主要是业务应用给目标客户发送相应的业务信息,如短信,邮件,微信,语音,app推送等,这些不需要强保证两端的一致性和同步。所有接入端的消息模板配置都可以通过此模块来完成。
消息关联配置主要配置消息的生产者和消费者之间的关联关系,目的是让调度单元中的消息处理线程感知消息推送的目标接口,以及监控单元中预发送任务线程感知消息确认的接口。此功能模块通过key值的方式,关联双方接口的调用关系和mq消息队列的对应关系。
(2)消息监控单元
消息监控单元在启动时会开启两个线程,一个线程监控消息任务池中的“未发送”状态的任务,一个线程监控消息任务池中的“预发送”任务。
预发送任务线程:线程会每隔60秒的时间扫描一下任务池,将池中的创建时间超过180秒,未死亡,状态为“预发送”的任务数据以创建时间顺序的方式取出前6000条。通过消息关联配置获取生产者消息确认接口,然后通过消息id请求相应的接口确认消息是否发送。如果成功则修改状态为未发送,如果失败则记录重发次数,当重发次数超过5次后,则修改消息为已死亡,相应的人员可以通过消息监控web页面查看死亡消息并做相应的处理。
未发送任务线程:线程会每隔60秒的时间扫描一下任务池,将池中的创建时间超过180秒,未死亡,状态为“未发送”的任务数据以创建时间顺序的方式取出前6000条。
(3)消息调度单元
消息调度单元主要分为消息接收线程,消息队列MQ,消息处理线程。
消息接收线程会从消息监控单元中接收状态为“未发送”的消息数据,通过消息中的消息模板id从消息模板配置中获取此消息的模板,然后通过模板及消息中的业务参数组装成消费者需要的请求数据(格式为json),然后将组装好的数据发送到相应的mq中的队列中。
消息队列MQ采用的是开源产品rabbitmq做为为任务通信的数据结构。
消息处理线程中的监听线程会去监听到相应队列中的数据,将数据取出后,通过队列routekey在消息关联配置中找出目标消费者接口,然后将组装好的数据推送到此接口。当消费者成功处理完消息后,消息处理线程就会将任务池中的此消息状态修改为已发送,并将此消息数据从任务池中删除,并存入消息历史日志库。
本发明实施例提供的基于分布式架构的数据处理装置用于执行上述基于分布式架构的数据处理方法,其具体的实施方式与方法实施方式一致,此处不再赘述。
本发明实施例提供的基于分布式架构的数据处理装置,通过消息服务端接收消息生产端发送的第一消息并获取第一消息的类型,若第一消息为事件类,则消息服务端在消息生产端成功完成第一消息的业务处理后,将第一消息发送至消息消费端,并在消息消费端完成第一消息的业务处理后,将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。本发明实施例通过建立独立的消息服务端来完成消息的数据处理服务,而不需要依赖每个业务服务系统分别构建自身的消息系统,从而降低了分布式架构中业务系统和消息系统之间的耦合性,同时根据消息的类型进行数据处理,保证了分布式架构中消息生产端和消息消费端数据的一致性。
图3为本发明实施例中电子设备的实体结构示意图,如图3所示,该电子设备可以包括:处理器(processor)310、通信接口(Communications Interface)320、存储器(memory)330和通信总线340,其中,处理器310,通信接口320,存储器330通过通信总线340完成相互间的通信。处理器310可以调用存储器330中的逻辑指令,以执行如上所述基于分布式架构的数据处理方法的各个步骤。
此外,上述的存储器330中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
另一方面,本发明实施例还提供一种非暂态计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现以执行上述各实施例提供的基于分布式架构的数据处理方法。
以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下,即可以理解并实施。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件。基于这样的理解,上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (10)
1.一种基于分布式架构的数据处理方法,其特征在于,用于各业务系统的消息服务,包括:
消息服务端接收分布式架构消息生产端发送的第一消息,并将所述第一消息存储至消息任务池;其中,所述第一消息中包含有第一消息的类型;
若所述第一消息的类型为事件类,消息服务端接收消息生产端发送的第一处理结果,并根据第一处理结果对第一消息进行数据处理,具体包括:
若所述第一处理结果为消息生产端成功完成第一消息的业务处理,则消息服务端将第一消息发送至消息消费端;消息消费端接收第一消息后,若成功完成第一消息的业务处理,则向消息服务端发送第二处理结果;消息服务端接收到第二处理结果后,将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。
2.根据权利要求1所述的基于分布式架构的数据处理方法,其特征在于,还包括:
若所述第一消息的类型为通知类,消息服务端将第一消息发送给消息消费端,并将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。
3.根据权利要求1所述的基于分布式架构的数据处理方法,其特征在于,还包括:
若所述第一处理结果为消息生产端放弃完成第一消息的业务处理,则消息服务端删除消息任务池中的第一消息。
4.根据权利要求1所述的基于分布式架构的数据处理方法,其特征在于,所述消息服务端接收分布式架构消息生产端发送的第一消息,并将所述第一消息存储至消息任务池,具体包括:
消息服务端接收分布式架构消息生产端发送的第一消息,将第一消息状态设置为预发送,然后将第一消息存储至消息任务池。
5.根据权利要求4所述的基于分布式架构的数据处理方法,其特征在于,所述若所述第一消息的类型为通知类,消息服务端将第一消息发送给消息消费端,并将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息,具体包括:
若所述第一消息的类型为通知类,消息服务端将消息任务池中的第一消息状态由预发送修改为未发送;
消息服务端将状态为未发送的第一消息发送给消息消费端,然后将消息任务池中的第一消息状态由未发送修改为已发送;
消息服务端将状态为已发送的第一消息迁移至历史日志库,以及删除消息任务池中状态为已发送的第一消息。
6.根据权利要求4所述的基于分布式架构的数据处理方法,其特征在于,所述若所述第一处理结果为消息生产端成功完成第一消息的业务处理,则消息服务端将第一消息发送至消息消费端;消息消费端接收第一消息后,若成功完成第一消息的业务处理,则向消息服务端发送第二处理结果;消息服务端接收到第二处理结果后,将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息,具体包括:
若所述第一处理结果为消息生产端成功完成第一消息的业务处理,消息服务端将消息任务池中的第一消息状态由预发送修改为未发送,并将第一消息发送至消息消费端;
消息消费端接收第一消息后,若成功完成第一消息的业务处理,则向消息服务端发送第二处理结果;
消息服务端接收到第二处理结果后,将消息任务池中的第一消息状态由未发送修改为已发送,并将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。
7.根据权利要求5所述的基于分布式架构的数据处理方法,其特征在于,还包括:
若第一消息的创建时间超过第一阈值,且其状态为预发送,则消息服务端通过消息生产端接口获取第一处理结果;若消息服务端未获取到第一处理结果,则以第一时间间隔规则向消息生产端重发第一消息,若消息服务端仍未接收到第一处理结果,则将第一消息标记为已死亡。
8.根据权利要求5所述的基于分布式架构的数据处理方法,其特征在于,还包括:
若消息服务端在发送第一消息至消息消费端后,在第一预设时间段内没有接收到第二处理结果,则以第一时间间隔规则向消息消费端重复发送第一消息,若消息服务端仍未接收到第二处理结果,则将第一消息标记为已死亡。
9.一种基于分布式架构的数据处理装置,其特征在于,用于各业务系统的消息服务,包括:
消息服务单元,用于消息服务端接收分布式架构消息生产端发送的第一消息,并将所述第一消息存储至消息任务池;
消息处理单元,用于若所述第一消息的类型为事件类,消息服务端接收消息生产端发送的第一处理结果,并根据第一处理结果对第一消息进行数据处理,具体包括:
若所述第一处理结果为消息生产端成功完成第一消息的业务处理,则消息服务端将第一消息发送至消息消费端;消息消费端接收第一消息后,若成功完成第一消息的业务处理,则向消息服务端发送第二处理结果;消息服务端接收到第二处理结果后,将第一消息迁移至历史日志库,以及删除消息任务池中的第一消息。
10.一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其特征在于,所述处理器执行所述程序时实现如权利要求1至8任一项所述基于分布式架构的数据处理方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010525038.6A CN111786875A (zh) | 2020-06-10 | 2020-06-10 | 基于分布式架构的数据处理方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010525038.6A CN111786875A (zh) | 2020-06-10 | 2020-06-10 | 基于分布式架构的数据处理方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN111786875A true CN111786875A (zh) | 2020-10-16 |
Family
ID=72755903
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010525038.6A Pending CN111786875A (zh) | 2020-06-10 | 2020-06-10 | 基于分布式架构的数据处理方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111786875A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114268622A (zh) * | 2021-12-23 | 2022-04-01 | 广东南方新媒体科技有限公司 | 分布式场景下的低延迟高并发多平台稿件发布方法 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130036427A1 (en) * | 2011-08-03 | 2013-02-07 | International Business Machines Corporation | Message queuing with flexible consistency options |
CN106383737A (zh) * | 2016-09-09 | 2017-02-08 | 浪潮软件股份有限公司 | 一种分布式事务处理方法 |
CN106777026A (zh) * | 2016-12-08 | 2017-05-31 | 用友网络科技股份有限公司 | 支持微服务架构事务最终一致性的方法、装置及系统 |
CN107332906A (zh) * | 2017-06-30 | 2017-11-07 | 郑州云海信息技术有限公司 | 分布式系统事务管理方法及装置 |
CN108009252A (zh) * | 2017-12-04 | 2018-05-08 | 传神语联网网络科技股份有限公司 | 数据同步的方法及装置 |
CN108153598A (zh) * | 2017-12-25 | 2018-06-12 | 东软集团股份有限公司 | 基于微服务架构的数据一致性方法以及装置 |
-
2020
- 2020-06-10 CN CN202010525038.6A patent/CN111786875A/zh active Pending
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130036427A1 (en) * | 2011-08-03 | 2013-02-07 | International Business Machines Corporation | Message queuing with flexible consistency options |
CN106383737A (zh) * | 2016-09-09 | 2017-02-08 | 浪潮软件股份有限公司 | 一种分布式事务处理方法 |
CN106777026A (zh) * | 2016-12-08 | 2017-05-31 | 用友网络科技股份有限公司 | 支持微服务架构事务最终一致性的方法、装置及系统 |
CN107332906A (zh) * | 2017-06-30 | 2017-11-07 | 郑州云海信息技术有限公司 | 分布式系统事务管理方法及装置 |
CN108009252A (zh) * | 2017-12-04 | 2018-05-08 | 传神语联网网络科技股份有限公司 | 数据同步的方法及装置 |
CN108153598A (zh) * | 2017-12-25 | 2018-06-12 | 东软集团股份有限公司 | 基于微服务架构的数据一致性方法以及装置 |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114268622A (zh) * | 2021-12-23 | 2022-04-01 | 广东南方新媒体科技有限公司 | 分布式场景下的低延迟高并发多平台稿件发布方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109542639B (zh) | 一种保障微服务调用数据一致性的处理方法、处理装置 | |
US7886295B2 (en) | Connection manager, method, system and program product for centrally managing computer applications | |
US6345281B1 (en) | Recovery method and system for a resource management system | |
CN103067230A (zh) | 一种通过植入监控代码实现对http服务监控的方法 | |
CN107277083B (zh) | 一种数据交互的处理方法、装置及系统 | |
CN111526049B (zh) | 运维系统、运维方法、电子设备和存储介质 | |
CN116319732A (zh) | 一种基于RabbitMQ的消息队列集中配置管理系统及方法 | |
CN111953784A (zh) | 基于异步通信框架的文件传输方法、装置及系统 | |
CN111786875A (zh) | 基于分布式架构的数据处理方法及装置 | |
CN114003656A (zh) | 一种不同业务系统之间数据同步的方法及系统 | |
CN100359865C (zh) | 一种检测方法 | |
CN116662035A (zh) | 消息队列事务消息的处理方法和装置 | |
CN117640659A (zh) | 统一消息数据处理方法、装置及存储介质 | |
CN113472810B (zh) | 一种基于tcp/ip协议socket通信的方法及系统 | |
CN114238828A (zh) | 一种数据推送服务平台和方法 | |
CN113259404B (zh) | 基于tcp/ip协议的工业通信中间件及其使用方法 | |
CN111866118A (zh) | 一种工作平台文件存储传输方法及系统 | |
CN111552907A (zh) | 消息处理方法、装置、设备和存储介质 | |
CN113157461A (zh) | 一种在执行任务单过程中传送消息的方法和装置 | |
WO2020123261A1 (en) | Collecting repeated diagnostics data from across users participating in a document collaboration session | |
CN114466071B (zh) | 一种基于MQ PaaS的事务消息处理方法及装置 | |
CN114007111B (zh) | 资源分发方法、装置、电子设备及存储介质 | |
CN114172877B (zh) | 一种基于http协议的中间件数据传输方法、装置、设备及存储介质 | |
US20230004427A1 (en) | Re-initiation of microservices utilizing context information provided via service calls | |
CN113037839B (zh) | 一种分布式批量框架通讯系统及方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20201016 |