CN112905563A

CN112905563A - Processing method and device of sign-in data, storage medium and computer equipment

Info

Publication number: CN112905563A
Application number: CN202110162491.XA
Authority: CN
Inventors: 方雷江
Original assignee: Netease Hangzhou Network Co Ltd
Current assignee: Netease Hangzhou Network Co Ltd
Priority date: 2021-02-05
Filing date: 2021-02-05
Publication date: 2021-06-04

Abstract

The embodiment of the application discloses a processing method and device of sign-in data, a storage medium and computer equipment. The method comprises the following steps: acquiring first sign-in data, and storing the first sign-in data into a key-value storage database; determining the accumulated check-in times of the check-in user corresponding to the first check-in data; setting the survival time of all check-in data of the check-in user corresponding to the first check-in data through a TTL command of a key-value storage database according to a preset check-in rule and the accumulated check-in times; if the sign-in user corresponding to the first sign-in data does not generate specified operation within a specified time period in the survival time, all sign-in data of the sign-in user corresponding to the first sign-in data are deleted, and an additional timing task is not needed to be added to clear up the data, so that invalid sign-in data are cleared up in time, and storage space is released.

Description

Processing method and device of sign-in data, storage medium and computer equipment

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for processing check-in data, a storage medium, and a computer device.

Background

The sign-in task is a common means for improving daily lives of internet software, and at present, two common sign-in statistical modes are a mode of directly recording a user sign-in log through a database and a mode of recording the user sign-in log through a bitmap mode of a redis cache database.

However, both of the two statistical methods generate a large amount of log entries, which results in a large storage space occupation, and a timing task needs to be additionally added to clear up data, which results in a problem that the storage space cannot be timely released, and a system is easily jammed and crashed.

Disclosure of Invention

The embodiment of the application provides a processing method and device of check-in data, a storage medium and computer equipment, invalid data can be cleared in time without additionally adding a timing task to clear data, and therefore storage space is released.

The embodiment of the application provides a processing method of check-in data, which comprises the following steps:

acquiring first check-in data, and storing the first check-in data into a key-value storage database;

determining the accumulated check-in times of check-in users corresponding to the first check-in data;

setting the survival time of all check-in data of the check-in user corresponding to the first check-in data through a survival time TTL command of a key-value storage database according to a preset check-in rule and the accumulated check-in times;

and if the check-in user corresponding to the first check-in data does not generate specified operation data in a specified time period in the survival time, deleting all check-in data of the check-in user corresponding to the first check-in data.

Optionally, the setting, according to a preset check-in rule and the accumulated check-in times, the lifetime of all check-in data of the check-in user corresponding to the first check-in data through a time-to-live TTL command of a key-value storage database includes:

and if the accumulated check-in times are smaller than the preset times, setting a first preset time corresponding to a preset check-in rule as the survival time of all check-in data of the check-in user corresponding to the first check-in data through a time-to-live (TTL) command of a key-value storage database.

Optionally, the specifying operation data includes second check-in data, the specified time period includes a first time period, and if the check-in user corresponding to the first check-in data does not generate the specified operation data within the specified time period within the lifetime, deleting all check-in data of the check-in user corresponding to the first check-in data, including:

and if the check-in user corresponding to the first check-in data does not generate the second check-in data in the first time period in the survival time, deleting all check-in data of the check-in user corresponding to the first check-in data.

Optionally, the processing method of the check-in data further includes: and if the check-in user corresponding to the first check-in data generates second check-in data within a first time period in the survival time, storing the second check-in data in a key-to storage database, and returning to execute the step of determining the accumulated check-in times of the check-in user corresponding to the first check-in data.

and if the accumulated check-in times are larger than the preset times, setting second preset time corresponding to a preset check-in rule as the survival time of all check-in data of the check-in user corresponding to the first check-in data through a time-to-live (TTL) command of a key-value storage database.

Optionally, the designated operation data includes reward obtaining data, the designated time period includes a second time period, and if the designated operation data is not generated in the designated time period within the lifetime by the check-in user corresponding to the first check-in data, all check-in data of the check-in user corresponding to the first check-in data is deleted, including:

and if the check-in user corresponding to the first check-in data does not generate the reward drawing data in a second time period in the survival time, deleting all check-in data of the check-in user corresponding to the first check-in data.

Optionally, the processing method of the check-in data further includes: and if the check-in user corresponding to the first check-in data generates the reward drawing data in a second time period in the survival time, deleting all check-in data of the check-in user corresponding to the first check-in data.

Optionally, the key-value storage database includes a redis cache database, and the saving the first check-in data in the key-value storage database includes:

and storing the first check-in data into a hash table corresponding to a check-in user corresponding to the first check-in data in the redis cache database.

Optionally, the storing the first check-in data in a hash table corresponding to a check-in user corresponding to the first check-in data in the redis cache database includes:

determining whether the first check-in data is initial check-in data or not according to the user identification;

if the first check-in data is the initial check-in data, a hash table is newly built according to the user identification, and the first check-in data is stored in the newly built hash table;

and if the first check-in data is not the initial check-in data, storing the first check-in data into a corresponding existing hash table according to the user identification.

Optionally, the one-to-one correspondence between the names of all hash tables of the redis cache database and the user identifier, and determining whether the first check-in data is the initial check-in data according to the user identifier includes:

judging whether all hash tables of the redis cache database have hash tables corresponding to the user identification;

if all hash tables of the redis cache database have hash tables corresponding to user identifications, determining that the first check-in data is not initial check-in data;

and if the hash table corresponding to the user identifier does not exist in all hash tables of the redis cache database, determining that the first check-in data is the initial check-in data.

Optionally, the determining the cumulative check-in times of the check-in user corresponding to the first check-in data includes:

and acquiring the number of fields in a hash table corresponding to the user identification in the redis cache database through an HLEN command according to the user identification in the first check-in data, and determining the number as the accumulated check-in times of check-in users corresponding to the first check-in data.

Optionally, the setting, according to the accumulated check-in times, the lifetime of all check-in data of the check-in user corresponding to the first check-in data through a TTL command of a key-value storage database includes:

and setting the survival time of the hash table where the first check-in data is located according to the accumulated check-in times through a TTL (transistor-transistor logic) command of a redis cache database.

Optionally, if the check-in user corresponding to the first check-in data does not generate the specified operation data within the specified time period within the lifetime, deleting all check-in data of the check-in user corresponding to the first check-in data, including:

and if the sign-in user corresponding to the first sign-in data does not generate specified operation data within a specified time period in the survival time, deleting the hash table where the first sign-in data is located.

Optionally, the acquiring the check-in data includes:

and acquiring the check-in data from the message subscription system.

An embodiment of the present application further provides a device for processing check-in data, including:

the system comprises an acquisition module, a key-value storage database and a storage module, wherein the acquisition module is used for acquiring first check-in data and storing the first check-in data into the key-value storage database;

the determining module is used for determining the accumulated check-in times of check-in users corresponding to the first check-in data;

the setting module is used for setting the survival time of all check-in data of the check-in user corresponding to the first check-in data according to a preset check-in rule and the accumulated check-in times through a TTL (transistor-transistor logic) command of a key-value storage database;

and the deleting module is used for deleting all check-in data of the check-in user corresponding to the first check-in data if the check-in user corresponding to the first check-in data does not generate specified operation data in a specified time period in the survival time.

An embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored, where the computer program is suitable for being loaded by a processor to perform the steps in the check-in data processing method according to any of the above embodiments.

The embodiment of the present application further provides a computer device, where the computer device includes a memory and a processor, where the memory stores a computer program, and the processor executes the steps in the check-in data processing method according to any one of the above embodiments by calling the computer program stored in the memory.

According to the processing method and device for the check-in data, the storage medium and the computer equipment, the survival time of the hash table is set through the TTL of the redis cache database, invalid check-in data can be automatically cleared, an additional timing task is not needed to be added to clear the data, and therefore the invalid check-in data can be cleared in time, and the storage space is released.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

Fig. 1 is a system diagram of a device for processing check-in data according to an embodiment of the present disclosure.

Fig. 2 is a flowchart illustrating a processing method of check-in data according to an embodiment of the present disclosure.

Fig. 3 is a schematic structural diagram of a hash table according to an embodiment of the present application.

Fig. 4 is a schematic view of a first application scenario of a check-in data processing method according to an embodiment of the present application.

Fig. 5 is a schematic view of a second application scenario of the check-in data processing method according to the embodiment of the present application.

Fig. 6 is another schematic flow chart of a check-in data processing method according to an embodiment of the present application.

Fig. 7 is a schematic structural diagram of a device for processing check-in data according to an embodiment of the present disclosure.

Fig. 8 is a schematic structural diagram of a computer device according to 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.

The embodiment of the application provides a processing method and device of check-in data, a storage medium and computer equipment. Specifically, the check-in data processing method according to the embodiment of the present application may be executed by a computer device, where the computer device may be a server. The server can be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, and can also be a cloud server for providing basic cloud computing services such as cloud service, a cloud database, cloud computing, cloud functions, cloud storage, network service, cloud communication, middleware service, domain name service, security service, CDN, big data and artificial intelligence platform and the like.

Referring to fig. 1, please refer to fig. 1, where fig. 1 is a system diagram of a processing apparatus for check-in data according to an embodiment of the present disclosure. The system can comprise at least one terminal, at least one message subscription system and a server, wherein the terminal can be terminal equipment such as a smart phone, a tablet Computer, a notebook Computer, a touch screen, a game machine, a Personal Computer (PC), a Personal Digital Assistant (PDA) and the like, the terminal comprises a client, and the client can be a game application client, a browser client carrying a game program or an instant messaging client and the like. The terminal may be connected to the server through a network. In addition, the terminal has one or more multi-touch sensitive screens for sensing and obtaining input of a user through a touch or slide operation performed at a plurality of points of one or more touch display screens. In addition, when the system includes a plurality of terminals and a plurality of servers, different terminals may be connected to each other through different networks and through different servers 2000. The network may be a wireless network or a wired network, such as a Wireless Local Area Network (WLAN), a Local Area Network (LAN), a cellular network, a 2G network, a 3G network, a 4G network, a 5G network, etc. In addition, different terminals may be connected to other terminals or to a server using their own bluetooth network or hotspot network. For example, multiple users may be online through different terminals to connect and synchronize with each other over a suitable network to support multiplayer gaming.

For example, as shown in fig. 1, when a user signs through a client in a terminal, the client sends sign-in data to a message subscription system, and then, a server may obtain the sign-in data from the message subscription system, store the sign-in data in a key-value storage database, determine the cumulative sign-in times of the sign-in data corresponding to the sign-in user, set a lifetime of the sign-in data according to a preset sign-in rule and the cumulative sign-in times, and delete the sign-in data if no specified operation data is generated within a specified time period within the lifetime.

The embodiment of the application provides a processing method of check-in data, which can be executed by a server. Referring to fig. 2, fig. 2 is a schematic flow chart of a check-in data processing method according to an embodiment of the present application, where the method mainly includes steps 101 to 104, which are described as follows:

step 101: and acquiring first check-in data, and storing the first check-in data into a key-value storage database.

For ease of understanding, the application scenario of the processing method of the check-in data is explained here accordingly. In particular, applications of User check-in tasks to internet software are very widespread, for example, many terminal games utilize the check-in tasks to improve User stickiness, such as by setting attractive rewards (experience values, gold coins, clothing, and the like) to guide users to log in games Daily for check-in, thereby increasing the number of DAUs (Daily Active users or Daily lives) of the games. However, in the existing check-in data statistics manner, no matter the check-in data of the user is directly recorded through the database or the check-in data of the user is recorded through the bitmap mode of the redis cache database, when inquiring the progress of the check-in task of the user, the problem of complex calculation is faced, and for software with more users, a large amount of check-in data is generated, and a large storage space is occupied, so that the existing check-in data statistics manner has certain disadvantages.

Specifically, the step of "acquiring first check-in data" may specifically include: and acquiring first check-in data from the message subscription system.

In the embodiment of the present application, a method for processing check-in data provided by the present application is described with a client and a server of game software. For example, referring to fig. 4, fig. 4 is a schematic view of a first application scenario provided by an embodiment of the present application, as shown in fig. 4, the terminal 1000 includes a user interface 100, where the user interface 100 of the terminal 1000 displays a check-in interface 10 of a game client, the check-in interface 10 includes task bars 11, 12, and 13, as shown in the figure, the task bar 11 is provided with a check-in button 111, and the check-in button 111 is provided with a buried point, when a user clicks the check-in button 111, the game client may capture a check-in behavior of the user and upload check-in data of the user to a message subscription system for a server to obtain. Specifically, the check-in data may include an id (user name) of the user, a specific time of check-in, and the like.

In particular, the message subscription system may be Kafka. It is easy to understand that the number of users at the game client is large, and many users may check in at the same time, so that for the check-in behavior with high concurrency and large data volume, the check-in data is sent to the message subscription system, asynchronous processing of the check-in data is realized, the server can quickly receive the request, and the possibility of server thread blocking is reduced.

Specifically, the key-value storage database includes a redis cache database, and the step "saving the first check-in data in the key-value storage database" may specifically include: and storing the first check-in data into a hash table corresponding to the check-in user corresponding to the first check-in data in a redis cache database.

In this embodiment, the check-in data may be stored by a hash table of the redis cache database. Specifically, the first check-in data may include a user id, a check-in date, and a specific time of check-in. The hash table is a data structure in a key-value pair (key-value pair) form, in a redis cache database, a corresponding hash table may be established for each check-in user, that is, a user id of the check-in user is named for each hash table, and the check-in data of the check-in user is stored in the hash table named for the user id, where the specific format may be: xxx, wherein xxx is the user id.

Specifically, in the hash table, the key is used for storing the check-in date, and the check-in date can be in a yyyy-mm-dd format, so that when the historical check-in data of the check-in user needs to be inquired, the check-in date of the user can be inquired clearly; the value is used for storing a time stamp of the user check-in, and when the specific time when the user check-in is required to be accurately queried, the value field can be used for querying. Specifically, keys correspond to values one to one.

Specifically, referring to fig. 3, fig. 3 is a schematic structural diagram of a hash table provided in the present embodiment, for example, in a hash table user _ continuous _ sign: a corresponding to a check-in user a, a check-in date and a check-in time stamp of each check-in of the check-in user a are stored.

In this embodiment, the first check-in data includes a user identifier, and the step "storing the first check-in data in a hash table corresponding to a check-in user corresponding to the first check-in data in a redis cache database" mainly includes: determining whether the first check-in data is initial check-in data or not according to the user identification; if the first check-in data is the initial check-in data, a hash table is newly built according to the user identification, and the first check-in data is stored in the newly built hash table; and if the first check-in data is not the initial check-in data, storing the first check-in data into a corresponding existing hash table according to the user identification.

It is easy to understand that when a user signs in for the first time, a hash table needs to be created for the user to store the sign-in data of the user.

Specifically, the step "determining whether the first check-in data is the initial check-in data according to the user identifier" may specifically include: judging whether all hash tables of the redis cache database have hash tables corresponding to the user identification; if all hash tables of the redis cache database have hash tables corresponding to the user identification, determining that the first check-in data is not initial check-in data; and if the hash table corresponding to the user identifier does not exist in all hash tables of the redis cache database, determining that the first check-in data is the initial check-in data.

It is easy to understand that the names of all hash tables of the redis cache database correspond to the user identifiers one to one, so that if the hash table corresponding to the user identifier does not exist in the redis cache database, the user can be considered as an initial check-in, and the first check-in data is the initial check-in database, a new hash table named by the user identifier is created, and the first check-in data is stored in the newly created hash table. If the hash table corresponding to the user identifier exists in the redis cache database, it may be considered that the user is not a first sign-in, and the first sign-in data may be directly stored in the hash table corresponding to the user identifier.

In some embodiments, the step "determining whether the first check-in data is the initial check-in data according to the user identifier" may specifically include: acquiring the number of fields in a hash table corresponding to the user identification in a redis cache database through an HLEN command; if the number is zero, determining that the first check-in data is first check-in data; if the number is not zero, determining that the first check-in data is not the initial check-in data.

Specifically, the HLEN command may be used to obtain the number of fields in the hash table, for example, as shown in fig. 3, the number of fields in the hash table user _ continuous _ sign may be obtained by the HLEN command, where the number of fields in a is 5, that is, it is determined that the check-in data is not the first check-in data.

Step 102: and determining the accumulated check-in times of the check-in user corresponding to the first check-in data.

Specifically, step 102 may specifically include: and acquiring the number of fields in a hash table corresponding to the user identifier in a redis cache database through an HLEN command according to the user identifier in the first check-in data, and determining the number as the accumulated check-in times of the check-in user corresponding to the first check-in data.

Specifically, the HLEN command may be used to obtain the number of fields in the hash table, for example, as shown in fig. 3, the number of fields in the hash table user _ continuous _ sign may be obtained by the HLEN command, where a is 5, that is, it is determined that the cumulative check-in number of the user a is 5 times.

Step 103: and setting the survival time of all the check-in data of the check-in user corresponding to the first check-in data through a survival time TTL command of a key-value storage database according to a preset check-in rule and the accumulated check-in times.

In some embodiments, step 103 may comprise: and if the accumulated check-in times are smaller than the preset times, setting the first preset time corresponding to the preset check-in rule as the survival time of all check-in data of the check-in user corresponding to the first check-in data through a survival time TTL command of the key-value storage database.

The preset check-in rule mainly can have two task forms, the first is a continuous check-in task, namely a task which can obtain rewards continuously for check-in target days, for example, a task which can obtain rewards continuously for ten days; the second is a discontinuous, cumulative check-in task, i.e., a task that receives a reward by cumulating a target number of check-in days over a certain period of time, e.g., a task that receives a reward by cumulating ten check-in days over thirty days. It should be noted that the execution time of the check-in task is generally specified by the natural day, and taking the continuous check-in task as an example, if the user checks in at any time of a certain day, he or she must check in again before 0 o 'clock to 24 o' clock of the next check-in day.

Specifically, the preset times and the first preset time are both determined by the preset check-in rule. For example, if the check-in task is set such that the reward is available for checking in for ten consecutive days, the preset number of times is ten, and the first preset time may be 23 hours, 59 minutes and 59 seconds of the check-in next day at the moment.

In some embodiments, step 103 may generally comprise: and if the accumulated check-in times are larger than the preset times, setting second preset time corresponding to the preset check-in rule as the survival time of all check-in data of the check-in user corresponding to the first check-in data through a survival time TTL command of the key-value storage database.

As above, the predetermined number of times and the second predetermined time are both determined by the predetermined check-in rule. The second predetermined time may be determined by a time limit for drawing the reward in the predetermined check-in rule, for example, if it is set that the reward must be drawn within ten days after the completion of the check-in task, the second predetermined time should be the end time from the moment the task is completed to the tenth natural day.

In some embodiments, step 103 may specifically include: and setting the survival time of the hash table where the first check-in data is located according to a preset check-in rule and the accumulated check-in times through a TTL (transistor-transistor logic) command of a redis cache database.

Specifically, the check-in data of each check-in user corresponds to a lifetime, for example, taking a redis cache database and a form that the check-in data of each check-in user is a hash table as an example, a lifetime is set for the check-in data corresponding to each check-in user, that is, the lifetime of the check-in data corresponding to each check-in user is also recorded in the redis cache database and is also in the form of the hash table, wherein a key field may be a name of the hash table where the check-in data of each check-in user is located, a value field may be a lifetime of the check-in data corresponding to each check-in user, and the key and the value have a one-to-one correspondence relationship.

Step 104: and if the first check-in data corresponds to the check-in user and does not generate the specified operation data in the specified time period in the survival time, deleting all check-in data of the check-in user corresponding to the first check-in data.

Wherein the designated operation data may include second check-in data, the designated time period may include a first time period, and step 104 may mainly include: and if the check-in user corresponding to the first check-in data does not generate the second check-in data in the first time period in the survival time, deleting all check-in data of the check-in user corresponding to the first check-in data.

For example, if the task is continuously checked in, the first time period should be from 0 to 24 the next day, and if the task is accumulated, the first time period should be determined by the time limit of the accumulated check-in task.

It is easily understood that according to a preset check-in rule, for example, a check-in task of ten consecutive check-in days, the first check-in data corresponds to that the check-in user should check in next time before 0 o 'clock to 24 o' clock of the next day of the current check-in time, if the check-in user does not check in before 0 o 'clock to 24 o' clock of the next day of the current check-in time, the task is considered to be failed, and therefore, all check-in data should be deleted to release the storage space.

In this embodiment, the processing method may further include: and if the first check-in data corresponds to second check-in data generated by the check-in user in the first time period in the survival time, storing the second check-in data into the key-to-storage database, and returning to execute the step S102.

It is readily understood that according to a preset check-in rule, for example, a check-in task for ten consecutive check-in days, if the first check-in data corresponds to the check-in user checking in before 0 o 'clock to 24 o' clock of the next day of the current check-in time, the task may continue until the check-in user task fails or the task is completed.

In particular, in order to guide the user to a task of signing in, a reward is typically provided. Therefore, it can be understood that the above-mentioned specifying operation may further include reward extraction data, the specified time period includes the second time period, and the step S104 may mainly include: and if the first check-in data corresponds to the check-in user and the reward drawing data is not generated in the second time period in the survival time, deleting all check-in data of the check-in user corresponding to the first check-in data.

It is easy to understand that the user can receive the reward after completing the check-in, but the reward also has a validity period, if the user does not receive the reward in the validity period, the reward is invalid, and at this time, all check-in data of the user can be deleted to release the storage space. Specifically, the specified time period depends on a preset check-in rule. For example, if the preset check-in rule is: the reward may be received before the end of the second day to the tenth birthday of the completion of the check-in, and the second time period may be 0 o 'clock to 24 o' clock before the second day to the tenth birthday.

In some embodiments, the processing method may further include: and if the first check-in data corresponds to the check-in user and the reward drawing data is generated in the second time period in the survival time, deleting all check-in data of the check-in user corresponding to the first check-in data.

It is easy to understand that when the user receives the reward, the user can be considered to complete the check-in task, and all check-in data of the user should be clear, so as to release the storage space.

Specifically, referring to fig. 5, fig. 5 is a schematic view of a second application scenario of the check-in data processing method according to the embodiment of the present application, as shown in the figure, when the task progress in the taskbar 11 is 30/30, that is, the task is completed, a get button 112 is displayed in the taskbar, and when the user clicks the get button 112 to get the reward, the reward get data is generated, so that all the check-in data of the user can be deleted.

In some embodiments, step 104 may specifically include: and if the first check-in data corresponds to the check-in user and does not generate the specified operation data in the specified time period in the survival time, deleting the hash table where the first check-in data is located.

Specifically, if the user does not check in or receive the reward within a specified time period within the lifetime, the task is considered to be incomplete, and the historical data checked in by the user should be deleted to release the storage space. For example, assuming that the sign-in task is ten days of continuous sign-in and can obtain rewards, and the user signs in at any time of today, the survival time should be set to be 24 o ' clock before the sign-in time to the next day, the specified time period should be set to be 0 o ' clock before 24 o ' clock of the next day, if the user does not sign in before 0 o ' clock to 24 o ' clock of the next day, the task is considered to be not completed, all sign-in data of the user is deleted, namely the hash table where the sign-in data is located is deleted, and if the user signs in again after deleting the sign-in data, the step of initial sign-in is repeated, namely the hash table is newly created to store the sign-in data.

All the above technical solutions can be combined arbitrarily to form the optional embodiments of the present application, and are not described herein again.

According to the processing method of the check-in data, the first check-in data are obtained and stored in the key-value storage database; determining the accumulated check-in times of the check-in user corresponding to the first check-in data; and setting the survival time of all check-in data of the first check-in data corresponding to the check-in user through a TTL command of a key-value storage database according to a preset check-in rule and the accumulated check-in times, and deleting all check-in data of the first check-in data corresponding to the check-in user if the first check-in data corresponding to the check-in user does not generate specified operation within a specified time period within the survival time, without adding an additional timing task to clear the data, thereby timely clearing invalid check-in data and releasing storage space.

Referring to fig. 6, fig. 6 is another schematic flow chart of a check-in data processing method according to an embodiment of the present application, where the method mainly includes steps 201 to 206, which are described as follows:

step 201: and acquiring first check-in data, and storing the first check-in data into a hash table corresponding to a check-in user corresponding to the first check-in data in the redis cache data.

The specific implementation of step 201 can refer to the embodiment of step 101, and is not described herein again.

Step 202: and according to the user identification in the first check-in data, acquiring the field number in the hash table corresponding to the user identification in the redis cache database through an HLEN command, and determining the number as the accumulated check-in times of the check-in user corresponding to the first check-in data.

The specific embodiment of step 202 can refer to the embodiment of step 102, and is not described herein again.

Step 203: and if the accumulated check-in times are smaller than the preset times, setting a first preset time corresponding to the preset check-in rule as the survival time of the hash table where the first check-in data are located through a TTL (transistor-transistor logic) command of the redis cache database.

Specifically, for example, if the sign-in task is set to be 10 accumulated sign-in times within 30 days, the reward can be received, the preset number of times is 10, and the first preset time is from the sign-in time to the end time of the 30 th natural day.

Step 204: and if the accumulated check-in times are not less than the preset times, setting second preset time corresponding to the preset check-in rule as the survival time of the hash table where the first check-in data are located through a TTL (transistor-transistor logic) command of the redis cache database.

Specifically, if the second preset time is determined by the time limit for picking up the reward in the preset check-in rule, for example, if it is set that the reward must be picked up within ten days after the completion of the check-in task, the second preset time should be 24 o' clock before the task completion time to the tenth sunday.

Step 205: and if the first check-in data corresponds to the check-in user and does not generate second check-in data in the first time period in the survival time, deleting the hash table where the first check-in data is located.

Specifically, the first time period depends on the preset check-in rule, for example, if the check-in task is continuous, the first time period should be from 0 to 24 o' clock of the next day, and if the check-in task is accumulated, the first time period should depend on the time limit of the accumulated check-in task. It is easily understood that according to a preset check-in rule, for example, a check-in task of ten consecutive check-in days, the first check-in data corresponds to that the check-in user should check in next time before 0 o 'clock to 24 o' clock of the next day of the current check-in time, if the check-in user does not check in before 0 o 'clock to 24 o' clock of the next day of the current check-in time, the task is considered to be failed, and therefore, all check-in data, namely the hash table where the first check-in data is located, should be checked in to release the storage space.

Step 206: and if the first check-in data corresponds to the fact that the check-in user does not generate the reward receiving data in the second time period in the survival time, deleting the hash table where the first check-in data is located.

It is easy to understand that the user can receive the reward after completing the check-in, but the reward also has a validity period, if the user does not receive the reward in the validity period, the reward is invalid, and at this time, all check-in data of the user can be deleted to release the storage space. In particular, the second time period depends on a preset check-in rule. For example, if the preset check-in rule is: the reward may be received before the end of the second day to the tenth birthday of the completion of the check-in, and the second time period may be 0 o 'clock to 24 o' clock before the second day to the tenth birthday.

The processing method of the check-in data provided by the embodiment of the application is applied to a server, and comprises the steps of firstly, obtaining first check-in data, storing the first check-in data into a hash table corresponding to a check-in user corresponding to the check-in data in redis cache data, then, obtaining the field number in the hash table corresponding to the user identifier in a redis cache database through an HLEN command according to the user identifier in the first check-in data, determining the field number as the accumulated check-in times of the check-in user corresponding to the first check-in data, avoiding the need of large amount of calculation when inquiring the accumulated check-in times, if the accumulated check-in times are smaller than the preset times, setting the first preset time corresponding to the preset check-in rule as the survival time of the first check-in data through a TTL command of a redis cache database, and if the first check-in data corresponding to the check-in user does not generate second check-in data in the first time period in time, and deleting the hash table where the first check-in data is located, if the accumulated check-in times are not less than the preset times, setting second preset time corresponding to the preset check-in rule as the survival time of the hash table where the check-in data is located through a TTL (transistor-transistor logic) command of a redis cache database, and if the first check-in data corresponding to the check-in user does not generate reward pickup data in the second time period in the survival time, deleting the hash table where the first check-in data is located, so that invalid data can be conveniently clear, and the condition that a large amount of check-in data stored in the database occupy a storage space is avoided.

In order to better implement the processing method of check-in data in the embodiments of the present application, an embodiment of the present application further provides a processing apparatus of check-in data. Referring to fig. 7, fig. 7 is a schematic structural diagram of a check-in data processing device according to an embodiment of the present disclosure. The processing device 20 of the check-in data may include an obtaining module 21, a determining module 22, a setting module 23 and a deleting module 24.

The obtaining module 21 is configured to obtain first check-in data, and store the first check-in data in the key-value storage database.

The determining module 22 is configured to determine the cumulative check-in times of the check-in user corresponding to the first check-in data;

and the setting module 23 is configured to set a lifetime of all check-in data of the check-in user corresponding to the first check-in data according to a preset check-in rule and the accumulated check-in times through a TTL command of the key-value storage database.

And the deleting module 24 is configured to delete all check-in data of the check-in user corresponding to the first check-in data if the check-in user corresponding to the first check-in data does not generate the specified operation data within the specified time period in the lifetime.

In some embodiments, the obtaining module 21 may specifically be configured to: and acquiring first check-in data from the message subscription system.

Specifically, the key-value storage database includes a redis cache database, and the obtaining module 21 may be specifically configured to: and storing the first check-in data into a hash table corresponding to the check-in user corresponding to the first check-in data in a redis cache database.

Further, the first check-in data includes a user identifier, and the obtaining module 21 may specifically be configured to: determining whether the first check-in data is initial check-in data or not according to the user identification; if the first check-in data is the initial check-in data, a hash table is newly built according to the user identification, and the first check-in data is stored in the newly built hash table; and if the first check-in data is not the initial check-in data, storing the first check-in data into a corresponding existing hash table according to the user identification.

Further, names of all hash tables of the redis cache database correspond to the user identifiers one to one, and the obtaining module 21 may specifically be configured to: judging whether all hash tables of the redis cache database have hash tables corresponding to the user identification; if all hash tables of the redis cache database have hash tables corresponding to the user identification, determining that the first check-in data is not initial check-in data; and if the hash table corresponding to the user identifier does not exist in all hash tables of the redis cache database, determining that the first check-in data is the initial check-in data.

Specifically, the determining module 22 may be specifically configured to: and acquiring the number of fields in a hash table corresponding to the user identifier in a redis cache database through an HLEN command according to the user identifier in the first check-in data, and determining the number as the accumulated check-in times of the check-in user corresponding to the first check-in data.

Specifically, the setting module 23 may be specifically configured to: and setting the survival time of the hash table where the first check-in data is located according to a preset check-in rule and the accumulated check-in times through a TTL (transistor-transistor logic) command of a redis cache database.

In some embodiments, the setting module 23 may be specifically configured to: and if the accumulated check-in times are smaller than the preset times, setting the first preset time corresponding to the preset check-in rule as the survival time of all check-in data of the check-in user corresponding to the first check-in data through a survival time TTL command of the key-value storage database.

In this embodiment, the designated operation data includes second check-in data, the designated time period includes a first time period, and the deleting module 24 is mainly configured to: and if the check-in user corresponding to the first check-in data does not generate the second check-in data in the first time period in the survival time, deleting all check-in data of the check-in user corresponding to the first check-in data.

In addition, the processing apparatus 20 for check-in data further includes a saving module, configured to save the second check-in data in the key-to-storage database and return to execute the function of the determining module 22 if the first check-in data corresponds to second check-in data generated by the check-in user within the first time period in the lifetime.

In some embodiments, the setup module 23 may be primarily for: and if the accumulated check-in times are larger than the preset times, setting second preset time corresponding to the preset check-in rule as the survival time of all check-in data of the check-in user corresponding to the first check-in data through a survival time TTL command of the key-value storage database.

In this embodiment, the designated operation data includes reward obtaining data, the designated time period includes a second time period, and the deleting module 24 is mainly configured to: and if the first check-in data corresponds to the check-in user and the reward drawing data is not generated in the second time period in the survival time, deleting all check-in data of the check-in user corresponding to the first check-in data.

Further, the deletion module 24 may be further configured to: and if the first check-in data corresponds to the check-in user and the reward drawing data is generated in the second time period in the survival time, deleting all check-in data of the check-in user corresponding to the first check-in data.

Further, the deletion module may specifically be configured to: and if the first check-in data corresponds to the check-in user and does not generate the specified operation data in the specified time period in the survival time, deleting the hash table where the first check-in data is located.

The processing device 20 for check-in data provided by the embodiment of the application acquires the first check-in data through the acquisition module 21, stores the first check-in data in the key-value storage database, then, the determining module 22 determines the accumulated check-in times of the check-in users corresponding to the first check-in data, and then the setting module 23 sets the lifetime of all the check-in data of the check-in users corresponding to the first check-in data according to the preset check-in rule and the accumulated check-in times through the TTL command of the key-value storage database, if the designated operation data is not generated in the designated time period within the lifetime by the check-in users corresponding to the first check-in data, the deleting module 24 deletes all the check-in data of the check-in user corresponding to the first check-in data without adding an additional timing task to clear the data, thereby clearing the invalid check-in data in time and releasing the storage space.

Correspondingly, the embodiment of the present application further provides a Computer device, where the Computer device may be a terminal or a server, and the terminal may be a terminal device such as a smart phone, a tablet Computer, a notebook Computer, a touch screen, a game machine, a Personal Computer (PC), a Personal Digital Assistant (PDA), and the like. As shown in fig. 8, fig. 8 is a schematic structural diagram of a computer device according to an embodiment of the present application. The computer apparatus 400 includes a processor 401 having one or more processing cores, a memory 402 having one or more computer-readable storage media, and a computer program stored on the memory 402 and executable on the processor. The processor 401 is electrically connected to the memory 402. Those skilled in the art will appreciate that the computer device configurations illustrated in the figures are not meant to be limiting of computer devices and may include more or fewer components than those illustrated, or some components may be combined, or a different arrangement of components.

The processor 401 is a control center of the computer device 400, connects the respective parts of the entire computer device 400 using various interfaces and lines, performs various functions of the computer device 400 and processes data by running or loading software programs and/or modules stored in the memory 402 and calling data stored in the memory 402, thereby monitoring the computer device 400 as a whole.

In the embodiment of the present application, the processor 401 in the computer device 400 loads instructions corresponding to processes of one or more application programs into the memory 402 according to the following steps, and the processor 401 runs the application programs stored in the memory 402, thereby implementing various functions:

acquiring first sign-in data, and storing the first sign-in data into a key-value storage database; determining the accumulated check-in times of the check-in user corresponding to the first check-in data; setting the survival time of all check-in data of the check-in user corresponding to the first check-in data through a TTL command of a key-value storage database according to a preset check-in rule and the accumulated check-in times; and if the check-in user corresponding to the first check-in data does not generate specified operation in a specified time period in the survival time, deleting all check-in data of the check-in user corresponding to the first check-in data.

The above operations can be implemented in the foregoing embodiments, and are not described in detail herein.

Optionally, as shown in fig. 8, the computer device 400 further includes: touch-sensitive display screen 403, radio frequency circuit 404, audio circuit 405, input unit 406 and power 407. The processor 401 is electrically connected to the touch display screen 403, the radio frequency circuit 404, the audio circuit 405, the input unit 406, and the power source 407. Those skilled in the art will appreciate that the computer device configuration illustrated in FIG. 8 does not constitute a limitation of computer devices, and may include more or fewer components than those illustrated, or some components may be combined, or a different arrangement of components.

The touch display screen 403 may be used for displaying a graphical user interface and receiving operation instructions generated by a user acting on the graphical user interface. The touch display screen 403 may include a display panel and a touch panel. The display panel may be used, among other things, to display information entered by or provided to a user and various graphical user interfaces of the computer device, which may be made up of graphics, text, icons, video, and any combination thereof. Alternatively, the Display panel may be configured in the form of a Liquid Crystal Display (LCD), an Organic Light-Emitting Diode (OLED), or the like. The touch panel may be used to collect touch operations of a user on or near the touch panel (for example, operations of the user on or near the touch panel using any suitable object or accessory such as a finger, a stylus pen, and the like), and generate corresponding operation instructions, and the operation instructions execute corresponding programs. Alternatively, the touch panel may include two parts, a touch detection device and a touch controller. The touch detection device detects the touch direction of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch sensing device, converts the touch information into touch point coordinates, sends the touch point coordinates to the processor 401, and can receive and execute commands sent by the processor 401. The touch panel may overlay the display panel, and when the touch panel detects a touch operation thereon or nearby, the touch panel may transmit the touch operation to the processor 401 to determine the type of the touch event, and then the processor 401 may provide a corresponding visual output on the display panel according to the type of the touch event. In the embodiment of the present application, the touch panel and the display panel may be integrated into the touch display screen 403 to realize input and output functions. However, in some embodiments, the touch panel and the touch panel can be implemented as two separate components to perform the input and output functions. That is, the touch display screen 403 may also be used as a part of the input unit 406 to implement an input function.

The rf circuit 404 may be used for transceiving rf signals to establish wireless communication with a network device or other computer device via wireless communication, and for transceiving signals with the network device or other computer device.

The audio circuit 405 may be used to provide an audio interface between a user and a computer device through speakers, microphones. The audio circuit 405 may transmit the electrical signal converted from the received audio data to a speaker, and convert the electrical signal into a sound signal for output; on the other hand, the microphone converts the collected sound signal into an electrical signal, which is received by the audio circuit 405 and converted into audio data, which is then processed by the audio data output processor 401, and then sent to, for example, another computer device via the radio frequency circuit 404, or output to the memory 402 for further processing. The audio circuit 405 may also include an earbud jack to provide communication of a peripheral headset with the computer device.

The input unit 406 may be used to receive input numbers, character information, or user characteristic information (e.g., fingerprint, iris, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

The power supply 407 is used to power the various components of the computer device 400. Optionally, the power source 407 may be logically connected to the processor 401 through a power management system, so as to implement functions of managing charging, discharging, power consumption management, and the like through the power management system. The power supply 407 may also include one or more dc or ac power sources, recharging systems, power failure detection circuitry, power converters or inverters, power status indicators, or any other component.

Although not shown in fig. 8, the computer device 400 may further include a camera, a sensor, a wireless fidelity module, a bluetooth module, etc., which are not described in detail herein.

In the foregoing embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

As can be seen from the above, the computer device provided in this embodiment obtains the first check-in data, and stores the first check-in data in the key-value storage database; determining the accumulated check-in times of the check-in user corresponding to the first check-in data; setting the survival time of all check-in data of the check-in user corresponding to the first check-in data through a TTL command of a key-value storage database according to a preset check-in rule and the accumulated check-in times; if the sign-in user corresponding to the first sign-in data does not generate specified operation within a specified time period in the survival time, all sign-in data of the sign-in user corresponding to the first sign-in data are deleted, and an additional timing task is not needed to be added to clear up the data, so that invalid sign-in data are cleared up in time, and storage space is released.

It will be understood by those skilled in the art that all or part of the steps of the methods of the above embodiments may be performed by instructions or by associated hardware controlled by the instructions, which may be stored in a computer readable storage medium and loaded and executed by a processor.

To this end, embodiments of the present application provide a computer-readable storage medium, in which a plurality of computer programs are stored, and the computer programs can be loaded by a processor to execute the steps in any one of the check-in data processing methods provided by the embodiments of the present application. For example, the computer program may perform the steps of:

Wherein the storage medium may include: read Only Memory (ROM), Random Access Memory (RAM), magnetic or optical disks, and the like.

Since the computer program stored in the storage medium can execute the steps in any check-in data processing method provided in the embodiments of the present application, beneficial effects that can be achieved by any check-in data processing method provided in the embodiments of the present application can be achieved, for details, see the foregoing embodiments, and are not described herein again.

The foregoing detailed description is directed to a method, an apparatus, a storage medium, and a computer device for processing check-in data provided in an embodiment of the present application, and a specific example is applied in the detailed description to explain the principles and embodiments of the present application, and the description of the foregoing embodiment is only used to help understand the method and the core idea of the present application; meanwhile, for those skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.

Claims

1. A processing method of check-in data is characterized by comprising the following steps:

2. The method as claimed in claim 1, wherein the setting of the lifetime of all check-in data of the check-in user corresponding to the first check-in data according to the preset check-in rule and the accumulated check-in times through the lifetime TTL command of the key-value storage database comprises:

3. The check-in data processing method of claim 2, wherein the designated operation data includes second check-in data, the designated time period includes a first time period, and if the designated operation data is not generated by the check-in user corresponding to the first check-in data within the designated time period within the lifetime, the deleting all check-in data of the check-in user corresponding to the first check-in data includes:

4. The check-in data processing method of claim 3, wherein the check-in data processing method further comprises:

and if the check-in user corresponding to the first check-in data generates second check-in data within a first time period in the survival time, storing the second check-in data in a key-to storage database, and returning to execute the step of determining the accumulated check-in times of the check-in user corresponding to the first check-in data.

5. The method as claimed in claim 1, wherein the setting of the lifetime of all check-in data of the check-in user corresponding to the first check-in data according to the preset check-in rule and the accumulated check-in times through the lifetime TTL command of the key-value storage database comprises:

6. The check-in data processing method of claim 5, wherein the designated operation data comprises reward pickup data, the designated time period comprises a second time period, and if the designated operation data is not generated in the designated time period within the lifetime of the check-in user corresponding to the first check-in data, all check-in data of the check-in user corresponding to the first check-in data is deleted, the method comprises the following steps:

7. The check-in data processing method of claim 6, wherein the check-in data processing method further comprises:

and if the check-in user corresponding to the first check-in data generates the reward drawing data in a second time period in the survival time, deleting all check-in data of the check-in user corresponding to the first check-in data.

8. The method of processing check-in data of claim 1, wherein the key-value store database comprises a redis cache database, and wherein saving the first check-in data into the key-value store database comprises:

9. The method as claimed in claim 8, wherein the first check-in data includes a user identifier, and the saving the first check-in data to a hash table corresponding to a corresponding check-in user of the first check-in data in the redis cache database includes:

10. The method as claimed in claim 9, wherein names of all hash tables of the redis cache database are in one-to-one correspondence with user identifiers, and the determining whether the first check-in data is first check-in data according to the user identifiers comprises:

11. The method of processing check-in data of claim 8, wherein said determining the cumulative number of check-ins of the check-in user corresponding to the first check-in data comprises:

12. The method as claimed in claim 8, wherein the setting of the lifetime of all check-in data of the check-in user corresponding to the first check-in data through the TTL command of the key-value storage database according to the preset check-in rule and the accumulated check-in times comprises:

and setting the survival time of the hash table where the first check-in data is located according to a preset check-in rule and the accumulated check-in times through a TTL (transistor-transistor logic) command of a redis cache database.

13. The method as claimed in claim 12, wherein deleting all check-in data corresponding to the check-in user from the first check-in data if the check-in user corresponding to the first check-in data does not generate the specified operation data within the specified time period within the lifetime comprises:

14. The method of processing check-in data of claim 1, wherein said obtaining first check-in data comprises:

and acquiring first check-in data from the message subscription system.

15. An apparatus for processing check-in data, comprising:

16. A computer-readable storage medium, characterized in that it stores a computer program adapted to be loaded by a processor for performing the steps of the method of processing check-in data according to any one of claims 1 to 14.

17. A computer device, characterized in that the computer device comprises a memory in which a computer program is stored and a processor which performs the steps in the method of processing check-in data according to any one of claims 1 to 14 by calling the computer program stored in the memory.