User blacklist synchronization method and device, storage medium, product and electronic equipment

Abstract

The invention provides a user blacklist synchronization method and device, a storage medium, a product and electronic equipment, and the method is applied to the technical field of computers, and comprises the steps: obtaining blacklist data snapshots of all user identifiers in a blacklist library, sequentially generating blacklist files based on the blacklist data snapshots, and storing the blacklist files in the blacklist library; the method comprises the following steps: acquiring blacklist files, storing all the blacklist files in a synchronous database, if a full-amount synchronization request sent by a client is received, sending the blacklist files before a full-amount synchronization time point in the synchronous database to the client, and performing full-amount synchronization on the blacklist files based on a heartbeat signal of the client. And sending the blacklist files after the full-amount synchronization time point in the synchronization database to the client in a preset time unit until all the blacklist files are sent to the client.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a user blacklist synchronization method, apparatus, storage medium, product, and electronic device in the field of computer technology. Background Technology

[0002] For promotional purposes and user convenience, an increasing number of service providers are setting up numerous physical client devices to meet user needs. For example, retailers can place vending machines in high-traffic areas like plazas and shopping malls for easy access. Since these devices are often unsupervised and operated by users themselves, service providers can create blacklists for users with low credit ratings and restrict their access to the client to mitigate potential losses. Currently, each time a user uses the client, it checks the blacklist against the cloud before providing service, resulting in long response times and impacting user efficiency. Furthermore, requesting the entire blacklist from the cloud could lead to the client becoming unresponsive or even corrupted. Therefore, a method to improve client response efficiency is needed. Summary of the Invention

[0003] This application provides a user blacklist synchronization method, apparatus, storage medium, product, and electronic device. The method can save all blacklist files offline in advance and send the blacklist files to the client for full synchronization by time-sharing and component-based methods. This saves blacklist file retrieval time, improves full synchronization efficiency, and avoids client unresponsiveness due to the large number of blacklist files.

[0004] In a first aspect, embodiments of this application provide a method for synchronizing a user blacklist, the method comprising: Retrieve a snapshot of all user identifiers in the blacklist database; Blacklist files are generated sequentially based on the blacklist data snapshots, and all blacklist files are saved in a synchronized database; If a full synchronization request is received from the client, the blacklist file prior to the full synchronization time point in the synchronization database is sent to the client. Based on the client's heartbeat signal, the blacklist files after the full synchronization time point in the synchronization database are sent to the client at preset time units until all the blacklist files are sent to the client.

[0005] Secondly, embodiments of this application provide a user blacklist synchronization device, the device comprising: The snapshot retrieval unit is used to retrieve a snapshot of blacklist data for all user identifiers from the blacklist database. The file storage unit is used to generate blacklist files sequentially based on the blacklist data snapshot, and save all the blacklist files in the synchronous database; The first full synchronization unit is used to send the blacklist files in the synchronization database that are before the full synchronization time point to the client if a full synchronization request is received from the client. The second full synchronization unit is used to send blacklist files after the full synchronization time point in the synchronization database to the client at preset time units based on the client's heartbeat signal, until all blacklist files are sent to the client.

[0006] Thirdly, embodiments of this application provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the above-described method steps.

[0007] Fourthly, embodiments of this application provide a computer program product that stores multiple instructions adapted for loading by a processor and executing the above-described method steps.

[0008] Fifthly, embodiments of this application provide an electronic device that may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the above-described method steps.

[0009] In one or more embodiments of this application, a snapshot of blacklist data for all user identifiers is obtained from a blacklist database. Blacklist files are generated sequentially based on these snapshots, and all blacklist files are stored in a synchronization database. If a full synchronization request is received from a client, blacklist files prior to the full synchronization time point in the synchronization database are sent to the client. Based on the client's heartbeat signal, blacklist files after the full synchronization time point in the synchronization database are sent to the client at preset time units until all blacklist files are sent to the client. By pre-fetching and saving all blacklist files offline, and sending them to the client for full synchronization in time slots and components, blacklist file retrieval time is saved, full synchronization efficiency is improved, and client unresponsiveness due to a large number of blacklist files is avoided. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a system architecture diagram of a user blacklist synchronization provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a user blacklist synchronization method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating a scheduled task provided in an embodiment of this application; Figure 4 This is a schematic diagram of a process for generating a blacklist based on a transaction object identifier, provided in an embodiment of this application; Figure 5 This is a schematic diagram of a synchronization process based on a transaction object identifier provided in an embodiment of this application; Figure 6 This is a schematic diagram of an incremental synchronization process based on a first incremental table provided in an embodiment of this application; Figure 7 This is a schematic diagram of an incremental synchronization process based on a second incremental table provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a user blacklist synchronization device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a user blacklist synchronization device provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] For purposes such as promotion and ease of use, service providers can deploy a large number of client devices in commercial complexes, transportation hubs, and other areas to be close to users. For example, client devices can be vending machines, coffee machines, power bank rental stations, etc., in an unattended state. When users need to use the client, they can send their user identifier to the client by scanning a QR code, Bluetooth, or Near Field Communication (NFC). The user identifier can be the user's account on the service provider's platform, used to identify the user and complete operations such as making purchases through the client. Users can have different user identifiers for different service providers, or for unified management, users can use a unified user identifier, such as the user's mobile phone number or payment account. To mitigate risks and avoid losses, service providers can create blacklists for certain users. These blacklists may include identifiers of users with credit, moral, or fraud risks, thus restricting client usage for blacklisted users. Since determining the blacklist requires comprehensive multi-dimensional user information, it is generated by the service provider's cloud server. In existing technologies, after receiving a user identifier, the client needs to access the cloud server to determine if the identifier is on the blacklist before providing service. Since clients can reside in different regions, network fluctuations and other factors can lead to longer client response times, resulting in longer waiting times for users. This application provides a user blacklist synchronization method that retrieves the blacklist from the cloud server and stores it in a database. The blacklist is then synchronized to the client based on the client's synchronization request, allowing the client to compare and verify user identifiers against its locally stored blacklist, reducing client response time. The user blacklist synchronization method provided in this application can be implemented using a computer program and can run on a von Neumann architecture-based user blacklist synchronization device. This computer program can be integrated into applications or run as a standalone utility application.

[0014] Please see also Figure 1This application provides a system architecture diagram for user blacklist synchronization, which may include four modules: a transaction terminal, a shadow service library, a data storage engine, and a storage platform. The storage platform is the lowest-level module, which can be used to store all operation records, task information, blacklist files, and various offline data. The data storage engine can provide atomic services to the upstream shadow service library based on the data storage capabilities encapsulated by the underlying storage platform. The shadow service library can provide transaction processes to the upstream transaction terminal, that is, it encapsulates the atomic capabilities of the data storage layer and integrates them into several sets of functions to provide services to the transaction terminal. The transaction terminal can be any client and can call the service functions in the shadow service library. The user blacklist synchronization device is applied to the user blacklist synchronization system, for example, it can be applied to the shadow service library, data storage engine, and storage platform.

[0015] Clients in the transaction server can send heartbeat signals to the downstream shadow service library. These heartbeat signals contain lightweight information without transaction data, indicating the client's normal online status. Clients can send heartbeat signals at pre-set time intervals, such as every two minutes, to quickly detect client failures, trigger failover, or reconnection. Following the heartbeat signals, clients can also send full synchronization requests, incremental synchronization requests, or acknowledgment (ACK) requests. Full synchronization requests are used to request all user blacklists from the user blacklist synchronization device, applicable during initial client startup, disk corruption, or data loss. Incremental synchronization requests are used to request recently added user blacklists from the user blacklist synchronization device, and can be sent periodically to ensure the timeliness of the user blacklists stored in the client.

[0016] The storage platform can include various databases, including a synchronization database, such as the OceanBase (OB) database. This database stores heartbeat records, verification records, ACK request records, version information, and list information. Heartbeat records allow the storage platform to record every heartbeat signal, full synchronization request, and incremental synchronization request from clients. Verification records allow the storage platform to report the user identifiers of each client's interactions to the cloud server at a preset daily verification time (midnight). Each client's heartbeat signal provides the latest version information, which the storage platform verifies to determine the time interval for subsequent incremental synchronization. The list information allows the storage platform to store different types of blacklists. The storage platform can also include an Open Data Processing Service (ODPS) database, used to feed offline data back to the synchronization database for subsequent processing.

[0017] The user blacklist synchronization device can obtain user identifiers from the blacklist database on the cloud server through offline computing services, and save them as blacklist files in the synchronization information database through offline ODPS data backflow. When a full synchronization request is received from the client, the blacklist file in the synchronization information database is sent to the client without having to fetch data from the cloud server again, thereby improving the response efficiency of the full synchronization request. This allows the blacklist file to be stored locally on the client, thereby reducing the user's waiting time for response and improving the efficiency of the client.

[0018] The user blacklist synchronization method provided in this application will be described in detail below with reference to specific embodiments.

[0019] Please see Figure 2 This is a flowchart illustrating a user blacklist synchronization method provided in this application embodiment. Figure 2 As shown, the method described in this application embodiment may include the following steps S102-S208.

[0020] S102, retrieve a snapshot of blacklist data for all user identifiers from the blacklist database.

[0021] Specifically, service providers can set up a blacklist database in the cloud server. The blacklist database can store the user identifiers of all users confirmed as blacklisted. The user blacklist synchronization device can identify all user identifiers in the blacklist database. However, since the number of user identifiers in the blacklist database is huge, directly pulling all user identifiers to the synchronization database will cause system lag. Therefore, a snapshot of the blacklist data of all user identifiers can be obtained first to facilitate subsequent data retrieval.

[0022] Optionally, a snapshot of all user identifiers in the blacklist database prior to a preset data retrieval time point can be obtained. The preset data retrieval time point can be midnight on the day all user identifiers are retrieved, or it can be the initial setting of the user blacklist synchronization device, or it can be set by relevant personnel. In order to ensure the timeliness of blacklist users in the synchronization database, the newly added user identifiers in the blacklist database of the previous day can be retrieved at midnight every day after the preset data retrieval time point, and then the newly added user identifiers can be retrieved to the synchronization database and saved as a blacklist file.

[0023] S104: Generate blacklist files sequentially based on blacklist data snapshots, and save all blacklist files in the synchronized database.

[0024] Specifically, after obtaining a snapshot of the blacklist data, the specific user identifiers can be queried from the blacklist database according to the blacklist data snapshots, and then the user identifiers are written into the blacklist file. Understandably, there can be an upper limit to the number of user identifiers contained in the blacklist file, so multiple blacklist files can be generated, and then all the blacklist texts are saved in the synchronized database.

[0025] S106. If a full synchronization request is received from the client, the blacklist file before the full synchronization time point in the synchronization database will be sent to the client.

[0026] Specifically, the client can send a full synchronization request to the user's blacklist synchronization device upon initial startup, disk damage, or data loss. The full synchronization request is used to obtain all blacklist files. However, sending all blacklist files to the client at once can cause client lag or even system damage. Therefore, if a full synchronization request is received from the client, the blacklist files before the full synchronization time in the synchronization database can be sent to the client first. The full synchronization time can be the initial setting of the user's blacklist synchronization device or can be set by relevant personnel. For example, it can be 00:00 on October 1, 2024.

[0027] S108, based on the client's heartbeat signal, sends blacklist files from the synchronization database after the full synchronization time point to the client at preset time units until all blacklist files are sent to the client.

[0028] Specifically, the client can send heartbeat signals to the user blacklist synchronization device at preset time intervals. Therefore, whenever a heartbeat signal is detected from the client, the blacklist files within each preset time unit after the full synchronization time point can be sent to the client until all blacklist files in the synchronization database have been sent to the client. The preset time unit can be the initial setting of the user blacklist synchronization device or can be set by relevant personnel. For example, it can be one day, i.e., 24 hours. Then, when the client sends the first heartbeat signal for the full synchronization request, the blacklist files within the first day after the full synchronization time point are sent to the client. When the second heartbeat signal is sent, the blacklist files within the second day after the full synchronization time point are sent to the client, and so on, until all blacklist files are sent to the client.

[0029] In this embodiment, a snapshot of blacklist data for all user identifiers is obtained from the blacklist database. Blacklist files are generated sequentially based on these snapshots, and all blacklist files are stored in a synchronization database. If a full synchronization request is received from a client, blacklist files prior to the full synchronization time point in the synchronization database are sent to the client. Based on the client's heartbeat signal, blacklist files after the full synchronization time point in the synchronization database are sent to the client at preset time units until all blacklist files are sent to the client. By pre-retrieving and saving all blacklist files offline, and sending them to the client for full synchronization in time slots and components, blacklist file retrieval time is saved, full synchronization efficiency is improved, and client unresponsiveness due to a large number of blacklist files is avoided.

[0030] Because the user identifier data in the blacklist database is huge, the user blacklist synchronization device can first identify all user identifiers using a blacklist data snapshot, and then use a scheduled task to pull user identifiers from the blacklist database, generate a blacklist file, and then save it to the synchronization database. The scheduled task is to set a preset task time point. For example, there can be an interval of 10 minutes between adjacent preset task time points. Every time the preset task time point is reached, the task of pulling user identifiers, generating a blacklist file, and saving it to the synchronization database is executed until all user identifiers are saved to the synchronization database.

[0031] Please see Figure 3 This document provides a flowchart illustrating a scheduled task in an embodiment of this application. Figure 3As shown, in one or more embodiments of this application, step S104 may include the following steps S202-S204.

[0032] S202, when the preset task time point is reached, the user identifier is obtained from the blacklist database based on the blacklist data snapshot and the obtained user identifier is written to the blacklist file.

[0033] Specifically, when the preset task time point is reached, the user identifier that has not yet been saved to the synchronization database can be identified in the blacklist data snapshot. Then, the user identifier is retrieved from the blacklist database and written to the blacklist file. For example, the user identifier can be a string of characters, and the blacklist file can be in the form of a TXT document.

[0034] S204. When the number of user identifiers in the blacklist file reaches the preset upper limit, the blacklist file will be compressed and stored in the database.

[0035] Specifically, there can be an upper limit to the number of user identifiers that can be written into a blacklist file. When the number of user identifiers written into a blacklist file reaches the preset upper limit, the blacklist file can be compressed and stored in the user database. The preset upper limit can be the initial setting of the user blacklist synchronization device or can be set by relevant personnel. For example, it can be 20,000.

[0036] Optionally, the user blacklist synchronization device can also split the user identifiers in the blacklist file into multiple batch processing units. For example, a blacklist file can contain up to 20,000 user identifiers, which can be split into 100 batch processing units, each containing 2,000 user identifiers. When the client subsequently compares the user identifiers entered by the user with the blacklist file, the splitting into multiple batch processing units facilitates the client's traversal and retries of the blacklist file. For example, if a batch processing unit fails, only the data within that single batch processing unit is retried, without needing to reprocess the entire blacklist file.

[0037] In this embodiment, when a preset task time point is reached, user identifiers are retrieved from the blacklist database based on a blacklist data snapshot and written to a blacklist file. When the number of user identifiers in the blacklist file reaches a preset upper limit, the blacklist file is compressed and stored in the database. Retrieving data from the blacklist database via snapshots avoids system lag and crashes caused by prolonged data processing when fetching data all at once.

[0038] Different service providers may have different criteria for setting blacklisted users. Therefore, the same user may be blacklisted by all service providers or only by some service providers. Thus, the user identifier in the blacklist database is associated with the transaction object identifier of the service provider. The transaction object identifier is used to distinguish between different service providers.

[0039] Please see Figure 4 This application provides a flowchart illustrating the process of generating a blacklist based on a transaction object identifier. For example... Figure 4 As shown, in one or more embodiments of this application, step S202 may include the following steps S302-S306.

[0040] S302, based on the blacklist data snapshot, retrieve the first user identifier whose transaction object identifier is empty from the blacklist database, and write the first user identifier into the global blacklist file.

[0041] Specifically, the first user identifier, which has not yet been saved to the synchronization database before being identified in the blacklist data snapshot and whose transaction object identifier is empty, is determined to be blacklisted by all service providers. Therefore, the first user identifier can be obtained from the blacklist database and written to the global blacklist file.

[0042] S304, based on the blacklist data snapshot, obtain the second user identifier corresponding to the target transaction object identifier in the blacklist database.

[0043] Specifically, the second user identifier corresponding to the target transaction object identifier is determined in the blacklist data snapshot but has not yet been saved to the synchronization database. The target transaction object identifier can be any transaction object identifier, indicating that the user corresponding to the second user identifier has been set as a blacklist user by the service provider corresponding to the target transaction object identifier.

[0044] S306 If the second user identifier does not exist in the global blacklist file, then the second user identifier is written into the blacklist file corresponding to the target transaction object identifier.

[0045] Specifically, to avoid duplicate user identifiers in the blacklist file, it is possible to check whether a second user identifier exists in the global blacklist. If the second user identifier does not exist in the global blacklist file, it can be obtained from the blacklist database and written into the blacklist file corresponding to the target transaction object identifier.

[0046] In this embodiment, based on a blacklist data snapshot, a first user identifier with an empty transaction object identifier is retrieved from the blacklist database and written to a global blacklist file. Then, based on the blacklist data snapshot, a second user identifier corresponding to the target transaction object identifier is retrieved from the blacklist database. If the second user identifier does not exist in the global blacklist file, it is written to the blacklist file corresponding to the target transaction object identifier. Classifying blacklist files according to transaction object identifiers improves the efficiency of blacklist file management and facilitates the rapid sending of corresponding blacklist files to clients of different service providers.

[0047] Please see Figure 5 This application provides a schematic diagram of a synchronization process based on transaction object identifiers, as illustrated in this embodiment. Figure 5 As shown, in one or more embodiments of this application, step S106 may include the following steps S402-S406.

[0048] S402, if a full synchronization request is received from the client, the target transaction object identifier corresponding to the client is obtained.

[0049] Specifically, when a client sends a full synchronization request, it can include the transaction object identifier corresponding to the client in the full synchronization request. If the client sends a full synchronization request, the target transaction object identifier corresponding to the client can be obtained.

[0050] S404: The global blacklist file in the synchronized database and the blacklist file corresponding to the target transaction object identifier are identified as the target blacklist file.

[0051] Specifically, the blacklist file corresponding to the target transaction object identifier is determined in the synchronization database, and then the global blacklist file and the blacklist file corresponding to the target transaction object identifier are determined together as the target blacklist file.

[0052] S406 sends the target blacklist file prior to the full synchronization time point to the client.

[0053] Specifically, the target blacklist files prior to the synchronization time point will be sent to the client from the synchronization database.

[0054] Step S108 may include the following steps: Based on the client's heartbeat signal, target blacklist files after the full synchronization time point are sent to the client at preset time units until all target blacklist files are sent to the client.

[0055] Specifically, whenever a heartbeat signal from a client is detected, the target blacklist files within each preset time unit after the full synchronization time point can be sent to the client until all target blacklist files in the synchronization database are sent to the client.

[0056] Optionally, the preset time unit can be a day, i.e. 24 hours. Therefore, in addition to obtaining the target transaction object identifier in the full synchronization signal, it can also obtain the sending timestamp of the full synchronization signal. The sending timestamp is used to identify the time point when the client sends the full synchronization signal. When the blacklist file of the day before the sending timestamp has been sent to the client, the supplementary time interval between midnight on the sending timestamp and the sending timestamp can be obtained. Then, the blacklist file within the supplementary time interval is obtained from the synchronization information database, and when the next heartbeat signal of the client is detected, the blacklist file within the supplementary time interval is sent to the client.

[0057] In this embodiment, if a full synchronization request is received from a client, the target transaction object identifier corresponding to the client is obtained. The global blacklist file in the synchronization database and the blacklist file corresponding to the target transaction object identifier are identified as target blacklist files. Target blacklist files before the full synchronization time point are sent to the client. Based on the client's heartbeat signal, target blacklist files after the full synchronization time point are sent to the client at preset time units until all target blacklist files are sent to the client. By obtaining the target transaction object identifier in the full synchronization request and retrieving the blacklist file corresponding to the client from the synchronization database, the efficiency and accuracy of synchronizing blacklist files for different service providers are improved.

[0058] Although the client can obtain the blacklist file through a full synchronization request, the blacklist file in the synchronization information database will also be updated as the user identifier in the blacklist database increases. Therefore, in order to ensure the timeliness of the blacklist file stored in the client, the client can periodically send incremental synchronization requests to the user blacklist synchronization device. The incremental synchronization request is used to obtain newly added blacklist files that are not saved locally on the client.

[0059] Please see Figure 6 This application provides a schematic diagram of an incremental synchronization process based on a first incremental table, as illustrated in this embodiment. Figure 6 As shown, in one or more embodiments of this application, the user blacklist synchronization method may further include the following steps S502-S504.

[0060] S502: If an incremental synchronization request is received from the client, the synchronization time interval corresponding to the incremental synchronization request is obtained.

[0061] Specifically, the incremental synchronization request can store the historical timestamp of the last full synchronization request or incremental synchronization request, and the incremental timestamp of the incremental synchronization request. The incremental timestamp represents the time when the client sent the incremental synchronization request. If the client's incremental synchronization request is received, the synchronization time interval can be calculated based on the historical timestamp and incremental timestamp in the incremental synchronization request.

[0062] S504 If the synchronization time interval is less than the preset incremental time interval, the blacklist file that matches the synchronization time interval in the first incremental table of the synchronization database will be sent to the client.

[0063] Specifically, the user blacklist synchronization device can set a first incremental table in the synchronization information database. This first incremental table stores blacklist files within a preset incremental time interval. The preset incremental time interval can be an initial setting for the user blacklist synchronization device or can be set by relevant personnel; for example, it can be 7 days, meaning the first incremental table can store blacklist files from the most recent seven days. If the synchronization time interval is shorter than the preset incremental time interval, then the blacklist files in the first incremental table can satisfy the client's incremental synchronization request, and the blacklist files matching the synchronization time interval in the first incremental table of the synchronization database can be directly sent to the client.

[0064] Optionally, the incremental synchronization request may also include the target transaction object identifier corresponding to the client. Therefore, the blacklist file corresponding to the target transaction object identifier that matches the synchronization time interval in the first incremental table can be sent to the client.

[0065] Optionally, to ensure that the first incremental table always contains blacklist files within the most recent preset incremental time interval, the user blacklist synchronization device can synchronously save the blacklist file generated by the newly added user identifier to the first incremental table as soon as it obtains the new user identifier from the blacklist database. An incremental table update time point can be set, for example, 8:00 AM every day. When the incremental table update time point is reached, blacklist files in the first incremental table that exceed the preset incremental time interval can be deleted. For example, the first incremental table can store blacklist files from the last seven days. If the incremental table update time point of 8:00 AM on November 8th is reached, blacklist files from November 1st stored in the first incremental table can be deleted, thus ensuring that the number of blacklist files in the first incremental table does not become excessive. When an incremental synchronization request is received, the device can quickly query from the first incremental table and respond to the client.

[0066] In this embodiment, if an incremental synchronization request is received from a client, the synchronization time interval corresponding to the incremental synchronization request is obtained. If the synchronization time interval is less than a preset incremental time interval, the blacklist file that matches the synchronization time interval in the first incremental table of the synchronization database is sent to the client. By setting a first incremental table with a recent preset incremental time interval, the amount of data in the first incremental table is controlled, thereby improving the response efficiency to incremental synchronization requests.

[0067] The time interval between two incremental synchronization requests set by the client can be less than the preset incremental time interval, in which case the first incremental table can satisfy the client's incremental synchronization request. However, if the time interval between two incremental synchronization requests set by the client is greater than the preset incremental time interval due to different service provider settings or poor network conditions in some areas, the first incremental table cannot fully satisfy the client's incremental synchronization request. The user blacklist synchronization device can set a second incremental table in addition to the first incremental table to store all blacklist files before the preset incremental time interval.

[0068] Please see Figure 7 This document provides a schematic diagram illustrating the process of incremental synchronization based on a second incremental table, as described in an embodiment of this application. Figure 7 As shown, in one or more embodiments of this application, the user blacklist synchronization method may further include the following steps S602-S606.

[0069] S602, if the synchronization time interval is greater than the preset incremental time interval, calculate the difference between the synchronization time interval and the preset incremental time interval to obtain the difference time interval.

[0070] Specifically, if the synchronization time interval is greater than the preset incremental time interval, the blacklist files in the first incremental table cannot fully satisfy the client's incremental synchronization request. The difference between the synchronization time interval and the preset incremental time can be calculated to obtain the difference time interval, which is the time interval of the client's incremental synchronization request but not the time interval of the blacklist files in the first incremental table.

[0071] S604, the blacklist file in the first incremental table is determined as the first incremental file, and the blacklist file in the second incremental table of the synchronized database that matches the difference time interval is determined as the second incremental file.

[0072] Specifically, the blacklisted files in the first incremental table are identified as the first incremental files. Then, the blacklisted files that match the time difference interval are searched in the second incremental table of the synchronization database, and these files are identified as the second incremental files.

[0073] Optionally, when the incremental table update time point is reached, the blacklist files deleted from the first incremental table can be saved to the second incremental table.

[0074] S606 sends the first and second incremental files to the client.

[0075] Specifically, the first and second incremental files are sent to the client, which can then update the blacklist file stored locally with the first and second incremental files, thus completing the incremental update of the blacklist file.

[0076] In this embodiment, if the synchronization time interval is greater than a preset incremental time interval, the difference between the synchronization time interval and the preset incremental time interval is calculated to obtain the difference time interval. The blacklisted files in the first incremental table are then identified as the first incremental files, and the blacklisted files in the second incremental table of the synchronization database that match the difference time interval are identified as the second incremental files. The first and second incremental files are then sent to the client. By setting a second incremental table, situations where the second incremental table cannot meet incremental synchronization requests are avoided. This ensures both a fast response to incremental synchronization requests and an accurate response to incremental synchronization requests.

[0077] The following will be combined with the appendix Figure 8 - Appendix Figure 9 This application provides a detailed description of the user blacklist synchronization device provided in its embodiments. It should be noted that the appendix... Figure 8 - Appendix Figure 9 The user blacklist synchronization device in the application is used to perform the following tasks. Figures 1-7 The methods shown in the embodiments are for illustrative purposes only, illustrating the parts relevant to the embodiments of this application. For specific technical details not disclosed, please refer to this application. Figures 1-7 The example shown.

[0078] Please see Figure 8 This illustration shows a schematic diagram of a user blacklist synchronization device provided in an exemplary embodiment of this application. The user blacklist synchronization device can be implemented as all or part of a device through software, hardware, or a combination of both. The device 1 includes a snapshot pulling unit 11, a file writing unit 12, a first full synchronization unit 13, and a second full synchronization unit 14.

[0079] Snapshot fetching unit 11 is used to retrieve a snapshot of blacklist data for all user identifiers in the blacklist database; File storage unit 12 is used to generate blacklist files sequentially based on the blacklist data snapshot, and save all the blacklist files in the synchronization database; The first full synchronization unit 13 is used to send the blacklist files in the synchronization database before the full synchronization time point to the client if a full synchronization request is received from the client. The second full synchronization unit 14 is used to send blacklist files after the full synchronization time point in the synchronization database to the client at preset time units based on the client's heartbeat signal, until all the blacklist files are sent to the client.

[0080] In this embodiment, a snapshot of blacklist data for all user identifiers is obtained from the blacklist database. Blacklist files are generated sequentially based on these snapshots, and all blacklist files are stored in a synchronization database. If a full synchronization request is received from a client, blacklist files prior to the full synchronization time point in the synchronization database are sent to the client. Based on the client's heartbeat signal, blacklist files after the full synchronization time point in the synchronization database are sent to the client at preset time units until all blacklist files are sent to the client. By pre-fetching and saving all blacklist files offline, and sending them to the client for full synchronization in time slots and components, blacklist file retrieval time is saved, full synchronization efficiency is improved, and client unresponsiveness due to a large number of blacklist files is avoided.

[0081] Please see Figure 9 This illustration shows a schematic diagram of a user blacklist synchronization device provided in an exemplary embodiment of this application. The user blacklist synchronization device can be implemented as all or part of a device through software, hardware, or a combination of both. The device 1 includes a snapshot pulling unit 11, a file writing unit 12, a first full synchronization unit 13, a second full synchronization unit 14, a first incremental synchronization unit 15, and a second incremental synchronization unit 16.

[0082] Snapshot fetching unit 11 is used to retrieve a snapshot of blacklist data for all user identifiers in the blacklist database; File storage unit 12 is used to generate blacklist files sequentially based on the blacklist data snapshot, and save all the blacklist files in the synchronization database; Optionally, the file storage unit 12 is specifically used to obtain the user identifier from the blacklist database based on the blacklist database snapshot and write the obtained user identifier into the blacklist file when the preset task time point is reached; When the number of user identifiers in the blacklist file reaches a preset upper limit, the blacklist file is compressed and stored in the database.

[0083] Optionally, the file storage unit 12 is specifically used to obtain a first user identifier with an empty transaction object identifier from the blacklist database based on the blacklist data snapshot, and write the first user identifier into the global blacklist file; Based on the blacklist data snapshot, obtain the second user identifier corresponding to the target transaction object identifier from the blacklist database; If the second user identifier does not exist in the global blacklist file, then the second user identifier is written into the blacklist file corresponding to the target transaction object identifier.

[0084] The first full synchronization unit 13 is used to send the blacklist files in the synchronization database before the full synchronization time point to the client if a full synchronization request is received from the client. Optionally, the first full synchronization unit is specifically used to obtain the target transaction object identifier corresponding to the client if a full synchronization request is received from the client. The global blacklist file and the blacklist file corresponding to the target transaction object identifier in the synchronization database are determined as the target blacklist file; The target blacklist file prior to the full synchronization time point is sent to the client.

[0085] The second full synchronization unit 14 is used to send blacklist files after the full synchronization time point in the synchronization database to the client at preset time units based on the client's heartbeat signal, until all the blacklist files are sent to the client.

[0086] Optionally, the second full synchronization unit 14 is specifically used to send the target blacklist files after the full synchronization time point to the client based on the client's heartbeat signal at a preset time unit, until all the target blacklist files are sent to the client.

[0087] The first incremental synchronization unit 15 is used to obtain the synchronization time interval corresponding to the incremental synchronization request if it receives an incremental synchronization request from the client. If the synchronization time interval is less than the preset incremental time interval, then the blacklist file that matches the synchronization time interval in the first incremental table of the synchronization database is sent to the client. The first incremental table stores blacklist files within the preset incremental time interval.

[0088] The second incremental synchronization unit 16 is used to calculate the difference between the synchronization time interval and the preset incremental time interval if the synchronization time interval is greater than the preset incremental time interval, and obtain the difference time interval. The blacklist file in the first incremental table is determined as the first incremental file, and the blacklist file in the second incremental table of the synchronization database that matches the difference time interval is determined as the second incremental file. The second incremental table stores all blacklist files before the preset incremental time interval. The first incremental file and the second incremental file are sent to the client.

[0089] In this embodiment, a snapshot of all user identifiers in the blacklist database is obtained. When a preset task time point is reached, user identifiers are retrieved from the blacklist database based on the blacklist data snapshot and written to the blacklist file. When the number of user identifiers in the blacklist file reaches a preset upper limit, the blacklist file is compressed and stored in the database. Retrieving data from the blacklist database using snapshots avoids system lag and crashes caused by long data processing times when fetching data all at once. Based on the blacklist data snapshot, a first user identifier with an empty transaction object identifier is retrieved from the blacklist database and written to the global blacklist file. Based on the blacklist data snapshot, a second user identifier corresponding to the target transaction object identifier is retrieved from the blacklist database. If the second user identifier does not exist in the global blacklist file, it is written to the blacklist file corresponding to the target transaction object identifier. Categorizing blacklist files according to transaction object identifiers improves the management efficiency of blacklist files and facilitates the rapid sending of corresponding blacklist files to clients of different service providers. If a full synchronization request is received from a client, the target transaction object identifier corresponding to the client is obtained. The global blacklist file in the synchronization database and the blacklist file corresponding to the target transaction object identifier are identified as the target blacklist files. Target blacklist files prior to the full synchronization time are sent to the client. Based on the client's heartbeat signal, target blacklist files after the full synchronization time are sent to the client at preset time units until all target blacklist files are sent to the client. By obtaining the target transaction object identifier from the full synchronization request and retrieving the corresponding blacklist file from the synchronization database, the efficiency and accuracy of synchronizing blacklist files for different service providers are improved. By pre-fetching and saving all blacklist files offline and sending them to the client for full synchronization in time slots and components, blacklist file retrieval time is saved, full synchronization efficiency is improved, and client unresponsiveness due to a large number of blacklist files is avoided.

[0090] Furthermore, if an incremental synchronization request is received from a client, the system obtains the corresponding synchronization time interval. If the synchronization time interval is less than a preset incremental time interval, the system sends the blacklist files from the first incremental table of the synchronization database that match the synchronization time interval to the client. By setting a first incremental table with a recent preset incremental time interval, the amount of data in the first incremental table is controlled, thereby improving the response efficiency to incremental synchronization requests. If the synchronization time interval is greater than the preset incremental time interval, the system calculates the difference between the synchronization time interval and the preset incremental time interval to obtain the difference time interval. The blacklist files in the first incremental table are then identified as the first incremental files, and the blacklist files from the second incremental table of the synchronization database that match the difference time interval are identified as the second incremental files. Both the first and second incremental files are then sent to the client. By setting a second incremental table, the system avoids situations where the second incremental table cannot meet the incremental synchronization request requirements, ensuring both a fast and accurate response to incremental synchronization requests.

[0091] It should be noted that the user blacklist synchronization device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the user blacklist synchronization method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the user blacklist synchronization device and the user blacklist synchronization method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0092] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0093] This application also provides a computer storage medium that can store multiple instructions, which are adapted to be loaded and executed by a processor as described above. Figures 1-7 The user blacklist synchronization method described in the illustrated embodiment can be found in the following documentation for its specific execution process. Figures 1-7 The specific details of the illustrated embodiments will not be elaborated here.

[0094] This application also provides a computer program product storing at least one instruction, which is loaded and executed by the processor as described above. Figures 1-7 The user blacklist synchronization method described in the illustrated embodiment can be found in the following documentation for its specific execution process. Figures 1-7 The specific details of the illustrated embodiments will not be elaborated here.

[0095] Please refer to Figure 10This diagram illustrates a structural block diagram of an electronic device provided in an exemplary embodiment of this application. The electronic device in this application may include one or more components such as a processor 110, a memory 120, an input device 130, an output device 140, and a bus 150. The processor 110, memory 120, input device 130, and output device 140 may be connected via the bus 150.

[0096] Processor 110 may include one or more processing cores. Processor 110 connects to various parts of the electronic device using various interfaces and lines, and executes various functions of terminal 100 and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 120, and by calling data stored in memory 120. Optionally, processor 110 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). Processor 110 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user page, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into processor 110 and may be implemented separately using a communication chip.

