WO2021237433A1

WO2021237433A1 - Message pushing method and apparatus, and electronic device and computer-readable medium

Info

Publication number: WO2021237433A1
Application number: PCT/CN2020/092206
Authority: WO
Inventors: 刘杰
Original assignee: 深圳市欢太科技有限公司; Oppo广东移动通信有限公司
Priority date: 2020-05-26
Filing date: 2020-05-26
Publication date: 2021-12-02
Also published as: CN115004673B; CN115004673A

Abstract

The present application relates to the field of pushing, and disclosed are a message pushing method and apparatus, and an electronic device and a computer-readable medium. The method comprises: obtaining a message pushing request, the message pushing request comprising a specified client identifier; determining a specified connector on the basis of the specified client identifier, the specified connector being connected to a specified SDK assembly, wherein the specified SDK assembly is an SDK assembly corresponding to a specified client; and sending, to the specified SDK assembly on the basis of the specified connector, a message to be pushed, so that the specified SDK assembly sends said message to the specified client. A server sends said message to the specified SDK assembly by means of the specified connector, and the specified SDK assembly sends said message to the specified client. Therefore, message pushing can be achieved by means of a connector and an SDK assembly, and a pushing framework is simple.

Description

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

Technical field

This application relates to the push field, and more specifically, to a message push method, device, electronic device, and computer-readable medium.

Background technique

The current society is an era of information explosion. All kinds of information are conveyed to information recipients through various channels. There are all kinds of news at every moment, and the way of transmission is also varied. At present, the popularization of mobile phones and the development of network technology have made it simple and easy to receive information. With the development of Internet technology, there are more and more applications on the terminal. As an important means of transmitting information, message push is an effective way to stimulate activity and is widely used by major app manufacturers. The pushed message can be manually designated, or it can be calculated by the service based on user interests. As the recommendation system matures, it is more suitable to apply it to push. The recommendation system can effectively find the focus of user attention, accurately locate user interests, push content that users are interested in, and improve the push effect.

However, in the current message push solution in the prior art, the structure of the message push depends on a third-party architecture like zookeeper, and the structure is too complicated.

Summary of the invention

This application proposes a message push method, device, electronic equipment, and computer readable medium to improve the above-mentioned drawbacks.

In the first aspect, an embodiment of the present application provides a message push method, which is applied to a server of a push system, the push system further includes at least one client, and the method includes: obtaining a message push request, the message push request It includes a designated client identifier; a designated connector is determined based on the designated client identifier, and the designated connector is connected to a designated SDK component, wherein the designated SDK component is the SDK component corresponding to the designated client; The designated connector sends the message to be pushed to the designated SDK component, so that the designated SDK component sends the message to be pushed to the designated client.

In the second aspect, the embodiments of the present application also provide a message pushing device, which is applied to the server of the pushing system, the pushing system further includes at least one client, and the message pushing device includes: an acquiring unit, a determining unit, and a sending unit. unit. The obtaining unit is configured to obtain a message push request, where the message push request includes a designated client identifier. The determining unit is configured to determine a designated connector based on the designated client identifier, and the designated connector is connected to a designated SDK component, wherein the designated SDK component is an SDK component corresponding to the designated client. The sending unit is configured to send the message to be pushed to the designated SDK component based on the designated connector, so that the designated SDK component sends the message to be pushed to the designated client.

In a third aspect, an embodiment of the present application also provides an electronic device, including: one or more processors; a memory; one or more application programs, wherein the one or more application programs are stored in the memory And is configured to be executed by the one or more processors, and the one or more application programs are configured to execute the foregoing method.

In a fourth aspect, an embodiment of the present application also provides a computer-readable medium, the readable storage medium stores program code executable by a processor, and when the program code is executed by the processor, the processor Perform the above method.

The message push method, device, electronic equipment, and computer-readable medium provided in this application obtain the message push request corresponding to the designated client identifier, and determine the designated connector based on the designated client identifier, and the designated client passes the designated client’s designation The SDK component is connected to the designated connector, and then the server sends the message to be pushed to the designated SDK component through the designated connector, and the designated SDK component sends the message to be pushed to the designated client. Therefore, the push of messages can be realized through the connector and SDK components, and the push structure is simple.

Description of the drawings

In order to explain the technical solutions in the embodiments of the present application more clearly, the following will briefly introduce the drawings needed in the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those skilled in the art, without creative work, other drawings can be obtained based on these drawings.

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

Figure 2 shows a schematic diagram of a message push architecture provided by an embodiment of the present application;

FIG. 3 shows a method flowchart of a message pushing method provided by an embodiment of the present application;

FIG. 4 shows a method flowchart of a message pushing method provided by another embodiment of the present application;

FIG. 5 shows a schematic diagram of a message push architecture provided by another embodiment of the present application;

FIG. 6 shows a schematic diagram of a message cross-region notification provided by the present application;

FIG. 7 shows a method flowchart of a message pushing method provided by another embodiment of the present application;

FIG. 8 shows a method flowchart of a message pushing method provided by still another embodiment of the present application;

FIG. 9 shows a block diagram of a message pushing device provided by an embodiment of the present application;

FIG. 10 shows a block diagram of a module of a message pushing device provided by another embodiment of the present application;

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

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

Detailed ways

In order to enable those skilled in the art to better understand the solutions of the present application, the technical solutions in the embodiments of the present application will be described clearly and completely in conjunction with the accompanying drawings in the embodiments of the present application.

Please refer to FIG. 1, which shows a schematic diagram of an application scenario of a message push method according to an embodiment of the present application. 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 in the user terminal 10, for example, it may be an application program installed in the user terminal 10. The user logs in through an account at the client, 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, or a server cluster, and may be a local server or a cloud server.

The user can use the user terminal 10 to interact with the server 20 through the network to receive or send messages and so on. Various communication client applications, such as web browser applications, instant messaging tools, social platform software, etc., may be installed on the user terminal 10.

The user terminal 10 may be various electronic devices having a display screen and supporting web browsing, including but not limited to a smart phone, a tablet computer, a laptop portable computer, a desktop computer, and so on.

The server 20 may be a server that provides various services, for example, a server that provides support for a live video website browsed by the user using the user terminal 10. The server 20 can process messages generated by the user using the user terminal 10. The server 20 can, for example, receive target messages generated by the user using the user terminal 10. The server 20 can process the received push information and other data. The server 20 can also process The push information is forwarded to other user terminals 10.

The server 20 may be a physical server, or may be, for example, a cluster composed of multiple servers. A part of the server 20 may be, for example, a target message receiving server in the present application for receiving target messages generated by users using the user terminal 10; A part of the server 20 may also be used as a push server in the present application, for example, for pushing the target message to the message receiving end in the receiving group through the push server corresponding to the receiving group.

As shown in Figure 2, Figure 2 shows a message push architecture.

The registration authentication module is also deployed in a cluster, and is loaded through the front-end proxy service (Nginx). Its main purpose is to do authentication and return a token to the client. Among them, Nginx is a high-performance HTTP and reverse proxy web server, and also provides IMAP/POP3/SMTP services.

After the push-server cluster has another function, it has to return a push-server that can be used by the current client. The platform in Figure 2 can refer to the management platform, which can view the current real-time online number, push messages to designated clients, and so on. Push messages need to go through a push-server to find the real push node.

All push-servers need to register their information to the coordination service (Zookeeper) when they are started. ZooKeeper is a distributed, open source distributed application coordination service, an open source implementation of Google’s Chubby, and an important component of Hadoop and Hbase. It is a software that provides consistent services for distributed applications. The functions provided include: configuration maintenance, domain name services, distributed synchronization, group services, etc. The registration authentication module will subscribe to the nodes in Zookeeper, so that you can get the latest service list.

The core of Zookeeper is atomic broadcasting. This mechanism ensures synchronization between various service processes (Server). The protocol that implements this mechanism is called the consensus protocol (Zab protocol). The Zab protocol has two modes, which are recovery mode (primary selection) and broadcast mode (synchronization). When the service starts or after the leader crashes, Zab enters the recovery mode. When the leader is elected and most of the servers are synchronized with the state of the main process (leader), the recovery mode ends. State synchronization ensures that the leader and server have the same system state.

In order to ensure the consistency of the transaction sequence, zookeeper uses an increasing transaction id number (zxid) to identify the transaction. All proposals are added with zxid when they are made. In the implementation, zxid is a 64-bit number, and its high 32-bit is the period number (epoch) used to identify whether the leader relationship has changed. Every time a leader is selected, it will have a new epoch that identifies the current leader. The period of reign. The lower 32 bits are used to count up.

After obtaining the list of all services, select the appropriate push-server for the client according to preset standards. Specifically, the preset standard may include: try to ensure that the connection of each node is balanced, and whether to add or delete nodes to be balanced.

Specifically, there are several algorithms for ensuring balance: polling, that is, assigning each node to the client one by one. But there will be uneven distribution of new nodes. The way of Hash taking the modulus. Similar to HashMap, but there are also polling problems. Of course, you can do a balance like HashMap, and let all clients reconnect. However, this will cause all connections to be interrupted and reconnected, which is a bit expensive. Due to the problem of the Hash modulus method, a consistent Hash algorithm is brought about, but there will still be some clients that need to be balanced. Set the weight, that is, you can manually adjust the load of each node, or even make it automatic. Based on monitoring, when the load of some nodes is high, the weight will be automatically adjusted down, and the weight can be increased for the low load.

When the platform pushes messages to the client, it needs to know which node the client's channel is stored on. That is, Redis (ie, routing storage) that stores the routing relationship in the architecture diagram. When the client accesses the push-server, the unique identifier of the current client and the ip+port of the service node need to be stored in Redis. At the same time, this connection must be deleted in Redis when the client is offline.

Assuming that there are 10W clients, first, you can set numbers for all clients, that is, client IDs. Send these numbers to a push route through Nginx under the platform. In order to improve efficiency, this batch of numbers can even be distributed to each push-route again. Then according to the number of numbers, start multi-threading to get the push-server corresponding to the client from the previous route Redis. Then call push-server through HTTP to deliver real messages. After the push is successful, the result needs to be updated to the database, and the offline client can push it again according to the business, etc.

If it is not appropriate to do business in push-sever, you can completely choose the processing platform (Kafka) to decouple. Enter all upstream data directly into Kafka. Then the consumer program can take out the data and write it into the database.

Among them, Kafka is a message consumption mechanism, specifically, it can include broadcast consumption and single consumption. Among them, broadcast consumption is to identify the messages that belong to the broadcast by defining topic prefixes, such as topicname: gonggao1535680698557. When consuming these messages prefixed with announcements, different roles and different user IDs (userid) represent the corresponding user group IDs. (groupid), to achieve broadcast consumption. Among them, single consumption: by defining a topic prefixed by topic as a person (person). For example, person1time1536031022097, where the number between person and time is the current user, and the corresponding groupid is fixed when the message is consumed. Kafka cannot broadcast consumption and can only correspond to a certain user consumption.

Then, the inventor found in his research that the existing push architecture has a complicated structure. For example, third-party middleware such as Kafka, redis, and zookeeper need to be used, and at the same time, it cannot support the expansion of the computer room to send messages.

Therefore, in order to overcome the above shortcomings, an embodiment of the present application provides a message push method, which is applied to a push system, wherein the push system includes a server and at least one client. Specifically, the push system may be the one shown in FIG. 1 In the system shown, the server can be the above-mentioned server. In the embodiment of the present application, the execution subject of the method may be the server. As shown in Fig. 3, the method includes: S301 to S303.

S301: Obtain a message push request.

Among them, the message push request includes a designated client identifier. Then the message push request is used to request to send the specified message content to the specified client.

As an implementation manner, the message push request further includes a message identifier, and the message identifier is used to request to send a message corresponding to the message identifier to a designated client, that is, the message corresponding to the message identifier is used as a message to be pushed.

As an implementation manner, if the message push request does not include the message push identifier, the content pushed by the server for each client is consistent, that is, the content to be pushed is pre-stored, and the content to be pushed accepted by each client The content is the same, and the message push request is used to trigger the pre-obtained content to be pushed to be sent to the designated client.

S302: Determine a designated connector based on the designated client identifier.

The designated connector is connected to a designated SDK component, where the designated SDK component is an SDK component corresponding to the designated client.

Among them, the connector can be a port of the server. Specifically, the port can be a physical port or a data port. The data port is used to package data in a certain format and send the packaged data to the The client or other module connected to this port. For example, the connector can be an API interface.

As an implementation manner, a connector correspondence table is stored in the server, and the connector correspondence table is used to record the client identifier corresponding to each connector. Specifically, each connected machine corresponds to a connected machine ID, and the connector correspondence table can be recorded through the corresponding relationship between the connector ID and the client ID. The connector correspondence table can determine the connector identifier corresponding to the designated client identifier in the message push request, and then determine the designated connector corresponding to the designated client identifier.

As an implementation manner, the designated client corresponds to an SDK component, and the SDK component for the designated client is named the designated SDK component.

Among them, SDK (Software Development Kit) components are generally a collection of specific software packages, software frameworks, hardware platforms, operating systems and other development tools when building application software. Specifically, if multiple access interfaces are integrated in the SDK component, the server can connect to the client through the integrated access interface. And, each client corresponds to at least one SDK component.

In the device SDK component, the communication protocol between the server and the client is integrated, and the SDK component is used to implement data interaction and communication between the server and the client.

As an implementation manner, each connector can be connected to at least one SDK component. Specifically, a connector management record is set in the server, and each connector corresponds to a connector management record, and the connection management record includes the connector The ID of each SDK component connected. Therefore, after determining the designated connector corresponding to the designated client identifier according to the message push request, the SDK component connected to the designated connector is determined, and the SDK component corresponding to the designated client identifier is searched for as the designated SDK component.

S303: Send the message to be pushed to the designated SDK component based on the designated connector, so that the designated SDK component sends the message to be pushed to the designated client.

The server sends the message to be pushed to the designated SDK component through the designated connector, so that the designated client can obtain the message to be pushed through the designated SDK component.

As an implementation manner, the designated SDK component is integrated in the designated client, and the designated client is installed in the user terminal, and the user terminal includes a storage space for storing the data of the designated client. The designated SDK component can The message to be pushed is stored in the storage space corresponding to the designated client, and the designated client is notified that the message to be pushed has been stored in the storage space corresponding to the designated client, and the designated client can obtain the to-be pushed through the storage space information.

As another implementation manner, the designated SDK component can also be installed in a user terminal. The user terminal is a terminal with a designated client installed, and the SDK component and the designated client are two independent programs, and the SDK component is used as the designated The channel between the client and the designated connector is used to send the message to be pushed to the designated client.

Therefore, the server sends the message to be pushed to the designated SDK component through the designated connector, and the designated SDK component sends the message to be pushed to the designated client. Therefore, the push of messages can be realized through the connector and SDK components, and the push structure is simple.

Please refer to Figure 4. Figure 4 shows a message push method, which is applied to a push system, where the push system includes a server and at least one client. Specifically, the push system may be the system shown in Figure 1 , The server can be the above-mentioned server. In the embodiment of the present application, the execution subject of the method may be the server. Specifically, as shown in FIG. 4, the method includes: S401 to S403.

S401: Obtain the message push request sent by the push module.

As an implementation manner, the server includes a push module and a database module. As shown in Figure 5, the push module is used to initiate a request to push messages to the client, that is, the push module can act as a decision maker for message push, and is used to determine a push strategy for pushing messages to the client.

As an implementation manner, the push module includes a service intelligence component, a configuration center, and a registration center. The registration center may be used to implement registration and subscription operations for each server or computer room or client. For example, the registration center is dynamic data. These data do not exist in the development situation. They are generated and changed through the start and stop of some instances. For example, a new node is added to the system, or a new client is subscribed to all service changes, and all online instances can be found through a certain service. Specifically, it can be implemented through technologies such as zookeeper, etc, nacos, etcd, redis, consul, and eruka.

Among them, the configuration center can perform parameter configuration for each node in the distributed system. Specifically, it can be manual configuration and automated deployment based on Jenkins or Ansible. Among them, the manual configuration method is that the configuration personnel manually modify the configuration parameters of each server and manually start the process of each server for realizing the specified service or completing the specified task. Specifically, the configuration file may be pushed for each node, that is, the pushed message is the configuration file of each node. Wherein, after the node device obtains the configuration file, it can configure the specified parameters for running the specified program according to the configuration file. Wherein, the designated parameter may include application-related parameters. 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 fuse threshold, service security black and white list, etc. In addition, the specified parameters may also include configuration parameters of the operating environment, for example, connection string configuration of databases, middleware, and other services. The specified parameters may also include security configuration parameters, for example, user name, password, access token, license certificate, etc.

Then, an implementation manner for the server to obtain the message push request may be that the push module sends the message push request to the database module, so that the database module obtains the message push request sent by the push module.

As an implementation manner, the server further includes an interface module. Specifically, the above-mentioned interface module and connector all belong to a database module. Specifically, the database module includes an interface module, a connector, and a database management system. In some embodiments, the interface module is used to realize the connection between the push module and the database management system, specifically, to realize the read and write operations on the database. Among them, the database management system is used to manage the database.

In some embodiments, the push module may be an application message push component, that is, the push module may be an application with an application message push function, and the server is integrated with an application message push component, so that the server has an application message Push function, where the application message push component can be a component for the server to push client messages for the user terminal.

Specifically, the application message push component may be an APP PUSH component, and the push module may be an application system using APP PUSH, that is, the APP PUSH component may be an application system using APP PUSH. Among them, the application system generally consists of a computer hardware system, system software, and application software. The basic computer hardware system is composed of arithmetic unit and controller, memory, peripheral interface and peripheral equipment rights. System software includes operating system, compiler, database management system, various high-level languages, etc. The application software consists of general support software and various application software packages. Then the application software can be software that can use the APP PUSH function.

APP PUSH refers to the active push of messages to users' mobile devices by operators through their own products or third-party tools. Users can see push message notifications on the lock screen and notification bar of their mobile devices. Tap on the notification bar to wake up the APP and go to the corresponding page.

As an implementation manner, the interface module is used as an APP PUSH interface, which defines the data transmission format between the push module and the database module. At the same time, communication between different servers can also pass through the interface module. In some embodiments, the message to be sent to the client is input to the interface module in the form of a message queue, and the interface module is written into 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), and the connector may be a Connector. Specifically, MySQL Connector is an interface for MySQL database client programming, which provides access to the database through the network. interface.

As an implementation manner, the method for obtaining the message push request sent by the push module may be that the interface module obtains the message push request sent by the push module; the interface module writes the message push request into the The database module, that is, the interface module provides an interface for the push module to access the database. Specifically, the interface may be an API interface at the application layer. In some embodiments, the interface module may be HTTP API, that is, data is transmitted between the push module and the interface module based on the HTTP protocol.

S402: Determine a designated connector based on the designated client identifier.

S403: Send the message to be pushed to the designated SDK component based on the designated connector, so that the designated SDK component sends the message to be pushed to the designated client.

As an implementation manner, the interface module writes the message push request into the database module, and the message push request includes a designated client identifier, and the database module establishes a connection with the designated client identifier based on the message push request. Corresponding message push task. The message push task may include a designated client identifier.

In some embodiments, the interface module writes the message push request to the database management system. The message push task also includes the identification of the message to be pushed. The database management system determines the specified connector based on the identification of the specified client, and sends the message to be pushed. The identifier of is sent to the designated connector, and the designated connector obtains the message to be pushed corresponding to the identifier of the message to be pushed from the database 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, and each connector periodically reads the message push task in the database management system, and can identify each message push task according to the designated client identifier in the message push task. The corresponding connector then obtains the message push task corresponding to itself, and determines the message to be pushed according to the message push task.

In some embodiments, the message push task established by the database management system may also include the identifier of the designated connector and the identifier of the message to be pushed. Each connector can scan all message push tasks and identify the message push task. The identifier of the connector within, so that the specified connector can scan the message push task containing the identifier of the specified connector, so that the message push task can be obtained and the message to be pushed can be determined.

As an implementation manner, the designated connector obtains the message push task from the database module based on a preset time period. Specifically, it may be that the designated connector scans all message push tasks based on a preset time period, and finds the message push task corresponding to the designated connector. It may also be that the database management system issues a message push task to the designated connector according to a preset time period. Wherein, the preset time period can be set according to user requirements, for example, it can be 1 second.

Specifically, referring to Figure 5, an application system that uses App Push (for example: a registry) only needs to send a message delivery request to the HTTP API of the server of the App Push system, that is, send a message push request. At the same time specify the client, where the specified client can be one or multiple. Then, the HTTP API writes the sent message push task to MySQL.

After a preset time period (after 1 second at the latest), the designated connector obtains the client's task message list from MySQL. At the same time, a message is sent to the client. Among them, the designated connector is the connector that establishes a connection with the designated client (the client that accesses the App Push SDK).

As an implementation manner, it is also possible to implement message notification between multiple servers, that is, to implement message notification across computer rooms.

Specifically, the interface module obtains a synchronization request sent by another server, and the synchronization request includes the description content of a specified message; if the description content of the specified message is consistent with the description content of the message to be pushed, the interface The module sends the message to be pushed to the interface module of the other server.

Wherein, the description content may be a description of the content of the message, for example, it may be a summary of the message as an introduction to the content of the message. As an implementation manner, each message corresponds to a summary, the description content may be a summary of the message, the description content may include an introduction to the content of the message, the client information to be pushed, and the client information may include the client At least one of the identification and type of the terminal. 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, and the interface module includes multiple message push requests sent by the push module, and Each message push request includes the identification of the client.

As an implementation manner, the interface module can set a message queue, and the message queue includes multiple message push requests, then the interface module obtains synchronization requests sent by other servers, parses the synchronization requests to obtain client information, and finds information related to the The message push request that matches the client information, the matched message push request is used as the designated message push request, and the message content corresponding to the designated message push request is sent to the other server to achieve message synchronization and cross-region message notification . Among them, other servers can push the synchronized message to the corresponding client.

As shown in Figure 6, Figure 6 shows two computer rooms, namely the central computer room and the A computer room. Each computer room includes the aforementioned server and a client corresponding to each server. The HTTP API of the computer room A sends a synchronization request to the HTTP API of the central computer room. Through the interaction between HTTP APIs, message notifications across computer rooms can be realized. That is to say, the HTTP API of different computer rooms will continue to obtain the local computer room from the HTTP API of the central computer room. Required notification message.

Therefore, the message push system for implementing the message push method provided by the embodiment of the present application has low landing difficulty, simple upgrade and maintenance, and simple extension. The number of Connector connections can support more than one million client connections. At the same time, multiple Connectors and HTTP APIs can be added to decentralize client or server connections. At the same time, the supporting App push SDK is easy to use. The configuration center and the registration center can be easily accessed, and the same channel can be reused in the same SDK. And it solves the problem of resource consumption caused by different channels in different systems.

In addition, after the execution of sending the message to be pushed to the specified SDK component, it can also detect whether the message is successfully sent to the client, and then, based on the detection result, if the message is not sent successfully, it is sent again.

Specifically, please refer to FIG. 7. FIG. 7 shows a message push method applied to a push system. The push system includes a server and at least one client. Specifically, the push system may be the one shown in FIG. In the system shown, the server can be the above-mentioned server. In the embodiment of the present application, the execution subject of the method may be the server. Specifically, as shown in FIG. 7, the method includes: S701 to S705.

S701: Obtain a message push request.

S702: Determine a designated connector based on the designated client identifier.

S703: Send the message to be pushed to the designated SDK component based on the designated connector, so that the designated SDK component sends the message to be pushed to the designated client.

