CN107609086B - APP pushing method and engine system thereof - Google Patents
APP pushing method and engine system thereof Download PDFInfo
- Publication number
- CN107609086B CN107609086B CN201710799448.8A CN201710799448A CN107609086B CN 107609086 B CN107609086 B CN 107609086B CN 201710799448 A CN201710799448 A CN 201710799448A CN 107609086 B CN107609086 B CN 107609086B
- Authority
- CN
- China
- Prior art keywords
- task
- push
- module
- data
- pushing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 22
- 238000004891 communication Methods 0.000 claims abstract description 11
- 238000011144 upstream manufacturing Methods 0.000 claims abstract description 5
- 230000004044 response Effects 0.000 claims description 15
- 238000012544 monitoring process Methods 0.000 claims description 13
- 230000008569 process Effects 0.000 claims description 9
- 230000009471 action Effects 0.000 claims description 8
- 238000006243 chemical reaction Methods 0.000 claims description 5
- 238000010276 construction Methods 0.000 claims description 5
- 208000019116 sleep disease Diseases 0.000 claims description 4
- 238000010586 diagram Methods 0.000 description 6
- 239000000306 component Substances 0.000 description 5
- 230000000007 visual effect Effects 0.000 description 5
- LDSJMFGYNFIFRK-UHFFFAOYSA-N 3-azaniumyl-2-hydroxy-4-phenylbutanoate Chemical compound OC(=O)C(O)C(N)CC1=CC=CC=C1 LDSJMFGYNFIFRK-UHFFFAOYSA-N 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 241000272205 Columba livia Species 0.000 description 2
- 241000272201 Columbiformes Species 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 230000002708 enhancing effect Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 239000008358 core component Substances 0.000 description 1
- 230000005059 dormancy Effects 0.000 description 1
- 230000009191 jumping Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000007958 sleep Effects 0.000 description 1
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses an APP pushing method and an engine system thereof, which are formed by interconnecting an original pushing service system, a MongoDB database, a Redis database, an SQL Server database and a Kafka queue database. The push engine can convert data transmitted by an upstream system into a data format supported by each push service provider by using an internal push data adapter module, then transmits the data to a target device to be pushed in a communication mode specified by the service provider, then stores the result of the current push into a result storage module in the engine, and indirectly stores all push result data in the result storage module into a MongoDB database in batches through a Kafka queue database under the constraint of specified frequency and batch entry number. By applying the APP push method and the engine system thereof, one or more service providers can be freely selected to access the push service, and developers can quickly deploy a push service system on user equipment by writing a small amount of codes.
Description
Technical Field
The invention relates to a technical solution of APP push messages, in particular to an APP push method and an engine system thereof, which are compatible with multiple push service providers and can be developed and operated at low cost.
Background
With the popularization of mobile equipment and the high-speed development of internet technology, more and more living needs such as ticket buying and hotel booking can be completed through a mobile phone APP. After the user places an order, related information is sent to the user through a push technology, so that the excellent link for enhancing the user experience is achieved. In order to enable a broad range of developers to access push services more conveniently, apple companies open related program interfaces for the developers to use, users can send the content of messages appointed by the users to mobile phones of the users at appointed time through the interfaces, and after receiving the messages, the devices of the users can obtain reminding in the modes of ring, vibration, ticker and the like, and can see the messages in a notification bar of the system. When a user clicks on a message of the system notification bar, the message can be eliminated, and a behavior specified by a developer is triggered, such as opening a specific page of the APP. Since the interface opened by apple company is popular with developers, and a plurality of service providers in China also open similar interfaces for people to use, the data formats and calling methods of the push services are different because the push services do not form standards worldwide, and therefore, extra development cost is generated when developers try to replace the push service providers.
Disclosure of Invention
The invention aims to provide an APP pushing method and an engine system thereof, which solve the problem of low-cost development of compatibility and integrated application of data formats of different pushing services.
The first object of the present invention is achieved by the following technical solutions: an APP pushing method is characterized by being realized based on the association operation of a MongoDB database, a Redis database, an SQL Server database and a Kafka queue database, and comprises the following steps:
s1, constructing a Web platform, creating a push task through the Web platform of a visual interface, and providing service for checking task information, starting the push task, checking a push result and storing a message;
s2, constructing a push service interface, connecting an external system through the interface to create a push task, and providing service for checking task information, starting the push task, checking a push result and storing a message;
s3, constructing a push engine, automatically consuming a task waiting queue and an equipment queue in a Redis database in a single or batch mode, being compatible with data formats of multiple push suppliers in an adapter mode, automatically creating more threads or destroying redundant threads according to the task allowance in the equipment queue to adjust consumption speed, temporarily storing push results in the local, and storing the push results in a MongoDB database at a preset fixed frequency or number;
s4, constructing regular tasks, inquiring basic information data of the push tasks with the state of not starting or in progress from the SQL Server database at a preset fixed frequency, and writing basic information of the push tasks into a task waiting queue of Redis according to the number of the remaining items of the tasks in the corresponding equipment queue in the Redis database, or updating the state of the basic information data of the push tasks in the SQL Server to be completed;
and S5, constructing a message center, and providing the client to access the MongoDB database and inquire result data which is pushed in association with the self equipment.
Further, in the construction of a Web platform, a push task is created through a task creation module, the push task is composed of two parts, namely basic information and one or more pieces of equipment information, the basic information of each task comprises a globally unique queue name, and the basic information is stored in an SQL Server database; inquiring pushed task data through a task viewing module, wherein the task data comprise basic information and equipment information of a task, and one or more pieces of equipment information exist when the task is not started or is in progress; inquiring actual occurrence time and result of each pushing task through a task result module, wherein the result comprises actual pushing time and response result of each device related to the pushing task, and the response result comprises successful and failed identification, error code and error information; after a push task is created through a task starting module, the push task is dynamically started at regular time according to preset push time, and the action of starting the push task comprises the actions of writing basic information of the task into a task waiting queue in Redis and writing all device data of the task into a device queue of the task in the Redis; integrating the pushed basic task information and the pushed equipment information into pushed message data through a message storage module, and writing the pushed message data into a MongoDB database in batches according to the specified frequency and batch entries; in the construction of the push service interface, the push service interface opens a network interface which can be used for communication and provides equivalent services with a WEB platform for an external system.
Further, in the push engine, a batch task queue module consumes task basic data in a Redis task waiting queue, when one piece of task basic information is successfully taken out, a plurality of consumption threads of the task are created through the batch task push module, and when the number of the created consumption threads exceeds a preset threshold value, the creation operation is suspended until the number of the consumption threads is lower than the threshold value; the batch task pushing module consumes the device data in the device queue associated with the task in Redis by using a consumption thread, integrates the consumed device data with the basic information of the task and sends the integrated data to the adapter module until no device data of the task exists in the device queue, and then destroys the consumption thread; the single task pushing module is used for creating a fixed number of consuming threads to consume a single pushing fixed task queue when being started, sending the data into the adapter module and repeating the process until no data exists in the consumed queue, and then repeating the process of consuming the data and sending the data into the adapter after sleeping for several seconds; the data format conversion is carried out through a push data adapter module, a unified data format in the push system is converted into a data format supported by each push service provider, and then the data format is sent to a push task sending module; sending out and waiting for result response in a communication mode appointed by each push service provider through a push task sending module, and then sending the result of the push to a result storage module; and storing all the pushed results from the upstream task sending module into a Kafka queue database in batches through a result storage module.
Further, a section of code which can be executed at fixed frequency in a regular task is constructed, the code firstly queries incomplete push basic information data in an SQL Server database, then queries the number of the remaining items of the tasks in a task waiting queue of Redis equipment through a task monitoring module, and when the number of the remaining items is greater than a predefined threshold value, one or more pieces of basic information of the push tasks are written into the task queue of the Redis; and when the device queue has no data, the state of the push task is updated to be completed in the SQL Server.
Further, the constructed message center is used for the client to query through the APP or the Web site through the message query module, and after the query message of the client is sent, the unread information which is referred by the user is modified and marked as read through the message state module based on the transmitted equipment information and data format.
The second objective of the present invention is achieved by the following technical solutions: the APP push engine system is characterized by being realized based on MongoDB database, Redis database, SQL Server database and Kafka queue database correlation operation, and comprises the following components:
the Web platform is used for creating a push task through the Web platform of the visual interface, and providing service for checking task information, starting the push task, checking a push result and storing a message;
the push service interface is connected with an external system through an interface to create a push task and provide service for checking task information, starting the push task, checking a push result and storing a message;
the pushing engine can automatically consume the task waiting queue and the equipment queue in the Redis database in a single or multiple mode, is compatible with data formats of multiple pushing suppliers in an adapter mode, can automatically create more threads or destroy redundant threads to adjust consumption speed according to the task allowance in the equipment queue, and can temporarily store pushing results in the local and store the pushing results in an external data server in a preset fixed frequency or number;
the regular task unit is used for inquiring basic information data of the push tasks with the state of not starting or in progress from the SQL Server database at preset fixed frequency, and writing the basic information of the push tasks into a task waiting queue of the Redis according to the number of the residual equipment information items in the equipment queue corresponding to the tasks in the Redis database, or updating the state of the basic information data of the push tasks in the SQL Server to be completed;
and the message center provides the client to access the MongoDB database and inquire the result data pushed in association with the self equipment.
Further, a task creating module, a task viewing module, a task result module, a task starting module and a message storage module are arranged in the Web platform: creating a push task through a task creating module, wherein the push task is composed of two parts of basic information and one or more pieces of equipment information, the basic information of each task comprises a globally unique queue name, and the basic information is stored in an SQL Server database; inquiring pushed task data through a task viewing module, wherein the task data comprise basic information and equipment information of a task, and one or more pieces of equipment information exist when the task is not started or is in progress; inquiring actual occurrence time and result of each pushing task through a task result module, wherein the result comprises actual pushing time and response result of each device related to the pushing task, and the response result comprises successful and failed identification, error code and error information; after a push task is created through a task starting module, the push task is dynamically started at regular time according to preset push time, and the action of starting the push task comprises the actions of writing basic information of the task into a task waiting queue in Redis and writing all device data of the task into a device queue of the task in the Redis; integrating the pushed basic task information and the pushed equipment information into pushed message data through a message storage module, and writing the pushed message data into a MongoDB database in batches according to the specified frequency and batch entries; in the construction of the push service interface, the push service interface opens a network interface which can be used for communication and provides equivalent services with a WEB platform for an external system.
Further, a batch task queue module, a batch task pushing module, a single task pushing module, a pushed data adapter module, a pushed task sending module and a result storage module are arranged in the pushing engine, the batch task queue module consumes task basic data in the Redis task waiting queue, when one piece of task basic information is successfully taken out, a plurality of consumption threads of the task are created through the batch task pushing module, and when the number of created consumption threads exceeds a preset threshold value, the creating operation is suspended until the number of consumption threads is lower than the threshold value; the batch task pushing module consumes the device data in the device queue associated with the task in Redis by using a consumption thread, integrates the consumed device data with the basic information of the task and sends the integrated data to the adapter module until no device data of the task exists in the device queue, and then destroys the consumption thread; the single task pushing module is used for creating a fixed number of consuming threads to consume a single pushing fixed task queue when being started, sending the data into the adapter module and repeating the process until no data exists in the consumed queue, and then repeating the process of consuming the data and sending the data into the adapter after sleeping for several seconds; the data format conversion is carried out through a push data adapter module, a unified data format in the push system is converted into a data format supported by each push service provider, and then the data format is sent to a push task sending module; sending out and waiting for result response in a communication mode appointed by each push service provider through a push task sending module, and then sending the result of the push to a result storage module; and storing all the pushed results from the upstream task sending module into a Kafka queue database in batches through a result storage module.
Further, the regular task unit is provided with a task monitoring module and a task completion module, the task monitoring module executes a section of code at fixed frequency, the code firstly queries the incomplete push basic information data in the SQL Server database, then queries the number of the remaining items of the tasks in the task waiting queue of the Redis device through the task monitoring module, and when the number of the remaining items is greater than a predefined threshold value, one or more pieces of basic information of the push tasks are written into the task queue of the Redis device; and when the device queue has no data, the state of the push task is updated to be completed in the SQL Server.
Furthermore, the message center is provided with a message query module and a message state module, the client side can query through the APP or the Web site through the message query module, and after the query message of the client side is sent, the unread information which is consulted by the user is modified and marked as read through the message state module based on the transmitted equipment information and data format.
The APP pushing method and the engine system have the beneficial effects that: when the push service is accessed, one or more push service providers can be freely selected, and developers can access one service provider by writing a few codes through the push data adapter module and the push task sending module of the push engine in the device and the system. The device and the system can be deployed at the same time by one set or a plurality of sets, the more the deployment is, the higher the overall pushing performance is, and the user can deploy according to the actual needs of the user.
Drawings
FIG. 1 is an overall architecture diagram of the APP push engine system of the present invention.
FIG. 2 is a block diagram of a Web platform in the APP push engine system of the present invention.
FIG. 3 is a block diagram of a push engine in the APP push engine system according to the present invention.
FIG. 4 is a schematic diagram of scheduling multiple batch tasks simultaneously performed by a push engine in the APP push engine system according to the present invention.
Fig. 5 is a schematic scheduling diagram of a push engine in the APP push engine system of the present invention supporting multiple push providers simultaneously.
Detailed Description
The following detailed description of the embodiments of the present invention is provided in connection with the accompanying drawings for the purpose of facilitating understanding and understanding of the technical solutions of the present invention.
The APP pushing method and the engine system thereof mainly relate to a WEB platform, a pushing service interface, a pushing engine, a periodic task, a message center, a MongoDB database, a Redis database, an SQL Server database and a Kafka queue database. The overall architecture diagram is shown in fig. 1.
The push service is defined as bulk delivery and single delivery according to the characteristics of the target crowd range. Batch sending is characterized in that one push task (or called batch) can send the same push information to a plurality of devices; a single transmission is characterized by only one push message being sent to one device at a time.
The WEB platform comprises a task creating module, a task viewing module, a task result module, a task starting module and a message storage module, and provides a visual operation interface. The block structure is shown in fig. 2.
The user can create the push task through the task creation module, and pushed information can be specified in a personalized mode when the task is created. The push information is composed of a piece of task basic information and one or more pieces of equipment information. The basic information of the task refers to titles, contents, starting push time, validity period, designated pages which are automatically opened when the push information is clicked, and the like, so that when a user receives the push information on a terminal such as a mobile phone, a tablet computer, an intelligent watch and the like, the user can see icons, texts, patterns and sounds, or vibration, screen brightness and the like of equipment are caused, when the push information is clicked on a notification bar of the equipment, the APP can make description of response behaviors such as jumping to the designated pages and the like, and the equipment information refers to an equipment identification code of target equipment to be delivered and a push facilitator code. In addition to directly inputting one or more pieces of device information, the pushed device information can be selected by selecting feature tags of target people (the tags are device data which is cleaned in advance through a certain algorithm before the pushed task is created, such as adolescence, maiden, male, 20-30 years old, salary family and the like), or by combining the above methods for selecting the target devices. When a task is created, a queue (such as Device _ 1234) with a globally unique name is automatically created in the Redis database to store all Device information related to the task, and the name is written into the push basic information data. When the user saves the push task, the basic information data of the task containing the queue name is saved in the SQL Server database together, and the pushing state is recorded as 'not started'. If the task only comprises one push target device, the push target device is sent in a single task push mode. If the start push time specified by the task is earlier than or equal to the current time, the task start module is triggered immediately.
The task viewing module is used for inquiring pushed task data including title, content, pushing time and the like which are created by the task creating module and pushing task-related device data, and besides the device data of which the device information is directly specified, the module can also directly view the part of the device information data created by the label.
The task results data may see the time each push actually sent, the results of the sending (in addition to success and failure, when an error is encountered, a code representing the cause of the error). When the module queries the tasks sent in batches, the data report forms (such as success rate, time consumption distribution and the like) of the tasks can be viewed. The data queried by the module is generated by a result storage module of the push engine.
The task starting module can dynamically start a task according to the starting pushing time of the user after the user creates the task. The task sent in batch sequentially writes Device information data into a Device queue of Redis required to be used by a push engine, wherein the Device queue is named as a Device _1234 generated by a task creation module when the task is created, and meanwhile, basic task information and Device information are sent to a message storage module. After all the device data are written into the device queue, the data of the basic information of the push Task is written into the tail (name such as Task) of a Task waiting queue with a specified name in Redis, the basic information of the same push Task can be written into a plurality of Task waiting queues according to actual needs, the more the number of the written basic information is, the more the threads consuming the Task by the push engine is, and the faster the corresponding push speed is. After the basic data of the task is written into the queue, the whole batch sending task is in a state waiting for sending, and the state of the basic information data of the pushing task in the SQL Server database is updated to be 'in progress'. The Single sent task can directly integrate the basic information of the task and the equipment information into one piece of data to be written into the tail (such as Single) of another Single push queue with a specified name in Redis, and can also send the basic information of the task and the equipment information into a message storage module.
The message storage module is used for integrating the pushed basic task information and the pushed equipment information into pushed message data, and the pushed message data is written into the MongoDB database in batches according to the specified frequency and batch entries. If 15 seconds and 5000 pieces are specified as the frequency and the item limit, the data can be stored into the MongoDB once when the two conditions reach one of the two conditions, and the request initiated to the database server can be reduced by using the batch submission mode, so that the aim of reducing the database pressure can be achieved.
The push service interface provides functions similar to the WEB platform and also comprises a task creation module, and the difference is that the component does not provide a visual operation interface but provides services in an interface form. An external system can interface with this component through an interface to accomplish its customized push task. The functional module of the component is basically the same as that of the WEB platform, and a network interface which can be used for communication is opened for other systems or services to provide equivalent services with the WEB platform.
The push engine component is a core component of the present technology, and its main functional modules as shown in fig. 3 include: the system comprises a batch task queue module, a batch task pushing module, a single task pushing module, a pushed data adapter module, a pushed task sending module and a result storage module.
The batch Task queue module monitors data at the head of a Task waiting queue (such as Task) written by a starting module in a Web platform or a push service interface in Redis in real time, tries to operate the Task waiting queue in Redis in a taking-out and removing mode, and sleeps for 3 seconds (the time can be adjusted according to needs) for a short time if the data is not acquired, and the operation is repeated after the dormancy is finished. Once the data of the pushing task is obtained from the queue, a batch task pushing module is used to start one or more threads (set according to the actual needs of the project) to consume the Device queue (such as Device _ 1234) of the task in the Redis database. It should be noted that, if the same push Task data is obtained from the Task waiting queue (Task) for multiple times, the batch Task push module also starts the process of creating the thread for multiple times, so as to achieve the purpose of increasing the push speed.
And the batch task pushing module is responsible for opening a device queue used by the thread to consume the pushing task. As shown in fig. 4, when acquiring device data of a certain task from the device queue, the device data and the push task data associated with the consuming thread are integrated into a new piece of data that simultaneously includes basic information of the push task and device information, and the integrated data is sent to the push data adapter module.
The Single task pushing module can continuously monitor the queue tail of a Single pushing queue (Single) in Redis in a monitoring mode similar to that of the batch task queue module, once the Single pushing task data to be pushed is obtained, the Single pushing task data can be integrated into data which is similar to the batch task pushing module and simultaneously contains basic information and equipment information of a pushing task, and then the data can be sent to the pushing data adapter module.
The push data adapter module is the most valuable module in the push engine, and the function of the push data adapter module can be summarized as integrating the basic task information and the equipment information of the push engine into a format supported by a push service provider. When a plurality of push services need to be supported simultaneously, a plurality of modules exist in one push engine, for example, an apple APNS and a Tencent carrier pigeon which are selected to be accessed as push service providers, and then data adapter modules of the apple APNS and the Tencent carrier pigeon respectively exist in the push engine. After the module integrates the basic push information and the equipment information into a data format supported by a push service provider, the integrated data is sent to a corresponding push task sending module. The decoupling of the self push business logic of the company and the sending logic of the push service provider is finished just by the module in the push engine, and the development cost of the push business is greatly reduced by the module because the code of data conversion is simpler.
The push task sending modules may also exist in a plurality of push engines, and if the APP selects apple APNS and tengcong pigeon as push service providers, the push task senders of the apple APNS and the tengcong pigeon inevitably exist in the system respectively. The module is used for transmitting data sent by the push adapter module to the service provider in a communication mode (including but not limited to HTTP1.1, HTTP2.0 and Socket) specified by the push service provider, and waiting for a response of the result. After the result is obtained, the result, the basic information and the equipment information data are integrated into a piece of pushing result data according to whether the result is successful or not and an error code (if any), and the pushing result data are transmitted to a result storage module.
The result storage module is responsible for sending the pushed result data item by item to the Kafka queue database, which writes the pushed result data item into the MongoDB database in batches with the specified frequency and batch entries. If 15 seconds and 5000 pieces are specified as the frequency and the item limit, the MongoDB can be stored once when the two conditions reach one of the two, so as to achieve the aim of relieving the database pressure.
The regular tasks comprise a pushing task monitoring module and a pushing task completion module.
The task monitoring module is used for monitoring the sending progress of the batch tasks. The module queries, at a fixed frequency (e.g., 15 seconds), the pushed basic information data whose state is not completed (not started, in progress) from the SQL Server database, queries, according to a unique device queue name in each piece of pushed basic information data, the number of entries of the remaining device information in the device queue from the Redis, and writes one or more pieces of pushed Task basic information into a Task waiting queue (e.g., Task) of the Redis if the number of entries is greater than a specified threshold (e.g., 10000).
The pushing task completion module is used for monitoring the sending completion condition of the batch tasks. The module queries the push basic information data with the state in progress from the SQL Server database at a fixed frequency (e.g., 15 seconds), queries the number of entries of the remaining device information in the device queue from Redis according to the unique queue name of each piece of data, and updates the state of the push task to be "completed" in the SQL Server database if the number of entries is 0.
The message center comprises a message query module and a message state module. The module is mainly used for client inquiry (comprising APP, WEB site and other forms)
The message query module can query out corresponding push message information stored by the message storage module of the WEB platform according to the device information transmitted by the client, and can respond according to a data format (including but not limited to JSON, XML and the like) specified by the client.
The message status module is used for recording the read and unread information of the message. The information clicked and checked by the user on the client side is recorded by the module, and the module can update the state of the push message information to be read (the initial state is unread) after receiving the response sent by the user.
The technical advantages of the present authoring are further understood from the specific implementation case.
Example 1: on the premise that a plurality of push service providers are accessed originally, a new push service provider, Hua is pushed, after receiving a demand, the original push data format is converted into the format required by Hua is pushed by using a technical document of Hua push officer and writing a 'push data adapter module' by using GO language, and a 'push task sending module' is used for sending the converted Hua is the push data format to a Hua interface by an HTTP request, wherein the push data adapter module and the push task sending module only contain about 100 lines of codes, so that the push of a new provider is realized, a message center, a WEB background and the like do not need to be changed at all, and the support for Hua is naturally provided, and the implementation mode can also refer to fig. 5.
Example 2: the pushing marketing personnel sends a batch pushing task counting 1000 ten thousand devices, wherein the pushing task comprises the device of a colleague, but the colleague does not receive the pushing task after the pushing task is completed, the pushing result related to the device of the colleague is conveniently inquired through a visual interface provided by a task result module of a WEB platform, and the pushing marketing personnel quickly finds that the pushing task is closed by the colleague according to an error code. The practical problem can be easily positioned through the set of engine system, and the situation that the pushing result is difficult to query in the past is greatly improved.
Example 3: the push service has the arrival rate which cannot reach 100% due to the restriction of equipment, a network and the like, so a module for checking messages is designed on an APP, all messages which should be received by the equipment can be conveniently inquired by using a message inquiry module provided by a message center part of a push engine system, and even if a user cannot receive a prompt sent by the push service to a notification bar of a mobile phone system due to various reasons, the user has the same chance to expose the push information to the user, so that the purpose of enhancing the push arrival rate is achieved.
To sum up, with the detailed description of the embodiments and the accompanying drawings, it is not difficult to understand that the APP push solution applying the present invention is not limited to accessing limited one or two push providers when accessing push services, and one or more push providers can be freely selected under the guarantee of the flexibility of the push data adapter module in the push engine, and a developer can access one provider by compiling a very small number of push data adapter modules and push task sending modules of the push engine according to documents provided by the push providers. The push engine system is designed to support distributed deployment, when one set of deployment cannot meet performance requirements, one set or multiple sets of deployment can be deployed, the more the deployment is, the higher the overall performance of pushing is, and a user can deploy according to actual needs of the user.
The invention has various embodiments, and all technical solutions formed by adopting equivalent transformation or equivalent transformation are within the protection scope of the invention.
Claims (4)
1. An APP pushing method is characterized by being realized based on the association operation of a MongoDB database, a Redis database, an SQL Server database and a Kafka queue database, and comprises the following steps:
s1, constructing a Web platform, and creating a push task through a task creating module, wherein the push task is composed of two parts of basic information and one or more pieces of equipment information, the basic information of each task comprises a globally unique queue name, and the basic information is stored in an SQL Server database; inquiring pushed task data through a task viewing module, wherein the task data comprise basic information and equipment information of a task, and one or more pieces of equipment information exist when the task is not started or is in progress; inquiring actual occurrence time and result of each pushing task through a task result module, wherein the result comprises actual pushing time and response result of each device related to the pushing task, and the response result comprises successful and failed identification, error code and error information; after a push task is created through a task starting module, the push task is dynamically started at regular time according to preset push time, and the action of starting the push task comprises the actions of writing basic information of the task into a task waiting queue in Redis and writing all device data of the task into a device queue of the task in the Redis; integrating the pushed basic task information and the pushed equipment information into pushed message data through a message storage module, and writing the pushed message data into a MongoDB database in batches according to the specified frequency and batch entries; in the construction of a push service interface, the push service interface opens a network interface which can be used for communication and provides equivalent service with a WEB platform for an external system;
s2, constructing a push service interface, connecting an external system through the interface to create a push task, and providing service for checking task information, starting the push task, checking a push result and storing a message;
s3, constructing a push engine, consuming basic task data in the Redis task waiting queue through a single or batch task queue module, when one piece of basic task information is successfully taken out, creating a plurality of consumption threads of the task through the batch task push module, and when the number of created consumption threads exceeds a preset threshold value, pausing creation operation until the number of consumption threads is lower than the threshold value; the batch task pushing module consumes the device data in the device queue associated with the task in Redis by using a consumption thread, integrates the consumed device data with the basic information of the task and sends the integrated data to the adapter module until no device data of the task exists in the device queue, and then destroys the consumption thread; the single task pushing module is used for creating a fixed number of consuming threads to consume a single pushing fixed task queue when being started, sending the data into the adapter module and repeating the process until no data exists in the consumed queue, and then repeating the process of consuming the data and sending the data into the adapter after sleeping for several seconds; the data format conversion is carried out through a push data adapter module, a unified data format in the push system is converted into a data format supported by each push service provider, and then the data format is sent to a push task sending module; sending out and waiting for result response in a communication mode appointed by each push service provider through a push task sending module, and then sending the result of the push to a local result storage module; all pushing results from the upstream task sending module are stored in a Kafka queue database and a MongoDB database in batches through a result storage module;
s4, constructing regular tasks, executing a section of code at a preset fixed frequency, firstly querying the pushing basic information data which is in a non-starting or in-progress state in an SQL Server database by the code, then querying the number of the remaining items of the tasks in a Redis equipment queue through a task monitoring module, and writing one or more pieces of basic information of the pushing tasks into a task waiting queue of the Redis when the number of the remaining items is larger than a predefined threshold value; when the device queue has no data, the state of the basic information data of the pushing task is updated to be completed in the SQL Server;
and S5, constructing a message center, and providing the client to access the MongoDB database and inquire result data which is pushed in association with the self equipment.
2. The APP push method of claim 1, characterized by: the constructed message center is used for the client to inquire through the APP or the Web site through the message inquiry module, and after the inquiry message of the client is sent, the unread message which is consulted by the user is modified and marked as read through the message state module based on the transmitted equipment information and data format.
3. The APP push engine system is characterized by being realized based on MongoDB database, Redis database, SQL Server database and Kafka queue database correlation operation, and comprises the following components:
the Web platform is provided with a task creating module, a task checking module, a task result module, a task starting module and a message storage module: creating a push task through a task creating module, wherein the push task is composed of two parts of basic information and one or more pieces of equipment information, the basic information of each task comprises a globally unique queue name, and the basic information is stored in an SQL Server database; inquiring pushed task data through a task viewing module, wherein the task data comprise basic information and equipment information of a task, and one or more pieces of equipment information exist when the task is not started or is in progress; inquiring actual occurrence time and result of each pushing task through a task result module, wherein the result comprises actual pushing time and response result of each device related to the pushing task, and the response result comprises successful and failed identification, error code and error information; after a push task is created through a task starting module, the push task is dynamically started at regular time according to preset push time, and the action of starting the push task comprises the actions of writing basic information of the task into a task waiting queue in Redis and writing all device data of the task into a device queue of the task in the Redis; integrating the pushed basic task information and the pushed equipment information into pushed message data through a message storage module, and writing the pushed message data into a MongoDB database in batches according to the specified frequency and batch entries; in the construction of a push service interface, the push service interface opens a network interface which can be used for communication and provides equivalent service with a WEB platform for an external system;
the push service interface is connected with an external system through an interface to create a push task and provide service for checking task information, starting the push task, checking a push result and storing a message;
the system comprises a pushing engine, a data adapter module, a pushing task sending module and a result storage module, wherein the pushing engine is provided with a batch task queue module, a batch task pushing module, a single task pushing module, a pushing data adapter module, a pushing task sending module and a result storage module, the batch task queue module consumes task basic data in a Redis task waiting queue, when one piece of task basic information is successfully taken out, a plurality of consumption threads of the task are created through the batch task pushing module, and when the number of the created consumption threads exceeds a preset threshold value, the creating operation is suspended until the number of the consumption threads is lower than the threshold value; the batch task pushing module consumes the device data in the device queue associated with the task in Redis by using a consumption thread, integrates the consumed device data with the basic information of the task and sends the integrated data to the adapter module until no device data of the task exists in the device queue, and then destroys the consumption thread; the single task pushing module is used for creating a fixed number of consuming threads to consume a single pushing fixed task queue when being started, sending the data into the adapter module and repeating the process until no data exists in the consumed queue, and then repeating the process of consuming the data and sending the data into the adapter after sleeping for several seconds; the data format conversion is carried out through a push data adapter module, a unified data format in the push system is converted into a data format supported by each push service provider, and then the data format is sent to a push task sending module; sending out and waiting for result response in a communication mode appointed by each push service provider through a push task sending module, and then sending the result of the push to a result storage module; all pushing results from the upstream task sending module are stored in a Kafka queue database and a MongoDB database in batches through a result storage module;
the regular task unit is provided with a task monitoring module and a task completion module, the task monitoring module executes a section of code at fixed frequency, the code firstly inquires the incomplete push basic information data in an SQL Server database, then the task monitoring module inquires the number of the remaining items of the tasks in a task waiting queue of Redis equipment, and when the number of the remaining items is greater than a predefined threshold value, one or more pieces of basic information of the push tasks are written into the task queue of the Redis equipment; when the device queue has no data, the state of the pushing task is updated to be completed in the SQL Server;
and the message center provides the client to access the MongoDB database and inquire the result data pushed in association with the self equipment.
4. The APP push engine system of claim 3, wherein: the message center is provided with a message query module and a message state module, the client side can query through the APP or the Web site through the message query module, and after the client side queries the message, the unread information which is consulted by the user is modified and marked as read through the message state module based on the transmitted equipment information and data format.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710799448.8A CN107609086B (en) | 2017-09-07 | 2017-09-07 | APP pushing method and engine system thereof |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710799448.8A CN107609086B (en) | 2017-09-07 | 2017-09-07 | APP pushing method and engine system thereof |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107609086A CN107609086A (en) | 2018-01-19 |
| CN107609086B true CN107609086B (en) | 2021-03-16 |
Family
ID=61062531
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710799448.8A Active CN107609086B (en) | 2017-09-07 | 2017-09-07 | APP pushing method and engine system thereof |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107609086B (en) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108809994A (en) * | 2018-06-15 | 2018-11-13 | 挖财网络技术有限公司 | Unified message method for pushing and system based on event and regulation management |
| CN111429633A (en) * | 2020-03-27 | 2020-07-17 | 电子科技大学中山学院 | Intelligent access control system with video acquisition function |
| CN112286973B (en) * | 2020-11-19 | 2022-09-30 | 每日互动股份有限公司 | Data message storage method and device, computer equipment and storage medium |
| CN114500443B (en) * | 2021-12-27 | 2024-03-29 | 北京百度网讯科技有限公司 | Message pushing method, device, system, electronic equipment and storage medium |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2496173A (en) * | 2011-11-04 | 2013-05-08 | Performance Horizon Group | Database system for manipulating data |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103020056A (en) * | 2011-09-20 | 2013-04-03 | 佳都新太科技股份有限公司 | Subscription pushing engine for cross-open-platform social intercourse information optimizing computation |
| CN103906013B (en) * | 2014-04-14 | 2018-01-09 | 夷希数码科技(上海)有限公司 | A kind of information push method and device based on mobile device |
| US20160055233A1 (en) * | 2014-08-25 | 2016-02-25 | Ca, Inc. | Pre-join tags for entity-relationship modeling of databases |
| CN106326469A (en) * | 2016-08-31 | 2017-01-11 | 无锡雅座在线科技发展有限公司 | Synchronization method and device of data |
-
2017
- 2017-09-07 CN CN201710799448.8A patent/CN107609086B/en active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2496173A (en) * | 2011-11-04 | 2013-05-08 | Performance Horizon Group | Database system for manipulating data |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107609086A (en) | 2018-01-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107609086B (en) | APP pushing method and engine system thereof | |
| AU2007275428B2 (en) | System and method for providing remote access to events from a database access system | |
| CN100483405C (en) | Method and system for alert delivery architecture | |
| US9313104B2 (en) | Method for extending business systems to a mobile workforce | |
| US8181151B2 (en) | Modeling and managing heterogeneous applications | |
| CN1609873B (en) | Method, apparatus, and user interface for managing electronic mail and alert messages | |
| US8312451B2 (en) | Computing system for providing software components on demand to a mobile device | |
| CN102710593B (en) | Method, device and system for publishing message in graph mashup | |
| WO2008148130A2 (en) | Distributed system for monitoring information events | |
| CN102664909A (en) | Re-establishing push notification channels via user identifiers | |
| CN103995906A (en) | Abnormity processing method and device | |
| US7451127B2 (en) | Web store events | |
| CN107291938B (en) | Order inquiry system and method | |
| CN101924815A (en) | 3G MOA phone middleware embedded system | |
| CN102831179A (en) | Webpage processing method and device | |
| CN118251656A (en) | Automatic work or automatic generation code for service worker threads of Progressive Web Application (PWA) | |
| CN111782373A (en) | Job scheduling method and device | |
| Aragao et al. | Conflict resolution in web service federations | |
| CN116866427B (en) | Unified pushing method and system for heterogeneous messages | |
| EP1769332A2 (en) | Natural language for programming a specialized computing system | |
| EP1909220A1 (en) | Event-driven system for programming a mobile device | |
| US11301482B2 (en) | Assist system and assist method | |
| CN115378792B (en) | Alarm processing method, device and storage medium | |
| US20240012835A1 (en) | Synchronizing changes in a distributed system with intermittent connectivity | |
| JP4916876B2 (en) | POS system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |