CN115314458A - Message pushing method and device, electronic equipment and storage medium - Google Patents

Message pushing method and device, electronic equipment and storage medium Download PDF

Info

Publication number
CN115314458A
CN115314458A CN202210784912.7A CN202210784912A CN115314458A CN 115314458 A CN115314458 A CN 115314458A CN 202210784912 A CN202210784912 A CN 202210784912A CN 115314458 A CN115314458 A CN 115314458A
Authority
CN
China
Prior art keywords
service type
task
message
pushed
current
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
CN202210784912.7A
Other languages
Chinese (zh)
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.)
Shenzhen Handhui Technology Group Co ltd
Original Assignee
Shenzhen Handhui Technology Group 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 Shenzhen Handhui Technology Group Co ltd filed Critical Shenzhen Handhui Technology Group Co ltd
Priority to CN202210784912.7A priority Critical patent/CN115314458A/en
Publication of CN115314458A publication Critical patent/CN115314458A/en
Pending legal-status Critical Current

Links

Images

Landscapes

  • Information Transfer Between Computers (AREA)

Abstract

The application is applicable to the field of data transmission, and provides a message pushing method, a message pushing device, electronic equipment and a computer-readable storage medium. The method comprises the following steps: acquiring the current service type of the current message; if the push task of the current message is abnormal, determining a sub-level service type of the current service type according to a preset service type dependency relationship; establishing the pushing task of the sub-level service type as a to-be-pushed task in a blocking state; the service type dependency relationship comprises a sub-level service type and a parent-level service type of each preset service type of the message; the method and the device can interrupt the subsequent pushing task when the pushing process is abnormal, the subsequent message cannot be pushed to the receiving party first, and the time sequence for the receiving party to receive the message is the same as the time sequence required by the service.

Description

Message pushing method and device, electronic equipment and storage medium
Technical Field
The present application belongs to the field of data transmission, and in particular, to a message pushing method, an apparatus, an electronic device, and a computer-readable storage medium.
Background
With the development of internet technology, business data is pushed between enterprises more and more frequently. When an abnormality exists in the pushing process, a push strategy is usually adopted among enterprises, and the pushed message is pushed again for a certain number of times, so that the problem of message loss is reduced, and meanwhile, the pushing of subsequent messages cannot be stopped. However, in a strong time sequence service scenario, a push party pushes messages with a specified time sequence, and if some message in the message is pushed abnormally, a subsequently pushed message arrives at a receiving party first, that is, the receiving party fails to receive the message successfully according to the same time sequence, and a problem occurs in service data.
Disclosure of Invention
The application provides a message pushing method, a message pushing device, electronic equipment and a computer readable storage medium, which can block a pushing task when an exception exists in a pushing process and ensure that a message pushing time sequence is correct.
A first aspect of an embodiment of the present application provides a message pushing method, including:
acquiring the current service type of the current message;
if the push task of the current message is abnormal, determining a sub-level service type of the current service type according to a preset service type dependency relationship;
establishing the pushing task of the sub-level service type as a to-be-pushed task in a blocking state;
the service type dependency relationship comprises a sub-level service type and a parent-level service type of each preset service type of the message.
A second aspect of the embodiments of the present application provides a message pushing apparatus, including:
the type acquisition module is used for acquiring the current service type of the current message;
the type acquisition module is also used for determining a sub-level service type of the current service type according to a preset service type dependency relationship when the push task of the current message is abnormal;
the message interception module is used for establishing the pushing task of the sub-level service type as a to-be-pushed task in a blocking state;
the monitoring module is used for determining that the push task of the current message is recovered to be normal after the successful callback event from the receiver is acquired;
the query module is used for querying whether the sub-level service type has the task to be pushed or not;
the activation module is used for changing the to-be-pushed task from a blocking state to an activation state when the to-be-pushed task exists in the sub-level service type, re-executing the to-be-pushed task of the sub-level service type and deleting the to-be-pushed task;
the service type dependency relationship comprises a sub-level service type and a parent-level service type of each preset service type of the message.
A third aspect of an embodiment of the present application provides an electronic device, including: a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the method according to the first aspect when executing the computer program.
A fourth aspect of embodiments of the present application provides a computer-readable storage medium, in which a computer program is stored, which, when executed by a processor, implements the method according to the first aspect above.
According to the message pushing method provided by the embodiment of the application, when the pushing task of the current message is abnormal, the sub-level service type of the current service type is determined according to the preset service type dependency relationship, and the pushing task of the sub-level service type is established as the to-be-pushed task in the blocking state. As can be understood from the above description, in a strong timing sequence service scenario, when there is an abnormality in the message pushing process, the subsequent message pushing task is created as a to-be-pushed task in a blocked state, so that it is possible to prevent the subsequent message from reaching the receiving party first, and ensure that the timing sequence of receiving the message by the receiving party is the same as the timing sequence specified by the pushing party.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without exceeding the protection scope of the present application.
Fig. 1 illustrates a flowchart of a message push method provided in an embodiment of the present application;
fig. 2 is a schematic flowchart illustrating a message push method according to another embodiment of the present application;
fig. 3 shows a schematic block diagram of a message pushing apparatus according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some, but not all, of the embodiments of the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the application. One skilled in the relevant art will recognize, however, that the embodiments of the present application can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known methods, devices, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the application.
Those skilled in the art will appreciate that the drawings are merely schematic illustrations of example embodiments, which may not be to scale. The modules or processes in the figures are not necessarily required to practice the present application and therefore should not be used to limit the scope of the present application.
The embodiment provides a message pushing method, which is suitable for a strong time sequence service pushing scene, and can block a pushing task when an exception occurs in a pushing process, so as to ensure that a message pushing time sequence is correct. The method is performed by a message push device, which is made up of software and/or hardware, typically integrated in an electronic device with communication capabilities, which can push messages to designated recipients or broadcast messages and receive responses from the recipients.
Fig. 1 is a schematic flowchart of a message pushing method provided in an embodiment of the present application, and as shown in fig. 1, the method may include:
step 101, obtaining a current service type of a current message.
In practical applications, when a business process must be executed in a specified order, the task belongs to a strong timing business. For different business processes, the business types of various messages in each business process can be defined in advance according to the execution sequence of the business processes. For example, what message defines why the type.
And 102, if the pushing task of the current message is abnormal, determining the sub-level service type of the current service type according to the preset service type dependency relationship.
In practical applications, the manner of determining that the push task of the current message is abnormal includes, but is not limited to: the method may be that when the push task of the current message is executed, if a successful callback event from the receiving party is not received after the preset time, it is determined that the push task of the current message is abnormal. Or the receiver checks that the received message is incomplete and has the condition of message loss, and sends an event requesting for re-pushing, and then determines that the pushing task of the current message has abnormality. And if other events cause that the push task cannot be normally executed or cannot be received, determining that the push task of the current message has an abnormality.
The dependency relationship of each service type is configured in advance and can be a hierarchy dependency relationship. The service type dependency relationship comprises a child service type and a parent service type of each preset service type of the message.
Configuration can be newly added in configuration directories of other systems in the enterprise, the dependency relationship of all service types is recorded, and then the configuration is applied to the service system. The configuration can be in a document form, a database form or a cache form.
And 103, establishing the pushing task of the sub-level service type as a to-be-pushed task in a blocking state.
Take the business information push process between two business systems, namely an order system and a marketing statistical system, in an enterprise as an example.
The order system is responsible for processing order business, and the marketing statistical system is provided with a user order statistical table in a database and is responsible for storing and counting the total order output amount and the total order output amount of the user. The order service includes a payment message and a refund message. And when the marketing statistical system receives the payment message, adding one to the user order number of the order-out statistical table, and adding the latest order-out amount to the total order-out amount. And after the marketing statistical system receives the refund message, the user order number of the order statistical table is reduced by one, and the total amount of the order is reduced by the amount of the order of the corresponding user.
The business is pushed according to the sequence of pushing the payment message first and pushing the refund message later, and the marketing statistical system receives the messages according to the sequence. If the pushing-receiving sequence is not followed, when the marketing statistical system does not successfully receive the payment message, the number of the user orders of the order-out statistical table is not increased, and then the refund message is received, so that the number of the user orders of the order-out statistical table in the marketing statistical system is reduced, and the total number of the user orders is inaccurate.
In this embodiment, the push party and the receiving party correspond to the order system and the marketing statistical system, respectively, and the push message includes a payment message and a refund message. In the above order service, the payment message and the refund message are defined as a payment service type and a refund service type, respectively. The dependency relationship between the two service types is preset to be a parent service type of the payment service type being a refund service type. That is to say, in this embodiment, when the order service is pushed, the current message is a payment message, and the current service type is a payment service type.
And when the marketing statistical system fails to receive the payment message, determining that the sub-level business type of the payment business type is the refund business type according to the business type dependency relationship, and establishing the pushing task of the refund business type as a to-be-pushed task in a blocking state. At this time, if the order system generates a refund message, the push task of the refund message is blocked.
It can be understood from the above description that, in a strong time sequence service scenario, when there is an abnormality in the message pushing process, a subsequent message pushing task is created as a to-be-pushed task in a blocked state, so that a subsequently sent message can be prevented from reaching a receiving party first, which causes confusion of data or service logic, and it is ensured that the time sequence of receiving the message by the receiving party is the same as the time sequence specified by the pushing party.
Fig. 2 is a schematic flow chart of a message pushing method in another embodiment of the present application, and based on the above method embodiment, as shown in fig. 2, after step 103, the method further includes the following steps:
s201, when a successful callback event from a receiving party is acquired, determining that the push task of the current message is recovered to be normal.
The successful callback event of the receiver indicates that the reason causing the exception of the push task is removed, and the subsequent messages can be continuously pushed according to the time sequence of the service flow.
S202, whether a task to be pushed exists in the sub-level service type is inquired, if yes, the step S203 is executed, and if not, the step S204 is executed.
S203, changing the blocking state of the task to be pushed into the activating state, re-executing the pushing task of the sub-level service type, and deleting the task to be pushed.
And S204, executing the pushing task of the sub-level service type.
According to the above example, after the marketing statistical system fails to receive the payment message, the refund service type pushing task is established as a blocking state to-be-pushed task, at the moment, the refund service type pushing task is interrupted, and the marketing statistical system cannot receive the refund message.
During this time, the order system will attempt to push the payment message multiple times until the marketing statistics system successfully receives the payment message. And the marketing statistical system triggers a successful call-back event and responds to the message pushed by the order system.
And after the successful call-back event of the marketing statistical system is acquired, the pushing task determining the payment service type is recovered to be normal, the marketing statistical system successfully receives the payment message, the user order number of the order-out statistical table is increased by one, and the total amount of the order-out is increased by the latest amount of the order-out. And the order system inquires the tasks to be pushed with the refund business types in the blocking state, changes the tasks to be pushed from the blocking state to the activating state, re-executes the pushing tasks of the refund business types and deletes the tasks to be pushed. Through the above description, it can be understood that the push task of the subsequent message is executed after the push task of the current message is determined to be recovered, the message can be prevented from being lost, whether the sub-level service type has the task to be pushed or not is simultaneously inquired, the existing push task is re-executed, the task to be pushed in the blocking state is re-pushed to the receiving party according to the push appointed time sequence, and the receiving party is ensured to correctly receive the push message.
In another embodiment of the present application, after obtaining the current service type of the current message, the step 101 further includes:
and acquiring the parent service type of the current service type according to the preset service type dependency relationship.
And inquiring whether a service success log of the pushing task exists in the parent-level business type.
And if so, executing the push task of the current message.
And if not, establishing the current service type as a task to be pushed in a blocking state.
For example, before executing the pushing task of the refund service type, the parent service type of the refund service type is acquired according to the dependency relationship, and is the payment service type. And inquiring whether a service success log of the push task exists in the payment service type.
In another embodiment of the present application, the service success log of the push task is generated in a manner including, but not limited to: and after a successful callback event from a receiving party is acquired, a service success log of the push task is created for the current service type.
It can be understood that after the successful callback event of the marketing statistical system is obtained, it is determined that the marketing statistical system successfully receives the payment message, and a service success log of the push task is created for the payment service type corresponding to the payment message. Of course, if the marketing statistics system does not return a successful callback event, it is determined that the marketing statistics system does not successfully receive the payment message, and the service success log does not exist.
And executing the pushing task of the refund service type after the service success log of the pushing task existing in the payment service type is inquired. And if the service success log does not exist in the inquiry, establishing the refund service type as a to-be-pushed task in a blocking state.
In this embodiment, whether the push task of the parent service type is normal is determined by querying the service success log, and whether the push task of the current message service type is executed is further determined, so that whether an exception exists in the current push process can be effectively determined. Meanwhile, the method can record the service type corresponding to the current message when the push task is abnormal.
In another embodiment of the present application, after the step 103 creates the push task of the sub-level service type as the to-be-pushed task in the blocking state, the method further includes:
and acquiring the number of the tasks to be pushed of all the service types.
And if the number reaches a preset threshold value, sending an alarm.
In this embodiment, the threshold is used to determine whether to issue an alarm. In practical application, a threshold may be set for the tasks to be pushed of all service types, or may be set for the tasks to be pushed of part of service types. The value of the threshold value can be set by a user or preset by the system. After the alarm is sent out, the marketing statistical system can receive the alarm, the order system can receive the alarm, other systems can receive the alarm, and a system administrator follows up to process the abnormity. In this embodiment, the number of the tasks to be pushed is obtained and counted, so that the number of the tasks to be pushed, which are received abnormally by the receiving party, can be known. In addition, an alarm is sent, so that abnormity can be timely processed, and the service pushing efficiency is improved.
Fig. 3 is a schematic block diagram of a message pushing apparatus 300 according to an embodiment of the present application, as shown in fig. 3, including:
the type obtaining module 301 is configured to obtain a current service type of the current message, and further configured to determine a sub-level service type of the current service type according to a preset service type dependency relationship when a push task of the current message is abnormal.
The message intercepting module 302 is configured to create a push task of a sub-level service type as a to-be-pushed task in a blocking state.
The monitoring module 303 is configured to determine that the push task of the current message is recovered to be normal after the successful callback event from the receiving party is acquired.
And the query module 304 is configured to query whether the sub-level service type has a task to be pushed.
The activation module 305 is configured to, when a sub-level service type has a to-be-pushed task, change the to-be-pushed task from a blocking state to an activation state, re-execute the push task of the sub-level service type, and delete the to-be-pushed task.
Further, the type obtaining module 301 is further configured to obtain a parent service type of the current service type according to a preset service type dependency relationship.
The query module 304 is further configured to query whether a service success log of the push task exists in the parent service type.
In another embodiment of the present application, the message pushing apparatus 300 further includes:
the push service module 306 is configured to execute the push task of the current message when the service success log of the push task exists in the parent service type.
In another embodiment of the present application, the message pushing apparatus 300 further includes:
the counting module 307 is configured to obtain the number of tasks to be pushed of all the service types.
And an alarm module 308 for sending an alarm when the number reaches a preset threshold.
It should be noted that the message pushing apparatus 300 is an apparatus corresponding to the above-mentioned method applied to message pushing, and all the implementation manners in the above-mentioned method embodiments are applicable to the embodiment of the apparatus, and the same technical effect can be achieved.
The embodiment of the present application further provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, the method applied to message pushing is implemented.
The embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored, and when the computer program is executed by a processor, the computer program is implemented by applying the foregoing method for pushing a message.
The above embodiments are only used to illustrate the technical solutions of the present application, and not to limit the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not depart from the spirit and scope of the embodiments of the present application, and they should be construed as being included in the present application.

Claims (10)

1. A message pushing method is characterized by comprising the following steps:
acquiring the current service type of the current message;
if the push task of the current message is abnormal, determining a sub-level service type of the current service type according to a preset service type dependency relationship;
establishing the pushing task of the sub-level service type as a to-be-pushed task in a blocking state;
the service type dependency relationship comprises a sub-level service type and a parent-level service type of each preset service type of the message.
2. The method of claim 1, wherein after creating the push task of the sub-level traffic type as the to-be-pushed task in a blocked state, further comprising:
when a successful callback event from a receiver is acquired, determining that the push task of the current message is recovered to be normal;
inquiring whether the sub-level service type has the task to be pushed or not;
if yes, changing the to-be-pushed task from a blocking state to an activation state, re-executing the pushing task of the sub-level service type, and deleting the to-be-pushed task.
3. The method of claim 1, wherein after obtaining the current service type of the current message, further comprising:
acquiring a parent service type of the current service type according to a preset service type dependency relationship;
inquiring whether the service success log of the pushing task exists in the parent service type or not;
if yes, executing the pushing task of the current message;
if not, the current service type is established as a task to be pushed in a blocking state.
4. The method of claim 2, wherein after acquiring the successful callback event from the recipient, further comprising:
and creating a service success log of the pushing task for the current service type.
5. The method of claim 1, wherein after creating the push task of the sub-level traffic type as the to-be-pushed task in a blocked state, further comprising:
acquiring the number of the tasks to be pushed of all the service types;
and if the number reaches a preset threshold value, sending an alarm.
6. A message push apparatus, comprising:
the type acquisition module is used for acquiring the current service type of the current message;
the type obtaining module is further configured to determine a sub-level service type of the current service type according to a preset service type dependency relationship when a push task of the current message is abnormal;
the message interception module is used for establishing the pushing task of the sub-level service type as a to-be-pushed task in a blocking state;
the monitoring module is used for determining that the push task of the current message is recovered to be normal after the successful callback event from the receiver is acquired;
the query module is used for querying whether the sub-level service type has the task to be pushed or not;
the activation module is used for changing the to-be-pushed task from a blocking state to an activation state when the to-be-pushed task exists in a sub-level service type, re-executing the pushing task of the sub-level service type and deleting the to-be-pushed task;
the service type dependency relationship comprises a sub-level service type and a parent-level service type of each preset service type of the message.
7. The apparatus of claim 6, wherein the apparatus further comprises:
the type obtaining module is further configured to obtain a parent service type of the current service type according to a preset service type dependency relationship;
the query module is further configured to query whether a service success log of a push task exists in the parent service type;
and the push service module is used for executing the push task of the current message when the service success log of the push task exists in the parent service type.
8. The apparatus of claim 6, wherein the apparatus further comprises:
the counting module is used for acquiring the number of the tasks to be pushed of all the service types;
and the alarm module is used for sending an alarm when the number reaches a preset threshold value.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method of any of claims 1 to 5 when executing the computer program.
10. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1 to 5.
CN202210784912.7A 2022-07-05 2022-07-05 Message pushing method and device, electronic equipment and storage medium Pending CN115314458A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210784912.7A CN115314458A (en) 2022-07-05 2022-07-05 Message pushing method and device, electronic equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210784912.7A CN115314458A (en) 2022-07-05 2022-07-05 Message pushing method and device, electronic equipment and storage medium

Publications (1)

Publication Number Publication Date
CN115314458A true CN115314458A (en) 2022-11-08

Family

ID=83856146

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210784912.7A Pending CN115314458A (en) 2022-07-05 2022-07-05 Message pushing method and device, electronic equipment and storage medium

Country Status (1)

Country Link
CN (1) CN115314458A (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1921368A (en) * 2005-08-25 2007-02-28 松下电器产业株式会社 Multiple-layer automatic repeating transmission request with high speed and high reliability in broad band wireless communication system
CN103368689A (en) * 2013-06-18 2013-10-23 曙光信息产业股份有限公司 Data transmission method and system
WO2017044041A1 (en) * 2015-09-09 2017-03-16 ZingMobile Pte Ltd Method and device for delivering alert messages
CN112988407A (en) * 2019-12-16 2021-06-18 浙江宇视科技有限公司 Data processing method and device, electronic equipment and computer readable storage medium

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1921368A (en) * 2005-08-25 2007-02-28 松下电器产业株式会社 Multiple-layer automatic repeating transmission request with high speed and high reliability in broad band wireless communication system
CN103368689A (en) * 2013-06-18 2013-10-23 曙光信息产业股份有限公司 Data transmission method and system
WO2017044041A1 (en) * 2015-09-09 2017-03-16 ZingMobile Pte Ltd Method and device for delivering alert messages
CN112988407A (en) * 2019-12-16 2021-06-18 浙江宇视科技有限公司 Data processing method and device, electronic equipment and computer readable storage medium

Similar Documents

Publication Publication Date Title
CN110661659B (en) Alarm method, device and system and electronic equipment
US9495229B2 (en) Methods, apparatus and computer programs for managing persistence
CN109815291B (en) Data synchronization method and device, electronic equipment and storage medium
CN111897825A (en) Distributed transaction processing method and device
CN111585913B (en) Service flow limiting method based on recovery token and storage medium
CN112527879A (en) Kafka-based real-time data extraction method and related equipment
CN108509322B (en) Method for avoiding excessive return visit, electronic device and computer readable storage medium
CN112463318A (en) Timed task processing method, device and system
CN110941622A (en) Data processing method and device
CN115314458A (en) Message pushing method and device, electronic equipment and storage medium
CN111367934A (en) Data consistency checking method, device, server and medium
US11811894B2 (en) Reduction of data transmissions based on end-user context
CN112751743A (en) Message sending exception processing method, message sending device and electronic equipment
CN108037950B (en) Information deleting method and device, electronic equipment and readable storage medium
CN115033927A (en) Method, device, equipment and medium for detecting data integrity
CN115391059A (en) Data playback method and device, computer equipment and computer readable storage medium
CN113177052A (en) Method and device for processing service data consistency of distributed system
CN112860746A (en) Cache reduction-based method, equipment and system
CN113098978A (en) Data transmission method, device and medium
CN112053150A (en) Data processing method, device and storage medium
US11601449B2 (en) Event evaluation pipeline for alert engine
CN113961639A (en) Distributed transaction processing method, terminal and computer readable storage medium
CN111917572B (en) Transaction request processing method and device, electronic equipment and readable storage medium
CN115271501A (en) Order processing method and device, storage medium and electronic equipment
US20220206919A1 (en) Self-adaptive circuit breakers for applications that include execution location markers

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