CN114979250B - Message pushing method, device and equipment - Google Patents
Message pushing method, device and equipment Download PDFInfo
- Publication number
- CN114979250B CN114979250B CN202210404159.4A CN202210404159A CN114979250B CN 114979250 B CN114979250 B CN 114979250B CN 202210404159 A CN202210404159 A CN 202210404159A CN 114979250 B CN114979250 B CN 114979250B
- Authority
- CN
- China
- Prior art keywords
- message
- channel
- pushing
- push
- message body
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 60
- 230000005540 biological transmission Effects 0.000 claims description 49
- 230000000903 blocking effect Effects 0.000 claims description 22
- 230000003068 static effect Effects 0.000 claims description 13
- 238000012545 processing Methods 0.000 claims description 3
- 238000012360 testing method Methods 0.000 description 8
- 238000004422 calculation algorithm Methods 0.000 description 7
- 238000010586 diagram Methods 0.000 description 6
- 230000001360 synchronised effect Effects 0.000 description 4
- 238000012423 maintenance Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- 230000001934 delay Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000003032 molecular docking Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
The disclosure provides a message pushing method, device and equipment, wherein the method comprises the following steps: acquiring a message pushing request, and generating a message body containing a message to be pushed according to the message pushing request; according to the message type of the message body, the message body is routed to a corresponding intelligent dispatcher; and determining a pushing channel of the message body through the intelligent dispatcher, and pushing the message to be pushed through the pushing channel. The method and the device can realize balanced scheduling of the messages of multiple types by independently pushing and scheduling the message bodies of different message types.
Description
Technical Field
The present disclosure relates to the field of message pushing technologies, and in particular, to a message pushing method, device and equipment.
Background
Message pushing refers to active message pushing of user mobile equipment by enterprise operators through own products or third party tools. The user can see the push message notification on the mobile device locking screen and the notification bar, and click on the push message notification can call the application program and go to the corresponding page, so that a bridge for communication and item communication between enterprises and the user can be established.
The timeliness, accuracy, stability and success rate of message pushing are important indexes for measuring the message pushing performance. At present, a multithreading mode is commonly used for improving message pushing timeliness, but in the case of message congestion, a scheduling imbalance phenomenon of large-area delay of a certain type of message still occurs.
Disclosure of Invention
In view of this, the present disclosure proposes a method, an apparatus, and a device for pushing messages, which can implement balanced scheduling for multiple types of messages.
According to a first aspect of the present disclosure, there is provided a message pushing method, including:
Acquiring a message pushing request, and generating a message body containing a message to be pushed according to the message pushing request;
according to the message type of the message body, the message body is routed to a corresponding intelligent dispatcher;
And determining a pushing channel of the message body through the intelligent dispatcher, and pushing the message to be pushed through the pushing channel.
In one possible implementation manner, after obtaining the message push request, the method further includes: a processing step of risk identification for the message pushing request obtained currently;
And when the currently acquired message push request is determined to be a non-risk request, executing the step of generating the message body according to the message push request.
In one possible implementation manner, when generating the corresponding message body of the message to be pushed according to the push request, the method includes:
extracting a message template identifier and a message type identifier in the push request;
Acquiring a message template corresponding to the push request based on the message template identifier, and generating message content of the message to be pushed based on the message template;
Acquiring channel data of at least two push channels corresponding to the message to be pushed based on the message type identifier;
and generating a corresponding message body of the message to be pushed based on the message content and the channel data.
In one possible implementation manner, after generating the message body according to the message push request, the method further includes:
Determining a sending mode of the message body;
And when the sending mode of the message body is asynchronous sending, adding the message body into a message queue, and then routing each message body to a corresponding intelligent dispatcher according to the sequence of the message queue.
In one possible implementation, when the message body is routed to the intelligent scheduler according to the message type of the message body, the method further includes: determining whether the message body meets a preset transmission scene requirement, and routing the message body to the intelligent scheduler when determining that the message body meets the transmission scene requirement;
the sending scene requirements are used for representing the configuration of the sending scene of the message body, and the message bodies of different message types correspond to different sending scene requirements.
In one possible implementation, the message body is routed to an intelligent scheduler corresponding to the message type based on a blocking queue implementation corresponding to the message type.
In one possible implementation manner, the intelligent scheduler, when determining the push channel of the message body, includes:
Obtaining channel configuration and operation statistical data of at least two pushing channels;
and determining the push channel of the message body based on the channel data, the channel configuration and the operation statistic data of at least two push channels.
In one possible implementation manner, after the pushing of the message to be pushed through the pushing channel, the method further includes:
acquiring a push receipt of the message to be pushed;
Judging whether the message to be pushed is successfully pushed or not according to the push receipt;
And under the condition that the message to be pushed is not pushed successfully, the pushing channel of the message body is redetermined according to the pushing failure reason in the pushing return license.
According to a second aspect of the present disclosure, there is provided a message pushing apparatus, comprising:
The message body generation module is used for acquiring a message pushing request and generating a message body containing a message to be pushed according to the message pushing request;
the routing module is used for routing the message body to a corresponding intelligent dispatcher according to the message type of the message body;
The intelligent scheduling module is used for determining a pushing channel of the message body through the intelligent scheduler and pushing the message to be pushed through the pushing channel.
According to a third aspect of the present disclosure, there is provided a message pushing device, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to perform the method of the first aspect of the present disclosure.
In the present disclosure, independent intelligent schedulers are respectively provided for message bodies of different message types, after the message bodies are obtained, the message bodies are routed to corresponding intelligent schedulers according to the message types of the message bodies to perform push scheduling of the message bodies, and balanced scheduling of multiple types of messages can be realized by performing independent push scheduling on the message bodies of different message types.
Other features and aspects of the present disclosure will become apparent from the following detailed description of exemplary embodiments, which proceeds with reference to the accompanying drawings.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments, features and aspects of the present disclosure and together with the description, serve to explain the principles of the disclosure.
FIG. 1 shows a schematic flow chart of a message pushing method according to an embodiment of the present disclosure;
FIG. 2 shows a schematic flow diagram of an example message pushing method according to an embodiment of the present disclosure;
Fig. 3 shows a schematic block diagram of a message pushing device according to an embodiment of the present disclosure;
Fig. 4 shows a schematic block diagram of a message pushing device according to an embodiment of the present disclosure.
Detailed Description
Various exemplary embodiments, features and aspects of the disclosure will be described in detail below with reference to the drawings. In the drawings, like reference numbers indicate identical or functionally similar elements. Although various aspects of the embodiments are illustrated in the accompanying drawings, the drawings are not necessarily drawn to scale unless specifically indicated.
The word "exemplary" is used herein to mean "serving as an example, embodiment, or illustration. Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.
In addition, numerous specific details are set forth in the following detailed description in order to provide a better understanding of the present disclosure. It will be understood by those skilled in the art that the present disclosure may be practiced without some of these specific details. In some instances, methods, means, elements, and circuits well known to those skilled in the art have not been described in detail in order not to obscure the present disclosure.
< Method example >
Fig. 1 shows a schematic flow chart of a message pushing method according to an embodiment of the present disclosure. As shown in fig. 1, the method includes steps S1100-S1300.
S1100, obtaining a message pushing request, and generating a message body containing a message to be pushed according to the message pushing request.
Before message pushing, the application pushing the message needs to be accessed into the message pushing system through an API interface. The API interface is a unified abstract interface (such as an API interface constructed based on the dubbo protocol or the Restful protocol), and an application can send and receive different types of messages in a unified programming mode without interfacing a plurality of interfaces according to different message types. In one possible implementation, the API interface may integrate at least one type of message from among a sms, voice phone, mail, and APP message sent by the access application. In one possible implementation, the API interface may also provide multiple messaging modes to meet various access requirements. The message transmission means may include at least one of synchronous transmission, asynchronous transmission, single transmission, batch transmission, dynamic transmission, and static transmission.
In one possible implementation manner, after obtaining the message push request, the method further includes: and carrying out risk identification on the currently acquired message pushing request.
It should be noted that, before risk identification is performed on the message pushing request, the risk identification rule may be configured through a preset management interface. The risk identification rule may include at least one of a test flow identification rule, a number (such as a mobile phone number, a mailbox number, an APP device ID number, etc.) black and white list identification rule, a message bombing identification rule, a wool-out identification rule, and a distributed network robot request identification rule. In this way, risk identification can be performed on the currently acquired message push request according to the configured risk identification rule.
In one possible implementation manner, when performing risk identification on the currently acquired message push request according to the configured risk identification rule, the method includes: and extracting a characteristic field related to the risk identification rule from the message push request, and determining whether the currently acquired message push request has risk or not according to the extraction result of the characteristic field.
For example, the risk identification rules include test traffic identification rules that are: it is detected whether a "test traffic" feature field is included in the message push request. For a currently acquired message push request, extracting a 'test traffic' field from the message push request: when the currently acquired message push request does not comprise a field of 'test flow', the message push request is characterized as not being the test flow, namely being a non-risk request; and when the currently acquired message push request comprises a test flow field, characterizing the message push request as a test flow, namely a risk request.
As another example, the risk identification rule includes a number blacklist identification rule, where the number blacklist identification rule is: and detecting whether the characteristic value of the number characteristic field in the message push request is in a preset blacklist. For a currently acquired message push request, extracting a characteristic value of a number characteristic field from the message push request, and judging whether the characteristic value is in a preset blacklist or not: when the message pushing request belongs to a blacklist, characterizing that the message pushing request obtained currently comes from an unreliable application, namely a risk request; and when the message pushing request does not belong to the blacklist, characterizing that the message pushing request obtained currently comes from a reliable application, namely, the message pushing request is a non-risk request.
In another possible implementation manner, when performing risk identification on the currently acquired message push request according to the configured risk identification rule, the method includes: extracting feature fields related to risk identification rules from a message push request, acquiring an algorithm model corresponding to the risk identification rules from a preset algorithm model, calculating a risk score of the message push request based on the feature fields and the algorithm model, and determining whether the currently acquired message push request has risk or not based on the risk score.
For example, the risk identification rules include a distributed network robot request identification rule that is: and whether the message pushing request flow of the same number characteristic field exceeds a set flow threshold value in a preset time window. And the algorithm model corresponding to the request identification rule of the distributed network robot is the same characteristic time window flow calculation algorithm model. For a currently acquired message push request, extracting the characteristic value of the number characteristic field from the message push request, calculating the flow value which is the same as the characteristic value of the number characteristic field in the current message push request in a preset time window based on the same characteristic time window flow calculation algorithm model, and judging whether the flow value exceeds a set flow threshold value or not: when the flow threshold value is exceeded, representing that the currently acquired message pushing request is a message pushing request sent by the distributed network robot, namely a risk request; and when the message pushing request is smaller than or equal to the set flow threshold, representing that the currently acquired message pushing request is not the message pushing request sent by the distributed network robot, namely, the message pushing request is a non-risk request. The set traffic threshold may be 10 traffic values per day, that is, the traffic values with the same characteristic values of the "number" characteristic field in the push request exceed 10 traffic values per day, which indicates that the push request is a risk request.
As another example, the risk identification rules include a distributed network robot request identification rule, which is: and whether the number of push failure corresponding to the message push requests of the same number characteristic field in a preset time window exceeds a set push failure threshold value or not. When risk identification is carried out, if the number of pushing failure exceeds a set pushing failure threshold, representing that the currently acquired message pushing request is a message pushing request sent by the distributed network robot, namely the message pushing request is a risk request; if the number of the pushing failure does not exceed the set pushing failure threshold, the currently acquired message pushing request is characterized as not being a message pushing request sent by the distributed network robot, namely, is a non-risk request. The push failure threshold may be 10 push failures/5 min, that is, within 5 min, where the number of push failures corresponding to the message push requests with the same "number" feature field exceeds 10, which indicates that the currently received push request is a risk request.
In this implementation manner, the risk recognition rule and the algorithm model corresponding to the risk recognition rule may be set according to specific application requirements, which is not specifically limited in the present application.
After the risk identification result of the currently acquired message pushing request is obtained, a corresponding operation can be executed according to the risk identification result.
In one possible implementation, the step of generating a message body from the message push request is performed upon determining that the currently acquired message push request is a non-risky request. When the currently acquired message pushing request is determined to be a risk request, the message pushing request is recorded and displayed in a monitoring and counting page, so that operation and maintenance personnel can process the message pushing request with risk in time.
In an embodiment of determining whether the currently acquired message push request has a risk according to the risk score, the risk level of the message push request may also be determined according to the risk score and a preset risk level threshold. The risk level may include at least one of a serious risk and a general risk. When the currently acquired message pushing request is at serious risk, the message pushing request can be informed to the operation and maintenance personnel through a voice telephone mode, so that the operation and maintenance personnel can process in time.
In one possible implementation, steps S1110-S1140 are included when generating a corresponding message body of a message to be pushed according to a push request.
S1110, extracting a message template identifier and a message type identifier in the push request.
The message template identification is used to uniquely identify a particular message template. It should be noted that, before pushing the message, the message template of the message to be pushed and the corresponding message template identifier need to be stored in the database, so that after extracting the message template identifier in the message pushing request, the corresponding message template can be extracted from the database based on the message template identifier.
The message type identification is used to uniquely identify a particular message type. Thus, after the corresponding message body is generated based on the message type identifier, the message type identifier in the message body can determine the message type of the message body. The message type is consistent with the type of the API interface, and will not be described herein.
S1120, acquiring a message template corresponding to the pushing request based on the message template identification, and generating message content of the message to be pushed based on the message template.
The message template may be a dynamic message template or a static message template, and is not specifically limited herein. The dynamic message template content contains variables. When the message template corresponding to the push request is obtained as a dynamic template, the variable in the content of the dynamic message template is required to be replaced according to the parameters in the message push request, so as to dynamically generate the message content of the message to be pushed. The static template content is fixed content. When the message template corresponding to the push request is obtained as a static template, the content of the static template is directly used as the message content of the message to be pushed.
S1130, obtaining channel data of at least two push channels corresponding to the message to be pushed based on the message type identifier.
The pushing channel refers to a channel capable of pushing a message to be pushed. The push channel may be a channel implemented by the message push system itself, or may be a purchased third party channel service, which is not specifically limited herein.
When it is required to be described, in the message pushing system, at least two or more pushing channels are configured for each message type, so as to ensure the reliability of message pushing. In one possible implementation manner, before message pushing is performed, channel data of at least two push channels corresponding to the message type identifier are stored in a database in the form of a mapping relation table, so that when the message type identifier is extracted, the channel data of at least two push channels corresponding to the message to be pushed can be obtained in the mapping relation table. Wherein the channel data may include at least one of channel identification, channel usage priority, and channel usage unit price.
S1140, based on the message content and the channel data, a corresponding message body of the message to be pushed is generated. Specifically, after the message content of the message to be pushed is obtained, the channel data of the message to be pushed is added to the message content to obtain the corresponding message body of the message to be pushed.
In one possible implementation, after generating the message body according to the message push request, steps S1150-S1160 are further included.
S1150, determining the sending mode of the message body.
Specifically, a transmission mode identifier may be configured in the message push request to uniquely identify the transmission mode of the message body by the transmission mode identifier. The transmission method may be synchronous transmission or asynchronous transmission. When the transmission method identifier is configured in the message push request, the transmission method identifier is also included in the message body generated according to the message push request, so that after the message body is obtained, the transmission method of the message body can be determined by the transmission method identifier in the message body.
S1160, when the sending mode of the message body is asynchronous sending, adding the message body into a message queue, and then routing each message body to a corresponding intelligent dispatcher according to the sequence of the message queue. When the sending mode of the message body is synchronous sending, the message body can be directly routed to the corresponding intelligent dispatcher.
In one possible implementation, when the message body is routed to the intelligent scheduler according to the message type of the message body, the method further includes: and determining whether the message body meets the preset transmission scene requirement, and routing the message body to the intelligent scheduler when the message body is determined to meet the transmission scene requirement. The transmission scenario requires a configuration of the transmission scenario for characterizing the message body. The transmission scenario requirements may be configured in a set management interface according to a specific application scenario, and the transmission scenario requirements are not specifically limited herein. For example, the transmission scenario requirement may be to prohibit transmission for a specified period of time. As another example, the transmission scenario requirement may be that repeated message bodies within a set time window prohibit transmission. Through the configuration of the sending scene requirements, the requirements of various message pushing scenes can be met for message pushing, so that the use experience of pushed users is improved.
The message bodies of different message types can correspond to the same transmission scene requirement, or can correspond to different transmission scene requirements, and the method is not particularly limited.
In an implementation manner that message bodies of different message types correspond to different transmission scene requirements, for a message body of a voice phone type, the corresponding transmission scene requirement may be that transmission is prohibited for a specified period of time. For example, after the voice telephone type message body is acquired, the time of acquiring the message body is detected, and then whether the time of acquiring the message body is within a specified time period from 10 pm to 6 am is judged, and if the time is within the specified time period, the message body is forbidden to be routed to the intelligent dispatcher so as to prevent sending the voice telephone type message at night and disturb the rest of the user. And temporarily storing the message body forbidden in the appointed time period in a database, and after the forbidden time, routing the message body to an intelligent dispatcher for reissuing so as to ensure that a user can receive a message to be pushed corresponding to the forbidden message body. For example, for message bodies that are forbidden between 10 pm and 6 am, they can be routed to the intelligent scheduler after 6 am the next day for reissue. In another possible implementation manner, for a message body with high timeliness, if the forbidden sending time exceeds a set timeliness threshold, the message body can be deleted directly in the database, so as to reduce the waste of storage resources.
In the realizable mode that the message bodies of different message types correspond to the same transmission scene requirement, the message bodies of any message type can be the repeated message bodies in the set time window to prohibit transmission according to the corresponding transmission scene requirement. For example, after the message body is obtained, whether the message body is repeated with the message body sent in the set time window is judged first, and in the case of repetition, the message body is forbidden to be routed to the intelligent scheduler, and after the message body is forbidden, the repeated message body can be directly deleted, so that the waste of storage resources is reduced.
S1200, according to the message type of the message body, the message body is routed to the corresponding intelligent dispatcher.
In the present disclosure, a message push system configures mutually independent intelligent schedulers for message bodies of each message type, and each intelligent scheduler corresponds to an independent thread pool to store and schedule different message bodies respectively, so as to ensure that the message bodies of different types can be uniformly scheduled.
For example, in an implementation where the message type includes a sms, voice call, mail, and APP message, when the message type of the message body is determined to be a sms, the message body is routed to the first thread pool and push scheduling is performed by the first intelligent scheduler. And when the message type of the message body is determined to be voice telephone, the message body is routed to a second thread pool, and the second intelligent scheduler performs push scheduling. And when the message type of the message body is determined to be mail, the message body is routed to a third thread pool, and the third intelligent scheduler performs push scheduling. And when the message type of the message body is determined to be the APP message, the message body is routed to a fourth thread pool, and the fourth intelligent scheduler performs push scheduling. The first thread pool, the second thread pool, the third thread pool and the fourth thread pool are mutually independent thread pools.
In one possible implementation, the blocking queue implementation is based on the message type when routing the message body to the intelligent scheduler corresponding to the message type. Specifically, a corresponding blocking queue is further arranged for each message type, when the message body is routed to the intelligent dispatcher corresponding to the message type, the message body is routed to the blocking queue corresponding to the message type, and the blocking queue judges whether a thread pool corresponding to the intelligent dispatcher corresponding to the message type has idle threads or not: when there is a free thread, the blocking queue allows the thread pool to pull the message body from the blocking queue into the thread pool to route the message body into the intelligent scheduler corresponding to the message type. When no idle thread exists (i.e. the thread pool is full), the blocking queue prohibits the thread pool from pulling the message body from the blocking queue to the thread pool, so as to protect the thread pool in a blocking mode of the blocking queue and avoid the problems of CPU surge and thread blocking caused by overload.
In one possible implementation, each thread pool may be adaptively adjusted according to configuration and operation parameters of different server CPUs, so as to achieve the purpose of resource awareness. In a host deployment environment, the greater the number of core threads of a thread pool, the greater the concurrency capability if the host CPU configuration is high. In a container environment or virtualized environment, the more core threads of a thread pool are and the stronger concurrency capability is if more resources are allocated. Specifically, steps S1210-S1220 are included when the thread pool is adaptively adjusted according to the configuration and operation parameters of different server CPUs.
S1210, obtaining the configuration and operation parameters of the server. Wherein the configuration of the server comprises the core number of the CPU, and the operation parameters comprise the current CPU load percentage and the idle content size (unit: MB) of the process.
S1220, carrying out self-adaptive adjustment on the thread pool according to the acquired configuration and operation parameters of the server.
For example, if the current CPU load percentage is less than 10%, the number of core threads of the thread pool is set to be CPU core number x 2, and the maximum number of threads is set to be process free memory size x 80% and rounded. If the current CPU load percentage is equal to or greater than 10% and less than 30%, setting the core thread number of the thread pool as the CPU core number, and rounding after setting the maximum thread number as the process idle memory size 80%. If the current CPU load percentage is not less than 30%, the core thread number of the thread pool is set to be the CPU core number/2 and then rounded, and the maximum thread number is set to be the process idle memory size 80% and then rounded.
In one possible implementation manner, for a message needing urgent push, a priority may be identified in a message push request, in the possible implementation manner, a message body generated according to the message push request has a priority identification, so that after the message body enters a thread pool, limited scheduling push may be performed on the message body with the priority identification, so as to ensure that important messages may be pushed to a user in time, and improve timeliness of message push.
In one possible implementation, after the message body enters the corresponding thread pool, the intelligent scheduler first determines whether the message body is a batch message or a single message according to the number of target user identifiers in the target user variable list in the message body. Specifically, when the number of target user identifiers in the target user variable list is 1, the message body is determined to be a single message, and at this time, intelligent scheduling can be directly performed on the message body. When the number of target user identifications in the target user variable list is greater than 1, determining that the message body is a batch message, at this time, splitting the message body into specific single message bodies, and then intelligently scheduling the single message bodies. In this way, a minimum granularity of scheduling control of the message body can be achieved.
S1300, determining a pushing channel of the message body through the intelligent dispatcher, and pushing the message to be pushed through the pushing channel.
In one possible implementation, the intelligent scheduler, when determining the push channel of the message body, includes steps S1310-S1320.
S1310, obtaining channel configuration and operation statistical data of at least two push channels.
The channel configuration includes at least one key parameter of vendor, quota and tariff to which the channel belongs. The operation statistics include at least one parameter of a total amount of window transmission, a push success rate, a push failure rate, a window average transmission time, a window average reception delay, and a channel availability status.
S1320, determining the push channels of the message body based on the channel data, the channel configuration and the operation statistics of at least two push channels.
In one possible implementation, the push channel data of the message body includes a channel identifier, the channel configuration includes a tariff for using the channel, and the running statistics include a push success rate per hour and an average receive delay per hour window of the channel. For example, the channel data, channel configuration data, and operation statistics of the message body may be as shown in table 1.
TABLE 1
In this implementation manner, when determining the push channel of the message body based on the channel data, the channel configuration and the operation statistics of at least two push channels, the method includes: calculating the difference value of the pushing success rate of any two channels per hour and the difference value of the average receiving delay of any two channels per small window respectively; when the difference between every two pushing success rates is larger than or equal to 5%, the channel with high pushing success rate is confirmed to be the pushing channel of the message body. And when the difference between every two average receiving delays of each small window is larger than or equal to 5 seconds, determining the channel with the lowest average receiving delay of the window as the pushing channel of the message body. And when the push success rate per hour is less than 5% and the average receiving delay per small window is less than 5 seconds, determining the channel with the lowest cost as the push channel of the message body.
After the message is pushed, the receiving state of the user cannot be known in time, and the user may not receive the push message due to various reasons (such as poor network signal, arrearage, network switching of the user, idle number and the like). And collecting the push receipt reflecting the receiving state of the user through the callback of the manufacturer channel and the channel callback realized by the manufacturer channel so as to carry out push statistics and query reasons through the push receipt. The intelligent scheduler also needs the receiving state and the receiving time consumption of the user to judge the speed and the quality of a certain channel and make decision basis for how the subsequent messages are scheduled.
In one possible implementation manner, after the pushing of the message to be pushed through the pushing channel, the method further includes: acquiring a push receipt of a message to be pushed; judging whether the message to be pushed is successfully pushed or not according to the push receipt; and under the condition that the message to be pushed is not pushed successfully, the pushing channel of the message body is redetermined according to the pushing failure reason in the pushing back license.
For example, if the cause of the push failure in the push back is the channel cause, the channel is switched to retry transmission. As another example, the reason for the failed push in the push back is that the user signal is not good, the original channel tries to retry again until N times (e.g. 3 times) of retry, and if the channel still fails, the switching channel is triggered, and the message is sent out by another available channel. For another example, when a channel fault is detected, the channel is disconnected in the available channel list, and the message is switched to other available channels for transmission, so that automatic channel fault switching is realized, and the reliability and stability of message transmission are greatly improved.
In the present disclosure, independent intelligent schedulers are respectively provided for message bodies of different message types, after the message bodies are obtained, the message bodies are routed to corresponding intelligent schedulers according to the message types of the message bodies to perform push scheduling of the message bodies, and balanced scheduling of multiple types of messages can be realized by performing independent push scheduling on the message bodies of different message types.
< Method example >
Fig. 2 shows a schematic flow diagram of an example of a message pushing method according to an embodiment of the present disclosure. As shown in fig. 2, the method includes the following steps.
Firstly, acquiring a message push request of at least one message type of a short message, a voice telephone, a mail and an APP message sent by an application in an integrated docking mode.
Secondly, performing risk identification on the currently acquired message pushing request according to the configured risk identification rule, and generating a corresponding message body according to the message pushing request when the message pushing request is determined to be a non-risk request.
Thirdly, determining the sending mode of the message body, and directly executing the fourth step when the sending mode of the message body is synchronous sending. When the message body is sent asynchronously, the message body is added into a message queue, and then the fourth step is executed on each message body according to the sequence of the message queue.
Fourth, it is determined whether the message body meets the preset transmission scene requirement, and when it is determined that the message body meets the transmission scene requirement, the message body is routed to the corresponding intelligent dispatcher according to the message type of the message body.
Fifthly, selecting an optimal channel from at least two pushing channels corresponding to the message type through the intelligent scheduler, and pushing the message to be pushed through the optimal pushing channel.
< Device example >
Fig. 3 shows a schematic block diagram of a message pushing device according to an embodiment of the present disclosure. As shown in fig. 3, the message pushing apparatus 100 includes:
the message body generating module 110 is configured to obtain a message push request, and generate a message body including a message to be pushed according to the message push request.
The routing module 120 is configured to route the message body to a corresponding intelligent scheduler according to the message type of the message body.
The intelligent scheduling module 130 is configured to determine a pushing channel of the message body through the intelligent scheduler, and push the message to be pushed through the pushing channel.
In one possible implementation, the message body generating module 110 is further configured to, after obtaining the message push request: performing risk identification on the currently acquired message pushing request;
When risk identification is performed on the currently acquired message pushing request, and it is determined that the currently acquired message pushing request is a non-risk request, the step of generating a message body according to the message pushing request is performed.
In one possible implementation manner, the message body generating module 110 is specifically configured to, when generating a corresponding message body of a message to be pushed according to a push request:
Extracting a message template identifier and a message type identifier in the push request;
Acquiring a message template corresponding to the pushing request based on the message template identifier, and generating message content of a message to be pushed based on the message template;
Acquiring channel data of at least two push channels corresponding to a message to be pushed based on the message type identifier;
based on the message content and the channel data, a corresponding message body of the message to be pushed is generated.
In one possible implementation, the message body generating module 110 is further configured to, after generating the message body according to the message push request:
Determining a sending mode of a message body;
When the sending mode of the message bodies is asynchronous sending, the message bodies are added into the message queues, and then each message body is routed to the corresponding intelligent dispatcher according to the sequence of the message queues.
In one possible implementation, the routing module 120, when routing the message body to the intelligent scheduler according to the message type of the message body, is further configured to: determining whether the message body meets the preset transmission scene requirement, and routing the message body to the intelligent scheduler when the message body is determined to meet the transmission scene requirement;
The sending scene requirements are used for representing the configuration of the sending scene of the message body, and the message bodies of different message types correspond to different sending scene requirements.
In one possible implementation, the routing module 120, when routing the message body to the intelligent scheduler corresponding to the message type, is implemented based on blocking the queue corresponding to the message type.
In one possible implementation, the intelligent scheduling module 130 is specifically configured to, when the intelligent scheduler determines the push channel of the message body:
obtaining channel configuration and operation statistics data of at least two pushing channels;
and determining the push channels of the message body based on the channel data, the channel configuration and the running statistics of at least two push channels.
In one possible implementation, the intelligent scheduling module 130 is further configured to, after pushing the message to be pushed through the push channel:
acquiring a push receipt of a message to be pushed;
Judging whether the message to be pushed is successfully pushed or not according to the push receipt;
And under the condition that the message to be pushed is not pushed successfully, the pushing channel of the message body is redetermined according to the pushing failure reason in the pushing back license.
< Device example >
Fig. 4 shows a schematic block diagram of a message pushing device according to an embodiment of the present disclosure. As shown in fig. 4, the message pushing device 200 includes a processor 210 and a memory 220 for storing instructions executable by the processor 210. Wherein the processor 210 is configured to implement any of the foregoing message pushing methods when executing the executable instructions.
Here, it should be noted that the number of processors 210 may be one or more. Meanwhile, in the message pushing apparatus 200 of the embodiment of the present disclosure, an input device 230 and an output device 240 may be further included. The processor 210, the memory 220, the input device 230, and the output device 240 may be connected by a bus, or may be connected by other means, which is not specifically limited herein.
The memory 220 is a computer-readable storage medium that can be used to store software programs, computer-executable programs, and various modules, such as: the message pushing method of the embodiment of the disclosure corresponds to a program or a module. The processor 210 executes various functional applications and data processing of the message pushing device 200 by running software programs or modules stored in the memory 220.
The input device 230 may be used to receive an input digital or signal. Wherein the signal may be a key signal generated in connection with user settings of the device/terminal/server and function control. The output means 240 may comprise a display device such as a display screen.
The foregoing description of the embodiments of the present disclosure has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the various embodiments described. The terminology used herein was chosen in order to best explain the principles of the embodiments, the practical application, or the technical improvement of the technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.
Claims (6)
1. A message pushing method, comprising:
Acquiring a message pushing request, and generating a message body containing a message to be pushed according to the message pushing request;
according to the message type of the message body, the message body is routed to a corresponding intelligent dispatcher;
Determining a pushing channel of the message body through the intelligent dispatcher, and pushing the message to be pushed through the pushing channel;
When the message body is routed to the corresponding intelligent scheduler according to the message type of the message body, the message body is firstly routed to the blocking queue corresponding to the message type, the blocking queue judges whether the thread pool corresponding to the message type has idle threads, and when the idle threads exist, the blocking queue allows the intelligent scheduler corresponding to the message type to pull the message body from the blocking queue to the thread pool corresponding to the message type, so that the pushing management of the intelligent scheduler corresponding to the message type on the message body is realized;
The method for adaptively adjusting the core thread number and the maximum thread number of the thread pool according to the configuration and the operation parameters of the server CPU, specifically, when adaptively adjusting the core thread number and the maximum thread number of the thread pool according to the configuration and the operation parameters of the server CPU, comprises the following steps: obtaining configuration and operation parameters of a server, wherein the configuration of the server comprises the core number of a CPU, the operation parameters comprise the current CPU load percentage and the process idle content size, if the current CPU load percentage is less than 10%, the core thread number of a thread pool is set to be CPU core number x 2, the maximum thread number is set to be process idle memory size x 80% and then rounded, if the current CPU load percentage is greater than or equal to 10% and less than 30%, the core thread number of the thread pool is set to be CPU core number, the maximum thread number is set to be process idle memory size x 80% and then rounded, if the current CPU load percentage is greater than or equal to 30%, the core thread number of the thread pool is set to be CPU core number/2 and then rounded, and the maximum thread number is set to be process idle memory size x 80% and then rounded;
when generating the corresponding message body of the message to be pushed according to the push request, the method comprises the following steps:
extracting a message template identifier and a message type identifier in the push request;
Acquiring a message template corresponding to the push request based on the message template identifier, and generating message content of the message to be pushed based on the message template, wherein the message template is divided into a dynamic message template and a static message template, the dynamic message template content comprises variables, the static message template content is fixed content, when the acquired message template is the dynamic message template, the variables in the dynamic message template content are replaced according to parameters in the message push request so as to dynamically generate the message content of the message to be pushed, and when the acquired message template is the static message template, the content of the static message template is directly used as the message content of the message to be pushed;
Acquiring channel data of at least two push channels corresponding to the message to be pushed based on the message type identifier;
generating a corresponding message body of the message to be pushed based on the message content and the channel data;
When the message body is routed to the intelligent scheduler according to the message type of the message body, the method further comprises the following steps: determining whether the message body meets preset sending scene requirements or not, and when the message body meets the sending scene requirements, routing the message body to the intelligent scheduler, wherein the sending scene requirements are used for representing configuration of sending scenes of the message body, and the message bodies of different message types correspond to different sending scene requirements; the transmission scene requirement comprises at least one of prohibition of transmission in a designated time period and prohibition of transmission of repeated message bodies in a set time window;
the intelligent scheduler, when determining the push channel of the message body, includes:
Obtaining channel configuration and operation statistical data of at least two pushing channels;
Determining a push channel of a message body based on the channel data, the channel configuration and the operation statistics of at least two push channels;
The channel data comprises a channel identifier, the channel configuration comprises the tariffs of the use channel, and the operation statistical data comprises the push success rate of the channel in each hour and the average receiving delay of the window in each hour;
Determining a push channel of a message body based on the channel data, the channel configuration and the operation statistics of at least two push channels includes:
Calculating the difference value of the pushing success rate of any two channels per hour and the difference value of the average receiving delay of any two channels per small window respectively; when the difference of every two pushing success rates is larger than or equal to 5%, confirming that the channel with high pushing success rate is a pushing channel of the message body; when the average receiving delay of each window per hour is equal to or greater than 5 seconds, determining a channel with the lowest average receiving delay of the windows as a pushing channel of a message body; and when the push success rate per hour is less than 5% and the average receiving delay per small window is less than 5 seconds, determining the channel with the lowest cost as the push channel of the message body.
2. The method of claim 1, further comprising, after obtaining the message push request: a processing step of risk identification for the message pushing request obtained currently;
And when the currently acquired message push request is determined to be a non-risk request, executing the step of generating the message body according to the message push request.
3. The method of claim 1, further comprising, after generating the message body from the message push request:
Determining a sending mode of the message body;
And when the sending mode of the message body is asynchronous sending, adding the message body into a message queue, and then routing each message body to a corresponding intelligent dispatcher according to the sequence of the message queue.
4. A method according to any of claims 1-3, characterized in that after pushing of the message to be pushed through the push channel, further comprising:
acquiring a push receipt of the message to be pushed;
Judging whether the message to be pushed is successfully pushed or not according to the push receipt;
And under the condition that the message to be pushed is not pushed successfully, the pushing channel of the message body is redetermined according to the pushing failure reason in the pushing return license.
5. A message pushing device, comprising:
The message body generation module is used for acquiring a message pushing request and generating a message body containing a message to be pushed according to the message pushing request;
the routing module is used for routing the message body to a corresponding intelligent dispatcher according to the message type of the message body;
The intelligent scheduling module is used for determining a pushing channel of the message body through the intelligent scheduler and pushing the message to be pushed through the pushing channel;
Wherein, for each message type, a blocking queue, a thread pool and an intelligent scheduler which are independent of each other are respectively configured, and the routing module is specifically configured to:
Firstly, the message body is routed to a blocking queue corresponding to the message type, the blocking queue judges whether a thread pool corresponding to the message type has idle threads, and when the idle threads exist, the blocking queue allows an intelligent dispatcher corresponding to the message type to pull the message body from the blocking queue to the thread pool corresponding to the message type so as to realize push management of the intelligent dispatcher corresponding to the message type on the message body;
The method for adaptively adjusting the core thread number and the maximum thread number of the thread pool according to the configuration and the operation parameters of the server CPU, specifically, when adaptively adjusting the core thread number and the maximum thread number of the thread pool according to the configuration and the operation parameters of the server CPU, comprises the following steps: obtaining configuration and operation parameters of a server, wherein the configuration of the server comprises the core number of a CPU, the operation parameters comprise the current CPU load percentage and the process idle content size, if the current CPU load percentage is less than 10%, the core thread number of a thread pool is set to be CPU core number x 2, the maximum thread number is set to be process idle memory size x 80% and then rounded, if the current CPU load percentage is greater than or equal to 10% and less than 30%, the core thread number of the thread pool is set to be CPU core number, the maximum thread number is set to be process idle memory size x 80% and then rounded, if the current CPU load percentage is greater than or equal to 30%, the core thread number of the thread pool is set to be CPU core number/2 and then rounded, and the maximum thread number is set to be process idle memory size x 80% and then rounded;
The message body generating module is specifically configured to, when generating the message body corresponding to the message to be pushed according to the push request:
extracting a message template identifier and a message type identifier in the push request;
Acquiring a message template corresponding to the push request based on the message template identifier, and generating message content of the message to be pushed based on the message template, wherein the message template is divided into a dynamic message template and a static message template, the dynamic message template content comprises variables, the static message template content is fixed content, when the acquired message template is the dynamic message template, the variables in the dynamic message template content are replaced according to parameters in the message push request so as to dynamically generate the message content of the message to be pushed, and when the acquired message template is the static message template, the content of the static message template is directly used as the message content of the message to be pushed;
Acquiring channel data of at least two push channels corresponding to the message to be pushed based on the message type identifier;
generating a corresponding message body of the message to be pushed based on the message content and the channel data;
The routing module is further configured to, when routing the message body to the intelligent scheduler according to a message type of the message body: determining whether the message body meets preset sending scene requirements or not, and when the message body meets the sending scene requirements, routing the message body to the intelligent scheduler, wherein the sending scene requirements are used for representing configuration of sending scenes of the message body, the message bodies of different message types correspond to different sending scene requirements, and the sending scene requirements comprise at least one of forbidden sending of a designated time period and forbidden sending of repeated message bodies in a set time window;
the intelligent scheduler, when determining the push channel of the message body, includes:
Obtaining channel configuration and operation statistical data of at least two pushing channels;
Determining a push channel of a message body based on the channel data, the channel configuration and the operation statistics of at least two push channels;
The channel data comprises a channel identifier, the channel configuration comprises the tariffs of the use channel, and the operation statistical data comprises the push success rate of the channel in each hour and the average receiving delay of the window in each hour;
the intelligent scheduler is specifically configured to, when determining a push channel of a message body based on the channel data, the channel configuration, and the operation statistics of at least two push channels:
Calculating the difference value of the pushing success rate of any two channels per hour and the difference value of the average receiving delay of any two channels per small window respectively; when the difference of every two pushing success rates is larger than or equal to 5%, confirming that the channel with high pushing success rate is a pushing channel of the message body; when the average receiving delay of each window per hour is equal to or greater than 5 seconds, determining a channel with the lowest average receiving delay of the windows as a pushing channel of a message body; and when the push success rate per hour is less than 5% and the average receiving delay per small window is less than 5 seconds, determining the channel with the lowest cost as the push channel of the message body.
6. A message pushing device, comprising:
a processor;
A memory for storing processor-executable instructions;
Wherein the processor is configured to implement the method of any one of claims 1 to 4 when executing the executable instructions.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210404159.4A CN114979250B (en) | 2022-04-18 | 2022-04-18 | Message pushing method, device and equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210404159.4A CN114979250B (en) | 2022-04-18 | 2022-04-18 | Message pushing method, device and equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114979250A CN114979250A (en) | 2022-08-30 |
| CN114979250B true CN114979250B (en) | 2024-06-04 |
Family
ID=82976820
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210404159.4A Active CN114979250B (en) | 2022-04-18 | 2022-04-18 | Message pushing method, device and equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114979250B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| TWI839106B (en) * | 2023-02-08 | 2024-04-11 | 臺灣中小企業銀行股份有限公司 | Device for determining transmitting order according to sending parameters to transmit messages and method thereof |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5758081A (en) * | 1995-12-08 | 1998-05-26 | Aytac; Haluk M. | Computing and communications transmitting, receiving system, with a push button interface, that is continously on, that pairs up with a personal computer and carries out mainly communications related routine tasks |
| CN108093063A (en) * | 2017-12-26 | 2018-05-29 | 中国电信股份有限公司新疆分公司 | Big file multithreading FTP method for uploading |
| CN108347374A (en) * | 2018-01-22 | 2018-07-31 | 广州欧赛斯信息科技有限公司 | A kind of information push method, system and device preventing invalid message |
| CN108737535A (en) * | 2018-05-14 | 2018-11-02 | 平安科技（深圳）有限公司 | A kind of information push method, storage medium and server |
| WO2019085449A1 (en) * | 2017-10-31 | 2019-05-09 | 平安科技（深圳）有限公司 | Service short message pushing method, apparatus, computer device and storage medium |
| CN109818789A (en) * | 2019-01-22 | 2019-05-28 | 苏州科达科技股份有限公司 | Picture transmission method and system, storage medium, electronic equipment |
| CN111953776A (en) * | 2020-08-12 | 2020-11-17 | 江苏云柜网络技术有限公司 | Application service message pushing method and device, computer equipment and computer storage medium |
| CN114125050A (en) * | 2021-11-29 | 2022-03-01 | 深圳十方融海科技有限公司 | Message scheduling method, device, equipment and storage medium |
| CN114205761A (en) * | 2021-11-10 | 2022-03-18 | 上海缘远信息技术有限公司 | Short message distribution method and device based on multiple short message channels |
-
2022
- 2022-04-18 CN CN202210404159.4A patent/CN114979250B/en active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5758081A (en) * | 1995-12-08 | 1998-05-26 | Aytac; Haluk M. | Computing and communications transmitting, receiving system, with a push button interface, that is continously on, that pairs up with a personal computer and carries out mainly communications related routine tasks |
| WO2019085449A1 (en) * | 2017-10-31 | 2019-05-09 | 平安科技（深圳）有限公司 | Service short message pushing method, apparatus, computer device and storage medium |
| CN108093063A (en) * | 2017-12-26 | 2018-05-29 | 中国电信股份有限公司新疆分公司 | Big file multithreading FTP method for uploading |
| CN108347374A (en) * | 2018-01-22 | 2018-07-31 | 广州欧赛斯信息科技有限公司 | A kind of information push method, system and device preventing invalid message |
| CN108737535A (en) * | 2018-05-14 | 2018-11-02 | 平安科技（深圳）有限公司 | A kind of information push method, storage medium and server |
| CN109818789A (en) * | 2019-01-22 | 2019-05-28 | 苏州科达科技股份有限公司 | Picture transmission method and system, storage medium, electronic equipment |
| CN111953776A (en) * | 2020-08-12 | 2020-11-17 | 江苏云柜网络技术有限公司 | Application service message pushing method and device, computer equipment and computer storage medium |
| CN114205761A (en) * | 2021-11-10 | 2022-03-18 | 上海缘远信息技术有限公司 | Short message distribution method and device based on multiple short message channels |
| CN114125050A (en) * | 2021-11-29 | 2022-03-01 | 深圳十方融海科技有限公司 | Message scheduling method, device, equipment and storage medium |
Non-Patent Citations (1)
| Title |
|---|
| 黑龙江省通信公司城域传送网的规划与建设;董胜, 孙德华;黑龙江通信技术;20020930(03);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114979250A (en) | 2022-08-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111131058B (en) | Access quantity control method and device | |
| CN109257293B (en) | Speed limiting method and device for network congestion and gateway server | |
| CN110611891B (en) | Short message sending method and device | |
| CN113448749B (en) | Method, system, device and medium for optimizing execution of expected timing task | |
| CN109656700A (en) | Distributed link tracking, system, equipment and storage medium under multi-tenant | |
| CN102148905B (en) | Method and device for queuing calls | |
| CN109669835B (en) | MySQL database monitoring method, device, equipment and readable storage medium | |
| CN107819797B (en) | Access request processing method and device | |
| CN109766172B (en) | Asynchronous task scheduling method and device | |
| CN110830964B (en) | Information scheduling method, internet of things platform and computer readable storage medium | |
| CN114979250B (en) | Message pushing method, device and equipment | |
| CN111526081B (en) | Mail forwarding method, device, equipment and storage medium | |
| CN111240864A (en) | Asynchronous task processing method, device, equipment and computer readable storage medium | |
| CN114448922A (en) | Message grading processing method, device, equipment and storage medium | |
| WO2016149945A1 (en) | Life cycle event processing method and vnfm | |
| EP2509255A1 (en) | Service processing method and apparatus | |
| EP3945420A1 (en) | Method and apparatus for data processing, server and storage medium | |
| CN114138506A (en) | Message queue scheduling method and device, equipment, medium and product thereof | |
| CN107426109B (en) | Traffic scheduling method, VNF module and traffic scheduling server | |
| EP2385726A1 (en) | Apparatus and method for controlling amount of concurrent calls | |
| CN107872594B (en) | Charging method, charging device and charging system | |
| CN101951571A (en) | Short message retrying method and short message gateway | |
| CN109144676A (en) | A kind of self-starting detection method, device and the server of application program | |
| CN111638986A (en) | QoS queue scheduling method, device, system and readable storage medium | |
| CN113238875A (en) | Queue-based request frequency control system and control method |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |