CN110764936A - Data acquisition method and device - Google Patents
Data acquisition method and device Download PDFInfo
- Publication number
- CN110764936A CN110764936A CN201911032119.6A CN201911032119A CN110764936A CN 110764936 A CN110764936 A CN 110764936A CN 201911032119 A CN201911032119 A CN 201911032119A CN 110764936 A CN110764936 A CN 110764936A
- Authority
- CN
- China
- Prior art keywords
- acquisition
- preset
- event
- queue
- reported
- 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.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/548—Queue
Abstract
The embodiment of the invention discloses a data acquisition method and a data acquisition device, wherein the method comprises the following steps: after detecting that a user triggers a preset operation, generating a plurality of corresponding acquisition events when executing a task corresponding to the preset operation; each acquisition event is used for recording an event for executing each subtask in the task, and further, the plurality of acquisition events are reported through a plurality of reporting processes, and one or more acquisition events which are not reported in the plurality of acquisition events are reported to an acquisition server in each reporting process. In the embodiment of the invention, the acquisition events are reported through a plurality of reporting processes, all the acquisition events do not need to be reported to the acquisition server once, and compared with the prior art which adopts a data acquisition strategy of receiving and sending, the pressure of the acquisition server can be reduced, and the efficiency of data acquisition can be improved.
Description
Technical Field
The invention relates to the technical field of financial technology (Fintech), in particular to a data acquisition method and device.
Background
With the development of computer technology, more and more technologies are applied in the financial field, and the traditional financial industry is gradually changing to financial technology (Fintech), however, higher requirements are also put forward on the technologies due to the requirements of the financial industry on safety and real-time performance. The data acquisition is a data processing method commonly used in the financial industry, and by acquiring user behavior data in a preset time period and establishing a service prediction model based on the user behavior data, the service execution condition in a future period of time can be analyzed by using the service prediction model, so that a better decision coping mechanism can be established; for example, by collecting user behavior data of a certain commodity in a certain period of time and establishing a user loss model corresponding to the commodity, the user loss condition of the commodity in a future period of time can be analyzed, so that a marketing department can adjust a marketing strategy of the commodity, and the user loss condition is reduced.
In the prior art, a data acquisition process is generally performed by adopting a receiving-sending strategy, specifically, as long as a service system detects a service triggering buried point event, an acquisition event corresponding to the buried point event is generated, and the acquisition event is reported to an acquisition server at the same time. However, the service system at the present stage usually supports parallel processing, and therefore, if a plurality of embedded point events are triggered simultaneously, the service system will report a plurality of acquisition events corresponding to the plurality of embedded point events to the acquisition server in parallel, so that the pressure of the acquisition server is large, and the normal operation of the acquisition server is affected.
In summary, a data acquisition method is needed to reduce the pressure of the acquisition server.
Disclosure of Invention
The embodiment of the invention provides a data acquisition method and device, which are used for reducing the pressure of an acquisition server.
In a first aspect, an embodiment of the present invention provides a data acquisition method, where the method includes:
after detecting that a user triggers a preset operation, generating a plurality of corresponding acquisition events when executing a task corresponding to the preset operation; each acquisition event is used for recording an event for executing each subtask in the task, and further, the plurality of acquisition events are reported through a plurality of reporting processes, and one or more acquisition events which are not reported in the plurality of acquisition events are reported to an acquisition server in each reporting process.
In the design, the collection events are reported through a plurality of reporting processes, all the collection events do not need to be reported to the collection server at one time, and compared with the data collection strategy that the collection server adopts the receiving and sending processes in the prior art, the design can reduce the pressure of the collection server and improve the efficiency of data collection.
In one possible design, the reporting the plurality of acquisition events through a multiple reporting process includes: and sequentially storing the plurality of acquisition events in a preset queue, and in each reporting process, reporting an acquisition event which is not reported in the preset queue to the acquisition server after determining that the acquisition event reported in the last reporting process is successfully reported to the acquisition server.
In the design, the generated acquisition events can be stored in a small occupied space by setting the preset queue, and a plurality of acquisition events can be accurately stored according to the generated time sequence, so that the accuracy of data acquisition can be improved; and by setting that one collection event reported in each reporting process is reported successfully and then starting the next reporting process, the pressure of the collection server can be reduced and the loss rate of the collection events can be reduced, so that the success rate of the collection server for receiving the collection events can be improved.
In one possible design, the reporting an acquisition event that is not reported in the preset queue to the acquisition server includes: and acquiring the acquisition events stored in the next position adjacent to the position indicated by the preset cursor in the preset queue, reporting the acquisition events to the acquisition server, and updating the preset cursor by using the position adjacent to the position indicated by the preset cursor, wherein the preset cursor is used for indicating the position of the acquisition event reported in each reporting process in the preset queue.
In the design, the position of the collection event reported each time is recorded by using the preset cursor, and the position of the collection event to be reported next time can be conveniently acquired according to the preset cursor, so that the flexibility and the accuracy of data collection can be improved.
In one possible design, the method further includes: after the acquisition event reported in the last reporting process is determined to be unsuccessfully reported to the acquisition server, repeatedly reporting the acquisition event reported in the last reporting process, and caching the acquisition event between the position indicated by the preset cursor in the preset queue and the position at the tail end of the preset queue to a preset position when the repeated reporting times exceed the preset times; further, after the fault is eliminated, the collection event cached in the preset position is reported to a collection server.
In the above design, because the reason for the failure of the multiple reporting processes is generally a network failure, the collection server can collect the most comprehensive collected data by caching the collection events which are not successfully reported and reporting the collection events which are not reported again after the network failure is recovered, so that the success rate of data collection can be improved.
In a possible design, if the position indicated by the preset cursor is the position at the end of the preset queue, or if the acquisition event between the position indicated by the preset cursor and the position at the end of the preset queue is cached to the preset position, the preset queue is deleted.
In the design, the preset queue is deleted after the cache is successfully buffered, or the preset queue is deleted after all the collection events in the preset queue are reported, so that the meaningless space occupation behavior can be avoided, and the performance loss of the system can be reduced.
In a possible design, the multiple acquisition events are sequentially stored in front of a preset queue, and whether the acquisition events are cached in the preset position is also queried, if so, the initial position of the preset queue is used for storing the acquisition events cached in the preset position, and then the multiple acquisition events are sequentially stored from the position behind the initial position of the preset queue; and if not, sequentially storing the plurality of acquisition events from the initial position of the preset queue.
In the design, after a new acquisition event is generated, the cached acquisition event is acquired from the preset position and is placed at the initial position of the preset queue, and after the new acquisition event is placed at the cached acquisition event, the acquisition events can be sequentially reported to the acquisition server according to the generated time sequence, so that the accuracy and the success rate of data acquisition can be improved.
In one possible design, the reporting an acquisition event that is not reported in the preset queue to the acquisition server includes: acquiring an acquisition event stored in the initial position in the preset queue, and reporting the acquisition event to the acquisition server; further, if it is determined that the collection event reported in the reporting process is successfully reported to the collection server, deleting the collection event stored in the initial position in the preset queue, and sequentially moving the collection event stored in each position in the preset queue forward by one position; and the acquisition event stored in the position behind the initial position in the preset queue is moved to the initial position.
In the design, the storage space occupied by the preset queue can be reduced by deleting the reported acquisition events from the preset queue, so that the storage space does not need to be expanded for the preset queue again when the number of the acquisition events is increased, and the availability of the preset queue and the utilization rate of the storage space are improved.
In a second aspect, an embodiment of the present invention provides a data acquisition apparatus, where the apparatus includes:
the processing module is used for generating a plurality of corresponding acquisition events when a task corresponding to a preset operation is executed after the preset operation is detected to be triggered by a user; each acquisition event is used for recording an event for executing each subtask in the task;
the receiving and sending module is used for reporting the plurality of acquisition events through a plurality of reporting processes; and reporting one or more non-reported acquisition events in the acquisition events to an acquisition server in each reporting process.
In one possible design, the transceiver module is specifically configured to: and sequentially storing the plurality of acquisition events in a preset queue, and in each reporting process, reporting an acquisition event which is not reported in the preset queue to the acquisition server after determining that the acquisition event reported in the last reporting process is successfully reported to the acquisition server.
In one possible design, the transceiver module is specifically configured to: acquiring an acquisition event stored in a next position adjacent to the position indicated by the preset vernier in the preset queue, reporting the acquisition event to the acquisition server, and updating the preset vernier by using the position adjacent to the position indicated by the preset vernier; the preset cursor is used for indicating the position of the collection event reported in each reporting process in the preset queue.
In one possible design, the apparatus further includes a cache module; the transceiver module is further configured to: after determining that the collection event reported in the last reporting process is not reported to the collection server successfully, repeatedly reporting the collection event reported in the last reporting process; when the number of times repeatedly reported by the transceiver module exceeds a preset number of times, the cache module is configured to: caching the acquisition event between the position indicated by the preset cursor in the preset queue and the position at the tail end of the preset queue to a preset position; correspondingly, the transceiver module is further configured to: and after the fault is eliminated, reporting the collection event cached in the preset position to a collection server.
In one possible design, the processing module is further to: and if the position indicated by the preset cursor is the position of the tail end of the preset queue, or if the acquisition event between the position indicated by the preset cursor and the position of the tail end of the preset queue is cached to the preset position, deleting the preset queue.
In a possible design, the caching module is further configured to store the plurality of acquisition events in sequence before a preset queue: inquiring whether the preset position caches the acquisition events or not, if so, using the initial position of the preset queue to store the acquisition events cached in the preset position, and then sequentially storing the acquisition events from the position behind the initial position of the preset queue; and if not, sequentially storing the plurality of acquisition events from the initial position of the preset queue.
In one possible design, the transceiver module is specifically configured to: acquiring an acquisition event stored in the initial position in the preset queue, and reporting the acquisition event to the acquisition server; further, if it is determined that the collection event reported in the reporting process is successfully reported to the collection server, deleting the collection event stored in the initial position in the preset queue, and sequentially moving the collection event stored in each position in the preset queue forward by one position; and the acquisition event stored in the position behind the initial position in the preset queue is moved to the initial position.
In a third aspect, an embodiment of the present invention provides a computing device, which includes at least one processing unit and at least one storage unit, where the storage unit stores a computer program, and when the program is executed by the processing unit, the processing unit is caused to execute the data acquisition method according to any of the first aspect.
In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium storing a computer program executable by a computing device, wherein the computer program, when executed on the computing device, causes the computing device to perform the data acquisition method according to any of the first aspect.
These and other aspects of the invention are apparent from and will be elucidated with reference to the embodiments described hereinafter.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise.
FIG. 1 is a schematic diagram of a possible system architecture according to an embodiment of the present invention;
fig. 2 is a schematic flow chart corresponding to a data acquisition method according to an embodiment of the present invention;
fig. 3 is a schematic diagram of a method for reporting an acquisition event based on a preset cursor according to an embodiment of the present invention;
fig. 4 is a schematic diagram of a method for reporting a collection event based on a first-in first-out queue algorithm according to an embodiment of the present invention;
fig. 5 is a schematic flow chart illustrating an implementation of a data acquisition method according to an embodiment of the present invention;
fig. 6 is a schematic structural diagram of a data acquisition device according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be described in further detail with reference to the accompanying drawings, and it is apparent that the described embodiments are only a part of the embodiments of the present invention, not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The field of financial technology (Fintech) generally involves many transactions, for example, bank transactions may include card-selling transactions, deposit transactions, loan transactions, insurance transactions, financing transactions, etc., and the daily transaction amount of a bank may reach thousands or even tens of thousands. In order to ensure that various transactions are carried out smoothly, a bank can usually collect events of various transactions executed by a user, and further carry out big data analysis on the collected events to obtain an analysis model; the analysis model may be various, such as a user attrition model, a user profile, and so on. In this way, the bank can use the analysis model to predict the user's behavior, so that the user can be provided with corresponding services based on the predicted user's behavior.
Fig. 1 is a schematic diagram of a possible system architecture provided by an embodiment of the present invention, and as shown in fig. 1, the system architecture may include an acquisition server 110 and at least one client device, such as a client device 121, a client device 122, and a client device 123; at least one client device may be respectively in communication connection with the acquisition server 110, for example, the connection may be implemented in a wired manner, or may also be implemented in a wireless manner, which is not limited in particular.
In an embodiment of the present invention, at least one client device may be respectively disposed in at least one business system, for example, the client device 121 is a client device disposed in a loan business system, the client device 122 is a client device disposed in an insurance business system, and the client device 123 is a client device disposed in a financial business system. In one example, the client device may refer to a server providing an Application (APP), and the APP may refer to an APP of an embedded browser, so that if the APP provided by the client device is installed on the user terminal, the client device may detect an operation triggered by the user on the browser of the APP, and may provide a service corresponding to the operation to the user.
It should be noted that fig. 1 is only an exemplary and simple illustration, the number of the listed client devices is only for convenience of the solution, and does not constitute a limitation on the solution, and in a specific implementation, the number of the client devices may be much greater than 3, for example, may be 4 or more than 4.
Based on the system architecture illustrated in fig. 1, fig. 2 is a schematic flow chart corresponding to a data acquisition method provided in an embodiment of the present invention, where the method includes:
On a possible premise, the preset operation may be an operation indicating that the point burying event is triggered, when the preset operation is triggered by a user, the client device may execute a service corresponding to the preset operation, and the point burying event is triggered in a service execution process, so that the client device may generate an acquisition event corresponding to the point burying event. Taking a point burying event as a loan event as an example, the preset operation corresponding to the loan event may be of various types, for example, the preset operation may be to click a loan application icon on a loan interface, or may be to press a preset key (which may be a single key or a combination key) on a keyboard, or may also be to input preset characters in a text box or to input preset characters by voice, or may also be to detect a preset brain waveform, or may also be to shoot a specified action or scan a preset bar code, and the like, and the details are not limited.
It should be noted that, in the embodiment of the present invention, the service execution process and the data acquisition process are respectively executed in respective processes, and the data acquisition process is determined by the service execution process and does not affect the service execution process. For example, after a loan event is triggered, a loan operation is performed in the business process, and a point-burying event triggered by the performance of the loan operation, such as an event that a user applies for a loan, is collected in the data collection process.
The following describes a specific implementation process for generating a plurality of collection events by taking preset operations as examples of clicking a loan application icon on a loan interface.
In specific implementation, if the client device provides the APP to the user, any operation of the user on the APP may be collected by the client device, and the client device may also respond to the operation of the user. For example, if the particle credit APP is an APP provided by the client device 121, after the user opens a particle credit product page of the particle credit APP in the user terminal, if the user triggers a "one-key debit" button on the particle credit product page, the client device 121 may sequentially query the user's related information from multiple third party platforms, so as to determine whether to provide a debit to the user; for example, the client device 121 may first query the personal information of the user from the personal information maintenance platform, may query the account opening information of the user from the account opening information maintenance platform after the personal information query is passed, and may query the loan qualification of the user from the loan information maintenance platform after the account opening information query is passed; further, the client device 121 may provide the user with the loan if the personal information, the account opening information, and the loan qualification all pass the query, and may reject the loan application of the user if any one of the personal information, the account opening information, and the loan qualification does not pass the query.
In the above process, when performing the loan transaction corresponding to the "one-key loan", the client device performs three sub tasks of querying the personal information of the user, querying the account opening information of the user, and querying the loan qualification of the user, respectively. In this way, if the client device 121 sets a first buried event, a second buried event and a third buried event in the particle loan APP in advance, the first buried event indicates that the client device 121 (or the user) has executed a sub-task of querying personal information in the personal information maintenance platform, the second buried event indicates that the client device 121 (or the user) has executed a sub-task of querying account opening information in the account opening information maintenance platform, and the third buried event indicates that the client device 121 (or the user) has executed a sub-task of querying loan qualification in the loan information maintenance platform, after the user triggers the button of "borrowing by one key", since the first buried event, the second buried event and the third buried event are triggered in sequence, the client device 121 may generate a first collection event corresponding to the first buried event and a second collection event corresponding to the second buried event in sequence, and a third acquisition event corresponding to the third buried point event.
In the embodiment of the present invention, the execution intervals of the three subtasks, i.e., querying the personal information of the user, querying the account opening information of the user, and querying the loan qualification of the user, are very short, and may be only a few milliseconds, so that the client device 121 is equivalent to generating the first collection event, the second collection event, and the third collection event in parallel during the process of executing the loan transaction.
It should be noted that the above is only an exemplary and simple description, the number of the sampling events is only for convenience of description, and does not constitute a limitation to the scheme, and in a specific implementation, the number of the sampling events may be 2, or may also be greater than 3, for example, 4 or more than 4, and is not specifically limited.
In a specific implementation, the client device 121 may first store a plurality of collection events in a first preset location, and then obtain one or more collection events that are not reported from the first preset location each time and report the one or more collection events to the collection server 110; therefore, the multiple acquisition events are reported through the multiple reporting processes, the multiple acquisition events do not need to be reported to the acquisition server at one time, and compared with the data acquisition strategy which adopts the receiving and sending mode in the prior art, the pressure of the acquisition server can be reduced, and the data acquisition efficiency can be improved.
In this embodiment of the present invention, the first preset position may be set by a person skilled in the art according to experience, or may also be set according to a service requirement, for example, the first preset position may be a memory (a magnetic disk, an external memory, a plug-in device, or the like) of the client device 121, or may also be a database server, or may also be a cloud storage (a cloud space, a cloud disk, or the like); the collection event may be stored in the first preset location in the form of a data table, or may also be stored in the first preset location in the form of a linked list, or may also be stored in the first preset location in the form of a machine language, and the like, which is not limited specifically.
In one possible implementation, the queue may be used to store the acquisition event, where the queue is a special linear table and may be composed of multiple elements, each of which may store an address pointer, and the queue may be disposed in a Random Access Memory (RAM) of the client device 121. In a specific implementation, after generating a plurality of acquisition events, the client device 121 may store the plurality of acquisition events in a preset queue in sequence, so that each time a report is made, one or more non-reported acquisition events may be obtained from the preset queue and reported to the acquisition server 110. By adopting the mode, the generated multiple acquisition events can be stored with less occupied space by setting the preset queue, and the multiple acquisition events can be accurately stored according to the generated time sequence, so that the accuracy of data acquisition can be improved.
Optionally, during each reporting, the client device 121 may obtain an unreported acquisition event from the preset queue and report the acquisition event to the acquisition server 110, so that the acquisition events are reported to the acquisition server 110 one by one; accordingly, before each report, it is required to determine that the last reported acquisition event is reported successfully, that is, after the last reported acquisition event is reported to the acquisition server 110 successfully, the client device 121 starts the next reporting process again. By adopting the mode, after one acquisition event reported in each reporting process is successfully reported, the next reporting process is started again, so that the pressure of the acquisition server is reduced, the loss rate of the acquisition event is reduced, and the success rate of the acquisition server for receiving the acquisition event can be improved.
In the embodiment of the present invention, after receiving an acquisition event reported by the client device 121, the acquisition server 110 sends a response message to the client device 121, where the response message includes a first type response message and a second type response message; the first type of response message is used to identify that the acquisition server 110 successfully receives the acquisition event reported by the client device 121, and the second type of response message is used to identify that the acquisition server 110 does not receive the acquisition event reported by the client device 121 within a set time period, or that the acquisition server 110 receives the acquisition event in an illegal format. Thus, in each reporting, if the client device 121 receives the first type response message sent by the acquisition server 110, it is determined that the reported acquisition event is successfully reported, so that the next reporting process can be started; if the client device 121 receives the second type response message sent by the acquisition server 110, it is determined that the acquisition event reported this time fails to be reported, so that the next reporting process may not be started.
In an example, after determining that reporting of a certain reported acquisition event fails, the client device 121 may repeatedly report the reported acquisition event, and if the number of times of repeated reporting exceeds a preset number, it indicates that the current network fails, so that the client device 121 may cache all non-reported acquisition events (including the reported acquisition event) stored in a preset queue to a second preset location; the preset number of times can be set by a person skilled in the art according to experience, for example, the preset number of times can be 3 times, or can also be 4 times or more than 4 times; the second preset position may be the same as or different from the first preset position, and is not limited specifically.
In this embodiment of the present invention, if the preset operation is an operation set on an APP of an embedded browser, the first preset location may be a RAM of the client device 121, and the second preset location may be a memory (ROM) of the device. In a specific implementation, after the client device 121 generates a plurality of acquisition events, the plurality of acquisition events may be stored in the RAM of the client device 121, and then, when reporting each time, an acquisition event that is not reported is obtained from the RAM, and the acquisition event is placed in a browser request queue, where the browser request queue is used to store request data to be processed by a browser; by adopting the method, each reporting process of the client device 121 can only occupy one position in the browser request queue, and compared with the mode that a plurality of acquisition events are reported once to cause occupation of a plurality of positions in the browser request queue in the prior art, the method can reduce the working pressure of the browser, thereby not affecting the normal working efficiency of the browser.
Further, when a certain collection event fails to be reported repeatedly for multiple times, the client device 121 may obtain all the collection events (including the collection event) that are not reported from the RAM, and cache the collection events that are not reported into the ROM of the device through the browser; thus, after it is determined that the network failure is recovered, if a new acquisition event is generated, the acquisition event cached in the ROM of the device may be reported to the acquisition server 110, and then the new acquisition event may be reported to the acquisition server 110. In the embodiment of the invention, because the reason of failure in the multiple reporting processes is network failure generally, the acquisition server can acquire the most comprehensive acquisition data by caching the acquisition events which cannot be reported successfully and reporting the unreported acquisition events again after the network failure is recovered, thereby improving the success rate of data acquisition.
In the embodiment of the present invention, there may be multiple ways to obtain an unreported acquisition event from a preset queue, and two possible implementation ways are mainly described below, it can be understood that the way to obtain an unreported acquisition event may also be other ways, and the embodiment of the present invention is not limited:
implementation mode one
In a first implementation manner, the client device 121 may preset a preset cursor, where the preset cursor is used to indicate a position of a collection event to be reported in a preset queue.
Fig. 3 is a schematic diagram of a method for reporting an acquisition event based on a preset cursor, as shown in fig. 3, at a current time, a first queue for reporting the acquisition event is already arranged in a client device 121, the first queue includes a head and a tail, the acquisition event can be sequentially inserted into the first queue from the tail of the first queue, an acquisition event 1, an acquisition event 2, and an acquisition event 3 are sequentially stored in the first queue, the acquisition event 1 occupies an initial position 0 of the first queue, the acquisition event 2 occupies a position 1 of the first queue, and the acquisition event 3 occupies a position 2 of the first queue. In the process of reporting the collection event in the first queue to the collection server 110, if the client device 121 generates a new collection event 4, a collection event 5, and a collection event 6 according to a preset operation newly triggered by a user, the collection event 4, the collection event 5, and the collection event 6 may be inserted into the first queue from the tail of the first queue, so that the collection event 4 may occupy the position 3 of the first queue, the collection event 5 may occupy the position 4 of the first queue, and the collection event 6 may occupy the position 5 of the first queue.
In a specific implementation, the preset cursor may indicate an initial position, that is, a position 0, of the first queue in an initial state, so that when the client device 121 reports the collection event for the first time, the collection event 1 stored in the position 0 indicated by the preset cursor may be obtained first, and then the collection event 1 may be placed in a browser request queue, and the collection event 1 is reported to the collection server 110 via the browser. Further, if the client device 121 receives the first type response message sent by the collection server 110, it indicates that the collection event 1 is successfully reported to the collection server 110, and therefore the client device 121 can control the preset cursor to move backward by one bit from the head direction to the tail direction of the first queue, so that the preset cursor can indicate the position 1 in the first queue, and the client device 121 can report the collection event 2 stored in the position 1 in the first queue to the collection server 110 at the next reporting time.
In a possible situation, when the collecting event 2 is reported, if the client device 121 receives the second type response message sent by the collecting server 110, it indicates that the collecting event 2 is not successfully reported to the collecting server 110, so the client device 121 may report the collecting event 2 repeatedly, and if the second type response message sent by the collecting server 110 is received after reporting for 3 times repeatedly, it indicates that the collecting event 2 is not successfully reported to the collecting server 110 in 3 times of repeated reporting, and the current network fails, so the client device 121 may cache the collecting events (i.e., collecting event 2 and collecting event 3) between the position 1 indicated by the preset cursor in the first queue and the position 2 at the end of the first queue to the second preset position.
In the embodiment of the present invention, after the collection event that is not reported in the first queue is cached to the second preset position, and/or when the position indicated by the preset cursor is the position of the end of the first queue, the client device 121 may delete the first queue, so that the first queue may be prevented from occupying a meaningless occupied space, and performance loss of the system may be reduced.
Further, after the first queue is deleted, if the client device 121 detects that the user newly triggers the preset operation and generates a new acquisition event 7 and an acquisition event 8, the client device 121 may create a second queue, and before storing the acquisition event 7 and the acquisition event 8 in the second queue, may first query whether a second preset location buffers an acquisition event that has not been reported before. If the acquisition event 2 and the acquisition event 3 are cached in the second preset position, the acquisition event 2 and the acquisition event 3 can be stored in the second queue in sequence, and then the acquisition event 7 and the acquisition event 8 can be stored in the second queue in sequence; thus, collection event 2 may occupy position 0, collection event 3 may occupy position 1, collection event 7 may occupy position 2, and collection event 8 may occupy position 3 of the second queue. Correspondingly, if the acquisition event is not cached in the second preset position, the acquisition event 7 and the acquisition event 8 can be directly and sequentially stored in the second queue; in this manner, collection event 7 may occupy position 0 of the second queue and collection event 8 may occupy position 1 of the second queue.
In the embodiment of the invention, after a new acquisition event is generated, the cached acquisition event is acquired from the preset position and is placed at the initial position of the preset queue, and after the new acquisition event is placed in the cached acquisition event, the acquisition events can be ensured to be sequentially reported to the acquisition server according to the generated time sequence, so that the accuracy and the success rate of data acquisition can be improved.
In the first implementation manner, since the position of the current acquisition event to be reported in the preset queue is recorded by using the preset cursor, the position of the acquisition event in the preset queue does not change. Therefore, the collection event does not need to be frequently moved, the performance loss of the system is reduced, and the position of the collection event to be reported next time can be conveniently obtained according to the preset cursor, so that the flexibility of data collection can be improved.
Implementation mode two
In the second implementation manner, the client device 121 may report the collected data by using a first-in-first-out queue algorithm, specifically, each time the client device 121 successfully reports one collection event, the collection event may be deleted from the preset queue, and other collection events may be sequentially moved forward, so as to keep the elements in the preset queue continuously updated.
Fig. 4 is a schematic diagram of an implementation method for reporting collected data based on a first-in-first-out queue algorithm according to an embodiment of the present invention, as shown in fig. 4, a first queue stores a collection event 1, a collection event 2, and a collection event 3 in sequence, where the collection event 1 occupies an initial position 0 of the first queue, the collection event 2 occupies a position 1 of the first queue, and the collection event 3 occupies a position 2 of the first queue.
In a specific implementation, the client device 121 may first obtain the collection event 1 stored in the position 0 of the first queue, then may place the collection event 1 in a browser request queue, and report the collection event 1 to the collection server 110 via the browser. Further, if the client device 121 receives the first type response message sent by the acquisition server 110, it indicates that the acquisition event 1 is successfully reported to the acquisition server 110, so that the client device 121 may control to move the acquisition event 1 out of the first queue from the head of the first queue (or directly delete the acquisition event 1), and sequentially control the acquisition event 2 and the acquisition event 3 to move forward by one position, so that the acquisition event 2 occupies the position 0 of the first queue, and the acquisition event 3 occupies the position 1 of the first queue. In this way, the acquisition event reported by the client device 121 each time is an acquisition event located at the initial position of the first queue.
Further, when the acquisition event 2 is reported, if the client device 121 receives the second type response message sent by the acquisition server 110, it indicates that the acquisition event 2 is not successfully reported to the acquisition server 110, so the client device 121 may report the acquisition event 2 repeatedly, and if the second type response message sent by the acquisition server 110 is received after 3 times of repeated reporting, it indicates that the acquisition event 2 is not successfully reported to the acquisition server 110 in 3 times of repeated reporting, and the current network fails, so the client device 121 may cache the acquisition event that is not reported to the acquisition server 110 in the first queue to the second preset location. Specifically, since the collection event is deleted from the first queue after being successfully reported to the collection server 110, the collection events stored in the first queue are all collection events that are not reported to the collection server 110, that is, when a network fault is determined, the client device 121 may cache all the collection events stored in the first queue.
Accordingly, when a certain collection event cannot be reported to the collection server, thereby causing all collection events in the first queue to be cached to the second preset location, and/or when collection events in the first queue are all reported to the collection server 110, thereby causing no collection events in the first queue, the client device 121 may delete the first queue, thereby preventing the first queue from occupying a meaningless occupied space, and reducing performance loss of the system.
In the second implementation manner, the storage space occupied by the preset queue can be reduced by deleting the reported acquisition events from the preset queue, so that the storage space does not need to be re-expanded for the preset queue when the number of the acquisition events increases, and the availability of the preset queue and the utilization rate of the storage space are improved.
For convenience of understanding, a specific implementation process of the data acquisition method in the embodiment of the present invention is described below from another perspective.
Fig. 5 is a schematic flow chart illustrating an implementation process of a data acquisition method according to an embodiment of the present invention, as shown in fig. 5, after a user triggers a first preset operation, if a point burying event 1, a point burying event 2, and a point burying event 3 are triggered when a service corresponding to the first preset operation is executed, a client device may sequentially generate an acquisition event 1 corresponding to the point burying event 1, an acquisition event 2 corresponding to the point burying event 2, and an acquisition event 3 corresponding to the point burying event 3. Further, if the client device is provided with a queue a for reporting the collected data1The client device may then queue a collection event 1, collection event 2, and collection event 3 from1Are sequentially inserted into the queue a1In, suppose queue a1Has occupied queue a with stored collection events1From position 0 to position i-1, then the acquisition event 1 may occupy queue a1Position i, collection event 2 may occupy queue a1Position i +1, collection event 3 may occupy queue a1Position i + 2; wherein i may be an integer greater than or equal to 0.
In the embodiment of the invention, when the collection event is stored in the queue a1Then, the client device can allocate a unique identifier for the acquisition event; wherein the unique identifier of the acquisition event can be set empirically by a person skilled in the art, and in one example, the unique identifier can be set as a combination of a time stamp and a random number, and has a length of 16 bits.
It should be noted that, in the embodiment of the present invention, the acquisition event may include, but is not limited to: the identifier of the APP, the identifier of the user, the identifier of the collection event, the information of the device, the information of the user and the information of the service. The information of the device may refer to a type of a processor, a core number of a CPU, a model of the device, etc., the information of the user may refer to a name, a gender, a mobile phone number, a place of daily use, etc., and the information of the service may refer to a type of a buried point event, a serial number of the service, etc., without limitation.
In the embodiment of the present invention, the client device may execute the reporting process according to a preset period, for example, if the preset period is 2 minutes, the client device may slave queue a every 2 minutes1Acquiring an unreported acquisition event (such as an acquisition event k) and reporting the acquisition event to an acquisition server; before reporting the acquisition event k, the client device may first query whether an acquisition event being reported exists in a reporting process, if not, the client device may directly report the acquisition event k to the acquisition server, and if so, the client device may first wait for the completion of reporting the acquisition event being reported (e.g., the acquisition event h) (i.e., receiving a response message sent by the acquisition server). After the collection event h is reported, if the collection event h is reported successfully, the collection event k can be reported to a collection server; if the collection event h is determined to be failed to report, the times that the collection event h has been reported to the collection server can be inquired, if the reported times are greater than or equal to the preset times, the current network fault is indicated, and therefore the network fault can be reported from the queue a1The method comprises the steps of caching all the acquisition events from an acquisition event h to the tail end position of a queue, if the reported times are less than the preset times, reporting the acquisition event h again, determining whether the acquisition event h is reported successfully after the reporting is finished, and repeatedly executing the steps.
Further, if queue a1In the unreported acquisition events are buffered, or queued a1If all the collection events in the queue are reported successfully, the client device can report the queue a1And (5) deleting. Thus, after the user triggers the second preset operation, if the embedded point event 3, the embedded point event 4 and the embedded point event 5 are triggered when the service corresponding to the second preset operation is executed, the client device may sequentially generate the acquisition event 3 corresponding to the embedded point event 3, the acquisition event 4 corresponding to the embedded point event 4 and the acquisition event 5 corresponding to the embedded point event 5; further, since the client device is not provided with a queue for reporting the collected data, the client device may create the queue a2And stores collection event 3, collection event 4, and collection event 5 in queue a2In (1). Wherein the client device is storing collection event 3, collection event 4 and collection event 5 in queue a2Before, it may be first queried to determine whether there is a cached acquisition event, and if there is a cached acquisition event, the cached acquisition event may be first selected from the queue a2Is inserted into queue a2Then the collection event 3, the collection event 4 and the collection event 5 are again from the queue a2Is inserted into queue a2In the end based on queue a2And executing a reporting process. Therefore, the client device can report the acquisition event which cannot be reported successfully last time to the acquisition server, and then report the newly generated acquisition event to the acquisition server, so that the acquisition success rate of the acquisition event is improved.
In one example, the client device may compress the acquisition event before caching the acquisition event, and the space occupied by the acquisition event may be reduced by caching the compressed acquisition event. If there are multiple acquisition events to be cached, the client device may perform compression on the multiple acquisition events once to obtain one compressed file, or may also perform compression on each acquisition event to obtain multiple compressed files, or may also perform compression on a preset number of continuous acquisition events to obtain multiple compressed files, where the number of compressed acquisition events may be specifically set according to the service needs, which is not limited in the embodiment of the present invention.
In the embodiment of the invention, after the preset operation triggered by the user is detected, a plurality of corresponding acquisition events are generated when the task corresponding to the preset operation is executed; each acquisition event is used for recording an event for executing each subtask in the task, and further, the plurality of acquisition events are reported through a plurality of reporting processes, and one or more acquisition events which are not reported in the plurality of acquisition events are reported to an acquisition server in each reporting process. In the embodiment of the invention, the acquisition events are reported through a plurality of reporting processes, all the acquisition events do not need to be reported to the acquisition server once, and compared with the prior art which adopts a data acquisition strategy of receiving and sending, the pressure of the acquisition server can be reduced, and the efficiency of data acquisition can be improved.
In view of the above method flow, an embodiment of the present invention further provides a data acquisition device, and the specific content of the device can be implemented with reference to the above method.
Fig. 6 is a schematic structural diagram of a data acquisition device according to an embodiment of the present invention, including:
the processing module 601 is configured to generate a plurality of corresponding acquisition events when a task corresponding to a preset operation is executed after a preset operation is detected to be triggered by a user; each acquisition event is used for recording an event for executing each subtask in the task;
a transceiver module 602, configured to report the multiple acquisition events through multiple reporting processes; and reporting one or more non-reported acquisition events in the acquisition events to an acquisition server in each reporting process.
Optionally, the transceiver module 602 is specifically configured to:
sequentially storing the plurality of acquisition events in a preset queue;
in each reporting process, after the collection event reported in the last reporting process is determined to be successfully reported to the collection server, reporting an un-reported collection event in the preset queue to the collection server.
Optionally, the transceiver module 602 is specifically configured to:
acquiring an acquisition event stored in a next position adjacent to the position indicated by the preset cursor in the preset queue, and reporting the acquisition event to the acquisition server; the preset vernier is used for indicating the position of the collection event reported in each reporting process in the preset queue;
and updating the preset cursor by using the position adjacent to the position indicated by the preset cursor.
Optionally, the apparatus further comprises a caching module 603;
the transceiver module 602 is further configured to: after determining that the collection event reported in the last reporting process is not reported to the collection server successfully, repeatedly reporting the collection event reported in the last reporting process;
when the number of times that the transceiver module 602 repeatedly reports exceeds a preset number of times, the buffer module 603 is configured to: caching the acquisition event between the position indicated by the preset cursor in the preset queue and the position at the tail end of the preset queue to a preset position;
the transceiver module 602 is further configured to: and after the fault is eliminated, reporting the collection event cached in the preset position to a collection server.
Optionally, the processing module 601 is further configured to:
and if the position indicated by the preset cursor is the position of the tail end of the preset queue, or if the acquisition event between the position indicated by the preset cursor and the position of the tail end of the preset queue is cached to the preset position, deleting the preset queue.
Optionally, the caching module 603 stores the multiple collection events in front of a preset queue in sequence, and is further configured to:
inquiring whether the preset position caches the acquisition events or not, if so, using the initial position of the preset queue to store the acquisition events cached in the preset position, and then sequentially storing the acquisition events from the position behind the initial position of the preset queue; and if not, sequentially storing the plurality of acquisition events from the initial position of the preset queue.
Optionally, the transceiver module 602 is specifically configured to:
acquiring an acquisition event stored in the initial position in the preset queue, and reporting the acquisition event to the acquisition server;
if the collection events reported in the reporting process are successfully reported to the collection server, deleting the collection events stored in the initial position in the preset queue, and sequentially moving the collection events stored in each position in the preset queue forward by one position; and the acquisition event stored in the position behind the initial position in the preset queue is moved to the initial position.
From the above, it can be seen that: in the embodiment of the invention, after the preset operation triggered by the user is detected, a plurality of corresponding acquisition events are generated when the task corresponding to the preset operation is executed; each acquisition event is used for recording an event for executing each subtask in the task, and further, the plurality of acquisition events are reported through a plurality of reporting processes, and one or more acquisition events which are not reported in the plurality of acquisition events are reported to an acquisition server in each reporting process. In the embodiment of the invention, the acquisition events are reported through a plurality of reporting processes, all the acquisition events do not need to be reported to the acquisition server once, and compared with the prior art which adopts a data acquisition strategy of receiving and sending, the pressure of the acquisition server can be reduced, and the efficiency of data acquisition can be improved.
Based on the same inventive concept, an embodiment of the present invention further provides a computing device, including at least one processing unit and at least one storage unit, where the storage unit stores a computer program, and when the program is executed by the processing unit, the processing unit is enabled to execute the data acquisition method as described in any of fig. 2 above.
Based on the same inventive concept, an embodiment of the present invention further provides a computer-readable storage medium, which stores a computer program executable by a computing device, and when the program runs on the computing device, the computer program causes the computing device to execute the data acquisition method as described in any of the above fig. 2.
It should be apparent to those skilled in the art that embodiments of the present invention may be provided as a method, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the invention.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.
Claims (16)
1. A method of data acquisition, the method comprising:
after detecting that a user triggers a preset operation, generating a plurality of corresponding acquisition events when executing a task corresponding to the preset operation; each acquisition event is used for recording an event for executing each subtask in the task;
reporting the plurality of acquisition events through a plurality of reporting processes; and reporting one or more non-reported acquisition events in the acquisition events to an acquisition server in each reporting process.
2. The method of claim 1, wherein reporting the plurality of acquisition events through a plurality of reporting processes comprises:
sequentially storing the plurality of acquisition events in a preset queue;
in each reporting process, after the collection event reported in the last reporting process is determined to be successfully reported to the collection server, reporting an un-reported collection event in the preset queue to the collection server.
3. The method of claim 2, wherein reporting an acquisition event not reported in the predetermined queue to the acquisition server comprises:
acquiring an acquisition event stored in a next position adjacent to the position indicated by the preset cursor in the preset queue, and reporting the acquisition event to the acquisition server; the preset vernier is used for indicating the position of the collection event reported in each reporting process in the preset queue;
and updating the preset cursor by using the position adjacent to the position indicated by the preset cursor.
4. The method of claim 3, further comprising:
after the acquisition event reported in the last reporting process is determined to be unsuccessfully reported to the acquisition server, repeatedly reporting the acquisition event reported in the last reporting process, and caching the acquisition event between the position indicated by the preset cursor in the preset queue and the position at the tail end of the preset queue to a preset position when the repeated reporting times exceed the preset times;
and after the fault is eliminated, reporting the collection event cached in the preset position to a collection server.
5. The method of claim 4, further comprising:
and if the position indicated by the preset cursor is the position of the tail end of the preset queue, or if the acquisition event between the position indicated by the preset cursor and the position of the tail end of the preset queue is cached to the preset position, deleting the preset queue.
6. The method according to claim 4 or 5, wherein the storing the plurality of acquisition events in sequence before the preset queue further comprises:
inquiring whether the preset position caches the acquisition events or not, if so, using the initial position of the preset queue to store the acquisition events cached in the preset position, and then sequentially storing the acquisition events from the position behind the initial position of the preset queue; and if not, sequentially storing the plurality of acquisition events from the initial position of the preset queue.
7. The method of claim 2, wherein reporting an acquisition event not reported in the predetermined queue to the acquisition server comprises:
acquiring an acquisition event stored in the initial position in the preset queue, and reporting the acquisition event to the acquisition server;
if the collection events reported in the reporting process are successfully reported to the collection server, deleting the collection events stored in the initial position in the preset queue, and sequentially moving the collection events stored in each position in the preset queue forward by one position; and the acquisition event stored in the position behind the initial position in the preset queue is moved to the initial position.
8. A data acquisition device, the device comprising:
the processing module is used for generating a plurality of corresponding acquisition events when a task corresponding to a preset operation is executed after the preset operation is detected to be triggered by a user; each acquisition event is used for recording an event for executing each subtask in the task;
the receiving and sending module is used for reporting the plurality of acquisition events through a plurality of reporting processes; and reporting one or more non-reported acquisition events in the acquisition events to an acquisition server in each reporting process.
9. The apparatus of claim 8, wherein the transceiver module is specifically configured to:
sequentially storing the plurality of acquisition events in a preset queue;
in each reporting process, after the collection event reported in the last reporting process is determined to be successfully reported to the collection server, reporting an un-reported collection event in the preset queue to the collection server.
10. The apparatus of claim 9, wherein the transceiver module is specifically configured to:
acquiring an acquisition event stored in a next position adjacent to the position indicated by the preset cursor in the preset queue, and reporting the acquisition event to the acquisition server; the preset vernier is used for indicating the position of the collection event reported in each reporting process in the preset queue;
and updating the preset cursor by using the position adjacent to the position indicated by the preset cursor.
11. The apparatus of claim 10, further comprising a caching module;
the transceiver module is further configured to: after determining that the collection event reported in the last reporting process is not reported to the collection server successfully, repeatedly reporting the collection event reported in the last reporting process;
when the number of times repeatedly reported by the transceiver module exceeds a preset number of times, the cache module is configured to: caching the acquisition event between the position indicated by the preset cursor in the preset queue and the position at the tail end of the preset queue to a preset position;
the transceiver module is further configured to: and after the fault is eliminated, reporting the collection event cached in the preset position to a collection server.
12. The apparatus of claim 11, wherein the processing module is further configured to:
and if the position indicated by the preset cursor is the position of the tail end of the preset queue, or if the acquisition event between the position indicated by the preset cursor and the position of the tail end of the preset queue is cached to the preset position, deleting the preset queue.
13. The apparatus according to claim 11 or 12, wherein the buffering module is further configured to store the plurality of collection events in sequence before a preset queue, and further configured to:
inquiring whether the preset position caches the acquisition events or not, if so, using the initial position of the preset queue to store the acquisition events cached in the preset position, and then sequentially storing the acquisition events from the position behind the initial position of the preset queue; and if not, sequentially storing the plurality of acquisition events from the initial position of the preset queue.
14. The apparatus of claim 9, wherein the transceiver module is specifically configured to:
acquiring an acquisition event stored in the initial position in the preset queue, and reporting the acquisition event to the acquisition server;
if the collection events reported in the reporting process are successfully reported to the collection server, deleting the collection events stored in the initial position in the preset queue, and sequentially moving the collection events stored in each position in the preset queue forward by one position; and the acquisition event stored in the position behind the initial position in the preset queue is moved to the initial position.
15. A computing device comprising at least one processing unit and at least one memory unit, wherein the memory unit stores a computer program that, when executed by the processing unit, causes the processing unit to perform the method of any of claims 1 to 7.
16. A computer-readable storage medium storing a computer program executable by a computing device, the program, when run on the computing device, causing the computing device to perform the method of any of claims 1 to 7.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911032119.6A CN110764936A (en) | 2019-10-28 | 2019-10-28 | Data acquisition method and device |
| PCT/CN2020/119039 WO2021082858A1 (en) | 2019-10-28 | 2020-09-29 | Data acquisition method and apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911032119.6A CN110764936A (en) | 2019-10-28 | 2019-10-28 | Data acquisition method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110764936A true CN110764936A (en) | 2020-02-07 |
Family
ID=69334231
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911032119.6A Pending CN110764936A (en) | 2019-10-28 | 2019-10-28 | Data acquisition method and device |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN110764936A (en) |
| WO (1) | WO2021082858A1 (en) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2021082858A1 (en) * | 2019-10-28 | 2021-05-06 | 深圳前海微众银行股份有限公司 | Data acquisition method and apparatus |
| CN112764837A (en) * | 2021-01-29 | 2021-05-07 | 腾讯科技（深圳）有限公司 | Data reporting method, device, storage medium and terminal |
| CN113750517A (en) * | 2020-11-30 | 2021-12-07 | 上海达龙信息科技有限公司 | Keyboard operation data transmission method and device and keyboard operation execution method and device |
| CN114567674A (en) * | 2022-02-25 | 2022-05-31 | 腾讯科技（深圳）有限公司 | Data processing method and device, computer equipment and readable storage medium |
| CN115393974A (en) * | 2022-08-01 | 2022-11-25 | 北京主线科技有限公司 | Method, device and equipment for recording fault event of automatic driving vehicle and storage medium |
| CN113750517B (en) * | 2020-11-30 | 2024-04-30 | 上海达龙信息科技有限公司 | Keyboard operation data transmission method and device and keyboard operation execution method and device |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113190458A (en) * | 2021-05-24 | 2021-07-30 | 北京映客芝士网络科技有限公司 | Method and device for automatically analyzing buried point data, computer equipment and storage medium |
| CN113900901A (en) * | 2021-10-21 | 2022-01-07 | 北京达佳互联信息技术有限公司 | Data reporting method, data monitoring method, device, equipment and storage medium |
| WO2023169251A1 (en) * | 2022-03-09 | 2023-09-14 | 北京字节跳动网络技术有限公司 | Index determination method and apparatus, and server and medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104348650A (en) * | 2013-08-05 | 2015-02-11 | 腾讯科技（深圳）有限公司 | Website monitoring method, business device and website monitoring system |
| CN107239389A (en) * | 2017-06-07 | 2017-10-10 | 网易（杭州）网络有限公司 | A kind of method and device that user operation records are determined in mixing APP |
| CN107885590A (en) * | 2017-11-30 | 2018-04-06 | 百度在线网络技术（北京）有限公司 | Task processing method and device for smart machine |
| CN108199902A (en) * | 2018-01-24 | 2018-06-22 | 精硕科技（北京）股份有限公司 | The processing method and processing device of data transmission |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104865953B (en) * | 2015-03-20 | 2019-04-05 | 北京远特科技股份有限公司 | A kind of vehicle data treating method and apparatus |
| CN110764936A (en) * | 2019-10-28 | 2020-02-07 | 深圳前海微众银行股份有限公司 | Data acquisition method and device |
-
2019
- 2019-10-28 CN CN201911032119.6A patent/CN110764936A/en active Pending
-
2020
- 2020-09-29 WO PCT/CN2020/119039 patent/WO2021082858A1/en active Application Filing
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104348650A (en) * | 2013-08-05 | 2015-02-11 | 腾讯科技（深圳）有限公司 | Website monitoring method, business device and website monitoring system |
| CN107239389A (en) * | 2017-06-07 | 2017-10-10 | 网易（杭州）网络有限公司 | A kind of method and device that user operation records are determined in mixing APP |
| CN107885590A (en) * | 2017-11-30 | 2018-04-06 | 百度在线网络技术（北京）有限公司 | Task processing method and device for smart machine |
| CN108199902A (en) * | 2018-01-24 | 2018-06-22 | 精硕科技（北京）股份有限公司 | The processing method and processing device of data transmission |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2021082858A1 (en) * | 2019-10-28 | 2021-05-06 | 深圳前海微众银行股份有限公司 | Data acquisition method and apparatus |
| CN113750517A (en) * | 2020-11-30 | 2021-12-07 | 上海达龙信息科技有限公司 | Keyboard operation data transmission method and device and keyboard operation execution method and device |
| CN113750517B (en) * | 2020-11-30 | 2024-04-30 | 上海达龙信息科技有限公司 | Keyboard operation data transmission method and device and keyboard operation execution method and device |
| CN112764837A (en) * | 2021-01-29 | 2021-05-07 | 腾讯科技（深圳）有限公司 | Data reporting method, device, storage medium and terminal |
| CN112764837B (en) * | 2021-01-29 | 2022-03-08 | 腾讯科技（深圳）有限公司 | Data reporting method, device, storage medium and terminal |
| CN114567674A (en) * | 2022-02-25 | 2022-05-31 | 腾讯科技（深圳）有限公司 | Data processing method and device, computer equipment and readable storage medium |
| WO2023160276A1 (en) * | 2022-02-25 | 2023-08-31 | 腾讯科技（深圳）有限公司 | Data processing method and apparatus, computer device and readable storage medium |
| CN114567674B (en) * | 2022-02-25 | 2024-03-15 | 腾讯科技（深圳）有限公司 | Data processing method, device, computer equipment and readable storage medium |
| CN115393974A (en) * | 2022-08-01 | 2022-11-25 | 北京主线科技有限公司 | Method, device and equipment for recording fault event of automatic driving vehicle and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2021082858A1 (en) | 2021-05-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110764936A (en) | Data acquisition method and device | |
| CN109034993B (en) | Account checking method, account checking equipment, account checking system and computer readable storage medium | |
| WO2020233212A1 (en) | Log record processing method, server, and storage medium | |
| CN110428127B (en) | Automatic analysis method, user equipment, storage medium and device | |
| CN110795166B (en) | Data processing method and device | |
| CN111143286B (en) | Cloud platform log management method and system | |
| CN106815254B (en) | Data processing method and device | |
| CN111813573B (en) | Communication method of management platform and robot software and related equipment thereof | |
| CN111338791A (en) | Method, device and equipment for scheduling cluster queue resources and storage medium | |
| EP3937022B1 (en) | Method and apparatus of monitoring interface performance of distributed application, device and storage medium | |
| CN109981715B (en) | Session management method and device | |
| CN107301091A (en) | Resource allocation methods and device | |
| CN111414389A (en) | Data processing method and device, electronic equipment and storage medium | |
| CN108765134B (en) | Order data processing method and device, electronic equipment and storage medium | |
| CN111553652B (en) | Service processing method and device | |
| CN114546590B (en) | Java virtual machine heap memory set object monitoring method and memory overflow analysis method | |
| CN113422808A (en) | Internet of things platform HTTP information pushing method, system, device and medium | |
| CN116842090A (en) | Accounting system, method, equipment and storage medium | |
| CN111427917A (en) | Search data processing method and related product | |
| CN106354722B (en) | Message processing method and device for streaming computing system | |
| CN115269288A (en) | Fault determination method, device, equipment and storage medium | |
| CN115129491A (en) | Micro service request message tracking method, generating method, device, medium and equipment | |
| CN111770080A (en) | Method and device for recovering device fingerprint | |
| CN110309121B (en) | Log processing method and device, computer readable medium and electronic equipment | |
| CN113032647A (en) | Data analysis 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 |