CN113595870A

CN113595870A - Push message processing method and device, electronic equipment and storage medium

Info

Publication number: CN113595870A
Application number: CN202110729939.1A
Authority: CN
Inventors: 迟文
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2021-06-29
Filing date: 2021-06-29
Publication date: 2021-11-02
Anticipated expiration: 2041-06-29
Also published as: CN113595870B

Abstract

The disclosure discloses a processing method and device of push messages, electronic equipment and a storage medium, and relates to the field of computers, in particular to the field of information flow. The specific implementation scheme is as follows: acquiring a first event registration request associated with a push message, wherein the first event registration request comprises a first event processing result, a processor identifier and the push message identifier; under the condition that the processing result of the first event is failure, generating a push feedback message according to the identifier of the processing party; and returning a push feedback message to the service end associated with the push message identifier. The method and the device realize the monitoring of the message pushing process by acquiring the event processing result in the message pushing process, generating the corresponding pushing feedback message and returning the pushing feedback message to the service end under the condition that the event processing result is failed.

Description

Push message processing method and device, electronic equipment and storage medium

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to the field of information flow technologies, and in particular, to a method and an apparatus for processing a push message, an electronic device, and a storage medium.

Background

With the explosion of internet communication, message push has gradually replaced short message reminding, and becomes a main way for application developers to send messages to users. When an application developer pushes a message, the message is usually sent to a client through a server of a device manufacturer. However, due to some special restrictions of the device vendor service, the influence of service stability and network factors, the client does not necessarily receive the message. Therefore, the method and the device have important significance for reliably monitoring the arrival condition of the push message.

Disclosure of Invention

The disclosure provides a processing method and device of a push message, electronic equipment and a storage medium.

According to a first aspect of the present disclosure, a method for processing a push message is provided, including:

acquiring a first event registration request associated with a push message, wherein the first event registration request comprises a first event processing result, a processor identifier and the push message identifier;

generating a push feedback message according to the identifier of the processing party under the condition that the processing result of the first event is failure;

and returning the push feedback message to the service end associated with the push message identifier.

According to a second aspect of the present disclosure, a push message processing method is provided, including:

acquiring a message pushing request, wherein the message pushing request comprises a client identification and a message to be pushed;

pushing the message to be pushed to a corresponding client according to the client identification, and generating a correlated event registration request;

and sending the event registration request to a message pushing monitoring end.

According to a third aspect of the present disclosure, there is provided a push message processing apparatus, including:

a first obtaining module, configured to obtain a first event registration request associated with a push message, where the first event registration request includes a first event processing result, a handler identifier, and the push message identifier;

the generating module is used for generating a push feedback message according to the identifier of the processing party under the condition that the processing result of the first event is failure;

and the sending module is used for returning the push feedback message to the service end associated with the push message identifier.

According to a fourth aspect of the present disclosure, there is provided a push message processing apparatus, including:

the system comprises an acquisition module, a sending module and a receiving module, wherein the acquisition module is used for acquiring a message pushing request, and the message pushing request comprises a client identifier and a message to be pushed;

the generation module is used for pushing the message to be pushed to the corresponding client according to the client identification and generating a correlated event registration request;

and the sending module is used for sending the event registration request to a message pushing monitoring end.

According to a fifth aspect of the present disclosure, there is provided an electronic device comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of the first aspect and/or the second aspect.

According to a sixth aspect of the present disclosure, there is provided a non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method of the first and/or second aspect.

According to a seventh aspect of the present disclosure, there is provided a computer program product comprising a computer program which, when executed by a processor, implements the method of the first and/or second aspect.

The processing method, the processing device, the electronic device and the storage medium for the push message have the following beneficial effects:

the method comprises the steps of firstly obtaining a first event registration request associated with a push message, generating a push feedback message under the condition that a first event processing result is failure, and returning the push feedback message to a service end associated with the push message so that the service end can know the push condition of the message. Therefore, reliable monitoring of message pushing is achieved.

It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present disclosure, nor do they limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

The drawings are included to provide a better understanding of the present solution and are not to be construed as limiting the present disclosure. Wherein:

fig. 1 is a flowchart illustrating a push message processing method according to an embodiment of the present disclosure;

fig. 2 is a flowchart illustrating a push message processing method according to another embodiment of the disclosure;

fig. 3 is a schematic structural diagram of a push message processing apparatus according to an embodiment of the present disclosure;

fig. 4 is a schematic structural diagram of a push message processing apparatus according to yet another embodiment of the present disclosure;

fig. 5 is a flowchart illustrating a push message processing method according to an embodiment of the disclosure;

fig. 6 is a flowchart illustrating a push message processing method according to another embodiment of the disclosure;

fig. 7 is a flowchart illustrating a push message processing method according to another embodiment of the disclosure;

