WO2023125672A1

WO2023125672A1 - Platform message tracking method, system and apparatus, and storage medium

Info

Publication number: WO2023125672A1
Application number: PCT/CN2022/142863
Authority: WO
Inventors: 李可; 张峰; 王世杰; 丁霞; 朱明�
Original assignee: 天翼物联科技有限公司
Priority date: 2021-12-30
Filing date: 2022-12-28
Publication date: 2023-07-06
Also published as: CN114385674A

Abstract

A platform message tracking method, system and apparatus, and a storage medium. The method comprises: according to a preset task creation policy, creating a message tracking task of a device in the form of ZNode of ZooKeeper, and writing a preset device identifier of the device into ZNode; at a service node, querying, according to the preset device identifier, whether there is ZNode of the current device in ZooKeeper, and determining whether it is necessary to perform message tracking; if it is necessary to perform message tracking, writing a processing log message of the service node into a cache queue; and reading the log message from the cache queue, and then writing same into a database. The system comprises a message tracking task management module, a message tracking module, a message caching module and a message recording persistence module. By means of the method, uplink and downlink messages of a terminal device can be tracked, thereby facilitating an improvement in the efficiency of development; and asynchronous message processing is performed, thereby facilitating the improvement of the development performance.

Description

A platform message tracking method, system, device and storage medium

technical field

The present application relates to the technical field of the Internet of Things, in particular to a platform message tracking method, system, device and storage medium.

Background technique

The Internet of Things PaaS platform can be used for the data flow of reporting messages and issuing instructions between terminals and applications. However, the Internet of Things PaaS platform is a black box for terminals and application developers, and data is stored between business modules of the Internet of Things PaaS platform. The flow process is invisible, which increases the difficulty for third-party developers to analyze and locate problems, and the development efficiency is low.

Contents of the invention

The purpose of this application is to solve one of the technical problems existing in the prior art at least to a certain extent.

Therefore, an object of the embodiment of the present application is to provide a platform message tracking method, which can track the uplink and downlink messages of the terminal device, which is conducive to improving development efficiency, and is conducive to improving development performance through asynchronous processing of messages.

Another object of the embodiments of the present application is to provide a platform message tracking system.

In order to achieve the above technical objectives, the technical solutions adopted in the embodiments of the present application include:

On the one hand, the embodiment of the present application provides a platform message tracking method, including the following steps:

In the platform message tracking method of the embodiment of the present application, according to the preset task creation strategy, the message tracking task of the device is created in the form of a ZNode node of zookeeper, and the preset device identifier of the device is written into the ZNode node; At the service node, according to the preset device identification, query whether there is a ZNode node of the current device in the zookeeper, and judge whether message tracking is required; if message tracking is required, write the processing log message at the service node into the cache queue; read the processing log message from the cache queue, and write it into the database. Being able to track the uplink and downlink messages of terminal devices is beneficial to improve development efficiency, and the asynchronous processing of messages is beneficial to improve development performance.

In addition, the platform message tracking method according to the above-mentioned embodiments of the present application may also have the following additional technical features:

Further, in the platform message tracking method of the embodiment of the present application, the preset task creation strategy includes: if the device has a message tracking task, the message tracking task of the device cannot be created; or, if the number of message tracking tasks is greater than If the task quantity threshold is not preset, the message tracking task for the device cannot be created.

Further, in an embodiment of the present application, the method further includes: if the message tracking task of the device stops, deleting the ZNode of the device.

Further, in one embodiment of the present application, the message tracking task of the device judges whether to stop through the following steps: if the tracking status identifier of the device is a preset status ID, determine to stop the message tracking task of the device task; or, if a user's stop message tracking instruction is received, determine to stop the message tracking task of the device.

Further, in an embodiment of the present application, the method further includes: if an abnormality occurs at the service node, determining that the tracking status identifier of the current device is an abnormal status identifier, and interrupting the service flow.

Further, in an embodiment of the present application, reading the processing log message from the cache queue and writing it into the database includes: reading the processing log message from the cache queue, by In the form of relational data, write it into the database; or, read the processing log message from the cache queue, and write it into the database in the form of key-value data.

Further, in one embodiment of the present application, it also includes: acquiring the accumulated duration; if the accumulated duration is equal to the preset duration, deleting the data in the database whose storage duration is greater than or equal to the preset storage duration, and recalculating the accumulated duration.

On the other hand, the embodiment of the present application proposes a platform message tracking system, including:

The message tracking task management module is used to create the message tracking task of the device in the form of the ZNode node of zookeeper according to the preset task creation strategy, and write the preset device identification of the device into the ZNode node; message tracking A module for, at the service node, querying whether there is a ZNode node of the current device in the zookeeper according to the preset device identifier, and judging whether message tracking is required; a message cache module, for when message tracking is required, Write the processing log message at the service node into a cache queue; the message record persistence module is used to read the processing log message from the cache queue and write it into a database.

On the other hand, an embodiment of the present application provides a platform message tracking device, including:

at least one processor;

at least one memory for storing at least one program;

When the at least one program is executed by the at least one processor, the at least one processor is made to implement any one of the above platform message tracking methods.

On the other hand, the embodiment of the present application provides a storage medium, which stores a processor-executable program, and the processor-executable program is used to implement any of the above-mentioned platform message tracking when executed by the processor. method.

In the platform message tracking method in the embodiment of the present application, according to the preset task creation strategy, the message tracking task of the device is created in the form of a ZNode node of zookeeper, and the preset device identifier of the device is written into the ZNode node ; At the service node, according to the preset device identification, query whether there is a ZNode node of the current device in the zookeeper, and judge whether message tracking is required; if message tracking is required, process the log message at the service node Write into the cache queue; read the processing log message from the cache queue, and write it into the database. Being able to track the uplink and downlink messages of terminal devices is beneficial to improve development efficiency, and the asynchronous processing of messages is beneficial to improve development performance.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings of the embodiments of the present application or the related technical solutions in the prior art are introduced below. It should be understood that the accompanying drawings in the following introduction are only In order to facilitate and clearly describe some embodiments of the technical solutions of the present application, those skilled in the art can also obtain other drawings based on these drawings without creative work.

Fig. 1 is a schematic flow chart of a specific embodiment of the platform message tracking method proposed by the present application;

Fig. 2 is a schematic diagram of the reporting message tracking process in the platform message tracking method proposed by the present application;

FIG. 3 is a schematic flow diagram of creating a message tracking task in the platform message tracking method proposed by the present application;

FIG. 4 is a schematic flow chart of exception handling in the platform message tracking method proposed by the present application;

Fig. 5 is a schematic flow chart of tracking message persistence in the platform message tracking method proposed by the present application;

FIG. 6 is a schematic structural diagram of a specific embodiment of the platform message tracking system proposed by the present application;

FIG. 7 is a schematic structural diagram of a specific embodiment of a platform message tracking device proposed in this application.

Detailed ways

Embodiments of the present application are described in detail below, examples of which are shown in the drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by referring to the figures are exemplary, are only for explaining the present application, and should not be construed as limiting the present application. For the step numbers in the following embodiments, it is only set for the convenience of illustration and description, and the order between the steps is not limited in any way. The execution order of each step in the embodiments can be adapted according to the understanding of those skilled in the art sexual adjustment.

The IoT PaaS platform connects to terminal devices in the south and connects to SaaS applications in the north, carrying the data flow of reporting messages and issuing instructions between terminals and applications. The Internet of Things PaaS platform is a black box for terminals and application developers, and the process of data flow between various business modules of the Internet of Things PaaS platform is invisible. While the IoT platform reduces the coupling between terminals and applications, it also makes it difficult for third-party developers and users to analyze and locate problems when connecting to the IoT PaaS platform.

The message tracking technology can realize the unboxing of the data processing business process of the IoT device in the IoT PaaS platform, record and present the business flow of the device and the platform within a specified period of time, and facilitate developers to locate and view the interactive records of the platform, terminals and applications , improve development efficiency.

The principle of message tracking is to insert probes at key nodes of the business modules of the IoT platform, and record business status or data snapshots when data passes through these business nodes. When the IoT platform is a single application, all business modules are in the same application, and the release of message tracking tasks and the reporting and storage of node data can all be completed through function calls in one application.

The business scenario of a high-performance IoT PaaS platform requires it to support millions of concurrent devices and tens of millions of devices online. Therefore, the Internet of Things platform mostly adopts the micro-service architecture and performs distributed deployment of multiple nodes to ensure the availability and stability of the business. In the microservice business architecture, each main module is scattered in multiple microservice applications, and each microservice contains multiple instances. The distributed message log recording method in the related art mainly focuses on the application system, and the business concerned is mainly the system operation log and the session log. The logs generated by the service are collected into a unified storage space. 2. Multiple sequential business node logs of the session are chained and tracked. The previous node will track the business number and business content and send them to the subsequent nodes to record the logs in turn. To sum up, ensuring that terminal messages can be tracked and recorded across applications, distributed, and multi-service modules is a problem that needs attention. At the same time, enabling message tracking for all existing terminals on the platform consumes massive storage resources and slows down system performance. Therefore, it is necessary to set reasonable tracking strategies to reduce costs.

In this regard, an embodiment of the present application proposes a platform message tracking method and system. First, the platform message tracking method proposed according to the embodiment of the present application will be described with reference to the accompanying drawings.

Referring to FIG. 1 , an embodiment of the present application provides a platform message tracking method. The platform message tracking method in the embodiment of the present application can be applied to a terminal, can also be applied to a server, and can also be run on a terminal or a server software etc. The terminal may be a tablet computer, a notebook computer, a desktop computer, etc., but is not limited thereto. The server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or it can provide cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, intermediate Cloud servers for basic cloud computing services such as software services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The platform message tracking method in the embodiment of the present application mainly includes the following steps:

S101: According to the preset task creation policy, create the message tracking task of the device in the form of a zookeeper ZNode node, and write the preset device identifier of the device into the ZNode node;

In this step, according to the preset task creation strategy, the message tracking task of the device is created in the form of a zookeeper ZNode node, and the preset device identifier of the device is written into the ZNode node. Among them, zookeeper is a distributed service framework, which is mainly used to solve some data management problems often encountered in distributed applications. In this application, the message tracking task of the device is created as a zookeeper node, which can share real-time message tracking task status information among distributed microservices, and can provide distributed consistency and ensure the message tracking task status Consistency, able to support multi-instance deployment under the microservice architecture. Specifically, each message tracking task needs to be registered as a ZNode node of zookeeper. In some possible implementations, when a message tracking task is created, the task ID, device ID, task status (tracking/stopping), start time, and planned end time are stored in the database, and the preset device identifier is written into the new zookeeper device node. Wherein, the preset device identifier is used to represent the identifier of the terminal device. It can be seen that the preset device identifier is unique and can be used to distinguish different terminal devices. Optionally, for the above parameters, the preset device identifier may be a task ID, a device ID, or other identifiers that can distinguish terminal devices. The preset task creation policy is used to characterize some conditions and restrictions that need to be considered when creating a message tracking task. It can be a limitation on the type of message tracking task, a limitation on the creation time of a message tracking task, or a limitation on the message tracking task The limit of the task volume of the system at the time of creation. This application does not limit the specific content of the preset device identification and preset task creation policy. In some possible implementations, the above process may be: the zookeeper client calls the Curator Framework to create a permanent node ZNode, and the path value is spliced with the device ID on the message tracking path prefix (/tracker/device/). And insert a message tracking task record in the database, each task can only be started once.

S102: At the service node, according to the preset device identifier, query whether there is a ZNode node of the current device in the zookeeper, and determine whether message tracking is required;

In this step, in the process of business processing, at the business node, after the message tracking point of the business node is triggered, according to the preset device identifier, query whether there is a ZNode node of the current device in zookeeper, if there is a ZNode node of the current device in zookeeper , to determine that the terminal device needs to perform message tracking. That is, if there is a tracking task for the device, the data processing log of the node needs to be reported. In some possible implementations, referring to the process shown in Figure 2, different service nodes in the data processing flow need to use the message tracker in the code for message tracking. After the current service node data processing is completed, the message tracking of the message tracker is triggered. Task inspection and tracking record reporting function, that is, by querying whether there is a ZNode node of the current device in zookeeper, it is judged whether the data generated by the node is transmitted to the subsequent process. Specifically, according to the incoming device ID, it is spliced with the prefix of the message tracking path to form a complete path, and the zookeeper client calls the Curator Framework interface to check whether the given complete path exists to determine whether message tracking is required.

S103: If message tracking is required, write the processing log message at the service node into the cache queue;

In this step, if message tracking is required, the processing log messages at the service node are written into the cache queue. Specifically, use the specified topic to write data into the message cache queue, and the reported content may include: task ID, device ID, processed message body, service node name, service status code, and time stamp. The message tracking records from each business module of the distributed nodes are gathered in the message cache queue. Report the terminal device data logs that need to be tracked to the message cache queue through the log burying point in the business, realize the decoupling of business and storage, realize the asynchronous processing of log data persistence, and alleviate the performance bottleneck caused by a large number of concurrent I/O .

S104: Read the processing log message from the cache queue, and write it into a database.

In this step, log messages are consumed and processed from the message queue, and stored in the database for query and display by the web service. In some possible implementations, the process is: the processing log message tracking record in the message cache queue is consumed by the message data storage, the processing log message record is consumed under the topic specified by the message queue, and the task is parsed out according to the business model ID, device ID, message body, service node information, etc., the data storage writes message records into the database, realizing the persistence of message tracking records.

Optionally, in this embodiment of the present application, the preset task creation policy includes:

If there is a message tracking task for the device, the message tracking task for the device cannot be created;

Or, if the number of message tracking tasks is greater than the preset task number threshold, the message tracking task of the device cannot be created.

In this step, the preset task creation strategy may be to limit each terminal device to have only one message tracking task, or it may be that the message tracking task data in the system is within a reasonable range. If the above limit is exceeded, message tracking tasks cannot be created. In some possible implementations, as shown in FIG. 3 , the process is as follows: the user of the terminal device starts the message tracking task, and needs to first check whether the device already has an ongoing message tracking task, and set the message tracking task manager to complete the above checking work. Specifically, new tasks cannot be created if they exist. It is also necessary to check the maximum number of message tracking tasks for the current user, and refuse to add new tasks if the maximum number limit specified by the system is exceeded. If all meet the preset task creation policy, start the message tracking task and create it in the form of zookeeper's ZNode node. Those skilled in the art can understand that the above preset task creation strategies are exemplary examples. In actual use, one of them can be selected as the preset creation strategy, or two of them can be selected as the preset creation strategy, or According to actual needs, select other measurements as the preset task creation strategy. This application does not limit the specific content and the number of specific strategies for creating preset tasks.

Optionally, in the embodiment of the present application, further comprising: if the message tracking task of the device stops, deleting the ZNode of the device.

In this step, after the message tracking task of the current device stops, the node of the current device is deleted, which is beneficial to avoid unnecessary message tracking of the terminal device and save system resources.

Optionally, in the embodiment of the present application, the message tracking task of the device judges whether to stop through the following steps:

If the tracking state identifier of the device is a preset status identifier, then determine to stop the message tracking task of the device;

Alternatively, if an instruction to stop message tracking from the user is received, it is determined to stop the message tracking task of the device.

In this step, it is determined whether to stop the message tracking task of the current device by checking the tracking state identifier of the current device. Specifically, the preset status identifier is used to represent the status of the message tracking task of the current device, which may be stopped or being created. The preset state identifier can use numbers to represent specific states. For example, 1 means start and 0 means stop; characters can also be used to represent the state of the data graph. For example, start means start and stop means stop. In some possible implementation manners, for a message tracking task that needs to be stopped by plan, the message tracking task is stopped by selecting a preset state identification method. Exemplarily, the timer checks at regular intervals (exemplarily, set to 5 minutes) whether the message tracking task in the tracking state in the comparison database has expired, and if it has expired (exemplarily, it can be set to: For the task of time start+duration<=current time now), mark the tracking status identifier of the corresponding terminal device as the default status identifier. The present application does not limit the specific expression form and specific meaning of the preset status identifier.

At the same time, the message tracking task can also be stopped when the user needs it, that is, manually stop the message tracking task. Specifically, the user manually operates on the web page, the backend stops the message tracking task, updates the task status in the database to stop, deletes the zookeeper node of the device ID, and ends the message tracking task.

Optionally, in the embodiment of the present application, further comprising: if an abnormality occurs at the service node, determining that the tracking status identifier of the current device is an abnormal status identifier, and interrupting the service flow.

In this step, if an abnormality occurs in the capture service node, it is determined that the tracking status of the current device is an abnormal status ID, and the system will perform fault location and fault analysis in abnormal situations according to the abnormal status ID, and interrupt the service flow at the same time. At the same time, if the exception is not caught, the data flow is interrupted at the node, and the system catches the exception. See Figure 4 for the specific process. By setting the abnormal status flag, developers can quickly locate and troubleshoot possible problems in the process of terminal docking with the IoT PaaS platform by querying message tracking records.

Optionally, in this embodiment of the present application, reading the processing log message from the cache queue and writing it into the database includes:

Read the processing log message from the cache queue, and write it into the database in the form of relational data;

Or, read the processing log message from the buffer queue, and write it into the database in the form of key-value data.

In this step, the processing log message is written into the database, and different methods may be selected for the writing operation according to the characteristics of different data. Specifically, as shown in FIG. 5 , the underlying database can be a relational database (MySQL) or a NoSQL database (HBase). According to the characteristics of relational and key-value data, different primary keys and query conditions should be used respectively. Relational data should use auto-increment primary key, message tracking task ID and device ID as indexes. Key-value databases such as HBase should use device ID-message task ID-time stamp concatenation as the key. At the same time, when using MySQL storage, in order to control the overall size of the data, it is also necessary to implement a timer to regularly clean up expired data. When using HBase storage, you can directly set the TTL when creating a table to automatically clear expired data.

Optionally, in the embodiment of the present application, it also includes:

Get the accumulated time;

If the cumulative duration is equal to the preset duration, delete the data in the database whose storage duration is greater than or equal to the preset storage duration, and recalculate the cumulative duration.

In this step, expired data will be processed by a timer, and a large amount of log data records will be generated for device message tracking, which will occupy a large amount of storage space, and outdated data needs to be cleaned up regularly. In some possible embodiments, the specific value of the preset storage period can be set according to the capacity of the database, the busyness of the system or the needs of customers. The scheduled task periodically clears the message tracking records in the database according to the set data storage duration to save storage space.

Optionally, users can also use the message tracking task ID, device ID, and service node to query message tracking records on the web page and display the data on the web page. You can check the message tracking record of the corresponding device according to the ongoing tasks in the message tracking task list.

It can be seen from the above description that the platform message tracking method provided by the present application can track the uplink and downlink messages of the terminal equipment, which is beneficial to improve the development efficiency, and the asynchronous processing of the messages is beneficial to improve the development performance.

Secondly, a platform message tracking system proposed according to an embodiment of the present application is described with reference to the accompanying drawings.

Fig. 6 is a schematic structural diagram of a platform message tracking system according to an embodiment of the present application. The system specifically includes:

The message tracking task management module 610 is used to create the message tracking task of the device in the form of a ZNode node of zookeeper according to the preset task creation strategy, and write the preset device identification of the device into the ZNode node;

The message tracking module 620 is configured to, at the service node, query whether there is a ZNode node of the current device in the zookeeper according to the preset device identifier, and determine whether message tracking is required;

The message cache module 630 is configured to write the processing log message at the service node into the cache queue when message tracking is required;

The message record persistence module 640 is configured to read the processing log message from the cache queue and write it into the database.

It can be seen that the content in the above-mentioned method embodiments is applicable to this system embodiment, and the functions realized by this system embodiment are the same as those of the above-mentioned method embodiments, and the beneficial effects achieved are also the same as those achieved by the above-mentioned method embodiments. same.

Referring to Figure 7, the embodiment of the present application provides a platform message tracking device, including:

at least one processor 710;

at least one memory 720 for storing at least one program;

When the at least one program is executed by the at least one processor 710, the at least one processor 710 is made to implement the platform message tracking method.

Similarly, the content in the above-mentioned method embodiment is applicable to this device embodiment. The functions realized by this device embodiment are the same as those of the above-mentioned method embodiment, and the beneficial effects achieved are the same as those achieved by the above-mentioned method embodiment. Also the same.

In some alternative implementations, the functions/operations noted in the block diagrams may occur out of the order noted in the operational diagrams. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/operations involved. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example for the purpose of providing a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logical flow presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and in which sub-operations described as part of larger operations are performed independently.

Furthermore, although the present application has been described in the context of functional modules, it should be understood that one or more of the functions and/or features may be integrated into a single physical device and/or software module unless stated to the contrary. or one or more functions and/or features may be implemented in separate physical devices or software modules. It will also be appreciated that a detailed discussion of the actual implementation of each module is not necessary to understand this application. Rather, given the attributes, functions and internal relationships of the various functional blocks in the devices disclosed herein, the actual implementation of the blocks will be within the ordinary skill of the engineer. Accordingly, one skilled in the art using ordinary techniques can implement the present application set forth in the claims without undue experimentation. It is also to be understood that the particular concepts disclosed are illustrative only and are not intended to limit the scope of the application which is to be determined by the appended claims and their full scope of equivalents.

If the functions described above are realized in the form of software function units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including Several programs are used to make a computer device (which may be a personal computer, server, or network device, etc.) execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disc, etc., which can store program codes. .

The logic and/or steps represented in the flowcharts or otherwise described herein, for example, can be considered as a sequential listing of executable programs for implementing logical functions, which can be embodied in any computer-readable medium, For use with program execution systems, devices, or equipment (such as computer-based systems, systems including processors, or other systems that can take programs from program execution systems, devices, or equipment and execute programs), or in combination with these program execution systems, devices or equipment for use. For purposes of this specification, a "computer-readable medium" may be any device that can contain, store, communicate, propagate, or transmit a program for use in or in conjunction with a program execution system, device, or device.

