CN110674180B

CN110674180B - Business data processing method and device and readable storage medium

Info

Publication number: CN110674180B
Application number: CN201910916693.1A
Authority: CN
Inventors: 李亮; 邵兵
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2019-09-26
Filing date: 2019-09-26
Publication date: 2021-07-27
Anticipated expiration: 2039-09-26
Also published as: CN110674180A

Abstract

The embodiment of the application discloses a service data processing method, a device and a readable storage medium, wherein the service data processing method comprises the following steps: receiving a behavior query request sent by a first service server, wherein the behavior query request comprises a first user identifier corresponding to a target user and target behavior parameters; acquiring a second user identifier of a target user in a second service server according to the first user identifier; acquiring historical behavior parameters respectively corresponding to a first user identifier and a second user identifier from a block chain, wherein the block chain comprises the historical behavior parameters respectively uploaded by a first service server and a second service server; and determining a behavior query result corresponding to the target user according to the historical behavior parameters respectively corresponding to the target behavior parameter, the first user identifier and the second user identifier. By adopting the embodiment of the application, the accuracy of the statistical service data can be improved.

Description

Business data processing method and device and readable storage medium

Technical Field

The present application relates to the field of internet technologies, and in particular, to a method and an apparatus for processing service data, and a readable storage medium.

Background

With the popularization of internet technology and intelligent devices, the frequency of entertainment and recreation of users through terminal devices is increasing, and the frequency has become an indispensable user demand. However, the underage users are not powerful, and are easy to be addicted to entertainment such as online games, which is not favorable for the development of the current age stage.

In order to prevent the minor users from being indulged in the online games for a long time, each game manufacturer sets corresponding anti-addiction system rules, for example, user information is registered by adopting a real-name system, and the game duration of the users is counted according to the unique identification (such as identification numbers) of the users. However, since the user data of the game manufacturer belongs to the business privacy, the user data of different game manufacturers are isolated from each other, each game manufacturer can only count the game duration of the user on its own platform, when the user participates in the game at a plurality of game manufacturers, the game duration counted by the game manufacturer is easily different from the total duration of the user actually participating in the game, and the accuracy of counting the game duration of the user is reduced.

Disclosure of Invention

The embodiment of the application provides a business data processing method, a business data processing device and a readable storage medium, which can improve the accuracy of business data statistics.

An aspect of the present application provides a method for processing service data, which is applied to a monitoring server, and includes:

receiving a behavior query request sent by a first service server, wherein the behavior query request comprises a first user identifier corresponding to a target user and target behavior parameters;

acquiring a second user identifier of the target user in a second service server according to the first user identifier;

obtaining historical behavior parameters respectively corresponding to the first user identifier and the second user identifier from a block chain, wherein the block chain comprises the historical behavior parameters respectively uploaded by the first service server and the second service server;

and determining a behavior query result corresponding to the target user according to the historical behavior parameters respectively corresponding to the target behavior parameter, the first user identifier and the second user identifier.

Each block in the block chain comprises a user identifier, and a historical behavior parameter and a behavior occurrence time corresponding to the user identifier, wherein the user identifier is any one user identifier in an identifier set, and the identifier set comprises the first user identifier and the second user identifier;

the obtaining of the historical behavior parameters corresponding to the first user identifier and the second user identifier from the block chain includes:

acquiring a block to be selected in the block chain according to the request timestamp of the behavior query request, the first user identifier and the second user identifier, wherein the block to be selected comprises behavior occurrence time in a target time range, and the target time range is determined based on the request timestamp;

and decrypting the ciphertext in the block to be selected to obtain historical behavior parameters respectively corresponding to the first user identifier and the second user identifier.

The decrypting the ciphertext in the block to be selected to obtain the historical behavior parameters corresponding to the first user identifier and the second user identifier respectively includes:

acquiring a first private key corresponding to the first service server and a second private key corresponding to the second service server;

based on the first private key, decrypting a ciphertext corresponding to the first user identifier in the block to be selected to obtain a historical behavior parameter corresponding to the first user identifier;

and based on the second private key, decrypting the ciphertext corresponding to the second user identification in the block to be selected to obtain the historical behavior parameter corresponding to the second user identification.

Determining a behavior query result corresponding to the target user according to the historical behavior parameters respectively corresponding to the target behavior parameter, the first user identifier and the second user identifier, including:

determining the total amount of the behavior parameters corresponding to the target user based on the historical behavior parameters respectively corresponding to the target behavior parameters, the first user identification and the second user identification;

if the total amount of the behavior parameters is larger than or equal to a parameter threshold value, determining that the target user belongs to a behavior abnormal state, and generating a behavior query result corresponding to the target user based on the total amount of the behavior parameters and the behavior abnormal state;

and if the total amount of the behavior parameters is smaller than the parameter threshold, determining that the target user belongs to a normal behavior state, and generating a behavior query result corresponding to the target user based on the normal behavior state and a difference value between the parameter threshold and the total amount of the behavior parameters.

The target behavior parameters comprise target game duration, wherein the target game duration refers to duration between a maximum login timestamp of the first service server for the target user and a request timestamp of the behavior query request; the historical behavior parameter corresponding to the first user identifier comprises a first historical game duration aiming at the target user in the first service server, and the historical behavior parameter corresponding to the second user identifier comprises a second historical game duration aiming at the target user in the second game server;

the determining, based on the historical behavior parameters respectively corresponding to the target behavior parameter, the first user identifier, and the second user identifier, a total amount of behavior parameters corresponding to the target user includes:

and determining the sum of the target game duration, the first historical game duration and the second historical game duration as the total game duration corresponding to the target user, and taking the total game duration as the total behavior parameter amount.

Wherein the administration server comprises an intelligent contract;

the intelligent contract is used for acquiring a second user identifier of a target user in a second service server; the intelligent contract is also used for acquiring historical behavior parameters respectively corresponding to the first user identification and the second user identification from a block chain; the intelligent contract is further used for determining a behavior query result corresponding to the target user according to the historical behavior parameters respectively corresponding to the target behavior parameter, the first user identifier and the second user identifier.

Wherein the method further comprises:

taking the historical behavior parameters uploaded by the first service server and the second service server respectively as to-be-uplink behavior data, and acquiring a user identifier and behavior occurrence time corresponding to the to-be-uplink behavior data;

and generating a block according to the to-be-uplink behavior data, and the user identifier and the behavior occurrence time corresponding to the to-be-uplink behavior data, and adding the block to the block chain.

Generating a block according to the to-be-uplink behavior data and the user identifier and the behavior occurrence time corresponding to the to-be-uplink behavior data, and adding the block to the block chain includes:

determining the to-be-uplink behavior data, and the user identifier and the behavior occurrence time corresponding to the to-be-uplink behavior data as to-be-uplink total data;

counting capacity information corresponding to the total data to be uplink;

if the capacity information is larger than a block capacity threshold in the block chain, splitting the total data to be uplink linked based on the block capacity threshold to obtain at least two sub data to be uplink linked;

and generating a block corresponding to each to-be-linked chain data, and adding the block to the block chain.

An aspect of the present embodiment provides a method for processing service data, which is applied to a first service server, and includes:

sending a behavior query request to a supervision server so that the supervision server determines a behavior query result corresponding to a target user based on the behavior query request;

the behavior query request comprises a first user identifier corresponding to a target user and target behavior parameters; the behavior query result is determined based on the target behavior parameters and historical behavior parameters respectively corresponding to the first user identifier and the second user identifier in the block chain; the block chain comprises historical behavior parameters uploaded by the first service server and the second service server respectively; the second user identifier refers to a user identifier of the target user in the second service server.

Wherein the method further comprises:

when a business exit behavior corresponding to the target user is detected, acquiring a historical behavior parameter associated with the business exit behavior;

and encrypting the historical behavior parameters, and sending the encrypted historical behavior parameters and the first user identifier corresponding to the target user to the supervision server so that the supervision server can perform uplink processing on the encrypted historical behavior parameters and the first user identifier corresponding to the target user.

An aspect of the present application provides a service data processing apparatus, which is applied to a monitoring server, and includes:

the system comprises a receiving module, a sending module and a receiving module, wherein the receiving module is used for receiving a behavior query request sent by a first service server, and the behavior query request comprises a first user identifier corresponding to a target user and target behavior parameters;

the first obtaining module is used for obtaining a second user identifier of the target user in a second service server according to the first user identifier;

a second obtaining module, configured to obtain historical behavior parameters corresponding to the first user identifier and the second user identifier respectively from a block chain, where the block chain includes the historical behavior parameters uploaded by the first service server and the second service server respectively;

and the determining module is used for determining a behavior query result corresponding to the target user according to the historical behavior parameters respectively corresponding to the target behavior parameter, the first user identifier and the second user identifier.

the second acquisition module includes:

a block determining unit, configured to obtain a block to be selected in the block chain according to a request timestamp of the behavior query request, the first user identifier, and the second user identifier, where the block to be selected includes a behavior occurrence time within a target time range, and the target time range is determined based on the request timestamp;

and the decryption unit is used for decrypting the ciphertext in the block to be selected to obtain the historical behavior parameters respectively corresponding to the first user identifier and the second user identifier.

Wherein the decryption unit includes:

the private key obtaining subunit is configured to obtain a first private key corresponding to the first service server and a second private key corresponding to the second service server;

the first decryption subunit is configured to decrypt, based on the first private key, a ciphertext corresponding to the first user identifier in the block to be selected to obtain a historical behavior parameter corresponding to the first user identifier;

and the second decryption subunit is configured to decrypt, based on the second private key, the ciphertext corresponding to the second user identifier in the block to be selected to obtain a historical behavior parameter corresponding to the second user identifier.

Wherein the determining module comprises:

a parameter total amount determining unit, configured to determine, based on historical behavior parameters respectively corresponding to the target behavior parameter, the first user identifier, and the second user identifier, a total amount of behavior parameters corresponding to the target user;

the abnormal state detection unit is used for determining that the target user belongs to the abnormal behavior state if the total amount of the behavior parameters is greater than or equal to a parameter threshold value, and generating a behavior query result corresponding to the target user based on the total amount of the behavior parameters and the abnormal behavior state;

and the normal state detection unit is used for determining that the target user belongs to a normal behavior state if the total amount of the behavior parameters is smaller than the parameter threshold, and generating a behavior query result corresponding to the target user based on the normal behavior state and a difference value between the parameter threshold and the total amount of the behavior parameters.

the parameter total amount determining unit is specifically configured to:

Wherein the apparatus comprises a smart contract; the intelligent contract is used for acquiring a second user identifier of a target user in a second service server; the intelligent contract is also used for acquiring historical behavior parameters respectively corresponding to the first user identification and the second user identification from a block chain; the intelligent contract is further used for determining a behavior query result corresponding to the target user according to the historical behavior parameters respectively corresponding to the target behavior parameter, the first user identifier and the second user identifier.

Wherein the apparatus further comprises:

a third obtaining module, configured to use the historical behavior parameters uploaded by the first service server and the second service server respectively as to-be-uplink behavior data, and obtain a user identifier and a behavior occurrence time corresponding to the to-be-uplink behavior data;

and the generating module is used for generating a block according to the to-be-uplink behavior data and the user identifier and the behavior occurrence time corresponding to the to-be-uplink behavior data, and adding the block to the block chain.

Wherein the generating module comprises:

a total data determining unit, configured to determine the to-be-uplink behavior data, and the user identifier and the behavior occurrence time corresponding to the to-be-uplink behavior data as total data to be uplink;

a counting unit, configured to count capacity information corresponding to the total data to be uplink;

a comparing unit, configured to split the total data to be uplink linked based on the block capacity threshold if the capacity information is greater than the block capacity threshold in the block chain, so as to obtain at least two sub data to be uplink linked;

and the adding unit is used for generating a block corresponding to each sub-data to be linked up and adding the block to the block chain.

An aspect of the present application provides a service data processing apparatus, which is applied to a first service server, and includes:

the first sending module is used for sending a behavior query request to a supervision server so that the supervision server determines a behavior query result corresponding to a target user based on the behavior query request;

Wherein the apparatus further comprises:

a third obtaining module, configured to obtain, when a service exit behavior corresponding to the target user is detected, a historical behavior parameter associated with the service exit behavior;

and the second sending module is used for encrypting the historical behavior parameters and sending the encrypted historical behavior parameters and the first user identifier corresponding to the target user to the supervision server so that the supervision server can carry out uplink processing on the encrypted historical behavior parameters and the first user identifier corresponding to the target user.

An aspect of the embodiments of the present application provides a computer device, including a memory and a processor, where the memory stores a computer program, and the computer program, when executed by the processor, causes the processor to execute the method according to an aspect of the embodiments of the present application.

An aspect of the embodiments of the present application provides a computer-readable storage medium storing a computer program, the computer program comprising program instructions that, when executed by a processor, perform a method as in an aspect of the embodiments of the present application.

According to the method and the device for inquiring the behavior of the target user, the behavior inquiry request sent by the first service server is received, the second user identification of the target user in the second service server is obtained based on the first user identification contained in the behavior inquiry request, further historical behavior parameters respectively corresponding to the first user identification and the second user identification can be obtained from the block chain, and the behavior inquiry result corresponding to the target user is determined based on the historical behavior parameters respectively corresponding to the target behavior parameters in the behavior inquiry request and the first user identification and the second user identification. Therefore, historical behavior parameters among a plurality of service servers are communicated through the block chain, the supervision server can determine the total amount of the behavior parameters corresponding to the user based on the historical behavior parameters in each service server and the behavior parameters in which the user is currently participating, and further judge whether the total amount of the behavior parameters corresponding to the user is illegal, so that omission of the behavior parameters of the user can be avoided, and accuracy of service data statistics can be improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

Fig. 1 is a schematic diagram of a blockchain network according to an embodiment of the present disclosure;

fig. 2 is a schematic timing diagram of a service data processing method according to an embodiment of the present application;

FIG. 3 is a schematic diagram illustrating a processing of a behavioral query request according to an embodiment of the present application;

fig. 4 is a timing diagram of another service data processing method provided in the embodiment of the present application;

fig. 5 is a schematic diagram of a block chain data structure according to an embodiment of the present application;

fig. 6a and fig. 6b are schematic structural diagrams of a game service data processing provided by an embodiment of the present application;

FIGS. 7a and 7b are schematic diagrams of an interface of game service data processing provided by an embodiment of the present application;

fig. 8 is a schematic structural diagram of a service data processing apparatus according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of another service data processing apparatus provided in an embodiment of the present application;

FIG. 10 is a schematic structural diagram of a computer device according to an embodiment of the present disclosure;

fig. 11 is a schematic structural diagram of another computer device provided in an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and 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 application.

Please refer to fig. 1, which is a block chain network structure diagram according to an embodiment of the present application. The blockchain network structure can be jointly constructed by a supervisory organization and a plurality of service providers. As shown in fig. 1, the blockchain network structure may include a server 10a, a server 10b, a server 10c, and a server 10d, each of which may backup the same blockchain 10e, and the server 10a, the server 10b, the server 10c, and the server 10d may be blockchain nodes in the blockchain network structure.

Taking the application of the blockchain network structure to the online game addiction prevention system as an example, the server 10a is represented as a supervision server corresponding to an online game supervision department, and the server 10a can acquire all data in the blockchain 10e and inquire whether the total game duration (also called as the total amount of behavior parameters) of a certain specific user in each game facilitator violates a rule; the server 10b, the server 10c, and the server 10d may be represented as background servers corresponding to game providers, and the background server corresponding to each game provider may write the collected user game duration (which may also be referred to as a historical behavior parameter) into the blockchain 10 e. The supervision server and the background server corresponding to the game facilitator can both backup the blockchain 10e and check the data written in the blockchain 10 e. Of course, if the game service provider wants to protect the game duration of the user, that is, other game service providers do not want to see the game duration of the user, the game service provider may apply for the public key to the server 10a, and encrypt the game duration of the user by using the public key, and the encrypted game duration of the user may be viewed only by the server 10 a.

The server 10a may assign a unique user number (also referred to as a user identifier) to the user included in each game facilitator, that is, different user numbers may be assigned to the same user according to the game facilitator, for example, the user number of the user 1 in the game facilitator a is 1, the user number of the game facilitator B is 2, and so on. The association relations between different user numbers corresponding to the same user are managed by the server 10a, so that when the game server looks up the data on the block chain 10e, the game duration of a certain user in other game servers cannot be tracked according to the data in the block chain 10e, and the user information in the game server can be ensured not to be leaked.

When it is detected that the user 1 is playing a game on a game platform (for example, a mobile client or a web game developed by a game service provider corresponding to the server 10b) corresponding to the server 10b, the server 10b (at this time, the server 10b may be referred to as a first service server) may send a game duration query request (also may be referred to as a behavior query request) for the user 1 to the server 10a, where the game duration query request may carry a user number 1 (may be referred to as a first user identifier) of the user 1 in the server 10b and a game duration (may be referred to as a target behavior parameter) of the user 1 in the game platform corresponding to the server 10 b.

After receiving the game duration query request sent by the server 10b, the server 10a may find the remaining user numbers having an association relationship with the user number 1, such as the user number 2 of the user 1 in the server 10c, and the user number 2 of the user 1 in the server 10d (at this time, the server 10c and the server 10d may both be referred to as a second service server, and the user number 2 and the user number 3 may both be referred to as a second user identifier), where the first user identifier (e.g., the user number 1) and the second user identifier (e.g., the user number 2 and the user number 3) are different from each other. The server 10a may obtain the game durations respectively corresponding to the user number 1, the user number 2, and the user number 3 within a specific time range (for example, within 24 hours) from the blockchain 10e, and add the obtained game durations to obtain the total game duration corresponding to the user 1. When the total game duration corresponding to the user 1 exceeds a specified time threshold, determining that the user 1 violates a rule set in the online game anti-addiction system, and returning a query result that the game duration exceeds the specification to the server 10 b; when the total game duration corresponding to the user 1 does not exceed the specified time threshold, it is determined that the user 1 does not violate the rule set in the online game anti-addiction system, and an inquiry result of the remaining game duration is returned to the server 10b, that is, after the user 1 continues to play for a longer time, the rule set in the online game anti-addiction system is violated.

The server 10b, upon receiving the query result returned by the server 10a, may generate a prompt message based on the query result and display the prompt message in the platform page where the user 1 is playing the game. When the returned inquiry result is that the user 1 has violated the rule set in the network game addiction prevention system, the server 10b may forcibly prohibit the user 1 from participating in the network game.

The server 10b may preset a trigger condition for sending the game duration query request to the server 10a, for example, automatically sending the game duration query request to the server 10a at intervals (for example, 10 minutes); or, after detecting that the user finishes one game in the game, automatically send a game duration query request to the server 10a, which is not limited herein.

Please refer to fig. 2, which is a timing diagram of a service data processing method according to an embodiment of the present application. As shown in fig. 2, the service data processing method may include the following steps:

step S101, sending a behavior query request to a supervision server, wherein the behavior query request comprises a first user identifier corresponding to a target user and target behavior parameters;

specifically, when a first service server (corresponding to the server 10b sending the game duration query request in the embodiment corresponding to fig. 1) detects that there is a user performing service processing in a service processing platform corresponding to the first service server, a behavior query request may be sent to a monitoring server (corresponding to the server 10a in the embodiment corresponding to fig. 1). The behavior query request at least includes a first user identifier and a target behavior parameter corresponding to a target user (i.e., a user performing service processing in a service processing platform corresponding to a first service server); the first subscriber identity represents the identity information of the target subscriber in the first service server, in other words, the target subscriber may have identity information different from the first subscriber identity in the rest service servers; the target behavior parameter represents a behavior parameter corresponding to the current service of the target user in the service processing platform.

It can be understood that, before the first service server sends the behavior query request, the first service server may request the monitoring server for a first user identifier of the target user in the first service server, and a specific process is described as follows:

after the target user registers and logs in the service processing platform corresponding to the first service server for the first time, the first service server may send a user identifier obtaining request to the monitoring server, so as to obtain the unique identifier information of the target user in the first service server from the monitoring server. The user identifier obtaining request at least may include identification information corresponding to the first service server (e.g., a name abbreviation of a service provider corresponding to the first service server, or an enterprise code of the service provider corresponding to the first service server, etc.), and real-name information corresponding to the target user (e.g., an identification number of the target user, etc.). When a target user fills in personal information on a service processing platform corresponding to a first service server for registration, real-name information filling is required, namely information such as a real name, a real identity card number and the like of the target user is required to be filled.

After acquiring the user identifier acquisition request sent by the first service server, the supervision server may allocate an unused user number to the target user, where the unused user number is used as the first user identifier of the target user in the first service server, and store an association relationship among the first user identifier, the target user real-name information, and the first service server in a local storage of the supervision server. For all users in the first service server, the user number is unique, that is, the target user can be determined based on the user number. It can be understood that the monitoring server may receive the user identifier obtaining requests of the plurality of service servers, and the monitoring server may determine the user numbers corresponding to the users included in the different service servers according to the timestamps of the received user identifier obtaining requests. For example, when the monitoring server receives a user identifier acquisition request for the user 1 sent by the first service server at 8:00, the value 1 may be used as the user number of the user 1 in the first service server; when the supervision server receives a user identifier acquisition request aiming at the user 1 sent by another service server at 9:00, the numerical value 2 can be used as the user number of the user 1 in the other service server; when the supervision server receives a user identifier acquisition request for the user 2 sent by the first service server at 9:05, the value 3 may be used as the user number of the user 2 in the first service server, and the like.

Optionally, the monitoring server may allocate a number segment to each service server in advance, and when the first service server sends a user identifier acquisition request to the monitoring server, the monitoring server may allocate an unused number to the target user from the number segment corresponding to the first service server, where the unused number is used as the first user identifier of the target user in the first service server. For example, the monitoring server may allocate the value segments 1 to 100 to the first service server in advance, and when the monitoring server receives a user identifier acquisition request for the user 4 sent by the first service server, the value 1 may be used as the user number of the user 4 in the first service server; when the monitoring server receives the user identifier obtaining request for the user 5 sent by the first service server again, the value 2 may be used as the user number of the user 5 in the first service server; by analogy, after each value in the value segments 1-100 is allocated to the user in the first service server, the monitoring server may reallocate a value segment for the first service server, such as 301 and 400. It should be noted that the first subscriber identity and the second subscriber identity are used to distinguish identification information of target subscribers in different service servers, and may be collectively referred to as a subscriber identity.

Step S102, acquiring a second user identification of the target user in a second service server according to the first user identification;

specifically, after receiving the behavior query request sent by the first service server, the monitoring server may obtain, based on a first user identifier carried in the behavior query request, real-name information associated with the first user identifier from a local storage, and further obtain a second user identifier matched with the real-name information, where the second user identifier is identification information of a target user in the second service server. The second service server is to distinguish from the first service server, and in essence, the second service server refers to one or more service servers capable of processing the same service type as the first service server, and when the second service server is a single service server, the second user identifier is also single identification information; and when the second service server comprises a plurality of service servers except the first service server, the second user identification represents identification information corresponding to the target user in each service server except the first service server.

For example, the monitoring server receives a behavior query request for the user 1 sent by the service server 1 (i.e., a first service server), where a first user identifier carried in the behavior query request is a value 1, and the monitoring server obtains real name information associated with the value 1 from the local storage as follows: "name: small a "," identification number: 421xxxxx000 ", namely" name: small a "," identification number: 421xxxxx000 "is the personal information of the user 1, and it can be determined that the user number of the user 1 in the service server 2 is the value 5, and the user number in the service server 3 is the value 16, so that both the service server 2 and the service server 3 can be referred to as a second service server, and both the value 5 and the value 16 can be referred to as a second user id, that is, the value 5 is referred to as the second user id of the user 1 in the service server 2, and the value 16 is referred to as the second user id of the user 1 in the service server 3.

Step 103, obtaining historical behavior parameters respectively corresponding to the first user identifier and the second user identifier from a block chain, wherein the block chain comprises the historical behavior parameters respectively uploaded by the first service server and the second service server;

specifically, after the monitoring server obtains the first user identifier and the second user identifier corresponding to the target user, based on the request timestamp of the behavioral query request and the first and second subscriber identities, acquiring a block to be selected from the block chain, acquiring historical behavior parameters corresponding to a first user identifier and a second user identifier from the block to be selected, the block chain may include historical behavior parameters uploaded by the first service server and the second service server respectively, and the action occurrence time (which may be a specific date) corresponding to the historical action parameter, the candidate block includes the action occurrence time within the target time range, the target time range may be determined based on a request timestamp of the behavioral query request, such as a request timestamp of 2019, 3, month 1, day 8:00, the target time range may be 0:00 on month 1 of 2019 to 8:00 on month 1 of 2019.

The block chain may be configured to store historical behavior parameters in a plurality of service servers, and the block chain may be formed by a plurality of blocks (blocks) in a block structure, where each block may be configured to store a user identifier, and a historical behavior parameter and a behavior occurrence time corresponding to the user identifier. Each tile in the chain of tiles may be generated according to the time of the historical behavior parameters uploaded by the plurality of traffic servers. And storing the historical behavior parameters, the user identification corresponding to the user generating the historical behavior parameters and the time of the occurrence of the historical behavior parameters into a block chain, so that the reading of subsequent data is facilitated. Each block can correspond to a generation time stamp, that is, when the block is generated, a time stamp can be automatically generated, and based on the time stamp, the front-back sequence of each block in the block chain can be quickly determined.

The monitoring server may determine, based on the request timestamp of the behavior query request, a query time range for the target user (i.e., the target time range), where the query time range may be a time range determined by a fixed duration, and if the fixed duration is 6 hours, the query time range is 6 hours before the request timestamp; alternatively, the query time range may be a specific date (that is, the date of the day of the request timestamp). And if the stored behavior occurrence time in the blocks of the block chain belongs to the query time range, determining the blocks as the blocks to be selected, and searching the historical behavior parameters corresponding to the first user identification and the second user identification from the blocks to be selected. Optionally, based on the generation timestamp corresponding to each block, a block within the query time range is determined from the block chain, the block within the query time range is determined as a block to be selected, then data stored in the block to be selected is read, and historical behavior parameters corresponding to the first user identifier and the second user identifier respectively are obtained from the block.

Optionally, if the data read by the monitoring server from the block to be selected is an encrypted ciphertext (i.e., an encrypted historical behavior parameter), a first private key corresponding to the first service server may be obtained, a second private key corresponding to the second server may be obtained, and the ciphertext corresponding to the first user identifier in the block to be selected is decrypted based on the first private key, so as to obtain a historical behavior parameter corresponding to the first user identifier; and based on the second private key, decrypting the ciphertext corresponding to the second user identification in the block to be selected to obtain the historical behavior parameter corresponding to the second user identification. For the ciphertexts encrypted by each service server in the block chain, the supervision servers can decrypt by using the private keys corresponding to each service server, namely, the private keys for decrypting the historical behavior parameters are controlled by the supervision servers, and the decryption cannot be performed between the service servers.

For example, the request timestamp of the behavior query request received by the monitoring server is No. 8:00 of No. 2/10 in 2019, and if the query duration is 24 hours each time, it may be determined that the query time range corresponding to the behavior query request is: 8:00 No. 2 month 9 of 2019 to 8:00 No. 2 month 10 of 2019; the supervision server determines the blocks generated within the range from 2019, 2, month 9, 8:00 to 2019, 2, month 10, 8:00 from the blockchain based on the behavior occurrence time (or the generation timestamp corresponding to each block) stored by each block in the blockchain as follows: block 5, block 6, block 7, and block 8, then block 5, block 6, block 7, and block 8 may be determined as candidate blocks; and reading data from the block 5, the block 6, the block 7 and the block 8 to obtain the historical behavior parameters corresponding to the first user identifier and the historical behavior parameters corresponding to the second user identifier. If the data stored in the block 5, the block 6, the block 7, and the block 8 are ciphertexts after encryption, the monitoring server may obtain a first private key corresponding to the first service server and a second private key corresponding to the second service server, and after the first private key and the second private key are used to decrypt the corresponding ciphertexts, historical behavior parameters respectively corresponding to the first user identifier and the second user identifier may be obtained from the block 5, the block 6, the block 7, and the block 8. Optionally, since the private keys corresponding to the first service server and the second service server are both controlled by the monitoring server, the first private key and the second private key may be the same or different, and are not specifically limited herein.

Step S104, determining a behavior query result corresponding to the target user according to the historical behavior parameters respectively corresponding to the target behavior parameter, the first user identifier and the second user identifier.

Specifically, the monitoring server may determine a total amount of behavior parameters corresponding to the target user according to historical behavior parameters corresponding to the target behavior parameter, the first user identifier, and the second user identifier, respectively; if the total amount of the behavior parameters is larger than or equal to the parameter threshold, determining that the target user belongs to a behavior abnormal state, and generating a behavior query result corresponding to the target user based on the total amount of the behavior parameters and the behavior abnormal state; and if the total amount of the behavior parameters is smaller than the parameter threshold, determining that the target user belongs to a behavior normal state, and generating a behavior query result corresponding to the target user based on the behavior normal state and the difference value between the parameter threshold and the total amount of the behavior parameters. In other words, the monitoring server may preset a parameter threshold, and after determining the historical behavior parameters corresponding to the first user identifier and the second user identifier, add the target behavior parameter to the historical behavior parameters corresponding to the first user identifier and the second user identifier, respectively, to obtain a total amount of the behavior parameters corresponding to the target user. If the total amount of the behavior parameters is larger than or equal to the set parameter threshold, determining that the target user belongs to a behavior abnormal state, generating a behavior query result based on the behavior abnormal state and the total amount of the behavior parameters, and returning the behavior query result to the first service server; and if the total amount of the behavior parameters is smaller than the set parameter threshold, determining that the target user belongs to a normal behavior state, calculating a difference value between the parameter threshold and the total amount of the behavior parameters, generating a behavior query result based on the normal behavior state and the difference value, and returning the behavior query result to the first service server. After receiving the behavior query result, the first service server may generate an information prompt window based on the behavior query result, and display the information prompt window in a display page of the service processing platform corresponding to the target user. For example, the parameter threshold preset in the monitoring server is 10, and when the total amount of the behavior parameters corresponding to the target user is 13, the monitoring server may determine the target user as a behavior abnormal state, and generate a behavior query result based on the behavior abnormal state and the total amount of the behavior parameters 13; when the total amount of the behavior parameters corresponding to the target user is 8, the monitoring server may determine that the target user is in a normal behavior state, subtract the total amount of the behavior parameters from the parameter threshold 10 by 8 to obtain a difference 2, and generate a behavior query result based on the normal behavior state and the difference 2.

Optionally, an intelligent contract may be deployed in the blockchain, and the specific implementation process of step 102 and step S104 is completed by invoking the intelligent contract, that is, the intelligent contract may be used to obtain a second user identifier of the target user in the second service server according to the behavior query request, may also be used to obtain historical behavior parameters corresponding to the first user identifier and the second user identifier respectively from the blockchain, and may also be used to determine a behavior query result corresponding to the target user according to the historical behavior parameters corresponding to the target behavior parameter, the first user identifier, and the second user identifier respectively. The intelligent contract is a behavior query contract participated by a supervisor (such as a supervision server) executing a query request, and the behavior query contract can be used for indicating the supervision server to obtain a second user identifier of a target user in a second service server when receiving a behavior query request of a first service server, obtaining historical parameters respectively corresponding to the first user identifier and the second user identifier from a block chain, and counting the historical parameters respectively corresponding to the target behavior parameter, the first user identifier and the second user identifier to obtain a behavior query result. The intelligent contract can include information such as query duration and parameter threshold corresponding to each behavior query request, the first user identifier included in the behavior query request sent by the first service server is used as a parameter and is input into the intelligent contract, the intelligent contract can obtain a second user identifier of a target user in the second service server through the first user identifier, and finally a behavior query result corresponding to the behavior query request is determined. The supervision server may update the intelligent contract, for example, the parameter threshold written in the intelligent contract is 10, the supervision server may change the parameter threshold to 5, and after the change, all node servers (i.e., all service servers) in the intelligent contract may be notified in a broadcast manner to achieve consensus among all node servers.

Please refer to fig. 3, which is a schematic diagram illustrating a processing of a behavior query request according to an embodiment of the present application. The blockchain 20a shown in fig. 3 may be a blockchain that contains historical behavior parameters of all users in a plurality of service servers.

It can be understood that, by recording the historical behavior parameters corresponding to all users in the multiple service servers on the blockchain, a non-falsifiable and difficult-to-lose distributed data reference can be provided for subsequent behavior query for a specific user, so that a behavior query result for any user can be realized. The behavior query processing procedure may include both the process of initiating a behavior query request and the process of executing a behavior query request. The method comprises the steps that a behavior query request is initiated mainly by a first service server, the first service server can collect state information (including two states of 'service processing in progress' and 'service processing not performed') of all users in a corresponding service processing platform in real time, when the state information collected by the first service server and corresponding to a target user is 'service processing in progress', the first service server can collect behavior parameters (namely target behavior parameters) of the current service processing of the target user in the first service server and a first user identifier corresponding to the target user, and sends the behavior query request to a supervision server based on the target behavior parameters and the first user identifier. Therefore, the process of executing the behavior query request is mainly completed by the monitoring server, and after receiving the behavior query request for the target user, the monitoring server can determine the second user identifier of the target user in the second service server, and further, based on the query time range and the behavior occurrence time stored in each block in the block chain 20a, the monitoring server can determine the blocks to be selected from the block chain 20a, which are the block N, the block N +1, the block N +2, and the block N +3, respectively. It is understood that the action occurrence time 1 in the block N, the action occurrence time 2 in the block N +1, the action occurrence time 3 in the block N +2, and the action occurrence time 4 in the block N +3 may all be within the query time range. According to the first user identification and the second user identification, historical behavior parameters respectively corresponding to the first user identification and the second user identification can be obtained from a block N, a block N +1, a block N +2 and a block N +3, then the historical behavior parameters respectively corresponding to the first user identification and the second user identification and target behavior parameters are counted to obtain a behavior parameter total amount, when the behavior parameter total amount is confirmed to exceed a parameter threshold value, a behavior abnormal state can be returned, the target user is reminded, and then management of the user behavior parameters can be effectively improved.

It can be understood that the first service server may periodically or periodically send a behavior query request for a target user to the monitoring server to obtain a behavior parameter query result corresponding to the target user in real time. Of course, the first service server may also send a behavior query request for other users to the monitoring server periodically or at regular time, so as to obtain the behavior parameter query results corresponding to all users in the first service server in real time.

It should be noted that the historical behavior parameter 1 stored in the block N refers to all the historical behavior parameters stored in the block, and the historical behavior parameter 1 may include a historical behavior parameter corresponding to a certain user in a certain service server; or, historical behavior parameters corresponding to a plurality of users in a certain service server can be included; or historical behavior parameters and the like corresponding to a plurality of users in a plurality of service servers. Correspondingly, the action occurrence time 1 stored in the block N may also refer to all action occurrence times stored in the block, and the historical action parameter of each user in any service server may correspond to one action occurrence time. In other words, each block may store historical behavior parameters and behavior occurrence times corresponding to a plurality of users in a plurality of service servers within a certain time period.

Please refer to fig. 4, which is a timing diagram of another service data processing method according to an embodiment of the present application. As shown in fig. 4, the service data processing method may include the following steps:

step S201, when a business exit behavior corresponding to the target user is detected, acquiring a historical behavior parameter associated with the business exit behavior;

specifically, when the first service server detects a service exit behavior of the target user, a behavior parameter associated with the service exit behavior may be obtained, and the obtained behavior parameter may also be referred to as a historical behavior parameter corresponding to the target user. The target user may perform service processing in the service processing platform corresponding to the first service server, and when the target user completes the service processing (for example, a completion option is selected in a display page of the service processing platform, or an exit option is selected, etc.), the first service server may detect a service exit behavior of the target user, and obtain a behavior parameter (i.e., a historical behavior parameter) of the target user in the service processing process. It can be understood that, if, in the service processing platform, the first service server detects service exit behaviors corresponding to multiple users at the same time, the historical behavior parameters corresponding to the multiple users may be obtained, and at this time, the multiple users may all be target users.

It should be noted that, before the first service server obtains the historical behavior parameters associated with the service exit behavior, the user identifier obtaining process for the target user is already completed, that is, when the target user registers and logs in any service processing platform corresponding to the first server for the first time, the first service server may request the first user identifier from the monitoring server; when the target user performs service processing on any service processing platform corresponding to the first server and exits, the first service server may be triggered to acquire the historical behavior parameters associated with the current service exiting behavior, so that the operation requesting the first user identifier occurs before the operation acquiring the historical behavior parameters. The specific process of requesting the first user identifier may refer to step S101 in the embodiment corresponding to fig. 2, which is not described herein again.

Step S202, encrypting the historical behavior parameters, and sending the encrypted historical behavior parameters and the first user identification corresponding to the target user to the supervision server;

specifically, after the first service server obtains the historical behavior parameter associated with the service exit behavior, if the first service server does not want other service servers to view the historical behavior parameter of the target user, the behavior parameter may be encrypted by using an encryption technology, and the encrypted historical behavior parameter and the first user identifier corresponding to the target user are sent to the supervision server, so that the supervision server writes the encrypted historical behavior parameter and the first user identifier corresponding to the target user into the block chain.

The encryption technology is a process of converting the behavior parameters through an algorithm, and a receiver can decrypt a ciphertext (i.e., the converted behavior parameters) through a key to restore the ciphertext into a plaintext (i.e., the restored behavior parameters). If the first service server encrypts the behavior parameter by using asymmetric cryptography (also referred to as public-key cryptography), the first service server may apply for an encryption public key from the monitoring server to implement an encryption process for the behavior parameter. When receiving the key application of the first service server, the supervision server may locally generate a pair of keys (including a public key and a private key), where the public key may be returned to the first service server to encrypt the behavior parameter, and the private key may be stored by itself. The behavior parameters encrypted by the public key can be decrypted only by the corresponding private key, so that after the first service server encrypts the behavior parameters by using the public key, only the supervision server can decrypt the behavior parameters and check corresponding contents, namely, only the supervision server has the right to check the encrypted behavior parameters. Common asymmetric encryption algorithms may include: RSA (a public key encryption algorithm), Elgamal (a discrete logarithm-based public key algorithm), backpacking algorithm, Rabin (an asymmetric encryption algorithm based on modulo square and modulo square root), and ECC (Elliptic curve encryption algorithm), etc.

Optionally, the first service server may further encrypt the behavior parameter by using symmetric encryption (also called public-key encryption), where the symmetric encryption is encryption and decryption by using the same key, that is, when the first service server applies for the key to the monitoring server, the monitoring server may generate a key corresponding to the first service server and distribute the key to the first service server, and the first service server may encrypt the behavior parameter of the target user based on the key. Common symmetric encryption algorithms may include: DES (Data Encryption Standard), AES (Advanced Encryption Standard), and the like.

Step S203, using the historical behavior parameters respectively uploaded by the first service server and the second service server as to-be-uplink behavior data, and obtaining a user identifier and a behavior occurrence time corresponding to the to-be-uplink behavior data;

specifically, the monitoring server may receive historical behavior parameters respectively sent by the plurality of service servers, and use the historical behavior parameters respectively sent by the plurality of service servers as to-be-uplink behavior data, i.e., write the received historical behavior parameters into the block chain. The historical behavior parameters respectively sent by the plurality of service servers may include historical behavior parameters respectively corresponding to the plurality of user identifications, in other words, the historical behavior parameters received by the supervision server may include the historical behavior parameters sent by the first service server for the target user, or may further include the historical behavior parameters sent by the first service server for the remaining users, or may further include the historical behavior parameters sent by the second service server for the other users. The supervision server can obtain a user identifier and behavior occurrence time corresponding to each historical behavior parameter in the to-be-uplink behavior data, wherein the behavior occurrence time refers to the date when the user generates the historical behavior parameters.

The historical behavior parameters received by the monitoring server may include historical behavior parameters that are not encrypted, and may also include ciphertexts corresponding to the encrypted historical behavior parameters.

Step S204, generating a block according to the to-be-uplink behavior data, and the user identifier and the behavior occurrence time corresponding to the to-be-uplink behavior data, and adding the block to a block chain;

specifically, the supervision server may add the to-be-uplink behavior parameters to the block chain based on the behavior occurrence time and the user identifier corresponding to each historical behavior parameter in the to-be-uplink behavior data. When the supervision server receives the historical behavior parameters sent by any service server, the supervision server can generate blocks based on the historical behavior parameters, the user identifiers and the occurrence dates, and adds the blocks into the block chain to complete the chain loading process of the to-be-chain-loaded behavior data. The supervision server receives the historical behavior parameters sent by the service server, can start a block packing function, packs and writes the historical behavior parameters, the user identification and the behavior occurrence time into a new block, and adopts a consensus algorithm to perform consensus on the packed new block to meet the block consistency requirement, and the block can be added into the block chain through the consensus. The consensus algorithm herein may include POW (Proof Of Work) algorithm, POS (Proof Of merit) algorithm, PBFT (Practical Byzantine Fault Tolerance) algorithm, Fabric consensus, and the like. For multiple historical behavior parameters received at the same time, the monitoring server may package and write all the historical behavior parameters received at the time into the same block. For example, at time 8:00, the monitoring server receives the historical behavior parameter 1 for the user 1 sent by the service server 1, the historical behavior parameter 2 for the user 2 sent by the service server 1, and the historical behavior parameter 3 for the user 3 sent by the service server 2, and then the monitoring server may package and write the historical behavior parameter 1, the historical behavior parameter 2, and the historical behavior parameter 3 into the same block, that is, generate a new block 1, and add the new block 1 passing the consensus to the block chain.

Optionally, the monitoring server may also pack and write the received historical behavior parameters into the block periodically to generate a new block. In other words, after receiving the historical behavior parameters sent by the service server, if the timestamp of the received historical behavior parameters does not satisfy the time period node for block generation, the monitoring server needs to wait for a period of time until the current time point satisfies the time period node for block generation, and then generates a new block based on all the historical behavior parameters received in the time period; if no historical behavior parameters sent by the service server are received in the time period, no new block may be generated when the time period node for block generation is satisfied, or an empty block may be generated (i.e., no historical behavior parameters of any user are stored in the block). For example, the monitoring server generates a new block every 10 minutes, and if the generation time point corresponding to the previous block is 8:00, the generation time point of the next new block may be determined to be 8: 10. When the supervision server receives the historical behavior parameter 1 sent by a certain service server at 8:02, the historical behavior parameter 1 can be cached locally until 8:10, a new block is generated based on all the historical behavior parameters received within the time range of 8:00 to 8:10, and the generated new block is added into the block chain. If no historical behavior parameters are received within the time range of 8:00 to 8:10, no new block is generated at 8:10, or an empty block is generated, which may also be added to the block chain.

The capacity of each block in the block chain is preset, and the maximum capacity of each block in the same block chain is the same. Therefore, after the supervision server receives the historical behavior parameters sent by the service server, the user identifier, the behavior occurrence time and the historical behavior parameters (namely the data of the to-be-uplink behaviors) can be determined as the total data of the to-be-uplink behaviors; counting capacity information corresponding to total data to be uplink; if the capacity information is larger than a block capacity threshold in the block chain, splitting total data to be uplink linked based on the block capacity threshold to obtain at least two sub data to be uplink linked; and generating a block corresponding to each to-be-linked chain datum, and adding the block to the block chain. In other words, when the amount of data of the historical behavior parameters received by the monitoring server at a certain time (or within a certain period of time) is too large, and the capacity of one block is not enough to store all the historical behavior parameters, the historical behavior parameters received at the certain time (or within the certain period of time) may be split to obtain at least two pieces of sub data to be uplink, generate blocks corresponding to each piece of sub data to be uplink, and add the generated blocks to the block chain. For example, as in the foregoing example, at time 8:00, the supervision server receives the historical behavior parameter 1 for the user 1 sent by the service server 1, the historical behavior parameter 2 for the user 2 sent by the service server 1, and the historical behavior parameter 3 for the user 3 sent by the service server 2, and determines the behavior occurrence time and the user identifier corresponding to the historical behavior parameter 1, the historical behavior parameter 2, the historical behavior parameter 3, and the three historical behavior parameters respectively as the total data to be uplink. Through statistics, the capacity corresponding to the total data to be uplink is 100 megabytes, and under the situation that the maximum capacity (i.e., the capacity threshold) corresponding to each block in the block chain is 80 megabytes, the total data to be uplink can be split into two pieces of sub data to be uplink, and the splitting method may include: based on the maximum capacity of 80 million corresponding to each block, if at least 2 blocks need to be generated for the total data to be uplink-linked, the total data to be uplink-linked can be equally divided to obtain 2 sub data to be uplink-linked with 50 million; or, according to the maximum capacity of 80 megabits corresponding to each block, dividing the total data to be uplink into 80 megabits of sub data to be uplink and 20 megabits of sub data to be uplink, which is not limited here.

The historical behavior parameters are stored in a block chain in a Key-Value pair (Key-Value) mode, the database is the simplest organization mode when the Key-Value pair is stored, the Key (Key) is a number corresponding to the stored data, the Value (Value) is the stored data, and the corresponding Value can be quickly inquired through the Key. Please refer to fig. 5, which is a block chain data structure according to an embodiment of the present disclosure. As shown in fig. 5, if the user a is in the service server 1, the user id allocated by the monitoring server is X, and the user a is in the service server 2, the user id allocated by the monitoring server is Y. After the user a completes the service processing in the service processing platform corresponding to the service server 1, the service server 1 may upload the historical behavior parameters corresponding to the service processing to the monitoring server, so that the monitoring server writes the historical behavior parameters corresponding to the service processing into the block chain, where the data form in the block chain is shown as the key value pair 30 a: the key is X, and the value is the date (No. 1/10 in 2019) and the historical behavior parameters of the business processing. After the user a completes the service processing in the service processing platform corresponding to the service server 2, the service server 2 may upload the historical behavior parameters corresponding to the service processing to the monitoring server, so that the monitoring server writes the historical behavior parameters corresponding to the service processing into the block chain, where the data form in the block chain is shown as the key value pair 30 b: the key is Y, and the value is the date (No. 1/10 in 2019) and the historical behavior parameters of the business processing. Of course, if the historical behavior parameters are encrypted in the service server, the historical behavior parameters in the key-value pair 30a and the key-value pair 30b are ciphertexts after encryption. After data is written into the chain, the blockchain can ensure that each server (including a plurality of business servers and supervision servers) on the chain has the same data and is difficult to tamper. The historical behavior parameters corresponding to all the users can be stored in a block chain in a key value pair mode.

It is understood that, for each node in the blockchain network, data such as historical behavior parameters uploaded into the blockchain network may be packed and written into a new block, and after the consensus is achieved, the newly generated block may be added to the blockchain. In other words, any node in the blockchain network can be used as an executor of the uplink processing procedure of the historical behavior parameters, such as the first service server, the second service server, and the supervision server. Taking the first service server as an example, the first service server is used as a node in the blockchain network, after obtaining the historical behavior parameters of the user, the first service server may encrypt the historical behavior parameters, encapsulate data such as the user identifier, the encrypted historical behavior parameters, and the behavior occurrence time (for example, encapsulate the data into a structural form of key value pairs) based on a data structure specified by the blockchain network, and send the encapsulated data to the blockchain network. The first server may pack and write data such as the user identifier, the encrypted historical behavior parameter, and the behavior occurrence time into a new block, and add the new block to the block chain after reaching the consensus.

Step S205, sending a behavior query request to a supervision server, wherein the behavior query request comprises a first user identifier corresponding to a target user and target behavior parameters;

step S206, acquiring a second user identifier of the target user in a second service server according to the first user identifier;

step S207, obtaining historical behavior parameters respectively corresponding to the first user identifier and the second user identifier from a block chain, where the block chain includes the historical behavior parameters uploaded by the first service server and the second service server, respectively;

step S208, determining a behavior query result corresponding to the target user according to the historical behavior parameters respectively corresponding to the target behavior parameter, the first user identifier and the second user identifier.

For a specific implementation process of step S205 to step S208, reference may be made to the description of step S101 to step S104 in the embodiment corresponding to fig. 2, and details are not repeated here.

The following takes the network game addiction prevention system as an example, and specifically describes the service data processing method. In the network game anti-addiction system, the target behavior parameter is a target game duration, namely the duration between a maximum login timestamp of the target user and a request timestamp of a behavior query request in the first service server; the historical behavior parameter represents the historical game duration of the user in each service server.

Please refer to fig. 6a and fig. 6b together, which are schematic structural diagrams of a game service data processing provided in the embodiment of the present application. As shown in fig. 6a, the supervision department 40a (corresponding to the server 10a in the embodiment corresponding to fig. 1) and the game vendors (specifically, the game vendor a, the game vendor B, the game vendor C, and the like in fig. 6a, which correspond to the server 10B, the server 10C, and the server 10d in the embodiment corresponding to fig. 1, respectively) jointly construct a blockchain network, which can be used for chaining the user game duration. The supervision department 40a and each game manufacturer may be a tile link point in the tile chain network, point-to-point transmission (P2P transmission) may be used to perform communication between tile link points, and information such as node connection and tile may be transmitted, that is, only data stored in the tile may be transmitted between different game manufacturers, and for user data except user game duration and user identifier, each game manufacturer is independent. Of course, if the game duration of the user is encrypted, the rest of the game manufacturers except the monitoring department 40a cannot check the encrypted game duration. Each game vendor may obtain from the regulatory authority 40a the unique user identifier of a particular user at that game vendor, and when the user finishes the game at the game vendor, the game vendor may request that the game duration of that user and the unique user identifier in that game vendor be linked. The supervision department writes an intelligent contract according to the established supervision rules, and the intelligent contract is used for inquiring whether the game duration of the same user (the same user has different user identifications in different game manufacturers, and the association relationship among the user identifications is managed by the supervision department 40 a) violates the rules so as to be inquired by the game manufacturers. Each game vendor may query the regulatory authority 40a for a particular user violation by a unique user identification that has been distributed to the user. The same blockchain 40b may be backed up by both the regulatory authority 40a and each game vendor, and both the regulatory authority 40a and each game vendor may know when data in the blockchain 40b is updated. In the blockchain network shown in fig. 6a, the processing procedure of the game duration mainly includes the following three service requests:

the game manufacturer requests the user identification from the regulatory authority 40 a. Taking the game manufacturer a as an example, when the game manufacturer a detects that there is a newly registered game user, a user identifier obtaining request may be sent to the monitoring department 40a to obtain a unique user identifier of the new game user in the game manufacturer a. The monitoring department 40a may assign different user identifications to the same user according to the game manufacturer. When viewing the data on the blockchain 40B, other game vendors (such as game vendor B and game vendor C) cannot track a specific user based on the user identifier, which ensures that the game duration of the user is stored in the blockchain 40B, and also ensures that the user data of each game vendor is not leaked. Of course, if the game manufacturer a desires that the game duration of each user is not seen by other game manufacturers, the game manufacturer a may synchronously apply for an encryption key (e.g., an asymmetric encryption public key) for the game manufacturer a from the monitoring department 40a, and encrypt the game duration of the user based on the encryption key distributed by the monitoring department 40 a.

The game manufacturer requests to uplink the game duration of the user. Taking the game manufacturer a as an example, when the game manufacturer a detects that there is a user ending the game, the game manufacturer a may obtain the duration of the game of the user in the game manufacturer a (i.e., the historical behavior parameters), and upload the duration of the game, the unique user identifier of the user in the game manufacturer a, and the date when the user ends the game to the blockchain network, so as to request the monitoring department 40a to write the duration of the game, the unique user identifier of the user in the game manufacturer a, and the date when the user ends the game into the blockchain 40 b. The duration of the game sent by the game manufacturer a to the regulation department 40a may be the duration after the game manufacturer a encrypts the game by using the encryption key distributed by the regulation department 40 a. The regulatory authority 40a may generate a new tile based on the duration of the game sent by the game vendor a, the unique user identifier of the user in the game vendor a, and the date when the user ended the game, and add the newly generated tile to the tile chain 40 b. Of course, in each game manufacturer, there may be a plurality of users ending the game at the same time (for example, when a team plays the game, each user in a battle team ends the game at the same time), and the game manufacturer may simultaneously send the game duration, the user identifier, and the date corresponding to the plurality of users to the monitoring department 40 a; for different game vendors, there may be a case where multiple game vendors send data such as the user game duration to the monitoring department 40a at the same time, and in this case, the monitoring department 40a may write a new tile into a new tile based on all data packets received at the same time, and add the new tile to the tile chain 40 b. As shown in FIG. 6b, when the regulatory authority 40a receives the data 40c from the game vendor A at the same time, the regulatory authority 40c may generate a new tile 40d based on the data 40 c. The data 40c may include information such as game duration corresponding to a plurality of users, for example, a user with a user identifier of 1, the corresponding occurrence time of 2019, 3, month and 1 day, and the game duration of 1 hour; the user with the user identification of 2 corresponds to the user with the occurrence time of 3 months and 1 day in 2019, and the game duration is 1 hour; the user identifier is 7, the corresponding occurrence time is 3, month and 1 day in 2019, and the game duration is 2 hours. All of the information contained in the data 40c may be stored in the block 40d, and of course, the block 40d may further include other information, such as a generation time stamp of the block 40d, a hash value of a previous block, a difficulty value, a random number, and the like. After the regulatory authority 40a generates a new tile 40d and passes the consensus, the tile 40d may be added to the blockchain 40 b.

If the amount of data received by the monitoring department 40a at the same time is too large and exceeds the maximum capacity of a single block in the block chain 40b, all the received data may be split to generate a plurality of new blocks, and the new blocks are added to the block chain 40 b.

Optionally, the game manufacturer a may also upload the game duration, the unique user identifier of the user in the game manufacturer a, and the date when the user finishes the game to the tile chain network, and then the game manufacturer a packages and writes the game duration, the unique user identifier of the user in the game manufacturer a, and the date when the user finishes the game into a new tile, and adds the new tile to the tile chain after the new tile passes the consensus.

The game manufacturer requests the monitoring department 40a to inquire the total game duration of a specific user. Taking the game manufacturer a as an example, the game manufacturer a is used as a first service server, and the game manufacturer B and the game manufacturer C are used as second service servers. When a user plays a game in a game application corresponding to the game vendor a, the game vendor a sends a duration query request (i.e., a behavior query request) for the user to the monitoring department 40a, where the duration query request may carry the user identifier of the user in the game vendor a and the game duration (i.e., the target behavior parameter) currently played by the user. The regulatory authority 40a makes a query from the blockchain 40b with the user identification and the length of the game currently being played as parameters. The monitoring department 40a may determine the user id of the user in the rest game vendors (e.g. game vendor B and/or game vendor C) based on the user id of the user in game vendor a, and according to the user id of the user in each game vendor, may query all the game durations of the user from the blockchain 40B, and further invoke the intelligent contract to calculate the total game duration (i.e. the total amount of the behavior parameters) of the user in the set time range. At least the following strategies can be adopted for acquiring the total game duration of the user: based on the user identifier of the user in each game vendor, finding out all game durations of the blockchain 40b for the user, then calling an intelligent contract, selecting the game durations within a set time range from all game durations of the user, for example, selecting the game durations of the current day (namely the date to which the request timestamp of the behavior query request belongs) from all game durations corresponding to the user 1 (which may be determined based on the behavior occurrence time stored in the key value pair), and adding the finally queried game durations and the current game durations to obtain the total game duration of the user; or, calling an intelligent contract, screening blocks within a set time range (which may be determined based on a time stamp generated by each block) from the block chain 40b based on the set time range (for example, a time range every 24 hours by taking a date as a unit) in the intelligent contract, further obtaining the game duration of the user from the screened blocks based on the user identifier of the user in each game vendor, and adding the finally queried game duration and the current game duration to obtain the total game duration of the user. After counting the total game duration of the user, the supervision department can judge whether the user violates the game rules in the online game addiction prevention system, and return the result to the game manufacturer A.

Optionally, the monitoring department 40a may invoke an intelligent contract to count the total game duration corresponding to each user periodically or at regular time, and when receiving a game duration query request for a certain user sent by the game manufacturer a, may directly add the latest statistical result of the user to the sent current game duration to obtain the final total game duration of the user.

Please refer to fig. 7a and fig. 7b together, which are schematic diagrams of an interface for processing game service data according to an embodiment of the present application. As shown in fig. 7a, if the total game duration of the user exceeds the duration threshold set in the smart contract, it is determined that the user belongs to an abnormal behavior state, and the query result is returned to the game vendor a, the game vendor a may generate an information prompt message 50a based on the query result after receiving the query result of the user, where the information prompt message 50a may be "the total duration of game play today is a hour, and exceeds the duration specified by the regulatory department, and after you finish the game, no game can be continued within this day", and a prompt window 50b containing the information prompt message 50a pops up in the game application being played by the user, so as to achieve the purpose of prompting the user. As shown in fig. 7b, if the total game duration of the user does not exceed the duration threshold set in the smart contract, it is determined that the user belongs to a normal behavior state, and the query result is returned to the game vendor a, after receiving the query result of the user, the game vendor a may generate an information prompt message 50c based on the query result, where the information prompt message 50c may be "the total duration of your game playing today is b hours, and after c hours, you will exceed the duration specified by the regulatory department and cannot continue playing the game", and a prompt window 50d including the information prompt message 50c is popped up in the game application being played by the user, so as to achieve the purpose of prompting the user.

It can be understood that the monitoring department 40a may set up game rules in the online game anti-addiction system, for example, if the time length of the user playing the game each day cannot exceed a certain time length threshold, if the total time length of the game of the user exceeds the set time length threshold, the user violates the rules; if the total game duration of the user does not exceed the set duration threshold, the user does not violate the rule. The supervision department 40a can compile the rules into an intelligent contract, and after completing the compilation of the intelligent contract, can broadcast and inform various game manufacturers.

Optionally, the service data processing method may also be applied to bank transfer management, and the blockchain network may be formed by a supervision department and a bank together. The supervision department may be a management institution such as a central bank, a bank prison or a guardian party, that is, the supervision server is a background server corresponding to the management institution such as the central bank, the bank prison or the guardian party, and the service server may be a background server corresponding to each bank; the target behavior parameter can refer to the transfer amount input by the user when the user transacts the transfer service in the bank; the historical behavior parameter may refer to the amount of money transferred that the user has completed the transfer service at each bank. When a user transacts a transfer service, a bank can send a behavior inquiry request to a monitoring department so as to obtain whether the total transfer amount (including the transfer amount input by the service and the transfer amount completed by the service) of the user on the same day exceeds the highest transfer amount of an individual on the same day, and if so, the transfer service of the user cannot be successfully processed; if not, the transfer service of the user can be successfully processed. The mode can effectively avoid illegal transfer of funds.

The method and the device have the advantages that the user game duration data among the game manufacturers are communicated through the blockchain network, the total game duration of the user among the game manufacturers can be quickly obtained, and the management of the online game user is facilitated; by using the intelligent contract, a supervision department can flexibly compile rules and compile the rules into the intelligent contract, so that whether the total game duration of a specific user violates rules or not can be quickly inquired, the omission of the game duration of the user can be avoided, the accuracy of counting the game duration of the user can be improved, and the management of the online game anti-addiction system is facilitated.

Please refer to fig. 8, which is a schematic structural diagram of a service data processing apparatus according to an embodiment of the present application. As shown in fig. 8, the service data processing apparatus 1 may be applied to the server 10a in the embodiment corresponding to fig. 1, and the service data processing apparatus 1 may include: the device comprises a receiving module 11, a first obtaining module 12, a second obtaining module 13 and a determining module 14;

a receiving module 11, configured to receive a behavior query request sent by a first service server, where the behavior query request includes a first user identifier and a target behavior parameter corresponding to a target user;

a first obtaining module 12, configured to obtain, according to the first user identifier, a second user identifier of the target user in a second service server;

a second obtaining module 13, configured to obtain historical behavior parameters corresponding to the first user identifier and the second user identifier respectively from a block chain, where the block chain includes the historical behavior parameters uploaded by the first service server and the second service server respectively;

a determining module 14, configured to determine a behavior query result corresponding to the target user according to historical behavior parameters respectively corresponding to the target behavior parameter, the first user identifier, and the second user identifier.

For specific functional implementation manners of the receiving module 11, the first obtaining module 12, the second obtaining module 13, and the determining module 14, reference may be made to step S101 and step S104 in the embodiment corresponding to fig. 2, which is not described herein again.

Referring to fig. 8, the service data processing apparatus 1 may further include: a third obtaining module 15, a generating module 16;

a third obtaining module 15, configured to use the historical behavior parameters uploaded by the first service server and the second service server, respectively, as to-be-uplink behavior data, and obtain a user identifier and behavior occurrence time corresponding to the to-be-uplink behavior data;

a generating module 16, configured to generate a block according to the to-be-uplink behavior data, and the user identifier and the behavior occurrence time corresponding to the to-be-uplink behavior data, and add the block to the block chain.

The specific functional implementation manner of the third obtaining module 15 and the generating module 16 may refer to steps S203 to S204 in the embodiment corresponding to fig. 4, which is not described herein again.

Referring to fig. 8, each block in the block chain includes a user identifier, and a historical behavior parameter and a behavior occurrence time corresponding to the user identifier, where the user identifier is any one of the user identifiers in an identifier set, and the identifier set includes the first user identifier and the second user identifier;

the second obtaining module 13 may include: a block determination unit 131, a decryption unit 132;

a block determining unit 131, configured to obtain a block to be selected in the block chain according to the request timestamp of the behavior query request, the first user identifier, and the second user identifier; the candidate block comprises a behavior occurrence time in a target time range, the target time range being determined based on the request timestamp;

the decryption unit 132 is configured to decrypt the ciphertext in the block to be selected to obtain historical behavior parameters corresponding to the first user identifier and the second user identifier, respectively.

The specific functional implementation manners of the block determining unit 131 and the decrypting unit 132 can refer to step S103 in the embodiment corresponding to fig. 2, which is not described herein again.

Referring also to fig. 8, the determination module 14 may include: a parameter total amount determining unit 141, an abnormal state detecting unit 142, a normal state detecting unit 143;

a parameter total amount determining unit 141, configured to determine a total amount of the behavior parameters corresponding to the target user based on historical behavior parameters respectively corresponding to the target behavior parameter, the first user identifier, and the second user identifier;

an abnormal state detection unit 142, configured to determine that the target user belongs to an abnormal behavior state if the total amount of the behavior parameters is greater than or equal to a parameter threshold, and generate a behavior query result corresponding to the target user based on the total amount of the behavior parameters and the abnormal behavior state;

a normal state detection unit 143, configured to determine that the target user belongs to a normal behavior state if the total amount of the behavior parameters is smaller than the parameter threshold, and generate a behavior query result corresponding to the target user based on the normal behavior state and a difference between the parameter threshold and the total amount of the behavior parameters.

The target behavior parameters comprise target game duration, wherein the target game duration refers to the duration between the maximum login timestamp of the first service server for the target user and the request timestamp of the behavior query request; the historical behavior parameter corresponding to the first user identifier comprises a first historical game duration aiming at the target user in the first service server, and the historical behavior parameter corresponding to the second user identifier comprises a second historical game duration aiming at the target user in the second game server;

the parameter total amount determining unit 141 is specifically configured to:

The specific functional implementation manners of the parameter total amount determining unit 141, the abnormal state detecting unit 142, and the normal state detecting unit 143 may refer to step S104 in the embodiment corresponding to fig. 2, which is not described herein again.

Referring also to fig. 8, the generation module 16 may include: a total data determination unit 161, a statistic unit 162, a comparison unit 163, an addition unit 164;

a total data determining unit 161, configured to determine the to-be-uplink behavior data, and the ue and the behavior occurrence time corresponding to the to-be-uplink behavior data as to-be-uplink total data;

a counting unit 162, configured to count capacity information corresponding to the total data to be uplink;

a comparing unit 163, configured to split the total data to be uplink based on the block capacity threshold to obtain at least two sub data to be uplink if the capacity information is greater than the block capacity threshold in the block chain;

an adding unit 164, configured to generate a block corresponding to each to-be-linked chain data, and add the block to the block chain.

The specific functional implementation manners of the total data determining unit 161, the counting unit 162, the comparing unit 163, and the adding unit 164 may refer to step S204 in the embodiment corresponding to fig. 4, which is not described herein again.

Referring to fig. 8, the decryption unit 132 may include: a private key obtaining subunit 1321, a first decrypting subunit 1322, a second decrypting subunit 1323;

a private key obtaining subunit 1321, configured to obtain a first private key corresponding to the first service server and a second private key corresponding to the second service server;

a first decryption subunit 1322, configured to decrypt, based on the first private key, a ciphertext corresponding to the first user identifier in the block to be selected, so as to obtain a historical behavior parameter corresponding to the first user identifier;

and the second decryption subunit 1323 is configured to decrypt, based on the second private key, the ciphertext corresponding to the second user identifier in the block to be selected, so as to obtain the historical behavior parameter corresponding to the second user identifier.

The specific functional implementation manners of the private key obtaining subunit 1321, the first decrypting subunit 1322, and the second decrypting subunit 1323 may refer to step S103 in the embodiment corresponding to fig. 2, which is not described herein again.

Please refer to fig. 9, which is a schematic structural diagram of another service data processing apparatus according to an embodiment of the present application. As shown in fig. 9, the service data processing apparatus 2 may be applied to the server 10b in the embodiment corresponding to fig. 1, and the service data processing apparatus 2 may include: a first transmission module 21;

a first sending module 21, configured to send a behavior query request to a monitoring server, so that the monitoring server determines a behavior query result corresponding to a target user based on the behavior query request;

For a specific implementation manner of the function of the first sending module 21, reference may be made to step S101 in the embodiment corresponding to fig. 2, which is not described herein again.

Referring to fig. 9, the service data processing apparatus 2 may further include: a third obtaining module 22, a second sending module 23;

a third obtaining module 22, configured to, when a service exit behavior corresponding to the target user is detected, obtain a historical behavior parameter associated with the service exit behavior;

the second sending module 23 is configured to encrypt the historical behavior parameters, and send the encrypted historical behavior parameters and the first user identifier corresponding to the target user to the monitoring server, so that the monitoring server performs uplink processing on the encrypted historical behavior parameters and the first user identifier corresponding to the target user.

The specific functional implementation manners of the third obtaining module 22 and the second sending module 23 may refer to steps S201 to S202 in the embodiment corresponding to fig. 4, which is not described herein again.

Fig. 10 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 10, the computer device 1000 may correspond to the server 10a in the embodiment corresponding to fig. 1, and the computer device 1000 may include: the processor 1001, the network interface 1004, and the memory 1005, and the computer apparatus 1000 may further include: a user interface 1003, and at least one communication bus 1002. Wherein a communication bus 1002 is used to enable connective communication between these components. The user interface 1003 may include a Display screen (Display) and a Keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a standard wireless interface. The network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). The memory 1004 may be a high-speed RAM memory or a non-volatile memory (e.g., at least one disk memory). The memory 1005 may optionally be at least one memory device located remotely from the processor 1001. As shown in fig. 10, a memory 1005, which is a kind of computer-readable storage medium, may include therein an operating system, a network communication module, a user interface module, and a device control application program.

In the computer device 1000 shown in fig. 10, the network interface 1004 may provide a network communication function; the user interface 1003 is an interface for providing a user with input; and the processor 1001 may be used to invoke a device control application stored in the memory 1005 to implement:

It should be understood that the computer device 1000 described in this embodiment of the present application may perform the description of the service data processing method in the embodiment corresponding to any one of fig. 2 and fig. 4, and may also perform the description of the service data processing apparatus 1 in the embodiment corresponding to fig. 8, which is not described herein again. In addition, the beneficial effects of the same method are not described in detail.

Further, here, it is to be noted that: an embodiment of the present application further provides a computer-readable storage medium, where a computer program executed by the aforementioned service data processing apparatus 1 is stored in the computer-readable storage medium, and the computer program includes program instructions, and when the processor executes the program instructions, the description of the service data processing method in any one of the embodiments corresponding to fig. 2 and fig. 4 can be executed, so that details are not repeated here. In addition, the beneficial effects of the same method are not described in detail. For technical details not disclosed in embodiments of the computer-readable storage medium referred to in the present application, reference is made to the description of embodiments of the method of the present application.

Please refer to fig. 11, which is a schematic structural diagram of another computer device according to an embodiment of the present application. As shown in fig. 11, the computer device 2000 may correspond to the server 10b in the embodiment corresponding to fig. 1, and the computer device 2000 may include: the processor 2001, the network interface 2004 and the memory 2005, the computer device 2000 may further include: a user interface 2003, and at least one communication bus 2002. The communication bus 2002 is used to implement connection communication between these components. The user interface 2003 may include a Display (Display) and a Keyboard (Keyboard), and the optional user interface 2003 may further include a standard wired interface and a standard wireless interface. The network interface 2004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). The memory 2004 may be a high-speed RAM memory or a non-volatile memory, such as at least one disk memory. The memory 2005 may optionally also be at least one memory device located remotely from the aforementioned processor 2001. As shown in fig. 11, the memory 2005, which is a type of computer-readable storage medium, may include therein an operating system, a network communication module, a user interface module, and a device control application program.

In the computer device 2000 shown in fig. 11, the network interface 2004 may provide a network communication function; and the user interface 2003 is primarily used to provide an interface for user input; and the processor 2001 may be used to invoke the device control application stored in the memory 1005 to implement:

It should be understood that the computer device 2000 described in this embodiment may perform the description of the service data processing method in the embodiment corresponding to any one of fig. 2 and fig. 4, and may also perform the description of the service data processing apparatus 2 in the embodiment corresponding to fig. 9, which is not described herein again. In addition, the beneficial effects of the same method are not described in detail.

Further, here, it is to be noted that: an embodiment of the present application further provides a computer-readable storage medium, where a computer program executed by the aforementioned service data processing apparatus 2 is stored in the computer-readable storage medium, and the computer program includes program instructions, and when the processor executes the program instructions, the description of the service data processing method in any one of the embodiments corresponding to fig. 2 and fig. 4 can be executed, so that details are not repeated here. In addition, the beneficial effects of the same method are not described in detail. For technical details not disclosed in embodiments of the computer-readable storage medium referred to in the present application, reference is made to the description of embodiments of the method of the present application.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), or the like.

The above disclosure is only for the purpose of illustrating the preferred embodiments of the present application and is not to be construed as limiting the scope of the present application, so that the present application is not limited thereto, and all equivalent variations and modifications can be made to the present application.

Claims

1. A business data processing method is applied to a supervision server and is characterized by comprising the following steps:

the method comprises the steps that a supervision server receives a behavior query request sent by a first service server, wherein the behavior query request comprises a first user identifier corresponding to a target user and target behavior parameters;

acquiring a second user identifier of the target user in a second service server according to the first user identifier, wherein the first service server and the second service server are background servers corresponding to different game service providers, and the first user identifier and the second user identifier are unique user numbers distributed by the supervision server for the target user in different game service providers;

determining the total amount of the behavior parameters corresponding to the target user according to the historical behavior parameters respectively corresponding to the target behavior parameter, the first user identifier and the second user identifier, and determining a behavior query result corresponding to the target user according to the total amount of the behavior parameters, wherein the behavior query result comprises a query result that the total amount of the behavior parameters exceeds a time length threshold, or a query result that the total amount of the behavior parameters does not exceed the time length threshold, the query result that the total amount of the behavior parameters exceeds the time length threshold is used for prompting that the target user cannot participate in service processing, and the query result that the total amount of the behavior parameters does not exceed the time length threshold is used for prompting the service remaining time length of the target user.

2. The method according to claim 1, wherein each tile in the tile chain comprises a user identifier and a historical behavior parameter and a behavior occurrence time corresponding to the user identifier, the user identifier is any one of a set of identifiers, and the set of identifiers comprises the first user identifier and the second user identifier;

3. The method according to claim 2, wherein the decrypting the ciphertext in the block to be selected to obtain the historical behavior parameters corresponding to the first user identifier and the second user identifier respectively comprises:

4. The method according to claim 1, wherein the determining, according to the historical behavior parameters corresponding to the target behavior parameter, the first user identifier, and the second user identifier, a total amount of behavior parameters corresponding to the target user, and determining, according to the total amount of behavior parameters, a behavior query result corresponding to the target user, includes:

5. The method of claim 4, wherein the target behavior parameter comprises a target game duration, and the target game duration is a duration between a maximum login timestamp for the target user in the first service server and a request timestamp of the behavior query request; the historical behavior parameter corresponding to the first user identifier comprises a first historical game duration aiming at the target user in the first service server, and the historical behavior parameter corresponding to the second user identifier comprises a second historical game duration aiming at the target user in the second service server;

6. The method of claim 1, wherein the administration server comprises a smart contract;

7. The method of claim 2, further comprising:

8. The method of claim 7, wherein the generating a block according to the to-be-uplink behavior data and the ue and the behavior occurrence time corresponding to the to-be-uplink behavior data, and adding the block to the blockchain comprises:

counting capacity information corresponding to the total data to be uplink;

9. A service data processing method is applied to a first service server, and is characterized by comprising the following steps:

the behavior query request comprises a first user identifier corresponding to a target user and target behavior parameters; the behavior query result is generated based on the total amount of the behavior parameters determined by the target behavior parameters and the historical behavior parameters respectively corresponding to the first user identification and the second user identification in the block chain; the block chain comprises historical behavior parameters uploaded by the first service server and the second service server respectively; the first service server and the second service server are background servers corresponding to different game service providers, and the first user identifier and the second user identifier are unique user numbers distributed by the supervision server for the target users in different game service providers; the second user identification refers to the user identification of the target user in the second service server; the behavior query result comprises a query result that the total amount of the behavior parameters exceeds a duration threshold, or a query result that the total amount of the behavior parameters does not exceed the duration threshold, the query result that the total amount of the behavior parameters exceeds the duration threshold is used for prompting that the target user cannot participate in service processing, and the query result that the total amount of the behavior parameters does not exceed the duration threshold is used for prompting the service remaining duration of the target user.

10. The method of claim 9, further comprising:

11. A business data processing device applied to a supervision server is characterized by comprising:

a first obtaining module, configured to obtain, according to the first user identifier, a second user identifier of the target user in a second service server, where the first service server and the second service server are background servers corresponding to different game service providers, and both the first user identifier and the second user identifier are unique user numbers allocated by the monitoring server to the target user in different game service providers;

a determining module, configured to determine, according to historical behavior parameters corresponding to the target behavior parameter, the first user identifier, and the second user identifier, a total amount of behavior parameters corresponding to the target user, and determine, according to the total amount of behavior parameters, a behavior query result corresponding to the target user, where the behavior query result includes a query result that the total amount of behavior parameters exceeds a duration threshold, or a query result that the total amount of behavior parameters does not exceed the duration threshold, where the query result that the total amount of behavior parameters exceeds the duration threshold is used to prompt the target user that the target user cannot participate in service processing, and the query result that the total amount of behavior parameters does not exceed the duration threshold is used to prompt the remaining duration of a service of the target user.

12. The apparatus according to claim 11, wherein each tile in the tile chain includes a user identifier, and a historical behavior parameter and a behavior occurrence time corresponding to the user identifier, where the user identifier is any one of a set of identifiers, and the set of identifiers includes the first user identifier and the second user identifier;

the second acquisition module includes:

13. A service data processing device applied to a first service server is characterized by comprising:

the sending module is used for sending a behavior query request to a supervision server so that the supervision server determines a behavior query result corresponding to a target user based on the behavior query request;

14. A computer arrangement comprising a memory and a processor, the memory storing a computer program which, when executed by the processor, causes the processor to carry out the steps of the method according to any one of claims 1 to 10.

15. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program comprising program instructions which, when executed by a processor, perform the steps of the method according to any one of claims 1 to 10.