fig. 8 is a flowchart illustrating a push message processing method according to another embodiment of the disclosure;

fig. 9 is a schematic structural diagram of a push message processing apparatus according to an embodiment of the present disclosure;

fig. 10 is a schematic structural diagram of a push message processing apparatus according to yet another embodiment of the present disclosure;

fig. 11 is a block diagram of an electronic device for implementing a push message processing method according to an embodiment of the present disclosure.

Detailed Description

Exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which various details of the embodiments of the disclosure are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

Currently, message pushing and short message reminding are two main means for an application developer to reach a message to a user. The communication cost of short message reminding is high, and hyperlink skipping of short messages often has various problems, so that a user cannot open an application through multilayer skipping, or even if the application is opened, the user needs to search for a landing page which actually generates interaction. Therefore, the short message reminding is often only applied to the reminding of the important message.

Message push is the touching of messages to users via the internet, which is commonly used for ordinary instant messaging messages or messages for marketing purposes. When an application developer pushes a message, the message is usually sent to a client through a server of a device manufacturer. However, due to some special restrictions of the device vendor service, the influence of service stability and network factors, the client does not necessarily receive the message. Therefore, the method and the device have important significance for reliably monitoring the arrival condition of the push message.

The following describes a push message processing method, apparatus, electronic device, and storage medium according to the present disclosure with reference to the drawings.

Fig. 1 is a flowchart illustrating a method for processing a push message according to a first embodiment of the present disclosure, where the method may be executed by a device for processing a push message provided by the present disclosure, and may also be executed by an electronic device provided by the present disclosure, where the electronic device may include, but is not limited to, a terminal device such as a desktop computer, a tablet computer, and the like, and may also be a server. The present disclosure is explained below by taking as an example a push message processing apparatus provided by the present disclosure, a push message processing method performed by the present disclosure.

As shown in fig. 1, the method for processing a push message may include the following steps:

step 101, a first event registration request associated with a push message is obtained, where the first event registration request includes a first event processing result, a processing party identifier, and a push message identifier.

The push message may be any type of message transmitted over the internet. Such as instant messaging messages, application marketing messages, and the like.

It should be noted that the push message may reach the corresponding client through the message push service, and the message push service may complete the message push through multiple hierarchical services.

For example, the message push service may examine, at a logic layer, whether a push message request sent by a service end is reasonable and legitimate.

Or, the message push service may receive a plurality of message push requests sent by a plurality of service terminals, and the plurality of message push requests may be respectively directed to different clients. Therefore, the message push service can search the distribution layer for the device addresses of the clients respectively corresponding to the plurality of message push requests.

Alternatively, since the client may return a message arrival receipt to the message push service when receiving the push message. Therefore, after the message pushing service finishes message pushing to the client, the message pushing service can determine the message arrival condition according to whether the receipt of the client is received.

Correspondingly, the message push service can generate corresponding event registration requests for different level services in the process of pushing messages, and record event processing results, processing party identifiers and push message identifiers in the event registration requests.

For example, the message push service may generate a message audit event registration request according to an audit result of the logic layer on the message push request.

The message inspection event registration request may include a message inspection result, a message inspection identifier, and a push message identifier. The message examination result can be success or failure, and the push message identification can be any type of identification associated with the push message.

Or, the message push service may generate a message distribution event registration request according to a distribution result of the distribution layer to the message push request.

The message distribution event registration request may include a message distribution result, a message distribution identifier, and a push message identifier. The message distribution result may be success or failure, and the push message identifier may be any type of identifier associated with the push message.

Alternatively, the message push service may generate a push receipt event registration request based on whether a message arrival receipt is received.

The push receipt event registration request may include a receipt feedback result, a handler identifier, and a push message identifier. The response piece feedback result may be received or not received, and the push message identifier may be any type of identifier associated with the push message.

In the embodiment of the present disclosure, after the message push service generates the first event registration request, the message push service may send the event registration request to the push service monitoring end. Therefore, the push service monitoring end can obtain the event processing result of the push message.

It should be noted that the above example is only an example, and cannot be taken as a limitation on the first event registration request in the embodiment of the present disclosure.

And 102, generating a push feedback message according to the identifier of the processing party under the condition that the processing result of the first event is failure.

For example, the first event registration request is a message inspection event registration request. The generated push feedback message may be a message inspection failure in case that the message inspection result is a failure.

Alternatively, the first event registration request is a message distribution event registration request. The generated push feedback message may be a message distribution failure in case that the message distribution result is a failure.

Alternatively, the first event registration request is a push receipt event registration request. The generated push feedback message may be a message reception failure in case no message arrival receipt is received.

It can be appreciated that in some real-time communication scenarios, it is important to ensure the timeliness of message arrival. For example, for business marketing of potential customers, determination of customer transaction information, and the like, if it cannot be guaranteed that the push message of the service end reaches the client in time, the transaction may fail.

In a possible implementation manner of the present disclosure, the first event registration request is a push receipt registration request, the first event registration request further includes a push request initiation time and a push message arrival time, and a push feedback message is generated when a difference between the push message arrival time and the push request initiation time is greater than a threshold.

For example, the initiation time of the push request in the first event registration request is 10 hours, 23 minutes and 11 seconds, the arrival time of the push message is 10 hours, 24 minutes and 11 seconds, and the set message push duration threshold is 5 seconds, because the push duration of the message is greater than the threshold, the client may still generate the push feedback message, which may be a message reception delay, although receiving the push message and sending a message arrival receipt.

In the embodiment of the disclosure, whether the touch of the push message is delayed is judged by calculating the actual time length of the message push and setting the threshold value of the message push time length; and generating a push feedback message to inform the service end of message receiving delay under the condition of message triggering delay. Therefore, the timeliness of the push message is monitored, and support and basis are provided for reprocessing of the push message by the service end.

It should be noted that the foregoing examples are merely illustrative, and should not be taken as limitations on push feedback messages in the embodiments of the present disclosure.

And 103, returning a push feedback message to the service end associated with the push message identifier.

It should be noted that, in the process of pushing a message, there may be different reasons that cause a message pushing failure. Therefore, when the service end initiates a message push request, the corresponding service end identifier can be added to the push message. Therefore, the associated service end can be determined according to the push message identifier, a message push result is fed back to the corresponding service end, and the service end takes corresponding measures according to the message push result.

For example, if the message fed back to the service end is a message inspection failure, the service end may resend the push message after adjusting the format, content, and the like of the push message, so that the push message conforms to the message inspection rule. Therefore, the blind message retransmission of the service end is avoided, the pushing service resource is wasted, and the pushing purpose cannot be realized.

Or, the message fed back to the service end may be a message distribution failure, and the service end may first verify whether the client side of the message push is registered or whether there is an error, and re-initiate the message push request under the condition that it is ensured that the corresponding client side is registered or there is no error, thereby avoiding invalid push of the message caused by an error at the client side.

Or, the message fed back to the service end may be a message reception failure, and the service end may confirm that the message push service is normal, so that the reason for the message reception failure may be that the client is not powered on or is not networked. At this time, the service end may choose to give up the push message, delay the push message, or send the message in a short message manner, etc.

The method for processing the push message according to the embodiment of the present disclosure generates a corresponding push feedback message by obtaining event processing results of different levels in a message pushing process, and when the event processing results are failure, returns the push feedback message to the service end. Therefore, the monitoring of the message pushing process is realized, and the service end is enabled to clarify the reason of the message pushing failure. Furthermore, the service end can take corresponding measures according to different reasons so as to avoid invalid pushing of the message and improve the arrival rate of the pushed message.

Fig. 2 is a flowchart illustrating a method for processing a push message according to another embodiment of the disclosure. As shown in fig. 2, the method for processing a push message may include the following steps:

step 201, a first event registration request associated with a push message is obtained, where the first event registration request includes a first event processing result, a processing party identifier, and a push message identifier.

It should be noted that, for the specific implementation manner of the step 201, reference may be made to the detailed description of other embodiments of the present disclosure, and details are not described herein again.

It is to be understood that the push message may be a plurality of push messages sent by a plurality of service terminals. Event registration requests for each push message need to be maintained and processed in memory.

In one possible implementation of the present disclosure, the event registration request may be stored using a non-relational database (No SQL). In order to ensure reliable storage of highly concurrent event registration requests, the database may be fragmented according to the service type, that is, the database is divided into a plurality of registration information storage sub-regions. And then according to the push message identifications associated with different service parties, putting the event registration request into the corresponding registration information storage subarea.

Furthermore, in order to avoid a failure of a certain registration information storage sub-region of the database, which results in loss of the event registration request managed by the registration information storage sub-region, more than one standby registration information storage sub-regions may be provided. When a certain registration information storage sub-region has a fault, the spare registration information storage sub-region can quickly replace the fault storage sub-region through a lock grabbing mode, and corresponding event registration requests are continuously managed.

In the embodiment of the disclosure, the registration information storage sub-region is allocated to the event registration request associated with different push message identifiers, so that reliable storage of high-concurrency event registration requests is ensured, and loss of event registration request data is avoided.

Step 202, under the condition that the processing result of the first event is successful, acquiring a second event registration request according to the push message identifier.

It is understood that, during the process of pushing the message, there is a possibility that the registration event of each tier service will be successful or failed, and each tier service will send its processing result to the pushing message processing device through the event registration request. That is, the push message processing device may obtain a plurality of event registration requests associated with the push message identifier, and after obtaining an event registration request each time, the push message processing device may generate a temporary push feedback message corresponding to the push message identifier according to the event registration request.

If the temporary push feedback message is failed, it indicates that the push message is not processed by the services of other levels, so that the failed temporary push feedback message can be sent to the service party associated with the message identifier.

If the temporary push feedback message is successful, it indicates that the push message may be continuously processed by services of other levels, so that the push message processing device may query whether the second event registration request associated with the obtained push message identifier is stored, and may determine the current temporary feedback message according to each event registration request associated with each obtained push message identifier.

For example, if the first event registration request is a message distribution event registration request. And acquiring a second event registration request sent by the examination service layer according to the push message identifier under the condition that the message distribution result is successful.

It should be noted that the above examples are only illustrative, and cannot be taken as a limitation on the first event registration request and the second event registration request in the embodiments of the present disclosure.

And step 203, updating the feedback message corresponding to the push message identifier according to the processing result of the second event and the processing result of the first event.

In the embodiment of the disclosure, a feedback message corresponding to the push message identifier may be generated according to the message push process. The feedback message can be updated according to the latest event processing result in the message pushing process to determine success or failure of each level of service in the message pushing process, and further determine the final result of message pushing.

For example, the first event is a message distribution event, and the second event is a message inspection event. When the processing result of the message distribution event is that the distribution is successful, the feedback message corresponding to the push message identifier can be updated to be successful in message distribution from successful message examination. When the processing result of the message distribution event is a distribution failure, the feedback message corresponding to the push message identifier may be updated to be a message distribution failure from the message audit success.

Or the first event is a push receipt event, and the second event is a message distribution event. When the processing result of the push receipt event is that the received message reaches the receipt, the feedback message corresponding to the push message identifier can be updated from message distribution success to message reception success. When the processing result of the push receipt event is that no message is received and the receipt is received, the feedback message corresponding to the push message identifier can be updated from message distribution success to message reception failure.

It should be noted that the above examples are only for illustration and are not intended to be limiting on the first event processing result, the second event processing result, and the feedback message in the embodiments of the present disclosure.

And step 204, returning a push feedback message to the service end associated with the push message identifier.

It can be understood that in actual service, the service end only needs to determine the message of the push failure, and then takes measures to reprocess the message. Therefore, in the embodiment of the present disclosure, the push feedback message is returned to the service end associated with the push message identifier, and may be only a feedback message with a failed push, such as a message inspection failure, a message distribution failure, or a message reception failure.

The specific implementation manner of returning the push feedback message to the service end associated with the push message identifier may refer to the detailed description of other embodiments of the present disclosure, and is not described herein again.

It should be noted that different service ends may have different requirements for the arrival rate of the message pushing. For example, for daily chat-like applications, the requirements of the client on timeliness and arrival rate of the push message are not high. Therefore, the service end does not need to monitor the arrival condition of the push message in real time. For applications related to business transactions, if it cannot be guaranteed that the push message of the service end reaches the client in time, the transaction may fail. Therefore, the service end needs to monitor the arrival condition of the push message in real time.

In a possible implementation manner of the present disclosure, a push feedback message is returned to a service end associated with a push message identifier, and the push feedback message and the push message identifier may be placed in a push failure message queue. Different service terminals can select how to subscribe to the feedback message in the push failure message queue according to actual service needs.

For example, for an application of a daily chat type, the feedback message in the push failure message queue may be obtained periodically to perform push service effect monitoring or offline data analysis.

Or, for the application of the business transaction type, the feedback message in the push failure message queue can be selected to be received in real time, and the push failure message can reach the user in other ways.

In the embodiment of the disclosure, the push feedback message and the push message identifier are placed in the push failure message queue, so that the possibility is provided for different service terminals to select and subscribe the push feedback message according to actual needs, and the coupling degree between the service terminal and the message push monitoring terminal is reduced.

According to the push message processing method, the success or failure of each level service is determined by recording the event processing result of each level service in the message pushing process. And then updating the feedback message corresponding to the push message identifier according to the latest event processing result, and further determining the final result of message push. Therefore, monitoring of the message pushing process and the message pushing result is achieved. Meanwhile, for the message with the failed push, the service end can take corresponding measures according to different reasons by providing the reasons for the message push failure for the service end, so that the invalid push of the message is avoided, and the arrival rate of the push message is improved.

According to the embodiment of the disclosure, the disclosure further provides a device for processing the push message.

Fig. 3 is a schematic structural diagram of a device for processing a push message according to an embodiment of the present disclosure. As shown in fig. 3, the push message processing apparatus 300 may include: a first obtaining module 310, a generating module 320 and a sending module 330.

The first obtaining module 310 is configured to obtain a first event registration request associated with a push message, where the first event registration request includes a first event processing result, a processing party identifier, and a push message identifier.

The generating module 320 is configured to generate a push feedback message according to the identifier of the processing party when the processing result of the first event is failure.

The sending module 330 is configured to return a push feedback message to the service end associated with the push message identifier.

In one possible implementation manner of the present disclosure, the first event registration request acquired by the first acquiring module 310 may be a message audit event registration request, a message distribution event registration request, or a push receipt event registration request.

In a possible implementation manner of the present disclosure, the first event registration request is a push receipt registration request, the first event registration request further includes a push request initiation time and a push message arrival time, and the generating module 320 is further configured to generate a push feedback message according to the identifier of the processing party when a difference between the push message arrival time and the push request initiation time is greater than a threshold.

In a possible implementation manner of the present disclosure, the sending module 330 is further configured to place the push feedback message and the push message identifier into a push failure message queue.

The functions and specific implementation principles of the modules in the embodiments of the present disclosure may refer to the embodiments of the methods, and are not described herein again.

The processing device for the push message of the embodiment of the disclosure generates a corresponding push feedback message and returns the push feedback message to the service end by acquiring event processing results of different levels in the message pushing process and under the condition that the event processing results are failed. Therefore, the monitoring of the message pushing process is realized, and the service end is enabled to clarify the reason of the message pushing failure. Furthermore, the service end can take corresponding measures according to different reasons so as to avoid invalid pushing of the message and improve the arrival rate of the pushed message.

In a possible implementation manner of the embodiment of the present disclosure, as shown in fig. 4, the apparatus 400 for processing a push message may include: the device comprises a first acquisition module 410, a generation module 420, a sending module 430, a second acquisition module 440, an updating module 450 and a storage module 460.

The second obtaining module 440 is configured to, when the first event processing result is successful, obtain the second event registration request according to the push message identifier.

The updating module 450 is configured to update the push feedback message corresponding to the push message identifier according to the processing result of the second event registration request and the processing result of the first registration event.

The storage module 460 is configured to place the first event registration request and the second event registration request into corresponding registration information storage sub-areas according to the push message identifier.

It is understood that the message processing apparatus 400 in the embodiment of the present disclosure and the message processing apparatus 300 in the above embodiment, the first obtaining module 410 and the first obtaining module 310 in the above embodiment, the generating module 420 and the generating module 320 in the above embodiment, and the sending module 430 and the sending module 330 in the above embodiment may have the same functions and structures.

The processing device for the push message of the embodiment of the disclosure firstly determines the success or failure of each level service by recording the event processing result of each level service in the message push process. And then updating the feedback message corresponding to the push message identifier according to the latest event processing result, and further determining the final result of message push. Therefore, monitoring of the message pushing process and the message pushing result is achieved. Meanwhile, for the message with the failed push, the service end can take corresponding measures according to different reasons by providing the reasons for the message push failure for the service end, so that the invalid push of the message is avoided, and the arrival rate of the push message is improved.

Fig. 5 is a flowchart illustrating a method for processing a push message according to an embodiment of the disclosure. As shown in fig. 5, the method for processing a push message may include the following steps:

step 501, a message pushing request is obtained, wherein the message pushing request includes a client identifier and a message to be pushed.

As will be appreciated from the description of other embodiments of the present disclosure, the push message may be any type of message transmitted over the internet. Such as instant messaging messages, application marketing messages, and the like.

The message pushing service acquires the message pushing request and sends the message to be pushed to the corresponding client according to the client identifier in the message pushing request.

Step 502, pushing a message to be pushed to a corresponding client according to the client identifier, and generating an associated event registration request.

As will be understood from the description of other embodiments of the present disclosure, the message push service may complete message push through multiple hierarchical services. Such as message review, message distribution, and push receipt, etc. Furthermore, in the process of pushing the message, the message pushing service may generate corresponding event registration requests for different tier services, and record an event processing result, a processing party identifier, and a pushing message identifier in the event registration requests.

For a specific implementation of the above process, reference may be made to the detailed description of other embodiments of the present disclosure, which is not repeated herein.

Step 503, sending the event registration request to the message pushing monitoring end.

As can be known from the description of other embodiments of the present disclosure, the event registration request in the message pushing process may include a message audit event registration request, a message distribution event registration request, a push receipt event registration request, and the like.

The message pushing service sends the generated event registration request to the message pushing monitoring end, so that the monitoring end can determine the processing result of each event in the message pushing process, and further the message pushing is monitored.

According to the method for processing the push message, the associated event registration request is generated in the process of pushing the message to the client, and the event registration request is sent to the message push monitoring end, so that message push monitoring is achieved.

Fig. 6 is a flowchart illustrating a method for processing a push message according to another embodiment of the disclosure. As shown in fig. 6, on the basis of the embodiment shown in fig. 5, in step 502, generating an associated event registration request may include the following steps:

step 601, based on the message examination rule, examining the message to be pushed to determine a message examination result.

The message examination rule may be an examination rule for the content, format, etc. of the push message to determine whether the push message is reasonable, legal, etc.

Accordingly, the message examination result may be the success or failure of the examination, or the pass or fail of the examination.

It should be noted that the above examples are only illustrative, and should not be taken as limitations on the message inspection rule and the message inspection result of the embodiments of the present disclosure.

Step 602, based on the message examination result, generating an examination event registration request associated with the push message.

In the embodiment of the disclosure, a message examination result in a message pushing process is determined first, and then an examination event registration request associated with a pushed message is generated based on the message examination result. Therefore, the monitoring of the message examination stage is realized, and a basis is provided for determining the reason of the message pushing failure.

It should be noted that, when the message examination result is failure, the message pushing process ends here. And when the message examination result is successful, the next link of message pushing needs to be continued. Fig. 7 is a flowchart illustrating a method for processing a push message according to another embodiment of the disclosure. As shown in fig. 7, generating the associated event registration request based on the embodiment shown in fig. 6 may include the following steps:

step 701, based on the message examination rule, examining the message to be pushed to determine a message examination result.

Step 702, based on the message examination result, generating an examination event registration request associated with the push message.

The detailed implementation manner of the above steps 701-702 can refer to the detailed description of other embodiments of the present disclosure, and will not be described herein again.

Step 703, querying the mapping table between the client identifier and the device address to determine the target device address corresponding to the client identifier, and generating a message distribution result.

Because a plurality of push messages sent by the service end can respectively face different clients, each client can respectively correspond to a terminal device with a specific address. Therefore, in the embodiment of the present disclosure, different one-to-one correspondence relationships between the client and the device address may be recorded through the client identifier and the device address mapping table.

Correspondingly, the message distribution result may be that the distribution is successful when the device address corresponding to the client can be queried, and the message distribution result may be that the distribution is failed when the device address corresponding to the client cannot be queried.

It should be noted that the above examples are only illustrative, and should not be taken as a limitation on the client identifier and device address mapping table and the message distribution result in the embodiment of the present disclosure.

Step 704, according to the message distribution result, generating a distribution event registration request associated with the push message.

In the embodiment of the disclosure, by determining the message inspection result and the message distribution result in the message pushing process and generating the inspection event registration request and the distribution event registration request associated with the pushed message, the monitoring of the message inspection stage and the message distribution stage is realized, and a basis is provided for determining the reason of the message pushing failure.

It should be noted that, when the message distribution result is failure, the message pushing flow ends here. And when the message distribution result is successful, the next link of message pushing needs to be continued. Fig. 8 is a flowchart illustrating a method for processing a push message according to another embodiment of the disclosure. As shown in fig. 8, generating the associated event registration request based on the embodiment shown in fig. 7 may include the following steps:

step 801, examining the message to be pushed based on the message examination rule to determine a message examination result.

Step 802, based on the message examination result, generating an examination event registration request associated with the push message.

Step 803, query the mapping table between the client identifier and the device address to determine the target device address corresponding to the client identifier, and generate a message distribution result.

Step 804, according to the message distribution result, a distribution event registration request associated with the push message is generated.

The detailed implementation manner of

steps

801 and 804 may refer to the detailed description of other embodiments of the present disclosure, and will not be described herein again.

Step 805, query the message pushing and message arrival receipt relation table to determine the arrival condition of the message to be pushed, and generate the message pushing result.

Since the client can return a message arrival receipt to the message push service when receiving the push message. Therefore, in the embodiment of the present disclosure, a one-to-one correspondence relationship between a pushed message and an arrival receipt, which is different from a message arrival receipt relationship table, may be recorded through message pushing.

Correspondingly, the message pushing result can be successful pushing under the condition that the message arrival receipt can be inquired, and the message pushing result can be failed pushing under the condition that the message arrival receipt cannot be inquired.

It should be noted that the above examples are only illustrative, and are not intended to be a limitation on the message push and message arrival receipt relation table and the message push result of the embodiment of the present disclosure.

Step 806, according to the message pushing result, generating a pushing event registration request associated with the pushing message.

The push event registration request may include a message push result, a handler identifier, and a push message identifier. The message pushing result may be success or failure, and the push message identifier may be any type of identifier associated with the push message.

The processing method for the push message of the embodiment of the disclosure determines success or failure of each level service by recording the processing results of message examination, message distribution and message push in the message push process. Therefore, the message pushing process and the message pushing result are monitored, and a basis is provided for determining the reason of the message pushing failure.

Fig. 9 is a schematic structural diagram of a device for processing a push message according to an embodiment of the present disclosure. As shown in fig. 9, the apparatus 900 for processing a push message may include: an obtaining module 910, a generating module 920 and a sending module 930.

The obtaining module 910 is configured to obtain a message pushing request, where the message pushing request includes a client identifier and a message to be pushed.

A generating module 920, configured to push a message to be pushed to a corresponding client according to the client identifier,

and generates an associated event registration request.

A sending module 930, configured to send the event registration request to the message pushing monitoring end.

The processing device for pushing messages in the embodiment of the disclosure generates the associated event registration request in the process of pushing messages to the client, and sends the event registration request to the message pushing monitoring end, thereby realizing the monitoring of message pushing.

In a possible implementation manner of the embodiment of the present disclosure, as shown in fig. 10, the apparatus 1000 for processing a push message may include: an obtaining module 1010, a generating module 1020 and a sending module 1030.

The generating module 1020 may include: a first determination unit 1021, a first generation unit 1022, a second determination unit 1023, a second generation unit 1024, a third determination unit 1025, a third generation unit 1026.

The first determining unit 1021 is configured to perform examination on the to-be-pushed message based on the message examination rule, so as to determine a message examination result.

A first generating unit 1022, configured to generate a review event registration request associated with the push message based on the message review result.

The second determining unit 1023 is configured to query the client identifier and device address mapping table to determine a target device address corresponding to the client identifier, and generate a message distribution result.

The second generating unit 1024 is configured to generate a distribution event registration request associated with the push message according to the message distribution result.

And the third determining unit 1025 is used for querying the message pushing and message arrival receipt relation table to determine the arrival condition of the message to be pushed and generate a message pushing result.

A third generating unit 1026, configured to generate a push event registration request associated with the push message according to the message push result.

It is understood that the message processing apparatus 1000 in the embodiment of the present disclosure may have the same functions and structures as the message processing apparatus 900 in the embodiment, the obtaining module 1010 may have the same functions and structures as the obtaining module 910 in the embodiment, the generating module 1020 may have the same functions and structures as the generating module 920 in the embodiment, and the sending module 1030 may have the same structures as the sending module 930 in the embodiment.

The present disclosure also provides an electronic device, a readable storage medium, and a computer program product according to embodiments of the present disclosure.

FIG. 11 shows a schematic block diagram of an example electronic device 1100 that may be used to implement embodiments of the present disclosure. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the disclosure described and/or claimed herein.

As shown in fig. 11, the device 1100 comprises a computing unit 1101, which may perform various appropriate actions and processes according to a computer program stored in a Read Only Memory (ROM)1102 or a computer program loaded from a storage unit 1108 into a Random Access Memory (RAM) 1103. In the RAM 1103, various programs and data necessary for the operation of the device 1100 may also be stored. The calculation unit 1101, the ROM 1102, and the RAM 1103 are connected to each other by a bus 1104. An input/output (I/O) interface 1105 is also connected to bus 1104.

A number of components in device 1100 connect to I/O interface 1105, including: an input unit 1106 such as a keyboard, a mouse, and the like; an output unit 1107 such as various types of displays, speakers, and the like; a storage unit 1108 such as a magnetic disk, optical disk, or the like; and a communication unit 1109 such as a network card, a modem, a wireless communication transceiver, and the like. The communication unit 1109 allows the device 1100 to exchange information/data with other devices through a computer network such as the internet and/or various telecommunication networks.

The computing unit 1101 can be a variety of general purpose and/or special purpose processing components having processing and computing capabilities. Some examples of the computing unit 1101 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various dedicated Artificial Intelligence (AI) computing chips, various computing units running machine learning model algorithms, a Digital Signal Processor (DSP), and any suitable processor, controller, microcontroller, and the like. The computing unit 1101 performs the respective methods and processes described above, such as a push message processing method. For example, in some embodiments, the push message processing method may be implemented as a computer software program tangibly embodied in a machine-readable medium, such as the storage unit 1108. In some embodiments, part or all of the computer program may be loaded and/or installed onto device 1100 via ROM 1102 and/or communication unit 1109. When the computer program is loaded into RAM 1103 and executed by the computing unit 1101, one or more steps of the method of processing push messages described above may be performed. Alternatively, in other embodiments, the computing unit 1101 may be configured to perform the push message processing method by any other suitable means (e.g., by means of firmware).

Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuitry, Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs), system on a chip (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.

Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), Wide Area Networks (WANs), the internet, and blockchain networks.

The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The Server can be a cloud Server, also called a cloud computing Server or a cloud host, and is a host product in a cloud computing service system, so as to solve the defects of high management difficulty and weak service expansibility in the traditional physical host and VPS service ("Virtual Private Server", or simply "VPS"). The server may also be a server of a distributed system, or a server incorporating a blockchain.

According to the technical scheme, a first event registration request associated with the push message is obtained, a push feedback message is generated under the condition that the processing result of the first event is failure, and the push feedback message is returned to a service end associated with the push message, so that the service end can know the push condition of the message. Therefore, reliable monitoring of message pushing is achieved.

It should be understood that various forms of the flows shown above may be used, with steps reordered, added, or deleted. For example, the steps described in the present disclosure may be executed in parallel, sequentially, or in different orders, as long as the desired results of the technical solutions disclosed in the present disclosure can be achieved, and the present disclosure is not limited herein.

The above detailed description should not be construed as limiting the scope of the disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made in accordance with design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present disclosure should be included in the scope of protection of the present disclosure.

Claims

1. A push message processing method comprises the following steps:

2. The method of claim 1, wherein after the obtaining the first event registration request associated with the push message, further comprising:

under the condition that the first event processing result is successful, acquiring a second event registration request according to the push message identifier;

and updating the push feedback message corresponding to the push message identifier according to the processing result of the second event registration request and the processing result of the first registration event.

3. The method of claim 1, wherein the first event registration request comprises:

a message audit event registration request; alternatively, the first and second electrodes may be,

a message distribution event registration request; alternatively, the first and second electrodes may be,

push receipt event registration request.

4. The method of claim 3, wherein the first event registration request is a push receipt event registration request, the first event registration request further includes a push request initiation time and a push message arrival time, and after the obtaining of the first event registration request associated with the push message, the method further includes:

and generating a push feedback message according to the identifier of the processing party under the condition that the difference value between the arrival time of the push message and the initiation time of the push request is greater than a threshold value.

5. The method of any of claims 1-4, wherein the returning the push feedback message to the service side associated with the push message identifier comprises:

and putting the push feedback message and the push message identification into a push failure message queue.

6. The method of claim 5, wherein after the obtaining the first event registration request associated with the push message, further comprising:

and according to the push message identification, putting the first event registration request into a corresponding registration information storage subarea.

7. A push message processing method comprises the following steps:

and sending the event registration request to a message pushing monitoring end.

8. The method of claim 7, wherein the generating an associated event registration request comprises:

based on a message examination rule, examining the message to be pushed to determine a message examination result;

and generating an examination event registration request associated with the push message based on the message examination result.

9. The method of claim 8, wherein after the generating the push message associated audit event registration request, further comprising:

inquiring a mapping table of a client identifier and an equipment address to determine a target equipment address corresponding to the client identifier and generate a message distribution result;

and generating a distribution event registration request associated with the push message according to the message distribution result.

10. The method of claim 9, wherein after generating the push message associated distribution event registration request, further comprising:

inquiring a message pushing and message arrival receipt relation table to determine the arrival condition of the message to be pushed and generate a message pushing result;

and generating a push event registration request associated with the push message according to the message push result.

11. A push message processing apparatus, comprising:

12. The apparatus of claim 11, further comprising:

a second obtaining module, configured to obtain a second event registration request according to the push message identifier when the first event processing result is successful;

and the updating module is used for updating the push feedback message corresponding to the push message identifier according to the processing result of the second event registration request and the processing result of the first registration event.

13. The apparatus of claim 11, wherein the first event registration request comprises:

a message audit event registration request; or

push receipt event registration request.

14. The apparatus of claim 13, wherein the first event registration request is a push receipt event registration request, the first event registration request further includes a push request initiation time and a push message arrival time, and the generating module is further configured to:

15. The apparatus according to any one of claims 11-14, wherein the sending module is specifically configured to:

16. The apparatus of claim 15, further comprising:

and the storage module is used for placing the first event registration request into a corresponding registration information storage subarea according to the push message identifier.

17. A push message processing apparatus, comprising:

18. The apparatus of claim 17, wherein the generating means comprises:

the first determining unit is used for examining the message to be pushed based on a message examination rule so as to determine a message examination result;

and the first generating unit is used for generating an examination event registration request associated with the push message based on the message examination result.

19. The apparatus of claim 18, wherein the generating means further comprises:

the second determining unit is used for inquiring the mapping table of the client identifier and the equipment address so as to determine the target equipment address corresponding to the client identifier and generate a message distribution result;

and the second generating unit is used for generating a distribution event registration request associated with the push message according to the message distribution result.

20. The apparatus of claim 19, wherein the generating means further comprises:

a third determining unit, configured to query a message pushing and message arrival receipt relation table to determine an arrival condition of the message to be pushed, and generate a message pushing result;

and a third generating unit, configured to generate a push event registration request associated with the push message according to the message push result.

21. An electronic device, comprising:

at least one processor; and

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-10.

22. A non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method of any one of claims 1-10.

23. A computer program product comprising a computer program which, when executed by a processor, implements the method according to any one of claims 1-10.