More specific examples (non-exhaustive list) of computer-readable media include the following: electrical connection with one or more wires (electronic device), portable computer disk case (magnetic device), random access memory (RAM), Read Only Memory (ROM), Erasable and Editable Read Only Memory (EPROM or Flash Memory), Fiber Optic Devices, and Portable Compact Disc Read Only Memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium on which the program can be printed, as it may be possible, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or other suitable processing if necessary. The program is processed electronically and stored in computer memory.

It should be understood that each part of the present application may be realized by hardware, software, firmware or a combination thereof. In the above-described embodiments, various steps or methods may be implemented by software or firmware stored in memory and executed by a suitable program execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented by any one or combination of the following techniques known in the art: Discrete logic circuits, ASICs with suitable combinational logic gates, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

In the above description of this specification, the description with reference to the terms "one embodiment/example", "another embodiment/example" or "some embodiments/example" means that the description is described in conjunction with the embodiment or example. A specific feature, structure, material, or characteristic is included in at least one embodiment or example of the present application. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the described specific features, structures, materials or characteristics may be combined in any suitable manner in any one or more embodiments or examples.

Although the embodiments of the present application have been shown and described, those skilled in the art can understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principle and spirit of the present application. The scope of the application is defined by the claims and their equivalents.

The above is a specific description of the preferred implementation of the present application, but the present application is not limited to the described embodiments, and those skilled in the art can also make various equivalent deformations or replacements without violating the spirit of the present application. These equivalent modifications or replacements are all within the scope defined by the claims of the present application.

Claims

A platform message tracking method is characterized in that it comprises the following steps:

According to the preset task creation strategy, the message tracking task of the device is created in the form of a ZNode node of zookeeper, and the preset device identification of the device is written into the ZNode node;

At the service node, according to the preset device identifier, query whether there is a ZNode node of the current device in the zookeeper, and determine whether message tracking is required;

If message tracking is required, write the processing log message at the service node into the cache queue;

Read the processing log message from the cache queue, and write it into the database.
The platform message tracking method according to claim 1, wherein the preset task creation strategy includes:

If there is a message tracking task for the device, the message tracking task for the device cannot be created;

Or, if the number of message tracking tasks is greater than the preset task number threshold, the message tracking task of the device cannot be created.
The platform message tracking method according to claim 1, wherein the method further comprises:

If the message tracking task of the device stops, the ZNode of the device is deleted.
The platform message tracking method according to claim 3, wherein the message tracking task of the device judges whether to stop by the following steps:

If the tracking state identifier of the device is a preset status identifier, then determine to stop the message tracking task of the device;

Alternatively, if an instruction to stop message tracking from the user is received, it is determined to stop the message tracking task of the device.
The platform message tracking method according to claim 1, wherein the method further comprises:

If an abnormality occurs at the service node, it is determined that the tracking status identifier of the current device is an abnormal status identifier, and the service flow is interrupted.
The platform message tracking method according to claim 1, wherein said reading the processing log message from the cache queue and writing it into a database includes:

Read the processing log message from the cache queue, and write it into the database in the form of relational data;

Or, read the processing log message from the buffer queue, and write it into the database in the form of key-value data.
The platform message tracking method according to claim 1, wherein the method further comprises:

Get the accumulated time;

If the cumulative duration is equal to the preset duration, delete the data in the database whose storage duration is greater than or equal to the preset storage duration, and recalculate the cumulative duration.
A platform message tracking system, characterized in that it includes:

The message tracking task management module is used to create the message tracking task of the device in the form of a ZNode node of zookeeper according to the preset task creation strategy, and write the preset device identification of the device into the ZNode node;

The message tracking module is used to query whether there is a ZNode node of the current device in the zookeeper according to the preset device identifier at the service node, and determine whether message tracking is required;

A message cache module, configured to write the processing log message at the service node into the cache queue when message tracking is required;

The message record persistence module is used to read the processing log message from the cache queue and write it into the database.
A platform message tracking device is characterized in that it comprises:

at least one processor;

at least one memory for storing at least one program;

When the at least one program is executed by the at least one processor, the at least one processor implements the platform message tracking method according to any one of claims 1-7.
A computer-readable storage medium, which stores a processor-executable program, wherein the processor-executable program is used to implement the program described in any one of claims 1-7 when executed by a processor. The platform message tracking method described above.