[0097] The memory 120 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 120 may include non-transitory computer-readable storage medium. The memory 120 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 120 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the various method embodiments described above, etc. The operating system may be the Android system, including systems deeply developed based on the Android system, the iOS system developed by Apple Inc., including systems deeply developed based on the iOS system, or other systems.

[0098] The memory 120 can be divided into operating system space and user space. The operating system runs in the operating system space, while native and third-party applications run in user space. To ensure that different third-party applications can achieve good running performance, the operating system allocates corresponding system resources for each application. However, different application scenarios within the same third-party application have different requirements for system resources. For example, in local resource loading scenarios, third-party applications have high requirements for disk read speed; in animation rendering scenarios, third-party applications have high requirements for GPU performance. Since the operating system and third-party applications are independent of each other, the operating system often cannot promptly perceive the current application scenario of a third-party application, resulting in the operating system's inability to adapt system resources accordingly.

[0099] In order for the operating system to distinguish the specific application scenarios of third-party applications, it is necessary to establish data communication between the third-party applications and the operating system. This would allow the operating system to obtain the current scenario information of the third-party applications at any time, and then perform targeted system resource adaptation based on the current scenario.

[0100] The input device 130 is used to receive input instructions or data, and includes, but is not limited to, a keyboard, mouse, camera, microphone, or touch device. The output device 140 is used to output instructions or data, and includes, but is not limited to, a display device and a speaker. In one example, the input device 130 and the output device 140 can be combined, and the input device 130 and the output device 140 can be a touch display screen.

[0101] The touch display screen can be designed as a full-screen, curved screen, or irregularly shaped screen. It can also be designed as a combination of a full-screen and a curved screen, or a combination of an irregularly shaped screen and a curved screen; however, this application does not limit the specific design in this regard.

[0102] In addition, those skilled in the art will understand that the structure of the electronic device shown in the above figures does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the electronic device may also include radio frequency circuits, input units, sensors, audio circuits, Wireless Fidelity (WiFi) modules, power supplies, Bluetooth modules, etc., which will not be described in detail here.

[0103] exist Figure 10 In the illustrated electronic device, the processor 110 can be used to call the user blacklist synchronization application stored in the memory 120, and specifically perform the following operations: Retrieve a snapshot of all user identifiers in the blacklist database; Blacklist files are generated sequentially based on the blacklist data snapshots, and all blacklist files are saved in a synchronized database; If a full synchronization request is received from the client, the blacklist file prior to the full synchronization time point in the synchronization database is sent to the client. Based on the client's heartbeat signal, the blacklist files after the full synchronization time point in the synchronization database are sent to the client at preset time units until all the blacklist files are sent to the client.

[0104] In one embodiment, when the processor 110 generates blacklist files sequentially based on the blacklist data snapshot and saves all the blacklist files in the synchronization database, it specifically performs the following operations: When the preset task time point is reached, the user identifier is obtained from the blacklist database based on the blacklist database snapshot and written into the blacklist file; When the number of user identifiers in the blacklist file reaches a preset upper limit, the blacklist file is compressed and stored in the database.

[0105] In one embodiment, when the processor 110 performs the following operations to obtain a user identifier from the blacklist database based on the blacklist database snapshot and write the obtained user identifier into the blacklist file: Based on the blacklist data snapshot, the first user identifier with an empty transaction object identifier is obtained from the blacklist database, and the first user identifier is written into the global blacklist file; Based on the blacklist data snapshot, obtain the second user identifier corresponding to the target transaction object identifier from the blacklist database; If the second user identifier does not exist in the global blacklist file, then the second user identifier is written into the blacklist file corresponding to the target transaction object identifier.

[0106] In one embodiment, when the processor 110 executes the operation of sending the blacklist file prior to the full synchronization time point in the synchronization database to the client if a full synchronization request is received from the client, it specifically performs the following operations: If a full synchronization request is received from a client, the target transaction object identifier corresponding to the client is obtained; The global blacklist file and the blacklist file corresponding to the target transaction object identifier in the synchronization database are determined as the target blacklist file; The target blacklist file prior to the full synchronization time point is sent to the client.

[0107] In one embodiment, when the processor 110 executes the process of sending blacklist files from the full synchronization time point onwards to the client based on the client's heartbeat signal at preset time units, until all blacklist files are sent to the client, it specifically performs the following operations: Based on the client's heartbeat signal, the target blacklist files after the full synchronization time point are sent to the client at preset time units until all target blacklist files are sent to the client.

[0108] In one embodiment, when executing the user blacklist synchronization method, the processor 110 also performs the following operations: If an incremental synchronization request is received from the client, the synchronization time interval corresponding to the incremental synchronization request is obtained; If the synchronization time interval is less than the preset incremental time interval, then the blacklist file that matches the synchronization time interval in the first incremental table of the synchronization database is sent to the client. The first incremental table stores blacklist files within the preset incremental time interval.

[0109] In one embodiment, when executing the user blacklist synchronization method, the processor 110 also performs the following operations: If the synchronization time interval is greater than the preset incremental time interval, then the difference between the synchronization time interval and the preset incremental time interval is calculated to obtain the difference time interval. The blacklist file in the first incremental table is determined as the first incremental file, and the blacklist file in the second incremental table of the synchronization database that matches the difference time interval is determined as the second incremental file. The second incremental table stores all blacklist files before the preset incremental time interval. The first incremental file and the second incremental file are sent to the client.

[0110] In this embodiment, a snapshot of all user identifiers in the blacklist database is obtained. When a preset task time point is reached, user identifiers are retrieved from the blacklist database based on the blacklist data snapshot and written to the blacklist file. When the number of user identifiers in the blacklist file reaches a preset upper limit, the blacklist file is compressed and stored in the database. Retrieving data from the blacklist database using snapshots avoids system lag and crashes caused by long data processing times when fetching data all at once. Based on the blacklist data snapshot, a first user identifier with an empty transaction object identifier is retrieved from the blacklist database and written to the global blacklist file. Based on the blacklist data snapshot, a second user identifier corresponding to the target transaction object identifier is retrieved from the blacklist database. If the second user identifier does not exist in the global blacklist file, it is written to the blacklist file corresponding to the target transaction object identifier. Categorizing blacklist files according to transaction object identifiers improves the management efficiency of blacklist files and facilitates the rapid sending of corresponding blacklist files to clients of different service providers. If a full synchronization request is received from a client, the target transaction object identifier corresponding to the client is obtained. The global blacklist file in the synchronization database and the blacklist file corresponding to the target transaction object identifier are identified as the target blacklist files. Target blacklist files prior to the full synchronization time are sent to the client. Based on the client's heartbeat signal, target blacklist files after the full synchronization time are sent to the client at preset time units until all target blacklist files are sent to the client. By obtaining the target transaction object identifier from the full synchronization request and retrieving the corresponding blacklist file from the synchronization database, the efficiency and accuracy of synchronizing blacklist files for different service providers are improved. By pre-fetching and saving all blacklist files offline and sending them to the client for full synchronization in time slots and components, blacklist file retrieval time is saved, full synchronization efficiency is improved, and client unresponsiveness due to a large number of blacklist files is avoided.

[0111] Furthermore, if an incremental synchronization request is received from a client, the system obtains the corresponding synchronization time interval. If the synchronization time interval is less than a preset incremental time interval, the system sends the blacklist files from the first incremental table of the synchronization database that match the synchronization time interval to the client. By setting a first incremental table with a recent preset incremental time interval, the amount of data in the first incremental table is controlled, thereby improving the response efficiency to incremental synchronization requests. If the synchronization time interval is greater than the preset incremental time interval, the system calculates the difference between the synchronization time interval and the preset incremental time interval to obtain the difference time interval. The blacklist files in the first incremental table are then identified as the first incremental files, and the blacklist files from the second incremental table of the synchronization database that match the difference time interval are identified as the second incremental files. Both the first and second incremental files are then sent to the client. By setting a second incremental table, the system avoids situations where the second incremental table cannot meet the incremental synchronization request requirements, ensuring both a fast and accurate response to incremental synchronization requests.

[0112] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0113] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

[0114] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, user identifiers, transaction object identifiers, and blacklist files involved in this specification were all obtained with full authorization.

Claims

1. A method for synchronizing a user blacklist, the method comprising: Retrieve a snapshot of all user identifiers in the blacklist database; Blacklist files are generated sequentially based on the blacklist data snapshots, and all blacklist files are saved in a synchronized database; If a full synchronization request is received from the client, the blacklist file prior to the full synchronization time point in the synchronization database is sent to the client. Based on the client's heartbeat signal, the blacklist files after the full synchronization time point in the synchronization database are sent to the client at preset time units until all the blacklist files are sent to the client.

2. The method according to claim 1, wherein generating blacklist files sequentially based on the blacklist data snapshots and storing all the blacklist files in a synchronized database comprises: When the preset task time point is reached, the user identifier is obtained from the blacklist database based on the blacklist database snapshot and written into the blacklist file; When the number of user identifiers in the blacklist file reaches a preset upper limit, the blacklist file is compressed and stored in the database.

3. The method according to claim 2, wherein obtaining the user identifier from the blacklist database based on the blacklist database snapshot and writing the obtained user identifier into the blacklist file comprises: Based on the blacklist data snapshot, the first user identifier with an empty transaction object identifier is obtained from the blacklist database, and the first user identifier is written into the global blacklist file; Based on the blacklist data snapshot, obtain the second user identifier corresponding to the target transaction object identifier from the blacklist database; If the second user identifier does not exist in the global blacklist file, then the second user identifier is written into the blacklist file corresponding to the target transaction object identifier.

4. The method according to claim 3, wherein if a full synchronization request is received from a client, the blacklist file prior to the full synchronization time point in the synchronization database is sent to the client, comprising: If a full synchronization request is received from a client, the target transaction object identifier corresponding to the client is obtained; The global blacklist file and the blacklist file corresponding to the target transaction object identifier in the synchronization database are determined as the target blacklist file; The target blacklist file prior to the full synchronization time point is sent to the client.

5. The method according to claim 2, wherein sending blacklist files after the full synchronization time point in the synchronization database to the client at preset time units based on the client's heartbeat signal, until all blacklist files are sent to the client, comprises: Based on the client's heartbeat signal, the target blacklist files after the full synchronization time point are sent to the client at preset time units until all target blacklist files are sent to the client.

6. The method according to claim 1, further comprising: If an incremental synchronization request is received from the client, the synchronization time interval corresponding to the incremental synchronization request is obtained; If the synchronization time interval is less than the preset incremental time interval, then the blacklist file that matches the synchronization time interval in the first incremental table of the synchronization database is sent to the client. The first incremental table stores blacklist files within the preset incremental time interval.

7. The method according to claim 6, further comprising: If the synchronization time interval is greater than the preset incremental time interval, then the difference between the synchronization time interval and the preset incremental time interval is calculated to obtain the difference time interval. The blacklist file in the first incremental table is determined as the first incremental file, and the blacklist file in the second incremental table of the synchronization database that matches the difference time interval is determined as the second incremental file. The second incremental table stores all blacklist files before the preset incremental time interval. The first incremental file and the second incremental file are sent to the client.

8. A user blacklist synchronization device, the device comprising: The snapshot retrieval unit is used to retrieve a snapshot of blacklist data for all user identifiers from the blacklist database. The file storage unit is used to generate blacklist files sequentially based on the blacklist data snapshot, and save all the blacklist files in the synchronous database; The first full synchronization unit is used to send the blacklist files in the synchronization database that are before the full synchronization time point to the client if a full synchronization request is received from the client. The second full synchronization unit is used to send blacklist files after the full synchronization time point in the synchronization database to the client at preset time units based on the client's heartbeat signal, until all blacklist files are sent to the client.

9. A computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the method steps of any one of claims 1 to 7.

10. A computer program product storing a plurality of instructions adapted for loading by a processor and executing the method steps of any one of claims 1 to 7.

11. An electronic device, comprising: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed the method steps as claimed in any one of claims 1 to 7.

Images