CN113783913A

CN113783913A - Message pushing management method and device

Info

Publication number: CN113783913A
Application number: CN202010897268.5A
Authority: CN
Inventors: 孙岑
Original assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Wodong Tianjun Information Technology Co Ltd
Current assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Wodong Tianjun Information Technology Co Ltd
Priority date: 2020-08-31
Filing date: 2020-08-31
Publication date: 2021-12-10

Abstract

The invention discloses a message pushing management method and device, and relates to the technical field of computers. One embodiment of the method comprises: counting login times of each user in the application within a preset historical time, determining users with the login times larger than or equal to a preset time threshold as active users, and determining the rest users as inactive users; acquiring a message list corresponding to a single user, comparing messages in the message record list and the message list, and determining the messages which are not pulled; preferentially executing the pulling operation of the non-pulled message of the active user, and executing the pulling operation of the non-pulled message of the inactive user after the message is pushed to the active user. The implementation mode ensures that the message is pushed to the user in the previous golden time period (such as 1-2 hours) of the activity, effectively ensures the participation degree of the user, particularly the active user, and realizes message level sending, thereby improving the message sending efficiency.

Description

Message pushing management method and device

Technical Field

The present invention relates to the field of computer technologies, and in particular, to a method and an apparatus for managing message pushing.

Background

When activities are to be carried out, messages need to be sent to millions or even millions of users for activity pushing, and the users can be guaranteed to receive the messages before the activities are not started. When a user views a message, the user needs to access a message detail interface of an application background, and after the user views the message, the background marks the message to be read.

Currently, the operation of storing the relationship between the user ID and the message ID in a database and pushing the message to the user mobile terminal according to the relationship requires more than 8 hours. Due to the fact that time is too long, only one day of sending is considered in advance, when the activity really starts, some users may forget, the pushing effect is not ideal, and therefore the pushing time point needs to be shortened, for example, messages are received within 1-2 hours before the activity starts.

In order to solve the above problems, a multithreading method is currently adopted to perform message warehousing processing so as to store the relationship between the user ID and the message ID in the database while sending the message to the user mobile terminal. With the increase of the number of users, the number of threads to be opened is increased, the performance requirement on the server is gradually improved, but the number of threads reaches a certain bottleneck, so that the problem of low sending efficiency still cannot be solved.

Disclosure of Invention

In view of this, embodiments of the present invention provide a message pushing management method and device, which can at least solve the problem of low message sending efficiency in the prior art.

In order to achieve the above object, according to an aspect of the embodiments of the present invention, there is provided a message push management method, including:

counting login times of each user in the application within a preset historical time, determining users with the login times larger than or equal to a preset time threshold as active users, and determining the rest users as inactive users;

acquiring a message list corresponding to a single user, comparing messages in a message record list and the message list, and determining a non-pulled message; the message list is used for storing pulled messages, and the message record list is used for recording all messages pushed in the application;

preferentially executing the pulling operation of the non-pulled message of the active user, and executing the pulling operation of the non-pulled message of the inactive user after the message is pushed to the active user.

Optionally, the method further includes: responding to login application operation of a single active user, judging whether a free position exists in a current queue or not, and if so, adding the single active user to the tail of the queue; and if not, removing the active users at the head of the queue, and sequentially forwarding the active users at the rest positions to add the single active user to the tail of the queue.

Optionally, the comparing the messages in the message record table and the message list and determining the message not to be pulled includes: acquiring message identifiers of all messages in the message list, and determining the maximum message identifier; and if the maximum message identifier is smaller than the maximum message identifier in the message record table, taking the message positioned behind the maximum message identifier in the message list in the message record table as the non-pulled message.

Optionally, the acting as the non-pull message further includes: acquiring the generation time of each message, and removing the messages of which the generation time is earlier than the registration time of the user in the application; and/or obtaining an activity start time corresponding to each message, and removing messages with start times earlier than the current time.

Optionally, the obtaining a message list corresponding to a single user further includes: and grouping the messages in the message list according to the primary type and the secondary type of each message to obtain a plurality of sub-message lists.

Optionally, the method further includes: determining a log file corresponding to a user identifier of a single user, and storing the identifier of the pulled message into the log file; and synchronizing the log file to a cache; wherein the log file is stored in a database.

Optionally, the method further includes: acquiring the state of each message in the message list, and determining that the state is an unread message; and in response to the click-to-read operation on at least one unread message, changing the state of the at least one unread message to be read.

To achieve the above object, according to another aspect of the embodiments of the present invention, there is provided a message push management apparatus, including:

the system comprises a frequency counting module, a time counting module and a time counting module, wherein the frequency counting module is used for counting login times of each user in an application within preset historical time, the user with the login times larger than or equal to a preset frequency threshold value is determined as an active user, and the rest users are determined as inactive users;

the message determining module is used for acquiring a message list corresponding to a single user, comparing messages in the message record list and the message list and determining the messages which are not pulled; the message list is used for storing pulled messages, and the message record list is used for recording all messages pushed in the application;

and the message pulling module is used for preferentially executing the pulling operation of the non-pulled message of the active user and then executing the pulling operation of the non-pulled message of the non-active user after the message is pushed to the active user.

Optionally, the apparatus further includes a queue management module, configured to:

responding to login application operation of a single active user, judging whether a free position exists in a current queue or not, and if so, adding the single active user to the tail of the queue;

and if not, removing the active users at the head of the queue, and sequentially forwarding the active users at the rest positions to add the single active user to the tail of the queue.

Optionally, the message determining module is configured to: acquiring message identifiers of all messages in the message list, and determining the maximum message identifier; and if the maximum message identifier is smaller than the maximum message identifier in the message record table, taking the message positioned behind the maximum message identifier in the message list in the message record table as the non-pulled message.

Optionally, the message determining module is configured to: acquiring the generation time of each message, and removing the messages of which the generation time is earlier than the registration time of the user in the application; and/or obtaining an activity start time corresponding to each message, and removing messages with start times earlier than the current time.

Optionally, the message determining module is configured to: and grouping the messages in the message list according to the primary type and the secondary type of each message to obtain a plurality of sub-message lists.

Optionally, the system further includes a log synchronization module, configured to: determining a log file corresponding to a user identifier of a single user, and storing the identifier of the pulled message into the log file; and synchronizing the log file to a cache; wherein the log file is stored in a database.

Optionally, the system further includes a status updating module, configured to: acquiring the state of each message in the message list, and determining that the state is an unread message; and in response to the click-to-read operation on at least one unread message, changing the state of the at least one unread message to be read.

To achieve the above object, according to still another aspect of the embodiments of the present invention, an electronic device for message push management is provided.

The electronic device of the embodiment of the invention comprises: one or more processors; a storage device, configured to store one or more programs, where when the one or more programs are executed by the one or more processors, the one or more processors implement any of the above message push management methods.

To achieve the above object, according to a further aspect of the embodiments of the present invention, there is provided a computer readable medium, on which a computer program is stored, the computer program, when executed by a processor, implementing any of the above message push management methods.

According to the scheme provided by the invention, one embodiment of the invention has the following advantages or beneficial effects: the method and the system ensure that the message is pushed to the user in the previous golden time period (such as 1-2 hours) of the activity, effectively ensure the participation activity of the user, simultaneously maintain the active user group, and provide powerful support for other large data volume services. For the message management in the user message list, by comparing the message list with the message record table, which message users are not pulled can be determined, so that missing pushing of messages is avoided.

Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.

Drawings

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

fig. 1 is a schematic main flow chart of a message push management method according to an embodiment of the present invention;

FIG. 2 is a schematic diagram of FIFO principle processing of message queues for active users;

fig. 3 is a flowchart illustrating an alternative message push management method according to an embodiment of the present invention;

fig. 4 is a schematic diagram of main modules of a message push management apparatus according to an embodiment of the present invention;

FIG. 5 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;

FIG. 6 is a schematic block diagram of a computer system suitable for use with a mobile device or server implementing an embodiment of the invention.

Detailed Description

Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention 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 invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

Referring to fig. 1, a main flowchart of a message push management method according to an embodiment of the present invention is shown, including the following steps:

s101: counting login times of each user in the application within a preset historical time, determining users with the login times larger than or equal to a preset time threshold as active users, and determining the rest users as inactive users;

s102: acquiring a message list corresponding to a single user, comparing messages in a message record list and the message list, and determining a non-pulled message; the message list is used for storing pulled messages, and the message record list is used for recording all messages pushed in the application;

s103: preferentially executing the pulling operation of the non-pulled message of the active user, and executing the pulling operation of the non-pulled message of the inactive user after the message is pushed to the active user.

In the above embodiment, as for step S101, a database is usually configured in the application for storing the user login account (i.e. identification). The user usually selects the mobile phone number to log in, and even if logging in by other modes, the mobile phone number of the user can be inquired through the login account. The subsequent message also needs to be sent to the mobile terminal of the user through the mobile phone number, so that the user account is generally understood to be the mobile phone number.

The scheme distinguishes active users from inactive users; the active users can be regarded as users who log in more frequently. The background records the login IP address and the login time point every time a user logs in the application, so that the login times of each user in the application within the preset historical time can be counted, and the user with the login times being larger than or equal to the preset threshold is determined as an active user, otherwise, the user is determined as an inactive user.

For steps S102 and S103, before the activity starts, the message is preferentially pushed to the active user, and it is ensured that both the active users can receive the message. For inactive users, the process can continue subsequently using two ways:

1) the background multithreading continues to save the inactive user group and sends a message to the inactive user.

2) When logging in the application, the inactive user actively pulls the message list which is not received and pushes the notice to the background.

In addition, by means of the syntax of the redis plug value and the value, the total number of the active queues can be guaranteed for the active users. Referring to fig. 2, the queue length is 11, after the user 1 logs in, the identifier of the user 1 is placed at the tail of the queue, after the user 2 logs in, the queue sequence is 12, and so on, 1-11 are obtained. However, when the user 12 logs in, the queue is full, and the user 1 at the head of the queue needs to be moved out by adopting a first-in first-out principle, and at this time, the queue sequence is 2-12.

It should be noted that besides Redis, mysql may also be implemented by means of mysql, but mysql requires all data to be put in storage, and only a small amount of data can be queried in each query, and performance is weak, so Redis is mainly used in the present scheme.

For a single user, how to determine which messages the user drops without pulling and how to pull the messages.

An operator sets a total-station pushing function in an application background in advance. When a message needs to be pushed to a user (usually hundreds or even tens of millions) in a total station, the function can be triggered to allow an operator to manually send the message, and a mobile end of the user can receive the message box of the application.

After the user logs in the application, the application will first display the list of messages that have been pulled to the message presentation under its user identification. All messages are put together before the primary and secondary types of unclassified messages, thus presenting a larger list of messages. With the increase of the number of messages and the improvement of application management, the messages can be classified into one level, two levels or even multiple levels (currently, the two levels are mainly used as the examples for the two levels), so that a corresponding message list (i.e., a sub-message list) can be established under each two-level type.

The first level, the second level and the multiple levels are only a scene description, and usually require the operator to manually define, for example, the first level type is a general message, and the second level type is a sub-category under the general message. Before pushing the message, the operator presets a primary type and a secondary type to which the message belongs, so that after the message is sent, the message can be displayed in a message list under the secondary type to which the message belongs.

In addition, for an active user, the message in the message list (or the sub-message list) is usually not empty, but for an inactive user, the message may be empty, at this time, the secondary type may be determined according to the primary type, and then the messages under each secondary type are acquired, and all the acquired messages are non-pulled messages.

And pre-establishing a user log for storing a corresponding relation between the user identifier and the message identifier of the message so as to be used for inquiring the message list and the subsequent inquiring message state. By querying the user log, the largest message identity in the current message list can be determined. If the maximum message identifier is zero, the user neither reads nor pulls the message before, all total-station push messages need to be inquired from the database message record table, and then the user is subjected to message storage.

The message record table of the total station push only records how many messages are pushed in total in the application and records in a message identification manner.

1) If the maximum message identifier is larger than the maximum message identifier of the message acquired by the user (for example, 10>5), it indicates that the identifier 6, the identifier 7, the identifier 8, the identifier 9, and the identifier 10 are not pulled messages, and this time, pulling is required to be started from the message of the identifier 6.

Further, some of the non-pulled messages may be generated earlier than the registration time of the subscriber identity, e.g., subscriber identity 2020.05.01 registered, while some of the pushed messages are generated 2019.10.10, and if these expired messages are pushed, they have no practical meaning, and therefore need to be pulled after the registration time.

Furthermore, some messages have expired corresponding activities, and it is meaningless to push these messages as well, so that messages with activity start time earlier than the current time can be removed.

2) If the number of the messages in the user message list is equal to the number of the messages in the database, the messages in the user message list are not different from the total number of the push messages in the database, the messages are all pushed into the database, and the messages do not need to be pulled again.

It should be noted that the above is described according to a single message list before the message is not classified, and actually, if the message is classified according to the primary and secondary types, the corresponding message record table may also be classified according to this method, and the determination method for the message not pulled is the same.

After the pulling operation of the un-pulled message is completed, the message needs to be displayed in a user message list, for example, the message pulled this time is arranged after the existing message is displayed according to the sorting of the message identifiers.

For the messages pulled this time, the user identifier and the message identifiers of the messages can be inserted into the user log as well. Since the log is primarily stored in the database, it can also be synchronized into the cache after the log is updated.

The updated message list may contain more messages, and thus may be gradually displayed in paging, thumbnail, interface sliding, and the like. And finally, assembling the messages to be displayed on the application, such as assembling user information and the like.

In the method provided by the embodiment, on a large-data-volume message pushing scene, by temporarily 'abandoning' a part of users, preferably pushing a message to an active user and then pushing the message to an inactive user, hierarchical sending is realized, so that the message sending efficiency is improved; and comparing the message record table with the user message list, determining which messages are not pulled for a single user, subsequently pulling the messages and synchronizing the messages to the message list for displaying, wherein the action is completed when the user logs in.

Referring to fig. 3, a schematic flow chart of an optional message push management method according to an embodiment of the present invention is shown, including the following steps:

s301: counting login times of each user in the application within a preset historical time, determining users with the login times larger than or equal to a preset time threshold as active users, and determining the rest users as inactive users;

s302: acquiring a message list corresponding to a single user, comparing messages in a message record list and the message list, and determining a non-pulled message; the message list is used for storing pulled messages, and the message record list is used for recording all messages pushed in the application;

s303: preferentially executing the pulling operation of the non-pulled message of the active user, and executing the pulling operation of the non-pulled message of the inactive user after the message is pushed to the active user;

s304: acquiring the state of each message in the message list, and determining that the state is an unread message;

s305: and in response to the click-to-read operation on at least one unread message, changing the state of the at least one unread message to be read.

In the above embodiment, the descriptions of steps S101 to S103 shown in fig. 1 can be referred to for steps S301 to S303, and are not repeated herein.

In the above embodiment, for the messages pushed to the users in steps S304 and S305, some users may have read the corresponding status, some are not read, and the corresponding status is not read.

The information status may also be stored in a cache and presented in the user message list to inform the user which messages have been read and which have not been read. But each message sent corresponds to a record to record the read/unread state thereof based on the user's demand for the read/unread state of the message.

The cache may be provided with a "read offset" for recording the number of read messages and the positions of the messages, and the offset in each level two type is a similar logic, and if there are 8 total-station push messages, the user has clicked to read the 5 th message at present.

In addition, the number of unread messages in each secondary type can be counted, and the sum of the counted number of messages is used as the total number of unread messages in the total station type. For example, the total number of unread messages is shown as 80 in the upper left corner of the application message option.

The user can click on the unread message in the message list, and the application responds to the click-to-read operation of the user to click on the message so as to change the state of the message from unread to read.

The method provided by the embodiment adaptively adjusts the read/unread states of the messages according to the read or unread operations of the user on the messages in the message list, so as to give the user a visual feeling.

Referring to fig. 4, a schematic diagram of main modules of a message push management apparatus 400 according to an embodiment of the present invention is shown, including:

the number counting module 401 is configured to count login times of each user in an application within a predetermined historical time, determine a user with the login time being greater than or equal to a predetermined threshold as an active user, and determine the remaining users as inactive users;

a message determining module 402, configured to obtain a message list corresponding to a single user, compare messages in the message record table and the message list, and determine a message that is not pulled; the message list is used for storing pulled messages, and the message record list is used for recording all messages pushed in the application;

the message pulling module 403 is configured to preferentially perform a pulling operation on an un-pulled message of an active user, and after the message is pushed to the active user, perform a pulling operation on an un-pulled message of an inactive user.

The apparatus further includes a queue management module 404 (not shown) for:

In the device for implementing the present invention, the message determining module 402 is configured to:

acquiring message identifiers of all messages in the message list, and determining the maximum message identifier;

and if the maximum message identifier is smaller than the maximum message identifier in the message record table, taking the message positioned behind the maximum message identifier in the message list in the message record table as the non-pulled message.

acquiring the generation time of each message, and removing the messages of which the generation time is earlier than the registration time of the user in the application; and/or

And acquiring the activity starting time corresponding to each message, and removing the messages with the starting time earlier than the current time.

In the device for implementing the present invention, the message determining module 402 is configured to: and grouping the messages in the message list according to the primary type and the secondary type of each message to obtain a plurality of sub-message lists.

The device for implementing the present invention further includes a log synchronization module 405 (not shown in the figure) for:

determining a log file corresponding to a user identifier of a single user, and storing the identifier of the pulled message into the log file; and

synchronizing the log file to a cache; wherein the log file is stored in a database.

The apparatus further includes a status update module 406 (not shown) for:

acquiring the state of each message in the message list, and determining that the state is an unread message;

and in response to the click-to-read operation on at least one unread message, changing the state of the at least one unread message to be read.

In addition, the detailed implementation of the device in the embodiment of the present invention has been described in detail in the above method, so that the repeated description is not repeated here.

Fig. 5 illustrates an exemplary system architecture 500 to which embodiments of the invention may be applied.

As shown in fig. 5, the system architecture 500 may include

terminal devices

501, 502, 503, a network 504, and a server 505 (by way of example only). The network 504 serves to provide a medium for communication links between the

terminal devices

501, 502, 503 and the server 505. Network 604 may include various types of connections, such as wire, wireless communication links, or fiber optic cables, to name a few.

The user may use the

terminal devices

501, 502, 503 to interact with a server 505 over a network 504 to receive or send messages or the like. Various communication client applications may be installed on the

terminal devices

501, 502, 503.

The

terminal devices

501, 502, 503 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.

The server 505 may be a server providing various services, such as a background management server (for example only) providing support for shopping websites browsed by users using the

terminal devices

501, 502, 503.

It should be noted that the method provided by the embodiment of the present invention is generally executed by the server 505, and accordingly, the apparatus is generally disposed in the server 505.

It should be understood that the number of terminal devices, networks, and servers in fig. 5 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Referring now to FIG. 6, a block diagram of a computer system 600 suitable for use with a terminal device implementing an embodiment of the invention is shown. The terminal device shown in fig. 6 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present invention.

As shown in fig. 6, the computer system 600 includes a Central Processing Unit (CPU)601 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)602 or a program loaded from a storage section 608 into a Random Access Memory (RAM) 603. In the RAM 603, various programs and data necessary for the operation of the system 600 are also stored. The CPU 601, ROM602, and RAM 603 are connected to each other via a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.

The following components are connected to the I/O interface 605: an input portion 606 including a keyboard, a mouse, and the like; an output portion 607 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage section 608 including a hard disk and the like; and a communication section 609 including a network interface card such as a LAN card, a modem, or the like. The communication section 609 performs communication processing via a network such as the internet. The driver 610 is also connected to the I/O interface 605 as needed. A removable medium 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 610 as necessary, so that a computer program read out therefrom is mounted in the storage section 608 as necessary.

In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 609, and/or installed from the removable medium 611. The computer program performs the above-described functions defined in the system of the present invention when executed by the Central Processing Unit (CPU) 601.

It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having 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. In the present invention, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules described in the embodiments of the present invention may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor comprises a number counting module, a message determining module and a message pulling module. Where the names of these modules do not in some cases constitute a limitation on the module itself, for example, the message determination module may also be described as an "un-pulled message determination module".

As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise:

According to the technical scheme of the embodiment of the invention, the message is pushed to the user in the previous golden time period (such as 1-2 hours) of the activity, the participation activity of the user is effectively ensured, the active user group is maintained, and powerful support is provided for other large-data-volume services. For the message management in the user message list, by comparing the message list with the message record table, which message users are not pulled can be determined, so that missing pushing of messages is avoided.

The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A message push management method, comprising:

2. The method of claim 1, further comprising:

3. The method of claim 2, wherein comparing the messages in the message log table and the message list to determine the non-pulled message comprises:

4. The method of claim 3, wherein the acting as an un-pulled message further comprises:

5. The method of claim 1, wherein obtaining a list of messages corresponding to a single user further comprises: and grouping the messages in the message list according to the primary type and the secondary type of each message to obtain a plurality of sub-message lists.

6. The method of claim 1, further comprising:

7. The method of claim 1, further comprising:

8. A message push management device, comprising:

9. An electronic device, comprising:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-7.

10. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-7.