S704: Detect the message push result of the designated client.

As an implementation manner, the message push result of the designated client may be detected according to the information replies from the designated client, or the message push result of the designated client may be detected according to the message push record of the designated client described above.

Specifically, the implementation manner of detecting the message push result of the designated client may be to detect whether the indication information of the synchronous successful reception message fed back by the designated client is received; if it is successfully received, it is determined that the message push result is The message is successfully received; if it is not successfully received, it is determined that the message push result is an unsuccessful message reception.

Among them, the message push result includes two results, which are successfully received messages and unsuccessfully received messages. Wherein, the successful reception of the message indicates that the client has successfully received the message pushed by the server, and the unsuccessful reception of the message indicates that the client has not successfully received the message pushed by the server. Wherein, the indication information of the synchronously successfully received message fed back by the client can be a text message, voice, picture, or video format information, or a parameter value used to indicate that the message pushed by the server has been successfully received.

As an implementation manner, it may be detecting whether the indication information of the synchronization successful reception message fed back by the designated client is received within a preset time period. Wherein, the time starting point of the preset time period may be the time point at which the operation of sending the message to be pushed to the specified SDK component based on the specified connector is performed, and the predetermined time length of the predetermined time period may be predetermined, for example, , Can be set based on experience. Then, in this embodiment, after the execution of sending the message to be pushed to the designated SDK component based on the designated connector, it will wait for the designated client to feed back the indication information that the synchronization has successfully received the message, that is, it is determined that it is within the preset time period. Whether to receive the indication information of the synchronization successful reception message fed back by the specified client.

As another implementation manner, after sending the message to be pushed to the designated SDK component based on the designated connector, a confirmation request is sent to the designated client, and the confirmation request is used to instruct the designated client to feed back the designated SDK component. information. Then, the time point at which the confirmation request is sent 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 within the preset time period.

In addition, in some embodiments, the message pushed by the server to the client is recorded and the message identifier is set. Specifically, the message identifier corresponding to the message determined by the server to be pushed to the specified client is named the first message Logo. After the client obtains the message pushed by the server, it will feed back the identifier of the pushed message to the server, so that the server can determine the client based on the identifier of the message fed back by the client and the identifier of the message pushed to the client Whether the terminal successfully receives the message to be pushed.

Specifically, the implementation manner of detecting the message push result of the designated client may be to obtain the first message identifier corresponding to the message sent by the server to the designated client; and to obtain the second message fed back by the designated client An identifier, the second message identifier is a first message identifier corresponding to a message successfully received by the designated client; the message push result of the designated client is determined 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. Then, the client records the first message identifier of all successfully received messages as the first message identifier. 2. Message identification. For example, the server sends 5 messages to the designated client, and the first message identifiers of the 5 messages are respectively marked as mes1, mes2, mes3, mes4, and mes5, and the messages successfully received by the client are mes2, mes3, and mes4. The client then marks mes2, mes3, and mes4 as the second message identifiers, and returns the second message identifiers to the server. The server determines whether the second message identifier matches the first message identifier, and if it matches, it determines that the message push result is a successfully received message; if it does not match, it determines that the message push result is an unsuccessful message received. For example, in the above example, the second message identifiers are mes2, mes3, and mes4. By matching the first message identifier and the second message identifier, the service can determine that mes2, mes3, and mes4 are successfully received by the client, but mes1 and mes5 It was not successfully received.

In some embodiments, the implementation manner for determining whether the first message identifier and the second message identifier match may be determining whether the first message identifier and the second message identifier are the same, for example, the first message identifier is mes1 , The second message identifier is mes1, which means that the first message identifier matches the second message identifier. If the first message identifier is mes1 and the second message identifier is mes2, it means that the first message identifier and the second message identifier do not match, which may indicate that the client has not successfully obtained the message corresponding to mes1, for example, the received message Mes2 may be sent by another server.

S705: If the message push result is that the message is not successfully received, send the message to be pushed to the designated client again.

If it is determined that the message to be pushed is not successfully sent to the designated client, then the message to be pushed is sent to the designated client again. In some embodiments, the operation of detecting the message push result of the designated client is performed again afterwards, until the message to be pushed is successfully sent to the designated client.

As an implementation manner, the number of retransmissions may be limited. Specifically, the implementation manner of S705 may be that the message to be pushed is sent to the designated client again, and the number of transmissions is counted. If the number of times is greater than a designated value, Then stop performing the operation of sending the message to be pushed to the designated client again. Among them, the specified value can be set according to needs,

Specifically, after the message to be pushed is sent to the designated SDK component based on the designated connector, the message push result of the designated client is detected; if the message push result is that the message is not successfully received, the server will record the message push result. The number of times the message to be pushed is sent to the designated SDK component, and it is determined whether the number is greater than a designated value, and if it is less than or equal to, the message to be pushed is sent to the designated client again, and the number is updated, At the same time, it returns to execute the step of detecting the message push result of the designated client and subsequent operations.

In addition, in the above embodiment, when only one message is pushed for a certain period of time, you can refer to the above embodiment to determine whether it is successfully sent to the specified client, and when there are multiple messages to be pushed, you can set a sending queue Way to send multiple messages to the client.

Specifically, please refer to FIG. 8. FIG. 8 shows a message push method applied to a push system. The push system includes a server and at least one client. Specifically, the push system may be the one shown in FIG. In the system shown, the server can be the above-mentioned server. In the embodiment of the present application, the execution subject of the method may be the server. Specifically, as shown in FIG. 8, the method includes: S801 to S804.

S801: Obtain a message push request.

S802: Determine a designated connector based on the designated client identifier.

S803: Determine the message sending queues corresponding to the multiple messages to be pushed according to the preset sending order.

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

S804: Send the multiple messages to be pushed to the designated SDK component in sequence based on the designated connector and according to the message sending queue.

As an implementation manner, the message sending queue corresponds to a sequence number, the sequence number corresponding to mes1 is sequence number 1, the sequence number corresponding to mes2 is sequence number 2, the sequence number corresponding to mes3 is sequence number 3, the sequence number corresponding to mes4 is sequence number 4, and the sequence number corresponding to mes5 is The sequence number is sequence number 5. The server sends multiple messages to be pushed to the client in sequence according to the sequence numbers of each message in the message sending queue.

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 on the client, and the serial number is updated every time a message is successfully received. Specifically, the serial number of each message in the message sending queue is recorded as the first serial number, and the serial number of the successfully received message recorded by the client's statistics is recorded as the second serial number.

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

Assuming that the second sequence number is seq2, the initial value is 0. When the first designated client successfully receives the message, the value of the second sequence number seq2 becomes 1, and the second designated client successfully receives the message When, the value of the second sequence number seq2 becomes 2, and so on, if the designated client successfully receives multiple messages, namely mes1, mes2, mes3, mes4, and mes5, the sequence number seq2 is 1, in turn 2, 3, 4, and 5.

If you need to explain, specify the seq2 of the client, and the seq2 will be changed when the message is successfully received.

Therefore, it can be determined whether the message to be pushed is successfully sent to the designated client according to the size relationship between the first sequence number and the second sequence number. Specifically, the size relationship between the first sequence number and the second sequence number is acquired; if the size relationship meets a specified condition, it is determined that the message to be pushed is successfully sent to the specified client; otherwise, it is determined The message to be pushed is not successfully sent to the designated client.

Wherein, the size relationship may be whether the first serial number is less than or equal to the second serial number, or another size relationship that can characterize whether the first serial number is less than or equal to the second serial number, for example, it may also be the acquisition of the first serial number. The ratio between the serial number and the second serial number. If the ratio is greater than 1, it indicates that the first serial number is greater than the second serial number. If the ratio is not greater than 1, it indicates that the first serial number is less than or equal to the second serial number. No.

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

In some embodiments, after the designated connector sequentially sends a plurality of the messages to be pushed to the designated SDK component according to the message sending queue, it is determined that the messages to be pushed are not successfully sent to the designated client, As a failure message; sending the failure message to the designated SDK component.

Specifically, each of the messages to be pushed corresponds to the first message identifier, and a plurality of the first message identifiers correspond to the sequence numbers in the message sending queue in a one-to-one correspondence, that is, the aforementioned mes1 to mes5, and mes1 correspond to The serial number is serial number 1, the serial number corresponding to mes2 is serial number 2, the serial number corresponding to mes3 is serial number 3, the serial number corresponding to mes4 is serial number 4, and the serial number corresponding to mes5 is serial number 5. Then, if the message is sent according to the serial number of the message sending queue Each message in the queue is sent to the designated client in turn, and the sending order of each message in the message sending queue [mes1, mes2, mes3, mes4, mes5] is mes1, mes2, mes3, mes4, and mes5.

The second message identifier is the first message identifier corresponding to the message successfully received recently by the designated client. As an implementation manner, the second message identifier may be a first message identifier corresponding to all messages successfully received by the designated client. For example, if it is specified that the messages successfully received by the client are mes1 and mes2, the second message identifiers are mes1 and mes2. As another implementation manner, the second information identifier may be a first message identifier corresponding to a part of the message received by the client.

Then, the client sends the second message identifier to the server, and the server uses the plurality of first message identifiers to search for the first message identifier that is the same as the second message identifier, as the designated message identifier; Look up the sequence number corresponding to the specified message identifier in the queue as the target sequence number; use the message to be pushed after the target sequence number in the message sending queue as a failure message, and send the failure message to the specified SDK component .

Assume that the message sending queue [mes1, mes2, mes3, mes4, mes5], the server sends mes1, mes2, mes3, mes4, mes5 to the specified client in turn, and then obtains the second message identifier returned by the specified client as mes1 And mes2, it indicates that mes3, mes4, and mes5 were not successfully sent. Specifically, the second message identifier is matched with the first message identifier in the message sending queue, and the determined designated message identifiers are mes1 and mes2, and the determined target sequence number is sequence number 2, so that sequence numbers 3 and 3 after sequence number 2 are combined. Mes3, mes4, and mes5 corresponding to 4 and 5 are regarded as failure messages.

As an implementation manner, a plurality of 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 among all the messages successfully received by the designated client .

Specifically, the connection between the server and the designated client may be disconnected due to a sudden disconnection of the connection or congestion of the line, so that some data cannot be successfully sent to the designated client. Therefore, the message that was not successfully sent to the specified client can be resent. Because, resending can re-establish the connection between the specified client and the server.

Specifically, the sequence numbers of the message sending queues increase sequentially, and as the sequence numbers gradually increase, the message identifiers also gradually increase. For example, the aforementioned message sending queue [mes1, mes2, mes3, mes4, mes5], mes1, mes2 The first message identifiers of, mes3, mes4, and mes5 increase in turn, that is, mes1 is the smallest and mes5 is the largest. Then, the largest first message identifier in the messages successfully received by the client is designated as the second message identifier, for example, specify The messages successfully received by the client are mes1, mes2, and mes3, and the second message identifier is mes3.

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

Specifically, considering that the data cannot be transmitted suddenly due to the connection problem between the server and the designated client, it can be considered that the message before mes3 is successfully sent to the designated client, and the message after mes3 is due to the server and the designated client. The connection between the terminals is faulty and cannot be sent successfully. Therefore, after the failure message is determined, for example, after it is determined that mes4 and mes5 have not been successfully sent, mes4 and mes5 are sent to the designated client again, so that by sending the connection between the established server and the designated client again, there can be more High probability to restore the connection between the two, even if the two can successfully connect, and successfully send mes4 and mes5 to the designated client.

Therefore, by using the returned maximum message Id, the re-weighting of messages is performed, so that all messages to be pushed are more likely to be successfully sent to the specified client.

Please refer to FIG. 9, which shows a structural block diagram of a message push device 900 provided by an embodiment of the present application. The device is applied to the server of a push system. The push system further includes at least one client. Specifically, the The message pushing device 900 may include: an acquiring unit 901, a determining unit 902, and a sending unit 903.

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

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

The sending unit 903 is configured to send the message to be pushed to the designated SDK component based on the designated connector, so that the designated SDK component sends the message to be pushed to the designated client.

Those skilled in the art can clearly understand that, for the convenience and conciseness of the description, the specific working process of the device and module described above can be referred to the corresponding process in the foregoing method embodiment, which will not be repeated here.

Please refer to FIG. 10, which shows a structural block diagram of a message pushing device 1000 provided by an embodiment of the present application. The device is applied to the server of a pushing system. The pushing system further includes at least one client. The message pushing device 1000 may include: an acquiring unit 1001, a determining unit 1002, a sending unit 1003, and a detecting unit 1004.

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

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

Further, the server further includes an interface module, and the acquiring unit 1001 is also configured to trigger the interface module to acquire the message push request sent by the push module, and trigger the interface module to write the message push request into the Database module.

Further, the acquiring unit 1001 is also configured to trigger: the database module establishes a message push task corresponding to the designated client identifier based on the message push request; the designated connector acquires the message from the database module A push task, which sends the message to be pushed to the designated SDK component based on the message push task.

Further, the acquiring unit 1001 is further configured to trigger: the designated connector acquires the message push task from the database module based on a preset time period.

The push module is a client terminal that uses the application message push component. The application message pushing component is an APP PUSH component. The interface module is HTTP API.

Further, the acquiring unit 1001 is also configured to trigger the interface module to acquire a synchronization request sent by another server, the synchronization request includes the description content of the specified message; if the description content of the specified message is the same as the description of the message to be pushed If the content is consistent, the interface module sends the message to be pushed to the interface module of the other server.

The determining unit 1002 is configured to determine a designated connector based on the designated client identifier, and the designated connector is connected to a designated SDK component, wherein the designated SDK component is an SDK component corresponding to the designated client.

The sending unit 1003 is configured to send the message to be pushed to the designated SDK component based on the designated connector, so that the designated SDK component sends the message to be pushed to the designated client.

Further, the sending unit 1003 is further configured to determine the message sending queues corresponding to the multiple messages to be pushed according to a preset sending order; and send the multiple messages to be pushed in sequence according to the message sending queue based on the designated connector To the specified SDK component.

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

Further, each of the messages to be pushed corresponds to the first message identifier, and a plurality of the first message identifiers correspond to the sequence numbers in the message sending queue in a one-to-one correspondence, and the second message identifier is the Specify the first message identifier corresponding to the message successfully received by the client recently, and the sending unit 1003 is further configured to search for a first message identifier that is the same as the second message identifier from a plurality of the first message identifiers as the designated message identifier; The sequence number corresponding to the specified message identifier is searched in the message sending queue as the target sequence number; the message to be pushed after the target sequence number in the message sending queue is regarded as the failure message.

Wherein, the plurality of first message identifiers increase sequentially according to the sequence number of the message sending queue, and the second message identifier is the largest first message identifier among all the messages successfully received by the designated client.

The detection unit 1004 is configured to detect the message push result of the designated client; if the message push result is that the message is not successfully received, the message to be pushed is sent to the designated client again.

Further, the detection unit 1004 is also used to detect whether the indication information of the synchronization successful reception message fed back by the designated client is received; if it is successfully received, it is determined that the message push result is a successful reception message; if it is not successfully received , It is determined that the message push result is that the message is not successfully received.

Further, the detection unit 1004 is further configured to obtain the first message identifier corresponding to the message sent by the server to the designated client; and obtain the second message identifier fed back by the designated client, where the second message identifier is The first message identifier corresponding to the message successfully received by the designated client; and the message push result of the designated client is determined according to the first message identifier and the second message identifier.

Further, the detection unit 1004 is also used to determine whether the first message identifier and the second message identifier match; if they match, determine that the message push result is a successful reception of the message; if they do not match, determine the message The push result is that the message was not successfully received.

In the several embodiments provided in this application, the coupling between the modules may be electrical, mechanical or other forms of coupling.

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 above-mentioned integrated modules can be implemented in the form of hardware or software function modules.

Please refer to FIG. 11, which shows a structural block diagram of an electronic device provided by an embodiment of the present application. The electronic device 100 may be an electronic device capable of running application programs, such as a smart phone, a tablet computer, or an e-book. The electronic device 100 in this application may be the aforementioned server. Specifically, 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, where one or more application programs may be stored in the memory 120 and configured to be operated by one Or multiple processors 110 execute, and one or more programs are configured to execute the method described in the foregoing method embodiment.

The processor 110 may include one or more processing cores. The processor 110 uses various interfaces and lines to connect various parts of the entire electronic device 100, and executes by running or executing instructions, programs, code sets, or instruction sets stored in the memory 120, and calling data stored in the memory 120. Various functions and processing data of the electronic device 100. Optionally, the processor 110 may adopt at least one of digital signal processing (Digital Signal Processing, DSP), Field-Programmable Gate Array (Field-Programmable Gate Array, FPGA), and Programmable Logic Array (Programmable Logic Array, PLA). A kind of hardware form to realize. The processor 110 may integrate one or a combination of a central processing unit (Central Processing Unit, CPU), a graphics processing unit (Graphics Processing Unit, GPU), and a modem. Among them, the CPU mainly processes the operating system, user interface and application programs, etc.; the GPU is used for rendering and drawing of display content; the modem is used for processing wireless communication. It can be understood that the above-mentioned modem may not be integrated into the processor 110, but may be implemented by a communication chip alone.

The memory 120 may include random access memory (RAM) or read-only memory (Read-Only Memory). The memory 120 may be used to store instructions, programs, codes, code sets or instruction sets. The memory 120 may include a program storage area and a data storage area, where the program storage area may store instructions for implementing the operating system and instructions for implementing at least one function (such as touch function, sound playback function, image playback function, etc.) , Instructions for implementing the following various method embodiments, etc. The storage data area can also store data (such as phone book, audio and video data, chat record data) created by the electronic device 100 during use.

Please refer to FIG. 12, which shows a structural block diagram of a computer-readable storage medium provided by an embodiment of the present application. The computer-readable medium 1200 stores program code, and the program code can be invoked by a processor to execute the method described in the foregoing method embodiment.

The computer-readable storage medium 1200 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read Only Memory), EPROM, hard disk, or ROM. Optionally, the computer-readable storage medium 1200 includes a non-transitory computer-readable storage medium. The computer-readable storage medium 1200 has storage space for the program code 1210 for executing any method steps in the above-mentioned methods. These program codes can be read from or written into one or more computer program products. The program code 1210 may be compressed in a suitable form, for example.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: The technical solutions recorded in the foregoing embodiments are modified, or some of the technical features are equivalently replaced; these modifications or replacements do not drive the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

A message push method, characterized in that it is applied to a server of a push system, the push system further includes at least one client, and the method includes:

Acquiring a message push request, where the message push request includes a designated client identifier;

Determining a designated connector based on the designated client identifier, and the designated connector is connected to a designated SDK component, wherein the designated SDK component is an SDK component corresponding to the designated client;

Send the message to be pushed to the designated SDK component based on the designated connector, so that the designated SDK component sends the message to be pushed to the designated client.
The method according to claim 1, wherein the server includes a push module and a database module, and the acquiring message push request includes:

Obtain the message push request sent by the push module.
The method according to claim 2, wherein the server further comprises an interface module; and said obtaining the message push request sent by the push module comprises:

The interface module obtains the message push request sent by the push module;

The interface module writes the message push request into the database module.
The method according to claim 3, wherein the sending a message to be pushed to the designated SDK component based on the designated connector comprises:

The database module establishes a message push task corresponding to the designated client identifier based on the message push request;

The designated connector obtains the message push task from the database module, and sends the message to be pushed to the designated SDK component based on the message push task.
The method according to claim 4, wherein the designated connector obtains the message push task from the database module, comprising:

The designated connector obtains the message push task from the database module based on a preset time period.
The method according to claim 2, wherein the push module is an application message push component.
The method according to claim 6, wherein the application message pushing component is an APP PUSH component.
The method according to claim 3, wherein the interface module is HTTP API.
The method according to claim 3, wherein the message push request includes description content of the message to be pushed, and the method further comprises:

The interface module obtains a synchronization request sent by another server, where the synchronization request includes the description content of the specified message;

If the description content of the designated 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 module of the other server.
The method according to claim 1, wherein after the sending a message to be pushed to the designated SDK component based on the designated connector, the method further comprises:

Detecting the message push result of the designated client;

If the result of the message push is that the message is not successfully received, the message to be pushed is sent to the designated client again.
The method according to claim 10, wherein said detecting a message push result of said designated client terminal comprises:

Detecting whether the indication information of the synchronization successful reception message fed back by the designated client is received;

If it is successfully received, it is determined that the message push result is a successfully received message;

If it is not successfully received, it is determined that the message push result is that the message is not successfully received.
The method according to claim 10, wherein said detecting a message push result of said designated client terminal comprises:

Acquiring the first message identifier corresponding to the message sent by the server to the designated client;

Acquiring a second message identifier fed back by the designated client, where the second message identifier is a first message identifier corresponding to a message successfully received by the designated client;

Determine the message push result of the designated client according to the first message identifier and the second message identifier.
The method according to claim 12, wherein the determining the message push result of the designated client according to the first message identifier and the second message identifier comprises:

Judging whether the first message identifier and the second message identifier match;

If it matches, it is determined that the message push result is a successful message reception;

If there is no match, it is determined that the message push result is that the message is not successfully received.
The method according to claim 1, wherein there are multiple pieces of information to be pushed, and the sending the message to be pushed to the designated SDK component based on the designated connector comprises:

Determining a plurality of message sending queues corresponding to the messages to be pushed according to a preset sending order;

Based on the designated connector, sequentially send a plurality of the messages to be pushed to the designated SDK component according to the message sending queue.
The method according to claim 14, wherein the step of sending, based on the designated connector, the plurality of messages to be pushed to the designated SDK component in turn according to the message sending queue comprises:

It is determined that a message to be pushed that is not successfully sent to the designated client is regarded as a failure message;

Send the failure message to the designated SDK component.
The method according to claim 15, wherein each of the messages to be pushed corresponds to one of the first message identifiers, and a plurality of the first message identifiers corresponds to a sequence number in the message sending queue one-to-one The second message identifier is the first message identifier corresponding to the message successfully received recently by the designated client, and the message to be pushed that is determined to be unsuccessfully sent to the designated client, as a failure message, includes:

Searching for a first message identifier that is the same as the second message identifier from a plurality of the first message identifiers as the designated message identifier;

Searching for the sequence number corresponding to the specified message identifier in the message sending queue as the target sequence number;

The message to be pushed after the target sequence number in the message sending queue is regarded as a failure message.
The method according to claim 16, wherein a plurality of the first message identifiers are sequentially increased according to the sequence number of the message sending queue, and the second message identifiers are all messages successfully received by the designated client The largest first message identifier in.
A message pushing device, which is characterized in that it is applied to a server of a pushing system, the pushing system further includes at least one client, and the message pushing device includes:

An obtaining unit, configured to obtain a message push request, where the message push request includes a designated client identifier;

A determining unit, configured to determine a designated connector based on the designated client identifier, where the designated connector is connected to a designated SDK component, wherein the designated SDK component is an SDK component corresponding to the designated client;

The sending unit is configured to send the message to be pushed to the designated SDK component based on the designated connector, so that the designated SDK component sends the message to be pushed to the designated client.
An electronic device, characterized in that it comprises:

One or more processors;

Memory

One or more application programs, wherein the one or more application programs are stored in the memory and configured to be executed by the one or more processors, and the one or more application programs are configured to execute The method of any one of claims 1-17.
A computer-readable medium, wherein the computer-readable medium stores a program code executable by a processor, and when the program code is executed by the processor, the processor executes any of claims 1-17. One of the methods described.