CN115004673B

CN115004673B - Message pushing method, device, electronic equipment and computer readable medium

Info

Publication number: CN115004673B
Application number: CN202080094837.0A
Authority: CN
Inventors: 刘杰
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd; Shenzhen Huantai Technology Co Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd; Shenzhen Huantai Technology Co Ltd
Priority date: 2020-05-26
Filing date: 2020-05-26
Publication date: 2024-04-16
Anticipated expiration: 2040-05-26
Also published as: WO2021237433A1; CN115004673A

Abstract

The application discloses a message pushing method, a device, electronic equipment and a computer readable medium, and relates to the field of pushing, wherein the method comprises the following steps: acquiring a message push request, wherein the message push request comprises a specified client identifier; determining a specified connector based on the specified client identifier, wherein the specified connector is connected with a specified SDK component, and the specified SDK component is a SDK component corresponding to the specified client; and sending a message to be pushed to the specified SDK component based on the specified connector so that the specified SDK component sends the message to be pushed to the specified client. The server sends the message to be pushed to the specified SDK component through the specified connector, and the specified SDK component sends the message to be pushed to the specified client. Therefore, the message can be pushed through the connector and the SDK component, and the pushing framework is simple.

Description

Message pushing method, device, electronic equipment and computer readable medium

Technical Field

The present disclosure relates to the field of pushing, and more particularly, to a message pushing method, device, electronic apparatus, and computer readable medium.

Background

The current society is an era of explosion of information volume, various information is transmitted to information receivers in various channel modes, various information is transmitted at all times, and the transmission mode is in a variety of states. At present, mobile phones are popular, network technology is developed, and information receiving is easy. With the development of internet technology, the application on the terminal is more and more, and the message push is an important means for transmitting information, and is an effective and active pulling way, and is widely used by various large app manufacturers. The pushed message can be manually specified or calculated by the service according to the user interests. With the maturation of the recommendation system, the recommendation system is more suitable for pushing, the focus of attention of the user can be effectively found through the recommendation system, the user interests are precisely positioned, the content of interest of the user is pushed, and the pushing effect is improved.

However, in the scheme of message pushing in the prior art, the structure of message pushing is attached to a third party architecture like zookeeper, and the structure is too complex.

Disclosure of Invention

The application provides a message pushing method, a message pushing device, electronic equipment and a computer readable medium, so as to overcome the defects.

In a first aspect, an embodiment of the present application provides a message pushing method, which is applied to a server side of a pushing system, where the pushing system further includes at least one client side, and the method includes: acquiring a message push request, wherein the message push request comprises a specified client identifier; determining a specified connector based on the specified client identifier, wherein the specified connector is connected with a specified SDK component, and the specified SDK component is a SDK component corresponding to the specified client; and sending a message to be pushed to the specified SDK component based on the specified connector so that the specified SDK component sends the message to be pushed to the specified client.

In a second aspect, an embodiment of the present application further provides a message pushing device, which is applied to a server side of a pushing system, where the pushing system further includes at least one client side, and the message pushing device includes: an acquisition unit, a determination unit and a transmission unit. The information pushing device comprises an acquisition unit and a message pushing unit, wherein the acquisition unit is used for acquiring the information pushing request, and the information pushing request comprises a specified client identifier. And the determining unit is used for determining a specified connector based on the specified client identifier, wherein the specified connector is connected with a specified SDK component, and the specified SDK component is the SDK component corresponding to the specified client. And the sending unit is used for sending the message to be pushed to the specified SDK component based on the specified connector so that the specified SDK component sends the message to be pushed to the specified client.

In a third aspect, an embodiment of the present application further provides an electronic device, including: one or more processors; a memory; one or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more applications configured to perform the above-described method.

In a fourth aspect, embodiments of the present application also provide a computer readable storage medium storing program code executable by a processor, the program code when executed by the processor causing the processor to perform the above method.

According to the message pushing method, the device, the electronic equipment and the computer readable medium, a message pushing request corresponding to the specified client identifier is obtained, a specified connector is determined based on the specified client identifier, the specified client is connected with the specified connector through a specified SDK component of the specified client, then a server sends a message to be pushed to the specified SDK component through the specified connector, and the specified SDK component sends the message to be pushed to the specified client. Therefore, the message can be pushed through the connector and the SDK component, and the pushing framework is simple.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly introduced below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 shows a schematic diagram of an application scenario of a message pushing method according to an embodiment of the present application;

FIG. 2 is a diagram of a message pushing architecture according to an embodiment of the present application;

fig. 3 shows a method flowchart of a message pushing method according to an embodiment of the present application;

fig. 4 is a method flowchart of a message pushing method according to another embodiment of the present application;

FIG. 5 is a schematic diagram of a message pushing architecture according to another embodiment of the present application;

FIG. 6 is a schematic diagram of a message cross-region notification provided herein;

fig. 7 is a method flowchart of a message pushing method according to another embodiment of the present application;

fig. 8 is a method flowchart of a message pushing method according to still another embodiment of the present application;

FIG. 9 is a block diagram of a message pushing device according to an embodiment of the present application;

FIG. 10 is a block diagram of a message pushing device according to another embodiment of the present application;

fig. 11 shows a schematic diagram of an electronic device provided in an embodiment of the present application;

fig. 12 is a storage unit for storing or carrying program code for implementing a message pushing method according to an embodiment of the present application.

Detailed Description

In order to enable those skilled in the art to better understand the present application, the following description will make clear and complete descriptions of the technical solutions in the embodiments of the present application with reference to the accompanying drawings in the embodiments of the present application.

Referring to fig. 1, fig. 1 is a schematic diagram illustrating an application scenario of a message pushing method according to an embodiment of the present application, where, as shown in fig. 1, a user terminal 10 and a server 20 are located in a wireless network or a wired network, and the user terminal 10 and the server 20 perform data interaction.

In some embodiments, the client is installed within the user terminal 10, for example, may be an application installed at the user terminal 10. The user logs in at the client through the account, and all information corresponding to the account can be stored in the storage space of the server 20. The server 20 may be a separate server, a server cluster, a local server, or a cloud server.

A user may interact with the server 20 through a network using the user terminal 10 to receive or transmit messages or the like. The user terminal 10 may have various communication client applications installed thereon, such as a web browser application, an instant messaging tool, social platform software, and the like.

The user terminal 10 may be a variety of electronic devices having a display screen and supporting web browsing, including but not limited to smartphones, tablets, laptop and desktop computers, and the like.

The server 20 may be a server providing various services, such as a server providing support for a live video website browsed by a user using the user terminal 10. The server 20 may process the message generated by the user using the user terminal 10, the server 20 may for example receive a target message generated by the user using the user terminal 10, the server 20 may for example process data such as received push information, and the server 20 may for example forward the push information to other user terminals 10.

The server 20 may be an entity server, and may also be, for example, a cluster of multiple servers, and some of the servers 20 may be, for example, a target message receiving server in the present application, configured to receive a target message generated by a user using the user terminal 10; some of the servers 20 may also be used, for example, as push servers in the present application, to push a target message to a message receiving end within a receiving group through a push server corresponding to the receiving group.

As shown in fig. 2, fig. 2 illustrates a message pushing architecture.

The registration authentication module is also cluster deployed, loaded through a pre-positioned proxy service (nminix). The main purpose of which is to authenticate and return a token to the client. Where Nginx is a high-performance HTTP and reverse proxy web server, and IMAP/POP3/SMTP services are also provided.

Push-server (push-route) cluster has a further role in returning a push-server available to the current client. The platform in fig. 2 may be referred to as a management platform that may view the current real-time online number, push messages to a given client, etc. Push messages then need to go through a push route (push-server) to find the true push node.

All push-servers need to register their own information into a coordination service (Zookeeper) at start-up. The ZooKeeper is a distributed application coordination service of open source codes, is an open source implementation of Chubbby of Google, and is an important component of Hadoop and Hbase. It is a software providing a consistency service for distributed applications, the provided functions include: configuration maintenance, domain name service, distributed synchronization, group service, etc. The registration authentication module subscribes to the nodes in the Zookeeper so that the latest service list can be obtained.

The core of the Zookeeper is atomic broadcast, and this mechanism ensures synchronization between the various service processes (servers). The protocol implementing this mechanism is called the coherence protocol (Zab protocol). The Zab protocol has two modes, a recovery mode (master selection) and a broadcast mode (synchronization), respectively. When the service starts or after the leader crashes, zab enters a recovery mode, which ends after the leader is elected and most servers have completed synchronizing with the state of the host process (leader). The state synchronization ensures that the leader and the Server have the same system state.

To ensure sequential consistency of transactions, the zookeeper employs an incremented transaction id number (zxid) to identify the transaction. All proposals (proposa l) add zxid when proposed. Zxid is a 64-bit number whose upper 32 bits are period number (epoch) to identify whether the leader relationship has changed, one leader is selected at a time, and there is a new epoch identifying the dominant period currently belonging to that leader. The lower 32 bits are used to increment the count.

And selecting a proper push-server for the client according to a preset standard after acquiring all the service lists. Specifically, the preset criteria may include: and ensuring the connection balance of each node as much as possible, and adding and deleting nodes to balance.

Specifically, the following algorithms are used to ensure equalization: the nodes are polled, i.e., allocated to clients one by one. But there may be a case where the newly added nodes are unevenly distributed. Hash (Hash) modulo. Similar to Ha Xisan list (HashMap), but the problem of polling also arises. Of course, the balancing can be performed once like HashMap, so that all clients are reconnected. However, this results in an interruption reconnection of all connections, which is somewhat costly. The problem of the Hash modulo mode brings about a consistent Hash algorithm, but some clients still need to be balanced. The weight is set, namely, the load condition of each node can be manually adjusted, even the system can be made to be automatic, the weight is automatically adjusted down based on monitoring when the load of some nodes is higher, and the weight can be improved when the load is lower.

When a platform pushes a message to a client, it needs to first know which node the channel of this client is stored on. That is, red is (i.e., routing memory) in the architecture diagram storing the routing relationship, when a client accesses a push-server, the unique identifier of the current client and ip+port of the service node need to be stored in Red is. And meanwhile, the connection relation is deleted in Red is when the client is offline.

Assuming that there are 10W clients, numbers, i.e., client identifications, may be set for all clients first. The batch of numbers is issued to a push route through Nginx under the platform. This batch of numbers may even be re-dispersed into each push-route for efficiency. And then, according to the number of the numbers, starting a multithreading mode to obtain a push-server corresponding to the client from the previous route Red is. And then the push-server is called in an HTTP mode to carry out real message issuing. After successful pushing, the result needs to be updated into a database, and the client which is not online can push again according to the service, and the like.

If the business is not suitable at the push-server, the processing platform (Kafka) can be selected for decoupling. All upstream data is directly input to Kafka. And then the consumption program takes out the data and writes the data into the database.

Wherein Kafka is a message consumption mechanism, and specifically may include broadcast consumption and single consumption. Wherein broadcast consumption is to identify messages belonging to a broadcast by defining a topic (topic) prefix, such as topicname: the gonggao1535680698557 realizes broadcast consumption by using different roles and different user identifiers (user ids) to represent corresponding user group identifiers (groups) when the prefixes are advertised messages. Wherein, a single consumption: a person (person) is prefixed to a topic by definition. For example, person1t time 1536031022097, where the number in between person and t time is the current user, and the corresponding group is fixed when the message is consumed, kafka cannot broadcast consumption, and only a certain user.

Then, the inventor finds that in the existing push architecture, the structure is relatively complex, for example, a third party middleware such as Kafka, red is, zookeeper is needed to be used, and meanwhile, the messaging of a machine room cannot be supported.

Therefore, in order to overcome the above-mentioned drawbacks, the embodiments of the present application provide a message pushing method, which is applied to a pushing system, where the pushing system includes a server and at least one client, and specifically, the pushing system may be a system shown in fig. 1, and then the server may be the server described above. In the embodiment of the present application, the execution body of the method may be a server. As shown in fig. 3, the method includes: s301 to S303.

S301: and acquiring a message push request.

Wherein the message push request includes a specified client identification. The message push request is used to request the sending of specified message content to a specified client.

In one embodiment, the message pushing request further includes a message identifier, where the message identifier is used to request to send a message corresponding to the message identifier to the specified client, that is, the message corresponding to the message identifier is used as the message to be pushed.

In one embodiment, if the message push request does not include a message push identifier, the content pushed by the server for each client is consistent, that is, the content to be pushed is pre-stored, the content to be pushed received by each client is the same, and the message push request is used for triggering the pre-acquired content to be pushed to be sent to the designated client.

S302: a designated connector is determined based on the designated client identification.

The specified connector is connected with a specified SDK component, wherein the specified SDK component is the SDK component corresponding to the specified client.

The connector may be a port of the service end, specifically, the port may be a physical port, or may be a data port, where the data port is used to package data according to a certain format, and send the packaged data to a client or other modules connected to the port. For example, the connector may be an API interface.

As an implementation manner, a connector correspondence table is stored in the server, and the connector correspondence table is used for recording the client identifier corresponding to each connector. Specifically, each linking machine corresponds to a linking machine identifier, and the corresponding relation between the connector identifier and the client identifier can record a connector corresponding table. And the connector corresponding table can determine the connector identifier corresponding to the specified client identifier in the message push request, thereby determining the specified connector corresponding to the specified client identifier.

As one implementation, the specified client corresponds to an SDK component, and the specified client is named as the specified SDK component for the SDK component.

Wherein SDK (Software Deve lopment Kit) components typically build a collection of development tools for application software for a particular software package, software framework, hardware platform, operating system, etc. Specifically, a plurality of interfaces to be accessed are integrated in the SDK component, and the server can be connected with the client through the integrated interfaces to be accessed. And, each client corresponds to at least one SDK component.

And in the equipment SDK component, a communication protocol between the server and the client is integrated, and the SDK component is used for realizing data interaction and communication between the server and the client.

As an implementation manner, each connector may be connected to at least one SDK component, specifically, a connector management record is provided in the server, and each connector corresponds to one connector management record, and the connection management record includes an identifier of each SDK component connected to the connector. Therefore, after determining a specified connector corresponding to the identification of a specified client according to a message push request, determining an SDK component to which the specified connector is connected, and searching for the SDK component corresponding to the identification of the specified client as the specified SDK component.

S303: and sending a message to be pushed to the specified SDK component based on the specified connector so that the specified SDK component sends the message to be pushed to the specified client.

The server side sends the message to be pushed to the specified SDK component through the specified connector, so that the specified client side can acquire the message to be pushed through the specified SDK component.

As one embodiment, the specified SDK component is integrated in the specified client, the specified client is installed in the user terminal, and a storage space for storing data of the specified client is included in the user terminal, the specified SDK component can store a message to be pushed into the storage space corresponding to the specified client, and notify the specified client that the message to be pushed is already stored into the storage space corresponding to the specified client, and the specified client can acquire the message to be pushed through the storage space.

As another embodiment, the specified SDK component may also be installed in a user terminal, where the user terminal is a terminal installed with a specified client, and the SDK component and the specified client are two independent programs, and the SDK component is used as a channel between the specified client and a specified connector, and is used for sending the message to be pushed to the specified client.

Therefore, the server sends the message to be pushed to the specified SDK component through the specified connector, and the specified SDK component sends the message to be pushed to the specified client. Therefore, the message can be pushed through the connector and the SDK component, and the pushing framework is simple.

Referring to fig. 4, fig. 4 shows a message pushing method, which is applied to a pushing system, where the pushing system includes a server and at least one client, and specifically, the pushing system may be the system shown in fig. 1, and then the server may be the server. In the embodiment of the present application, the execution body of the method may be a server. Specifically, as shown in fig. 4, the method includes: s401 to S403.

S401: and acquiring the message pushing request sent by the pushing module.

As one implementation, the server comprises a pushing module and a database module. As shown in fig. 5, the pushing module is configured to initiate a request for pushing a message to a client, that is, the pushing module may be used as a decision maker for pushing a message, and is configured to determine a pushing policy for pushing a message for the client.

As one embodiment, the push module includes a service intelligence component, a configuration center, and a registry. The registry may be an operation for implementing registration and subscription for individual servers or rooms or clients. For example, a registry is dynamic data that is not present in the development scenario, is generated and changed by the start-up and shut-down of some instances. Such as a new node joining the system or a new client (c.side) subscribing to all service changes, all online instances can be looked up by a service. Specifically, it can be realized by a technique such as zookeeper, etc, nacos, etcd, red is, condu l, eruka, or the like.

The configuration center can be used for carrying out parameter configuration on each node in the distributed system. Specifically, manual configuration and automated deployment based on Jenkins or an ib le are possible. The manual configuration mode is that configuration parameters of each server are manually modified by a configurator and processes of each server for realizing specified service or completing specified tasks are manually started. Specifically, a configuration file may be pushed for each node, that is, the pushed message is the configuration file of each node. After the configuration file is acquired, the node device can configure the designated parameters for running the designated program according to the configuration file. Wherein the specified parameters may include parameters related to the application. For example, the specified parameters may include service request timeout, thread pool and queue size, cache expiration time, database connection pool capacity, log output level, current limit fusing threshold, service security black-and-white list, etc. In addition, the specified parameters may also include configuration parameters of the operating environment, such as connection string configuration of databases, middleware, and other services. The specified parameters may also include parameters of the security configuration, such as a user name, password, access token, license certificate, etc.

The embodiment of the server side obtaining the message pushing request may be that the pushing module sends the message pushing request to the database module, so that the database module obtains the message pushing request sent by the pushing module.

As an implementation manner, the server further includes an interface module, specifically, the interface module and the connector belong to a database module, and specifically, the database module includes an interface module, a connector and a database management system. In some embodiments, the interface module is configured to implement connection between the push module and the database management system, and in particular, to implement read-write operations on the database. The database management system is used for managing the database.

In some embodiments, the pushing module may be an application message pushing component, that is, the pushing module may be an application program with an application message pushing function, and the server is integrated with the application message pushing component, so that the server has an application message pushing function, where the application message pushing component may be a component that the server pushes a client message for a user terminal.

Specifically, the application message pushing component may be an APP PUSH component, and then the pushing module may be an application system using APP PUSH, that is, the APP PUSH component may be an application system using APP PUSH. The application system generally comprises a computer hardware system, system software and application software. The basic hardware system of the computer consists of an arithmetic unit, a controller, a memory, a peripheral interface and a peripheral device weight. The system software includes an operating system, a compiler, a database management system, various high-level languages, and the like. The application software is composed of general support software and various application software packages. The application software may be software that is capable of using APP PUSH functions.

APP PUSH refers to active message pushing of an operator to user mobile equipment through own products or a third party tool. The user can see push message notifications on the mobile device lock screen and notification bar, which clicks on the APP and goes to the corresponding page.

As an implementation manner, the interface module is used as an APP PUSH interface, which defines a data transmission format between the PUSH module and the database module, and meanwhile, communication between different service ends can also pass through the interface module. In some embodiments, the message to be sent to the client is entered into the interface module in the form of a message queue, and the interface module is rewritten to the database management system to store the content of the message in the database.

In some embodiments, the database management system may be a relational database management system (MYSQL), the Connector may be a Connector, in particular MYSQL Connector is a MYSQL database client-programmed interface that provides an interface to access the database over a network.

As an implementation manner, the method for obtaining the message push request sent by the push module may be that an interface module obtains the message push request sent by the push module; the interface module writes the message push request to the database module, i.e. the interface module provides the push module with an interface for accessing the database, which may specifically be an API interface of the application layer. In some embodiments, the interface module may be an HTTP API, i.e. data is transferred between the push module and the interface module based on the HTTP protocol.

S402: a designated connector is determined based on the designated client identification.

S403: and sending a message to be pushed to the specified SDK component based on the specified connector so that the specified SDK component sends the message to be pushed to the specified client.

As one implementation mode, the interface module writes the message pushing request into the database module, the message pushing request includes a designated client identifier, and the database module establishes a message pushing task corresponding to the designated client identifier based on the message pushing request. The message push task may include a specified client identification.

In some embodiments, the interface module writes the message push request into a database management system, the message push task further includes an identifier of a message to be pushed, the database management system determines a designated connector based on the identifier of the designated client, sends the identifier of the message to be pushed to the designated connector, the designated connector obtains, from the database, the message to be pushed corresponding to the identifier of the message to be pushed according to the identifier of the message to be pushed, and sends the message to be pushed to the designated SDK component.

In other embodiments, the database module includes a plurality of connectors, each connector periodically reads a message pushing task in the database management system, and can identify a connector corresponding to each message pushing task according to a specific client identifier in the message pushing task, then acquire a message pushing task corresponding to the connector, and determine a message to be pushed according to the message pushing task.

In some embodiments, the message pushing task established by the database management system may further include an identifier of a designated connector and an identifier of a message to be pushed, where each connector is capable of scanning all the message pushing tasks and identifying the identifier of the connector in the message pushing task, so that the designated connector can scan the message pushing task including the identifier of the designated connector, and thus can acquire the message pushing task and determine the message to be pushed.

As one implementation, the designated connector obtains the message pushing task from the database module based on a preset time period. Specifically, the designated connector scans all the message pushing tasks based on a preset time period, and searches the message pushing tasks corresponding to the designated connector. The database management system can also issue a message pushing task to the designated connector according to a preset time period. The preset time period may be set according to a user's requirement, for example, may be 1 second.

Specifically, referring to fig. 5, an application system (for example, a registry) using App Push only needs to send a request for sending a message to an HTTP API of a server side of the App Push system, that is, send a message Push request. And designating the client, wherein the designated client can be one or a plurality of clients. The HTTP API then writes the posted message push task to MySQL.

After a preset period of time (after 1 second at the latest), the task message list for the client is obtained from MySQL by the designated connector. And simultaneously sending a message to the client. Wherein the designated connector is a connector connected with a designated client (a client accessing the App Push SDK).

As an implementation manner, message notification among multiple servers, that is, message notification across machine rooms, may also be implemented.

Specifically, the interface module acquires a synchronization request sent by other service ends, wherein the synchronization request comprises description contents of a specified message; and if the description content of the specified message is consistent with the description content of the message to be pushed, the interface module sends the message to be pushed to the interface modules of the other servers.

The description content may be a description of the content of the message, for example, may be a summary of the message, which is an introduction of the content of the message. As an embodiment, each message corresponds to a summary, and the description content may be the summary of the message, where the description content may include an introduction of the content of the message, and client information that needs to be pushed, and the client information may include at least one of an identifier and a type of a client. As an implementation manner, the client information may include the client identifier, the synchronization request sent by the other server includes the identifier of the client to be pushed, the interface module includes a plurality of message pushing requests sent by the pushing module, and each message pushing request includes the identifier of the client.

As an implementation manner, the interface module may set a message queue, where the message queue includes a plurality of message push requests, and then the interface module obtains a synchronization request sent by another server, analyzes the synchronization request to obtain client information, searches for a message push request matched with the client information, uses the matched message push request as a specified message push request, and sends message content corresponding to the specified message push request to the other server, so as to implement synchronization of a message and cross-regional message notification. The other servers can push the synchronized message to the corresponding clients.

As shown in fig. 6, fig. 6 shows two rooms, namely a central room and an a room, each including the above-mentioned service end and a client corresponding to each service end. The HTTP APIs of the machine room A send synchronous requests to the HTTP APIs of the central machine room, and message notification across the machine rooms can be achieved through interaction among the HTTP APIs, namely, the HTTP APIs of different machine rooms can continuously acquire notification messages required by the machine room from the HTTP APIs of the central machine room.

Therefore, the message pushing system for implementing the message pushing method provided by the embodiment of the application is low in landing difficulty, simple in upgrading and maintenance and simple in expansion. The number of connections of a Connector can support more than a million client connections, and a plurality of connectors and Http Api can be added to disperse the connections of clients or servers. Meanwhile, the matched App push SDK is simple to use. The configuration center and the registration center can be accessed simply, and the same channel can be multiplexed in the same SDK. And the problem that different systems consume resources due to different channels is solved.

In addition, after the transmission of the message to be pushed to the specified SDK component is performed, it may also be detected whether the message is successfully transmitted to the client, and then, based on the detection result, if the transmission is unsuccessful, the transmission is repeated.

Specifically, referring to fig. 7, fig. 7 shows a message pushing method, which is applied to a pushing system, where the pushing system includes a server and at least one client, and specifically, the pushing system may be the system shown in fig. 1, and then the server may be the server. In the embodiment of the present application, the execution body of the method may be a server. Specifically, as shown in fig. 7, the method includes: s701 to S705.

S701: and acquiring a message push request.

S702: a designated connector is determined based on the designated client identification.

S703: and sending a message to be pushed to the specified SDK component based on the specified connector so that the specified SDK component sends the message to be pushed to the specified client.

S704: and detecting a message pushing result of the appointed client.

As an implementation manner, the message pushing result of the specified client can be detected according to the information replied by the specified client, or the message pushing result of the specified client can be detected according to the message pushing record of the specified client.

Specifically, the implementation manner of detecting the message pushing result of the specified client may be to detect whether the indication information of the synchronous successfully received message fed back by the specified client is received; if the message is successfully received, judging that the message pushing result is a successfully received message; if the message is not successfully received, judging that the message pushing result is that the message is not successfully received.

The message pushing result comprises two results, namely a successfully received message and an unsuccessfully received message. The successful message receiving means that the client side successfully receives the message pushed by the server side, and the unsuccessful message receiving means that the client side does not successfully receive the message pushed by the server side. The indication information of the successful synchronous receiving message fed back by the client may be information in a format of text message, voice, picture or video, or may be a parameter value, which is used to characterize that the message pushed by the server has been successfully received.

As an implementation manner, the method may be to detect whether the indication information of the successful synchronization receiving message fed back by the specified client is received within a preset time period. Wherein the time start point of the preset time period may be a time point at which an operation of transmitting the message to be pushed to the specified SDK component based on the specified connector is performed, and the predetermined time length of the preset time period may be predetermined, for example, may be empirically set. In this embodiment, after the sending of the message to be pushed to the specified SDK component based on the specified connector is performed, the specified client waits for the indication information of the synchronization success reception message, that is, the indication information of whether the synchronization success reception message fed back by the specified client is received or not is determined within the preset time period.

As another embodiment, after the sending of the message to be pushed to the specified SDK component based on the specified connector is performed, a confirmation request is sent to the specified client, where the confirmation request is used to instruct the specified client to feed back the specified information. The time point of sending the confirmation request may be taken as the time starting point of the preset time period, and then it is determined whether the specified information fed back by the specified client based on the confirmation request is received in the preset time period.

In addition, in some embodiments, a message pushed to the client by the server may be recorded and set with a message identifier, and specifically, a message identifier corresponding to a message determined by the server to be pushed to a specified client is named as a first message identifier. After the client acquires the message pushed by the server, the client feeds back the identifier of the pushed message to the server, so that the server can determine whether the client successfully receives the message to be pushed according to the identifier of the message fed back by the client and the identifier of the message pushed to the client.

Specifically, the implementation of detecting the message pushing result of the specified client may be that a first message identifier corresponding to a message sent by the server to the specified client is obtained; acquiring a second message identifier fed back by the appointed client, wherein the second message identifier is a first message identifier corresponding to a message successfully received by the appointed client; and determining a message pushing result of the appointed client according to the first message identifier and the second message identifier.

As an implementation manner, the server sends at least one message to the designated client, and each message corresponds to a first message identifier, and then the client marks the first message identifiers of all successfully received messages as second message identifiers. For example, the server sends 5 messages to the specified client, where the first message identifiers of the 5 messages are respectively denoted as mes1, mes2, mes3, mes4, and mes5, and the messages successfully received by the client are denoted as mes2, mes3, and mes4, and the client marks the mes2, mes3, and mes4 as second message identifiers and returns the second message identifiers to the server. The server judges whether the second message identifier is matched with the first message identifier, if so, the message pushing result is judged to be the successfully received message; and if the message pushing results are not matched, judging that the message pushing results are unsuccessful in receiving the message. For example, in the above example, the second message identities are mes2, mes3, and mes4, and the service can determine that mes2, mes3, and mes4 were successfully received by the client, but that mes1 and mes5 were not successfully received by matching the first message identity and the second message identity.

In some embodiments, the implementation of determining whether the first message identifier and the second message identifier match may be to determine whether the first message identifier and the second message identifier are the same, for example, if the first message identifier is mes1 and the second message identifier is mes1, then it is indicated that the first message identifier and the second message identifier match. If the first message identifier is mes1 and the second message identifier is mes2, it indicates that the first message identifier and the second message identifier are not matched, it may be identified that the client side does not successfully acquire the message corresponding to mes1, for example, the received mes2 may be sent by other server sides.

S705: and if the message pushing result is that the message is not successfully received, the message to be pushed is sent to the appointed client again.

And if the message to be pushed is judged not to be successfully sent to the appointed client, the message to be pushed is sent to the appointed client again. In some embodiments, the operation of detecting the message pushing result of the specified client is returned again until the message to be pushed is successfully sent to the specified client.

As an embodiment, the number of retransmissions may be limited, specifically, S705 may be implemented by retransmitting the message to be pushed to the specified client, counting the number of transmissions, and if the number of transmissions is greater than a specified value, stopping executing the operation of retransmitting the message to be pushed to the specified client. Wherein, the appointed value can be set according to the requirement,

specifically, after the message to be pushed is sent to the specified SDK component based on the specified connector, detecting a message pushing result of the specified client; if the message pushing result is that the message is not successfully received, recording the times of sending the message to be pushed to the appointed SDK component by the server, judging whether the times are larger than an appointed numerical value, if so, sending the message to be pushed to the appointed client again, updating the times, and simultaneously, returning to execute the step of detecting the message pushing result of the appointed client and subsequent operations.

In addition, in the case where only one message is pushed for a certain period of time in the above embodiment, it may be determined whether or not to successfully send to a specified client with reference to the above embodiment, and when there are a plurality of messages to be pushed, a plurality of messages may be sent to the client by setting one send queue.

Specifically, referring to fig. 8, fig. 8 shows a message pushing method, which is applied to a pushing system, where the pushing system includes a server and at least one client, and specifically, the pushing system may be the system shown in fig. 1, and then the server may be the server. In the embodiment of the present application, the execution body of the method may be a server. Specifically, as shown in fig. 8, the method includes: s801 to S804.

S801: and acquiring a message push request.

S802: a designated connector is determined based on the designated client identification.

S803: and determining message sending queues corresponding to the messages to be pushed according to a preset sending sequence.

In this embodiment of the present application, if the number of to-be-pushed messages is multiple, the server may set a message sending queue for the multiple to-be-pushed messages. For example, the number of the information to be pushed is 5, and the first message identifiers corresponding to the 5 information to be pushed are mes1, mes2, mes3, mes4 and mes5 respectively, so that the determined message sending queue is [ mes1, mes2, mes3, mes4 and mes5].

S804: and sequentially sending the messages to be pushed to the specified SDK component according to the message sending queue based on the specified connector.

As an implementation manner, if the message sending queue corresponds to a sequence number, the service end sequentially sends a plurality of messages to be pushed to the client according to the sequence number of each message in the message sending queue, where the sequence number corresponding to mes1 is the sequence number 1, the sequence number corresponding to mes2 is the sequence number 2, the sequence number corresponding to mes3 is the sequence number 3, the sequence number corresponding to mes4 is the sequence number 4, and the sequence number corresponding to mes5 is the sequence number 5.

In some embodiments, the server sends each message to be pushed to the client according to the message sending list. Specifically, a serial number may be set at the client, and the serial number is updated once each time a message is successfully received. Specifically, the serial numbers of the messages in the message sending queue are recorded as first serial numbers, and the serial numbers of the messages successfully received by the records counted by the client are recorded as second serial numbers.

In this embodiment of the present application, assuming that the first sequence number is seq1 and the initial value is 0, after the first message is sent, the value of the first sequence number seq1 becomes 1, after the second message is sent, the value of the first sequence number seq1 becomes 2, and so on, if the number of the messages to be pushed is multiple, the corresponding relationship between the first message identifier and the value of the sequence number seq1 is: the sequence numbers seq1 corresponding to mes1, mes2, mes3, mes4 and mes5 are sequentially 1, 2, 3, 4 and 5.

Assuming that the second sequence number is seq2, the initial value is 0, when the client is successfully appointed to receive the message for the first time, the value of the second sequence number seq2 becomes 1, when the client is successfully appointed to receive the message for the second time, the value of the second sequence number seq2 becomes 2, and so on, if the client is successfully appointed to receive the message, the message comprises a plurality of mes1, mes2, mes3, mes4 and mes5, and the sequence numbers seq2 are sequentially 1, 2, 3, 4 and 5.

It should be noted that, the seq2 of the client is specified, and the seq2 is changed when the message is successfully received.

Thus, it may be determined whether the message to be pushed is successfully sent to the specified client according to the size relationship of the first sequence number and the second sequence number. Specifically, a size relation between the first serial number and the second serial number is obtained; and if the size relation meets the specified condition, judging that the message to be pushed is successfully sent to the specified client, otherwise, judging that the message to be pushed is not successfully sent to the specified client.

The size relationship may be whether the first sequence number is less than or equal to the second sequence number, or other size relationships capable of characterizing whether the first sequence number is less than or equal to the second sequence number, for example, a ratio between the first sequence number and the second sequence number may be obtained, if the ratio is greater than 1, it indicates that the first sequence number is greater than the second sequence number, and if the ratio is not greater than 1, it indicates that the first sequence number is less than or equal to the second sequence number.

Specifically, if the first sequence number is less than or equal to the second sequence number, the message to be pushed is successfully sent to the appointed client. For example, the first sequence number of mes2 is 2, which means that 2 messages are currently transmitted, i.e., the first sequence number of mes1 is 1, and if the second sequence number is 2, which means that two messages have been successfully received, it can be determined that mes2 has been successfully received.

In some embodiments, after the specified connector sequentially sends the plurality of messages to be pushed to the specified SDK component according to the message sending queue, determining the messages to be pushed which are not successfully sent to the specified client as failure messages; and sending the failure message to the specified SDK component.

Specifically, each message to be pushed corresponds to one first message identifier, and the plurality of first message identifiers are in one-to-one correspondence with the sequence numbers in the message sending queue, that is, the sequence number corresponding to the message 1 to the message 5, the sequence number corresponding to the message 1 is the sequence number 1, the sequence number corresponding to the message 2 is the sequence number 2, the sequence number corresponding to the message 3 is the sequence number 3, the sequence number corresponding to the message 4 is the sequence number 4, and the sequence number corresponding to the message 5 is the sequence number 5, if each message in the message sending queue is sent to a specified client in sequence according to the sequence number of the message sending queue, the sending sequence of each message in the message sending queues [ mes1, mes2, mes3, mes4, mes5] is the sequence number mes1, mes2, mes3, mes4, mes5.

The second message identifier is a first message identifier corresponding to a message which is successfully received by the appointed client recently. As an embodiment, the second message identifier may be a first message identifier corresponding to all messages that the specified client successfully receives. For example, designating that the messages successfully received by the client are mes1 and mes2, the second message is identified as mes1 and mes2. As another embodiment, the second information identifier may be a first message identifier corresponding to a part of messages in the messages received by the client.

Then, the client sends the second message identifier to the server, and the server searches the first message identifiers which are the same as the second message identifier by the plurality of first message identifiers and uses the first message identifiers as designated message identifiers; searching a sequence number corresponding to the appointed message identifier in the message sending queue to be used as a target sequence number; and sending the message to be pushed after the target sequence number in the message sending queue as a failure message, and sending the failure message to the specified SDK component.

Assuming that the message sending queues [ mes1, mes2, mes3, mes4, mes5] send mes1, mes2, mes3, mes4, and mes5 to the designated client in turn, and then, the second message obtained from the feedback of the designated client is identified as mes1 and mes2, it indicates that mes3, mes4, and mes5 are not successfully sent. Specifically, the second message identifier is matched with the first message identifier in the message sending queue, the determined designated message identifiers are mes1 and mes2, the determined target sequence number is sequence number 2, and then mes3, mes4 and mes5 corresponding to sequence numbers 3, 4 and 5 after the sequence number 2 are used as failure messages.

As one implementation manner, the plurality of first message identifications increase in sequence according to the sequence number of the message sending queue, and the second message identification is the largest first message identification in all messages successfully received by the appointed client.

Specifically, the connection between the server and the designated client may be disconnected due to abrupt disconnection of the connection or congestion of the line, so that a part of data cannot be successfully transmitted to the designated client. Thus, the message that was not successfully sent to the specified client may be retransmitted. Because the retransmission may reestablish the connection between the designated client and the server.

Specifically, the sequence numbers of the message transmission queues are sequentially increased, and as the sequence numbers are gradually increased, the message identifications are also gradually increased, for example, the first message identifications of the message transmission queues [ mes1, mes2, mes3, mes4, mes5], mes1, mes2, mes3, mes4, and mes5 are sequentially increased, that is, mes1 is minimum, and mes5 is maximum, then, the largest first message identification in the message successfully received by the specified client is marked as the second message identification, for example, the message successfully received by the specified client is marked as mes1, mes2, and mes3, and then the second message identification is marked as mes3.

The client is assigned to send the second message identifier to the server, and the server can determine that the messages after the first message identifier identical to the second message identifier are not successfully sent, namely messages after mes3 in [ mes1, mes2, mes3, mes4, mes5], namely messages after mes4 and mes5, in the message sending queue are failure messages.

Specifically, considering that data is suddenly unable to be transmitted due to a connection problem between the server and the designated client, it can be considered that a message before mes3 is successfully transmitted to the designated client, and a message after mes3 cannot be successfully transmitted due to a connection failure between the server and the designated client. Thus, after determining the failure message, for example, after determining that mes4 and mes5 were not successfully transmitted, mes4 and mes5 are transmitted again to the specified client, so that by transmitting the connection between the established server and the specified client again, it is possible to recover the connection therebetween with a high probability even if both can be successfully connected, and to successfully transmit mes4 and mes5 to the specified client.

Therefore, the message is re-arranged through the returned maximum message Id, so that all messages to be pushed are more likely to be successfully sent to the appointed client.

Referring to fig. 9, a block diagram of a message pushing device 900 provided in an embodiment of the present application is shown, where the device is applied to a service end of a pushing system, and the pushing system further includes at least one client, and specifically, the message pushing device 900 may include: an acquisition unit 901, a determination unit 902, and a transmission unit 903.

An obtaining unit 901, configured to obtain a message push request, where the message push request includes a specified client identifier.

And a determining unit 902, configured to determine, based on the specific client identifier, a specific connector, where the specific connector is connected to a specific SDK component, where the specific SDK component is an SDK component corresponding to the specific client.

A sending unit 903, configured to send a message to be pushed to the specified SDK component based on the specified connector, so that the specified SDK component sends the message to be pushed to the specified client.

It will be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working process of the apparatus and modules described above may refer to the corresponding process in the foregoing method embodiment, which is not repeated herein.

Referring to fig. 10, a block diagram of a message pushing device 1000 provided in an embodiment of the present application is shown, where the device is applied to a service end of a pushing system, and the pushing system further includes at least one client, and specifically, the message pushing device 1000 may include: an acquisition unit 1001, a determination unit 1002, a transmission unit 1003, and a detection unit 1004.

The obtaining unit 1001 is configured to obtain a message push request, where the message push request includes a specified client identifier.

Further, the server side includes a pushing module and a database module, and the obtaining unit 1001 is further configured to obtain the message pushing request sent by the pushing module.

Further, the server side further includes an interface module, and the obtaining unit 1001 is further configured to trigger the interface module to obtain a message pushing request sent by the pushing module, and trigger the interface module to write the message pushing request into the database module.

Further, the obtaining unit 1001 is further configured to trigger: the database module establishes a message pushing task corresponding to the specified client identifier based on the message pushing request; the appointed connector obtains the message pushing task from the database module, and sends the message to be pushed to the appointed SDK component based on the message pushing task.

Further, the obtaining unit 1001 is further configured to trigger: and acquiring the message pushing task from the database module by the appointed connector based on a preset time period.

The pushing module is a client using an application message pushing component. The application message pushing component is an APP PUSH component. The interface module is an HTTP API.

Further, the obtaining unit 1001 is further configured to trigger the interface module to obtain a synchronization request sent by another server, where the synchronization request includes a description content of the specified message; and if the description content of the specified message is consistent with the description content of the message to be pushed, the interface module sends the message to be pushed to the interface modules of the other servers.

A determining unit 1002, configured to determine, based on the specified client identifier, a specified connector, where the specified connector is connected to a specified SDK component, where the specified SDK component is an SDK component corresponding to the specified client.

A sending unit 1003, configured to send a message to be pushed to the specified SDK component based on the specified connector, so that the specified SDK component sends the message to be pushed to the specified client.

Further, the sending unit 1003 is further configured to determine a message sending queue corresponding to the plurality of messages to be pushed according to a preset sending sequence; and sequentially sending the messages to be pushed to the specified SDK component according to the message sending queue based on the specified connector.

Further, the sending unit 1003 is further configured to determine, as a failure message, a message to be pushed that is not successfully sent to the specified client; and sending the failure message to the specified SDK component.

Further, each message to be pushed corresponds to a first message identifier, the plurality of first message identifiers are in one-to-one correspondence with sequence numbers in the message sending queue, the second message identifier is a first message identifier corresponding to a message that the designated client has successfully received recently, and the sending unit 1003 is further configured to search, by using the plurality of first message identifiers, for a first message identifier that is the same as the second message identifier, as a designated message identifier; searching a sequence number corresponding to the appointed message identifier in the message sending queue to be used as a target sequence number; and taking the message to be pushed after the target sequence number in the message sending queue as a failure message.

The first message identifiers are sequentially increased according to the sequence number of the message sending queue, and the second message identifier is the largest first message identifier in all messages successfully received by the appointed client.

A detecting unit 1004, configured to detect a message pushing result of the specified client; and if the message pushing result is that the message is not successfully received, the message to be pushed is sent to the appointed client again.

Further, the detecting unit 1004 is further configured to detect whether indication information of a synchronization successful reception message fed back by the specified client is received; if the message is successfully received, judging that the message pushing result is a successfully received message; if the message is not successfully received, judging that the message pushing result is that the message is not successfully received.

Further, the detecting unit 1004 is further configured to obtain a first message identifier corresponding to a message sent by the server to the specified client; acquiring a second message identifier fed back by the appointed client, wherein the second message identifier is a first message identifier corresponding to a message successfully received by the appointed client; and determining a message pushing result of the appointed client according to the first message identifier and the second message identifier.

Further, the detecting unit 1004 is further configured to determine whether the first message identifier and the second message identifier match; if the message pushing result is matched, judging that the message pushing result is that the message is successfully received; and if the message pushing results are not matched, judging that the message pushing results are unsuccessful in receiving the message.

In several embodiments provided herein, the coupling of the modules to each other may be electrical, mechanical, or other.

In addition, each functional module in each embodiment of the present application may be integrated into one processing module, or each module may exist alone physically, or two or more modules may be integrated into one module. The integrated modules may be implemented in hardware or in software functional modules.

Referring to fig. 11, a block diagram of an electronic device according to an embodiment of the present application is shown. The electronic device 100 may be a smart phone, a tablet computer, an electronic book, or the like capable of running an application program. The electronic device 100 in the present application may be the above-mentioned service end. In particular, the electronic device 100 may include one or more of the following components: a processor 110, a memory 120, and one or more application programs, wherein the one or more application programs may be stored in the memory 120 and configured to be executed by the one or more processors 110, the one or more program(s) configured to perform the method as described in the foregoing method embodiments.

Processor 110 may include one or more processing cores. The processor 110 utilizes various interfaces and lines to connect various portions of the overall electronic device 100, perform various functions of the electronic device 100, and process data by executing or executing instructions, programs, code sets, or instruction sets stored in the memory 120, and invoking data stored in the memory 120. Alternatively, the processor 110 may be implemented in at least one hardware form of digital signal processing (Digita l Signa l Process ing, DSP), field programmable gate array (Fie ld-Programmab le Gate Array, FPGA), programmable logic array (Programmab le Logic Array, PLA). The processor 110 may integrate one or a combination of several of a central processing unit (Centra l Process ing Un it, CPU), an image processor (Graph ics Process i ng Un it, GPU), and a modem, etc. The CPU mainly processes an operating system, a user interface, an application program and the like; the GPU is used for being responsible for rendering and drawing of display content; the modem is used to handle wireless communications. It will be appreciated that the modem may not be integrated into the processor 110 and may be implemented solely by a single communication chip.

The Memory 120 may include a random access Memory (Random Access Memory, RAM) or a Read-only Memory (Read-only Memory). Memory 120 may be used to store instructions, programs, code, sets of codes, or sets of instructions. The memory 120 may include a stored program area and a stored data area, wherein the stored program area may store instructions for implementing an operating system, instructions for implementing at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing the various method embodiments described below, etc. The storage data area may also store data created by the electronic device 100 in use (e.g., phonebook, audiovisual data, chat log data), and the like.

Referring to fig. 12, a block diagram of a computer readable storage medium according to an embodiment of the present application is shown. The computer readable medium 1200 has stored therein program code that can be invoked by a processor to perform the methods described in the method embodiments described above.

The computer readable storage medium 1200 may be an electronic memory such as a flash memory, an EEPROM (electrically erasable programmable read only memory), an EPROM, a hard disk, or a ROM. Optionally, the computer readable storage medium 1200 includes a non-volatile computer readable medium (non-trans itory computer-readab le storage med ium). The computer readable storage medium 1200 has memory space for program code 1210 that performs any of the method steps described above. The program code can be read from or written to one or more computer program products. Program code 1210 may be compressed, for example, in a suitable form.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present application, and are not limiting thereof; although the present application has been described in detail with reference to the foregoing embodiments, one of ordinary skill in the art will appreciate that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not drive the essence of the corresponding technical solutions to depart from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A message pushing method, which is applied to a server side of a pushing system, wherein the server side comprises a pushing module and a database module, the database module comprises an interface module, a database management system and a plurality of connectors, the pushing system further comprises at least one client side, and the method comprises:

the interface module acquires a message pushing request sent by the pushing module;

the interface module writes the message push request into a database management system, wherein the message push request comprises a specified client identifier;

the database management system determines a specified connector corresponding to the identifier of the specified client from a plurality of connectors, wherein each connector is connected with at least one SDK component, the specified connector is connected with a specified SDK component, and the specified SDK component is the SDK component corresponding to the specified client;

The database management system issues a message pushing task to a designated connector according to a preset time period, wherein the message pushing task is used as a message to be pushed;

and sending a message to be pushed to the specified SDK component based on the specified connector so that the specified SDK component sends the message to be pushed to the specified client.

2. The method of claim 1, wherein the push module is an application message push component.

3. The method of claim 2, wherein the application message pushing component is an APP PUSH component.

4. The method of claim 1, wherein the interface module is an HTTP API.

5. The method of claim 1, wherein the message push request includes descriptive content of a message to be pushed, the method further comprising:

the interface module acquires synchronous requests sent by other service ends, wherein the synchronous requests comprise description contents of specified messages;

and if the description content of the specified message is consistent with the description content of the message to be pushed, the interface module sends the message to be pushed to the interface modules of the other servers.

6. The method of claim 1, wherein after the sending the message to be pushed to the specified SDK component based on the specified connector, further comprising:

detecting a message pushing result of the appointed client;

and if the message pushing result is that the message is not successfully received, the message to be pushed is sent to the appointed client again.

7. The method of claim 6, wherein the detecting the message push result of the specified client comprises:

detecting whether indication information of a synchronous successful receiving message fed back by the appointed client is received or not;

if the message is successfully received, judging that the message pushing result is a successfully received message;

if the message is not successfully received, judging that the message pushing result is that the message is not successfully received.

8. The method of claim 6, wherein the detecting the message push result of the specified client comprises:

acquiring a first message identifier corresponding to a message sent by the server to the appointed client;

acquiring a second message identifier fed back by the appointed client, wherein the second message identifier is a first message identifier corresponding to a message successfully received by the appointed client;

And determining a message pushing result of the appointed client according to the first message identifier and the second message identifier.

9. The method of claim 8, wherein the determining the message pushing result of the specified client according to the first message identifier and the second message identifier comprises:

judging whether the first message identifier is matched with the second message identifier;

if the message pushing result is matched, judging that the message pushing result is that the message is successfully received;

and if the message pushing results are not matched, judging that the message pushing results are unsuccessful in receiving the message.

10. The method of claim 1, wherein the message to be pushed is a plurality of, the sending the message to be pushed to the specified SDK component based on the specified connector comprising:

determining message sending queues corresponding to a plurality of messages to be pushed according to a preset sending sequence;

and sequentially sending the messages to be pushed to the specified SDK component according to the message sending queue based on the specified connector.

11. The method of claim 10, wherein after sequentially sending the plurality of messages to be pushed to the specified SDK component according to the message sending queue based on the specified connector, comprising:

Determining a message to be pushed which is not successfully sent to the appointed client side, and taking the message to be pushed as a failure message;

and sending the failure message to the specified SDK component.

12. The method of claim 11, wherein each message to be pushed corresponds to a first message identifier, and a plurality of the first message identifiers correspond to sequence numbers in the message sending queue one by one, and a second message identifier is a first message identifier corresponding to a message that the designated client has recently successfully received, and the determining that the message to be pushed is not successfully sent to the designated client, as a failure message, includes:

searching a first message identifier which is the same as the second message identifier by a plurality of first message identifiers as a designated message identifier;

searching a sequence number corresponding to the appointed message identifier in the message sending queue to be used as a target sequence number;

and taking the message to be pushed after the target sequence number in the message sending queue as a failure message.

13. The method of claim 12, wherein the plurality of first message identifications increase in sequence according to a sequence number of the message transmission queue, and wherein the second message identification is a largest first message identification among all messages successfully received by the designated client.

14. A message pushing device, which is applied to a service end of a pushing system, wherein the service end comprises a pushing module, an interface module, a plurality of connectors and a database management system, the pushing system further comprises at least one client, and the message pushing device comprises:

the information pushing system comprises an acquisition unit, an interface module and a database management system, wherein the acquisition unit is used for acquiring a message pushing request sent by the pushing module through the interface module, and writing the message pushing request into the database management system through the interface module, wherein the message pushing request comprises a designated client identifier;

a determining unit, configured to determine, by using the database management system, a specified connector corresponding to an identifier of the specified client from a plurality of connectors, where each connector is connected to at least one SDK component, and the specified connector is connected to a specified SDK component, where the specified SDK component is an SDK component corresponding to the specified client; a message pushing task is issued to a designated connector through a database management system according to a preset time period, and the message pushing task is used as a message to be pushed;

and the sending unit is used for sending the message to be pushed to the specified SDK component based on the specified connector so that the specified SDK component sends the message to be pushed to the specified client.

15. An electronic device, comprising:

one or more processors;

a memory;

one or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more applications configured to perform the method of any of claims 1-13.

16. A computer readable medium, characterized in that the computer readable medium stores a program code executable by a processor, which program code, when executed by the processor, causes the processor to perform the method of any of claims 1-13.