CN114979039A - 一种数据处理方法及装置 - Google Patents

一种数据处理方法及装置 Download PDF

Info

Publication number
CN114979039A
CN114979039A CN202210705783.8A CN202210705783A CN114979039A CN 114979039 A CN114979039 A CN 114979039A CN 202210705783 A CN202210705783 A CN 202210705783A CN 114979039 A CN114979039 A CN 114979039A
Authority
CN
China
Prior art keywords
data
pushing
pushed
push
queue
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
Application number
CN202210705783.8A
Other languages
English (en)
Inventor
李闯
孙华忠
杨杰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
State Grid E Commerce Technology Co Ltd
Original Assignee
State Grid E Commerce Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by State Grid E Commerce Technology Co Ltd filed Critical State Grid E Commerce Technology Co Ltd
Priority to CN202210705783.8A priority Critical patent/CN114979039A/zh
Publication of CN114979039A publication Critical patent/CN114979039A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/55—Prevention, detection or correction of errors
    • H04L49/552—Prevention, detection or correction of errors by ensuring the integrity of packets received through redundant connections
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1443—Transmit or communication errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24552—Database cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/35—Switches specially adapted for specific applications
    • H04L49/355—Application aware switches, e.g. for HTTP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9057—Arrangements for supporting packet reassembly or resequencing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/80—Database-specific techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/548—Queue

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Computational Linguistics (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明实施例公开了一种数据处理方法及装置，接收业务请求参数；根据业务请求参数组装得到推送数据；判断数据补偿表中是否存在与推送数据的主键相同的未处理完成的补偿数据；若存在补偿数据，则将推送数据保存到数据补偿表中；当死信队列中的补偿数据处理完成后，将推送数据推送到所述死信队列中；当推送数据进入死信队列的时长达到第一间隔时间时，将推送数据转到延迟队列；当监听到推送数据进入延迟队列时，将推送数据推送到交互系统。本发明实施例中推送数据是在补偿数据处理完成之后再推送给业务系统的，如此主键相同的数据是串行处理的，处理完一条数据再处理下一条数据，保证了数据有序抵达交互系统，从而保证了数据的完整性和可控性。

Description

一种数据处理方法及装置
技术领域
本发明涉及数据处理领域，更具体的说，涉及一种数据处理方法及装置。
背景技术
随着互联网的快速发展，多个业务系统之间的交互越来越多，经常会涉及到业务系统间的数据推送，大量敏感信息需要在多个业务系统间保持同步。
目前，是将数据直接推送给交互系统，若推送成功则数据会保存到交互系统中，若推送失败则数据不会保存到交互系统中。如此，当交互过程中因为网络延迟、重复点击、服务器不稳定等因素，而导致数据无法成功推送到业务系统中时，会存在大量敏感信息在多个业务系统间无法保持同步，从而会出现数据混乱的情况。
发明内容
有鉴于此，本发明实施例公开一种数据处理方法及装置，保证推送数据有序抵达交互系统，从而保证数据的完整性和可控性。
本发明实施例提供的技术方案如下：
本发明实施例第一方面提供了一种数据处理方法，其特征在于，所述方法包括：
接收业务请求参数；
根据所述业务请求参数组装得到推送数据；
判断数据补偿表中是否存在与所述推送数据的主键相同的未处理完成的补偿数据；
若存在所述补偿数据，则将所述推送数据保存到数据补偿表中；
当死信队列中的所述补偿数据处理完成后，将所述推送数据推送到所述死信队列中；
当所述推送数据进入所述死信队列的时长达到第一间隔时间时，将所述推送数据转到延迟队列；
当监听到所述推送数据进入所述延迟队列时，将所述推送数据推送到交互系统。
在一种可能的实现方式中，所述方法还包括：
判断所述推送数据是否成功推送到所述交互系统中；
若所述推送数据未成功推送到所述交互系统中，则更新所述数据补偿表中所述推送数据的推送次数；
判断更新后的推送次数是否达到最大推送次数；
若所述更新后的推送次数未达到最大推送次数，则将所述推送数据推送到所述死信队列中，当所述推送数据进入所述死信队列的时长达到第二间隔时间时，将所述推送数据转到所述延迟队列，当监听到所述推送数据进入所述延迟队列时，将所述推送数据推送到所述交互系统；
若所述更新后的推送次数达到最大推送次数，则更新所述数据补偿表中所述推送数据的推送状态为推送失败。
在一种可能的实现方式中，所述第二间隔时间大于所述第一间隔时间。
在一种可能的实现方式中，所述方法还包括：
判断所述推送数据是否成功推送到所述交互系统中；
若所述推送数据成功推送到所述交互系统中，则删除所述数据补偿表中的所述推送数据。
在一种可能的实现方式中，所述当监听到所述推送数据进入所述延迟队列时，将所述推送数据推送到交互系统包括：
当监听到所述推送数据进入所述延迟队列时，向所述业务交互系统发送超文本传输协议http请求；
判断所述http请求是否发送成功；
若所述http请求发送成功，则将所述推送数据推送到所述交互系统；
若所述http请求发送失败，则返回执行如下步骤：将所述推送数据推送到所述死信队列中。
在一种可能的实现方式中，所述主键包括如下至少一种：租户、业务类型、业务数据。
本发明实施例第二方面提供了一种数据处理装置，其特征在于，所述装置包括：
接收单元，用于接收业务请求参数；
参数组装单元，用于根据所述业务请求参数组装得到推送数据；
第一判断单元，用于判断数据补偿表中是否存在与所述推送数据的主键相同的未处理完成的补偿数据；
数据保存单元，用于若存在所述补偿数据，则将所述推送数据保存到数据补偿表中；
第一推送单元，用于当死信队列中的所述补偿数据处理完成后，将所述推送数据推送到所述死信队列中；
数据转移单元，用于当所述推送数据进入所述死信队列的时长达到第一间隔时间时，将所述推送数据转到延迟队列；
第二推送单元，用于当监听到所述推送数据进入所述延迟队列时，将所述推送数据推送到交互系统。
在一种可能的实现方式中，所述装置还包括：
第二判断单元，用于判断所述推送数据是否成功推送到所述交互系统中；
第一更新单元，用于若所述推送数据未成功推送到所述交互系统中，则更新所述数据补偿表中所述推送数据的推送次数；
第三判断单元，用于判断更新后的推送次数是否达到最大推送次数；
执行单元，用于若所述更新后的推送次数未达到最大推送次数，则将所述推送数据推送到所述死信队列中，当所述推送数据进入所述死信队列的时长达到第二间隔时间时，将所述推送数据转到所述延迟队列，当监听到所述推送数据进入所述延迟队列时，将所述推送数据推送到所述交互系统；
第二更新单元，用于若所述更新后的推送次数达到最大推送次数，则更新所述数据补偿表中所述推送数据的推送状态为推送失败。
在一种可能的实现方式中，所述装置还包括：
第二判断单元，用于判断所述推送数据是否成功推送到所述交互系统中；
删除单元，用于若所述推送数据成功推送到所述交互系统中，则删除所述数据补偿表中的所述推送数据。
在一种可能的实现方式中，所述第二推送单元包括：
请求单元，用于当监听到所述推送数据进入所述延迟队列时，向所述业务交互系统发送超文本传输协议http请求；
第四判断单元，用于判断所述http请求是否发送成功；
推送子单元，用于若所述http请求发送成功，则将所述推送数据推送到所述交互系统；
返回执行单元，用于若所述http请求发送失败，则返回执行如下步骤：将所述推送数据推送到所述死信队列中。
从上述的技术方案可知，本发明实施例公开了一种数据处理方法及装置，接收业务请求参数；根据业务请求参数组装得到推送数据；判断数据补偿表中是否存在与推送数据的主键相同的未处理完成的补偿数据；若存在补偿数据，则将推送数据保存到数据补偿表中；当死信队列中的补偿数据处理完成后，将推送数据推送到所述死信队列中；当推送数据进入死信队列的时长达到第一间隔时间时，将推送数据转到延迟队列；当监听到推送数据进入延迟队列时，将推送数据推送到交互系统。可见，本发明实施例中推送数据是在补偿数据处理完成之后再推送给业务系统的，如此主键相同的数据是串行处理的，处理完一条数据再处理下一条数据，保证了数据有序抵达交互系统，从而保证了数据的完整性和可控性。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据公开的附图获得其他的附图。
图1为本发明实施例公开的一种数据处理方法的流程图；
图2为本发明实施例中公开的一种消息处理方法的流程图；
图3为本发明实施例中公开的另一种数据处理的方法的流程图；
图4为本发明实施例中公开的另一种数据处理的方法的流程图；
图5为本发明实施例公开的一种数据处理装置的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明实施例公开了一种数据处理方法及装置，接收业务请求参数；根据业务请求参数组装得到推送数据；判断数据补偿表中是否存在与推送数据的主键相同的未处理完成的补偿数据；若存在补偿数据，则将推送数据保存到数据补偿表中；当死信队列中的补偿数据处理完成后，将推送数据推送到所述死信队列中；当推送数据进入死信队列的时长达到第一间隔时间时，将推送数据转到延迟队列；当监听到推送数据进入延迟队列时，将推送数据推送到交互系统。可见，本发明实施例中推送数据是在补偿数据处理完成之后再推送给业务系统的，如此主键相同的数据是串行处理的，处理完一条数据再处理下一条数据，保证了数据有序抵达交互系统，从而保证了数据的完整性和可控性。
需要说明的是，本发明实施例提供的数据处理方法及装置可以基于Spring Boot微服务架构、Redis缓存、RabbitMQ消息队列和MySQL数据库实现。
微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务，这个定义来自DDD领域驱动设计。
Spring Boot是由Pivotal团队提供的全新框架，其设计目的是用来简化新Spring应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。
Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存、分布式、可选持久性的键值对(Key-Value)存储数据库，并提供多种语言的API。它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set--有序集合)和hash(哈希类型)。
消息队列(Message Queue)是一种应用间的通信方式，消息发送后可以立即返回，由消息系统来确保消息的可靠传递。消息发布者只管把消息发布到MQ中而不用管谁来取，消息使用者只管从MQ中取消息而不管是谁发布的。这样发布者和使用者都不用知道对方的存在。
MySQL是一种关系型数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。
参见图1，本发明实施例公开的一种数据处理方法，该方法包括：
步骤S101、接收业务请求参数；
需要说明的是，本发明实施例中可以由微服务系统接收外部业务系统发送的业务请求参数。其中，微服务提供的API接口支持批量操作，也就是说可以推送多条数据给Spring Boot微服务。外部业务系统通过发送httpclient请求到Spring Boot微服务中，Spring Boot微服务的API对外接口接收到该请求，根据请求中的业务请求参数做进一步业务处理。
步骤S102、根据所述业务请求参数组装得到推送数据；
需要说明的是，本发明实施例中可以从业务请求参数中筛选出租户、业务类型和业务数据，根据租户和业务类型从数据库中获取交互对方的接口配置信息，包括请求地址、请求头、请求方式等信息，依据业务数据组装得到推送数据。
步骤S103、判断数据补偿表中是否存在与所述推送数据的主键相同的未处理完成的补偿数据；
需要说明的是，主键包括如下至少一种：租户、业务类型、业务数据。在推送组装得到的推送数据之前会根据租户、业务类型、业务数据这三个主键字段判断是否有未处理完成的补偿数据。
需要说明的是，数据补偿是因为一次跨机器的请求通信可能会通过DNS、网卡、交换机、路由机、负载均衡等设备，这些设备都不是一直稳定的，在数据传输的过程中只要一个问题出错，就会有问题的产生。在分布式里面，一次完整的业务流程是由多次跨机器的通信构成，那么产生问题的概率就会成倍的增加。但是这个并不表示真正的系统无法处理请求，所以我们应该尽可能的通过内部机制消化掉这些异常。
步骤S104、若存在所述补偿数据，则将所述推送数据保存到数据补偿表中；
可以理解的是，当存在与推送数据的主键相同的未处理完成的补偿数据时，将该推送数据保存到数据补偿表中时，该推送数据是被当做后续的补偿数据。
需要说明的是，若存在补偿数据的话，表明该推送数据之前有数据未同步到交互系统，需等待之前的补偿数据处理完成之后再处理该推送数据。若不存在补偿数据的话，表明该推送数据之前的数据已经全部同步到交互系统，可以将该推送数据直接推送到交互系统。
需要说明的是，本发明实施例中可以将数据补偿表存储在数据库MySQL中，该数据补偿表保存了需要补偿的业务数据。例如：字段可以包括主键、业务数据主键、业务数据字符串、接口请求地址、接口请求Header参数、接口返回结果、请求时间、响应时间、状态、补偿次数等，业务数据包括但不限于品牌、品类、商品、库存、价格、属性和规格等。上述例子只是示例性说明，不应理解为对本发明的限制。
步骤S105、当死信队列中的所述补偿数据处理完成后，将所述推送数据推送到所述死信队列中；
需要说明的是，死信队列设置有过期时间(Time-To-Live，TTL)特性和死信交换机(Dead Letter Exchange，DLX)特性。TTL特性表明了一条消息可在队列中存活的最大时间，单位为毫秒，DLX特性表明当消息到期后可以通过死信交换机的路由转到指定队列进行处理，也就是结合TTL和DLX特性，实现了一个延迟队列。
需要说明的是，在定义一个消息队列是会绑定死信对接名称、死信交换机、过期时间、延迟队列名称。在将数据推送到死信队列后，等待过期时间到了，会把该数据发布到死信交换机中，死信交换机会把数据推送到延迟队列中，只需要监听延迟队列就会拿到需要重新推送的数据。
需要说明的是，当某条消息被设置了TTL或者当某条消息进入了设置了TTL的队列时，这条消息会在经过TTL秒后“死亡”，成为DeadLetter。如果既配置了消息的TTL，又配置了队列的TTL，那么较小的那个值会被取用。被设置了TTL的消息在过期后会成为DeadLetter。其实在RabbitMQ中，一共有三种消息的“死亡”形式：第一种为消息被拒绝，通过调用basic.reject或者basic.nack并且设置的requeue参数为false；第二种为消息因为设置了TTL而过期；第三种为消息进入了一条已经达到最大长度的队列。如果队列设置了DLX，那么这些Dead Letter就会被重新publish到Dead Letter Exchange，通过Dead LetterExchange路由到其他队列。
步骤S106、当所述推送数据进入所述死信队列的时长达到第一间隔时间时，将所述推送数据转到延迟队列；
需要说明的是，本发明实施例中可以通过缓存Redis使用Map结构保存数据补偿的频率，该频率是表明下一次需要间隔多大时长才会补偿数据。其中，数据补偿次数是有限制的，每次间隔的时间也会不一样，越往后间隔的时间越长，时间间隔越短失败的几率越大。例如：缓存key值为固定值，编码为DELAY_FREQUENCY_HASH_KEY；缓存mapField值为次数，第一次为1，第二次为2，最多可只允许7次；缓存mapValue值为间隔时间，第一间隔时间为10秒(表示当推送数据第一次进入死信队列的时长达到10秒时，将推送数据转到延迟队列)，第二间隔时间为30秒(表示当第一次推动该推送数据给交互系统时，交互系统返回推动失败的结果时，该推送数据第二次进入死信队列的时长达到30秒时，将推送数据转到延迟队列)，第三间隔时间为1分钟，以此类推，一定要给补偿制定一个终止策略，防止过度积极的补偿策略对下游服务造成不利影响。需要说明的是，上述例子只是示例性说明，不应理解为对本发明的限制。
需要说明的是，实现数据延迟功能使用的是hash数据结构。hash数据结构是一个string类型的field(字段)和value(值)的映射表，hash特别适合用于存储对象。保存数据使用的是hset命令：HSET key field value，该命令涉及到三个参数，key为缓存键，field为字段，value为字段值，表示将哈希表key中的字段field的值设为value。其中，haset命令保存数据和hgetall命令查询数据执行结果为：
>hgetall DELAY_FREQUENCY_HASH_KEY
1
“10000”
2
“30000”
3
“60000”
>haset DELAY_FREQUENCY_HASH_KEY 4“360000”
1
步骤S107、当监听到所述推送数据进入所述延迟队列时，将所述推送数据推送到交互系统。
需要说明的是，延迟队列配置了消息监听，一旦监听到有推送数据转发到延迟队列会立即开展数据补偿。参见图2为本发明实施例中公开的一种消息处理方法的流程图。消费者发现该消息处理出现了异常，比如是因为网络波动引起的异常。那么如果不等待一段时间，直接就重试的话，很可能会导致在这期间内一直无法成功，造成一定的资源浪费。那么可以将其先放在缓冲队列(死信队列)中，等消息经过一段的延迟时间后再次进入实际消费队列(延迟队列)中，此时由于已经过了“较长”的时间了，异常的一些波动通常已经恢复，这些消息可以被正常地消费。
需要说明的是，队列中的消息内容是数据补偿表的全部信息，可以包括租户、业务类型、业务数据主键、请求数据、请求地址、请求方式、请求Header、状态、推送次数等信息。
本发明实施例公开了一种数据处理方法，接收业务请求参数；根据业务请求参数组装得到推送数据；判断数据补偿表中是否存在与推送数据的主键相同的未处理完成的补偿数据；若存在补偿数据，则将推送数据保存到数据补偿表中；当死信队列中的补偿数据处理完成后，将推送数据推送到所述死信队列中；当推送数据进入死信队列的时长达到第一间隔时间时，将推送数据转到延迟队列；当监听到推送数据进入延迟队列时，将推送数据推送到交互系统。可见，本发明实施例中推送数据是在补偿数据处理完成之后再推送给业务系统的，如此主键相同的数据是串行处理的，处理完一条数据再处理下一条数据，保证了数据有序抵达交互系统，从而保证了数据的完整性和可控性。
为了进一步优化上述实施例，本发明实施例中提供的数据处理方法，还包括：
步骤S201、判断所述推送数据是否成功推送到所述交互系统中；
需要说明的是，本发明实施例中可以通过分析交互系统的接口返回结果，判断该推送数据是否成功推动到交互系统中。
步骤S202、若所述推送数据未成功推送到所述交互系统中，则更新所述数据补偿表中所述推送数据的推送次数；
如果该数据成功推送到交互系统中，则该推送数据处理完毕，会删除数据补偿表中的该推送数据，判断该业务数据主键是否有其他等待状态的补偿数据，如果有数据的话将该数据推送到死信队列等待重新补偿推送。
如果该推送数据未成功推送到交互系统中，则将该推送数据继续保存在数据补偿表中，该推送数据包括租户、业务类型、业务数据主键、请求数据、请求地址、请求方式、请求Header、状态、推送次数等信息，并将推送次数加1，等待继续推送。
步骤S203、判断更新后的推送次数是否达到最大推送次数；
需要说明的是，最大推送次数可以设置为7次或8次等等，具体不做限制，可根据实际需求进行设置。
步骤S204、若所述更新后的推送次数未达到最大推送次数，则将所述推送数据推送到所述死信队列中，当所述推送数据进入所述死信队列的时长达到第二间隔时间时，将所述推送数据转到所述延迟队列，当监听到所述推送数据进入所述延迟队列时，将所述推送数据推送到所述交互系统；
需要说明的是，第二间隔时间大于第一间隔时间。其中，由于时间间隔越短失败的几率越大，故在第二次推送时等待更长的间隔时间再进行数据推送，能提高推送成功的概率。但是时间间隔过长会对整体性能造成不良影响，故需要根据实际情况合理设置间隔时间。
步骤S205、若所述更新后的推送次数达到最大推送次数，则更新所述数据补偿表中所述推送数据的推送状态为推送失败。
需要说明的是，当数据补偿表中推送数据的推送状态更新为推送失败时，后续不需要继续推送该推送数据。
本发明实施例中，通过设置一个最大推送次数，使得推送失败的数据不会一直被继续推送，避免了后续数据无法被推送的情况，如此能避免过度积极的补偿策略对下游服务造成不利影响。
为了进一步优化上述实施例，本发明实施例中提供的数据处理方法，还包括：
判断所述推送数据是否成功推送到所述交互系统中；
若所述推送数据成功推送到所述交互系统中，则删除所述数据补偿表中的所述推送数据。
本发明实施例中，当推送数据成功推送到交互系统中，会删除数据补偿表中的推送数据，如此保证了数据补偿表中的数据均是未处理完成的数据，保证了能有序进行数据的处理。
为了进一步优化上述实施例，本发明实施例中提供的数据处理方法中，步骤S107具体包括：
步骤S1071、所述当监听到所述推送数据进入所述延迟队列时，将所述推送数据推送到交互系统包括：
步骤S1072、当监听到所述推送数据进入所述延迟队列时，向所述业务交互系统发送超文本传输协议http请求；
步骤S1073、判断所述http请求是否发送成功；
步骤S1074、若所述http请求发送成功，则将所述推送数据推送到所述交互系统；
步骤S1075、若所述http请求发送失败，则返回执行如下步骤：将所述推送数据推送到所述死信队列中。
本发明实施例中，会对http请求是否发送成功进行判断，并针对不同的判断结果采取不同的操作，进一步保证了数据有序抵达交互系统，从而保证了数据的完整性和可控性。
图3为本发明实施例中公开的另一种数据处理的方法的流程图，该方法包括：
步骤S301、接收请求参数。
步骤S302、组装交互请求参数，即根据请求参数组装得到推送数据。
步骤S303、判断是否有未推送数据，即是判断数据补偿表中是否存在与组装得到的推送数据的主键相同的未处理完成的补偿数据。
步骤S304、如果有补偿数据，则保存数据到数据补偿表，即是将推送数据保存在数据补偿表中。
步骤S305、如果没有补偿数据，则发起http请求。
步骤S304之后，包括：
步骤S306、将数据推送到死信队列，即是当死信队列中的补偿数据处理完成后，将推送数据推送到死信队列中。
步骤S307、监听延迟队列，获取队列中的消息；即是当推送数据进入死信队列的时长达到第一间隔时间时，将推送数据转到延迟队列，监听延迟队列，获取队列中的消息。
步骤S308、发起http请求。
步骤S309、判断http请求是否发送成功。
步骤S310、若http请求发送成功，则分析交互系统发送的请求返回结果。
步骤S311、若http请求发送失败，则返回执行步骤S306将数据推送到死信队列，此处的数据指的是推送数据。
步骤S312、判断交互是否成功。
步骤S313、若交互成功，则删除补偿数据，获取下条补偿数据，返回执行步骤S306、将数据推送到死信队列，此处的数据指的是下条补偿数据，即是将下条补偿数据推送到死信队列。
步骤S314、若交互失败，则修改状态和推送次数，返回执行步骤S306将数据推送到死信队列，此处的数据指的是推送数据。
步骤S305之后，包括：
步骤S315、判断http请求是否发送成功；
步骤S316、若http请求发送成功，则分析交互系统发送的请求返回结果。
步骤S317、若http请求发送失败，则执行步骤S306将数据推送到死信队列，此处的数据指的是推送数据，之后步骤与上述步骤S306之后的步骤相同。
步骤S318、判断交互是否成功。
步骤S319、若交互成功，则保存返回结果。
步骤S320、若交互失败，则将该推送数据保存到数据补偿表中，执行步骤S306将数据推送到死信队列，此处的数据指的是推送数据，之后步骤与上述步骤S306之后的步骤相同。
图4为本发明实施例中公开的另一种数据处理的方法的流程图，该方法包括：
步骤S401、接收请求参数。
步骤S402、组装交互请求参数，即根据请求参数组装得到推送数据。
步骤S403、判断是否有未推送数据，即是判断数据补偿表中是否存在与组装得到的推送数据的主键相同的未处理完成的补偿数据。
步骤S404、如果有补偿数据，则保存数据到数据补偿表，状态为重新发送，推送次数为1，即是将推送数据保存在数据补偿表中。
步骤S405、如果没有补偿数据，则发起http请求。
步骤S404之后，包括：
步骤S406、将数据推送到死信队列，即是当死信队列中的补偿数据处理完成后，将推送数据推送到死信队列中。
步骤S407、监听延迟队列，获取队列中的消息；即是当推送数据进入死信队列的时长达到第一间隔时间时，将推送数据转到延迟队列，监听延迟队列，获取队列中的消息。
步骤S408、发起http请求。
步骤S409、判断http请求是否发送成功。
步骤S410、若http请求发送成功，则分析交互系统发送的请求返回结果。
步骤S411、若http请求发送失败，则返回执行步骤S406将数据推送到死信队列，此处的数据指的是推送数据。
步骤S412、判断交互是否成功。
步骤S413、若交互成功，则删除补偿数据，获取下条补偿数据，返回执行步骤S406、将数据推送到死信队列，此处的数据指的是下条补偿数据，即是将下条补偿数据推送到死信队列。
步骤S414、若交互失败，则将数据补偿表中的该推送数据的推送次数加1。
步骤S415、判断该推送数据的推送次数是否超过最大推送次数；
步骤S416、若超过最大推送次数，则该推送数据的状态修改为推送失败，不再推送。
步骤S417、若未超过最大推送次数，则返回执行步骤S406、将数据推送到死信队列，此处的数据指的是推送数据。
步骤S405之后，包括：
步骤S418、判断http请求是否发送成功；
步骤S419、若http请求发送成功，则分析交互系统发送的请求返回结果。
步骤S420、若http请求发送失败，则执行步骤S406将数据推送到死信队列，此处的数据指的是推送数据，之后步骤与上述步骤S406之后的步骤相同。
步骤S421、判断交互是否成功。
步骤S422、若交互成功，则保存返回结果。
步骤S423、若交互失败，则将该推送数据保存到数据补偿表中，该推送数据状态为重新发送，推送次数为1，执行步骤S406将数据推送到死信队列，此处的数据指的是推送数据，之后步骤与上述步骤S406之后的步骤相同。
图5为本发明实施例公开的一种数据处理装置的结构示意图，该装置包括：
接收单元501，用于接收业务请求参数；
参数组装单元502，用于根据所述业务请求参数组装得到推送数据；
第一判断单元503，用于判断数据补偿表中是否存在与所述推送数据的主键相同的未处理完成的补偿数据；
数据保存单元504，用于若存在所述补偿数据，则将所述推送数据保存到数据补偿表中；
第一推送单元505，用于当死信队列中的所述补偿数据处理完成后，将所述推送数据推送到所述死信队列中；
数据转移单元506，用于当所述推送数据进入所述死信队列的时长达到第一间隔时间时，将所述推送数据转到延迟队列；
第二推送单元507，用于当监听到所述推送数据进入所述延迟队列时，将所述推送数据推送到交互系统。
本发明实施例公开了一种数据处理装置，接收业务请求参数；根据业务请求参数组装得到推送数据；判断数据补偿表中是否存在与推送数据的主键相同的未处理完成的补偿数据；若存在补偿数据，则将推送数据保存到数据补偿表中；当死信队列中的补偿数据处理完成后，将推送数据推送到所述死信队列中；当推送数据进入死信队列的时长达到第一间隔时间时，将推送数据转到延迟队列；当监听到推送数据进入延迟队列时，将推送数据推送到交互系统。本发明实施例中推送数据是在补偿数据处理完成之后再推送给业务系统的，如此主键相同的数据是串行处理的，处理完一条数据再处理下一条数据，保证了数据有序抵达交互系统，从而保证了数据的完整性和可控性。
为了进一步优化上述实施例，本发明实施例中提供的数据处理装置，还包括：
第二判断单元，用于判断所述推送数据是否成功推送到所述交互系统中；
第一更新单元，用于若所述推送数据未成功推送到所述交互系统中，则更新所述数据补偿表中所述推送数据的推送次数；
第三判断单元，用于判断更新后的推送次数是否达到最大推送次数；
执行单元，用于若所述更新后的推送次数未达到最大推送次数，则将所述推送数据推送到所述死信队列中，当所述推送数据进入所述死信队列的时长达到第二间隔时间时，将所述推送数据转到所述延迟队列，当监听到所述推送数据进入所述延迟队列时，将所述推送数据推送到所述交互系统；
第二更新单元，用于若所述更新后的推送次数达到最大推送次数，则更新所述数据补偿表中所述推送数据的推送状态为推送失败。
为了进一步优化上述实施例，本发明实施例中提供的数据处理装置，还包括：
第二判断单元，用于判断所述推送数据是否成功推送到所述交互系统中；
删除单元，用于若所述推送数据成功推送到所述交互系统中，则删除所述数据补偿表中的所述推送数据。
为了进一步优化上述实施例，本发明实施例中提供的数据处理装置中，第二推送单元507包括：
请求单元，用于当监听到所述推送数据进入所述延迟队列时，向所述业务交互系统发送超文本传输协议http请求；
第四判断单元，用于判断所述http请求是否发送成功；
推送子单元，用于若所述http请求发送成功，则将所述推送数据推送到所述交互系统；
返回执行单元，用于若所述http请求发送失败，则返回执行如下步骤：将所述推送数据推送到所述死信队列中。
需要说明的是，装置实施例中各组成部分的具体工作原理请参见方法实施例对应部分，此处不再赘述。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种数据处理方法，其特征在于，所述方法包括：
接收业务请求参数；
根据所述业务请求参数组装得到推送数据；
判断数据补偿表中是否存在与所述推送数据的主键相同的未处理完成的补偿数据；
若存在所述补偿数据，则将所述推送数据保存到数据补偿表中；
当死信队列中的所述补偿数据处理完成后，将所述推送数据推送到所述死信队列中；
当所述推送数据进入所述死信队列的时长达到第一间隔时间时，将所述推送数据转到延迟队列；
当监听到所述推送数据进入所述延迟队列时，将所述推送数据推送到交互系统。
2.根据权利要求1所述的方法，其特征在于，所述方法还包括：
判断所述推送数据是否成功推送到所述交互系统中；
若所述推送数据未成功推送到所述交互系统中，则更新所述数据补偿表中所述推送数据的推送次数；
判断更新后的推送次数是否达到最大推送次数；
若所述更新后的推送次数未达到最大推送次数，则将所述推送数据推送到所述死信队列中，当所述推送数据进入所述死信队列的时长达到第二间隔时间时，将所述推送数据转到所述延迟队列，当监听到所述推送数据进入所述延迟队列时，将所述推送数据推送到所述交互系统；
若所述更新后的推送次数达到最大推送次数，则更新所述数据补偿表中所述推送数据的推送状态为推送失败。
3.根据权利要求2所述的方法，其特征在于，所述第二间隔时间大于所述第一间隔时间。
4.根据权利要求1所述的方法，其特征在于，所述方法还包括：
判断所述推送数据是否成功推送到所述交互系统中；
若所述推送数据成功推送到所述交互系统中，则删除所述数据补偿表中的所述推送数据。
5.根据权利要求1所述的方法，其特征在于，所述当监听到所述推送数据进入所述延迟队列时，将所述推送数据推送到交互系统包括：
当监听到所述推送数据进入所述延迟队列时，向所述业务交互系统发送超文本传输协议http请求；
判断所述http请求是否发送成功；
若所述http请求发送成功，则将所述推送数据推送到所述交互系统；
若所述http请求发送失败，则返回执行如下步骤：将所述推送数据推送到所述死信队列中。
6.根据权利要求1所述的方法，其特征在于，所述主键包括如下至少一种：租户、业务类型、业务数据。
7.一种数据处理装置，其特征在于，所述装置包括：
接收单元，用于接收业务请求参数；
参数组装单元，用于根据所述业务请求参数组装得到推送数据；
第一判断单元，用于判断数据补偿表中是否存在与所述推送数据的主键相同的未处理完成的补偿数据；
数据保存单元，用于若存在所述补偿数据，则将所述推送数据保存到数据补偿表中；
第一推送单元，用于当死信队列中的所述补偿数据处理完成后，将所述推送数据推送到所述死信队列中；
数据转移单元，用于当所述推送数据进入所述死信队列的时长达到第一间隔时间时，将所述推送数据转到延迟队列；
第二推送单元，用于当监听到所述推送数据进入所述延迟队列时，将所述推送数据推送到交互系统。
8.根据权利要求7所述的装置，其特征在于，所述装置还包括：
第二判断单元，用于判断所述推送数据是否成功推送到所述交互系统中；
第一更新单元，用于若所述推送数据未成功推送到所述交互系统中，则更新所述数据补偿表中所述推送数据的推送次数；
第三判断单元，用于判断更新后的推送次数是否达到最大推送次数；
执行单元，用于若所述更新后的推送次数未达到最大推送次数，则将所述推送数据推送到所述死信队列中，当所述推送数据进入所述死信队列的时长达到第二间隔时间时，将所述推送数据转到所述延迟队列，当监听到所述推送数据进入所述延迟队列时，将所述推送数据推送到所述交互系统；
第二更新单元，用于若所述更新后的推送次数达到最大推送次数，则更新所述数据补偿表中所述推送数据的推送状态为推送失败。
9.根据权利要求7所述的装置，其特征在于，所述装置还包括：
第二判断单元，用于判断所述推送数据是否成功推送到所述交互系统中；
删除单元，用于若所述推送数据成功推送到所述交互系统中，则删除所述数据补偿表中的所述推送数据。
10.根据权利要求7所述的装置，其特征在于，所述第二推送单元包括：
请求单元，用于当监听到所述推送数据进入所述延迟队列时，向所述业务交互系统发送超文本传输协议http请求；
第四判断单元，用于判断所述http请求是否发送成功；
推送子单元，用于若所述http请求发送成功，则将所述推送数据推送到所述交互系统；
返回执行单元，用于若所述http请求发送失败，则返回执行如下步骤：将所述推送数据推送到所述死信队列中。
CN202210705783.8A 2022-06-21 2022-06-21 一种数据处理方法及装置 Pending CN114979039A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210705783.8A CN114979039A (zh) 2022-06-21 2022-06-21 一种数据处理方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210705783.8A CN114979039A (zh) 2022-06-21 2022-06-21 一种数据处理方法及装置

Publications (1)

Publication Number Publication Date
CN114979039A true CN114979039A (zh) 2022-08-30

Family

ID=82965485

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210705783.8A Pending CN114979039A (zh) 2022-06-21 2022-06-21 一种数据处理方法及装置

Country Status (1)

Country Link
CN (1) CN114979039A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116094651A (zh) * 2022-10-31 2023-05-09 中国电信股份有限公司 消息重试方法、系统、电子设备及存储介质

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100666712B1 (ko) * 2005-11-15 2007-01-09 주식회사 케이티프리텔 푸시 에이전트 서비스 장치 및 방법, 그리고 이를 수용한개방형 모바일 비즈니스 지원 시스템
KR20130082937A (ko) * 2011-12-23 2013-07-22 유영민 개발자의 어플리케이션으로 푸시 서비스를 제공하는 푸시 서비스 시스템 및 푸시 서비스 방법
US20140304165A1 (en) * 2011-08-17 2014-10-09 Lookout, Inc. Mobile communications device payment method utilizing location information
KR20140121716A (ko) * 2013-04-08 2014-10-16 에스케이텔레콤 주식회사 모바일 디바이스 운영체제의 통합 변환을 이용한 푸시서비스 제공 장치 및 방법
CN106250250A (zh) * 2016-08-09 2016-12-21 广州唯品会信息科技有限公司 数据通信方法及装置
CN111311142A (zh) * 2019-12-31 2020-06-19 江苏苏宁物流有限公司 一种定制化实时数据高效推送方法及系统
CN112948491A (zh) * 2021-02-26 2021-06-11 平安普惠企业管理有限公司 数据同步的方法、装置、终端设备及计算机可读存储介质
US20210271715A1 (en) * 2020-02-27 2021-09-02 International Business Machines Corporation Processing database queries using data delivery queue
CN113742107A (zh) * 2021-09-03 2021-12-03 广州新丝路信息科技有限公司 一种避免消息队列中消息丢失的处理方法及相关设备
CN113934797A (zh) * 2021-12-17 2022-01-14 江苏苏宁银行股份有限公司 一种银行业超大数据同步方法和系统

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100666712B1 (ko) * 2005-11-15 2007-01-09 주식회사 케이티프리텔 푸시 에이전트 서비스 장치 및 방법, 그리고 이를 수용한개방형 모바일 비즈니스 지원 시스템
US20140304165A1 (en) * 2011-08-17 2014-10-09 Lookout, Inc. Mobile communications device payment method utilizing location information
KR20130082937A (ko) * 2011-12-23 2013-07-22 유영민 개발자의 어플리케이션으로 푸시 서비스를 제공하는 푸시 서비스 시스템 및 푸시 서비스 방법
KR20140121716A (ko) * 2013-04-08 2014-10-16 에스케이텔레콤 주식회사 모바일 디바이스 운영체제의 통합 변환을 이용한 푸시서비스 제공 장치 및 방법
CN106250250A (zh) * 2016-08-09 2016-12-21 广州唯品会信息科技有限公司 数据通信方法及装置
CN111311142A (zh) * 2019-12-31 2020-06-19 江苏苏宁物流有限公司 一种定制化实时数据高效推送方法及系统
US20210271715A1 (en) * 2020-02-27 2021-09-02 International Business Machines Corporation Processing database queries using data delivery queue
CN112948491A (zh) * 2021-02-26 2021-06-11 平安普惠企业管理有限公司 数据同步的方法、装置、终端设备及计算机可读存储介质
CN113742107A (zh) * 2021-09-03 2021-12-03 广州新丝路信息科技有限公司 一种避免消息队列中消息丢失的处理方法及相关设备
CN113934797A (zh) * 2021-12-17 2022-01-14 江苏苏宁银行股份有限公司 一种银行业超大数据同步方法和系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116094651A (zh) * 2022-10-31 2023-05-09 中国电信股份有限公司 消息重试方法、系统、电子设备及存储介质
CN116094651B (zh) * 2022-10-31 2024-05-14 中国电信股份有限公司 消息重试方法、系统、电子设备及存储介质

Similar Documents

Publication Publication Date Title
US6779002B1 (en) Computer software framework and method for synchronizing data across multiple databases
KR101203275B1 (ko) 서브큐를 이용한 로컬 메시지 프로세싱 개선
US20070162560A1 (en) System and method for asynchronous request response
US8484281B2 (en) System and method for callbacks based on web service addressing
CN108132830A (zh) 一种任务调度方法、装置及系统
US20050132086A1 (en) Port type agnostic proxy support for web services intermediaries
CZ381198A3 (cs) Zajišťování komunikačních spojů v počítačové síti
CN101616050B (zh) 总线系统
US20180324259A1 (en) Client connection method and system
US6269378B1 (en) Method and apparatus for providing a name service with an apparently synchronous interface
CN114979039A (zh) 一种数据处理方法及装置
JP2005521945A (ja) 共通作業キュー環境における最適格サーバ
US20090055511A1 (en) Non-programmatic access to data and to data transfer functions
US8694462B2 (en) Scale-out system to acquire event data
US7451127B2 (en) Web store events
JP6668456B2 (ja) 処理システムおよび処理方法
CN109905459B (zh) 一种数据传输方法及装置
CN113645260A (zh) 业务重试方法、装置、存储介质及电子设备
CN113626208A (zh) 一种基于nio异步线程模型的服务器通信方法
US20100332604A1 (en) Message selector-chaining
US11165736B2 (en) E-mail display device and non-transitory computer readable medium storing program
CN113765693B (zh) 一种需求测试方法、装置、服务器及存储介质
CN111026564A (zh) 命名服务的处理方法和系统
CN112181671A (zh) 一种延时消息处理的方法及装置
JP2003141070A (ja) 装 置

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