Strategy data synchronization method and system and storage medium

Abstract

The embodiment of the invention provides a strategy data synchronization method and system and a storage medium, and belongs to the technical field of computers. The synchronization method comprises: in response to a policy loading request, obtaining a target policy identifier, the policy loading request carrying the target policy identifier; obtaining a server version identifier corresponding to the target strategy identifier from a server, and obtaining a local version identifier corresponding to the target strategy identifier from a local strategy storage; according to a preset verification rule, comparing the server version identifier with the local version identifier, and executing one of the following loading operations: if the comparison result is consistent, loading local strategy data corresponding to the target strategy identifier from the local strategy storage; and if the comparison result is inconsistent, executing update data acquisition and loading operation corresponding to the target strategy identifier. According to the synchronization method, the problems of low updating efficiency and difficulty in guaranteeing data consistency of a processing method for policy data issuing and updating in the related technology are solved.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a strategy data synchronization method, system, and storage medium. Background Technology

[0002] In distributed system architectures, clients typically need to continuously retrieve policy data from the server to achieve dynamic configuration. Common implementation methods include directly initiating HTTP requests or using protocols such as FTP for file transfer.

[0003] However, such traditional methods have several inherent drawbacks in large-scale practical applications: First, when remotely retrieving policies, network instability may cause request interruptions or failures, leading to repeated retries by the client and thus reducing overall synchronization efficiency. Second, when faced with a large number of concurrent client requests, the server needs to handle the surge in request load, which can easily cause system performance lag or even service unavailability, highlighting resource consumption issues. Third, when multiple clients perform policy operations concurrently, the lack of effective coordination and synchronization mechanisms may result in inconsistent policy versions held by each client, leading to data discrepancies and conflicts.

[0004] Existing methods often employ a full-coverage approach for data updates, failing to determine the necessity of updates based on changes in data versions. This results in a large amount of redundant data transmission and processing operations. Finally, such solutions typically lack robust retry and exception handling mechanisms, and also lack sufficient operational log support, making it difficult to trace and locate problems when anomalies occur.

[0005] Therefore, the methods for distributing and updating policy data in related technologies suffer from low update efficiency and difficulty in ensuring data consistency. Summary of the Invention

[0006] The purpose of this application is to provide a strategy data synchronization method, system, and storage medium.

[0007] To achieve the above objectives, a first aspect of this application provides a policy data synchronization method applied to a client, comprising: in response to a policy loading request, obtaining a target policy identifier, wherein the policy loading request carries the target policy identifier; obtaining a server version identifier corresponding to the target policy identifier from a server, and obtaining a local version identifier corresponding to the target policy identifier from a local policy storage; comparing the server version identifier and the local version identifier according to a preset verification rule, and performing one of the following loading operations: if the comparison result is consistent, loading the local policy data corresponding to the target policy identifier from the local policy storage; and if the comparison result is inconsistent, performing an update data acquisition and loading operation corresponding to the target policy identifier.

[0008] In this embodiment of the application, obtaining the server version identifier corresponding to the target policy identifier from the server includes: sending a version query request to the server, wherein the version query request carries the target policy identifier; and receiving the server version identifier returned by the server in response to the version query request.

[0009] In this embodiment of the application, the update data acquisition and loading operation includes: sending an update data request to the server, wherein the update data request carries the server version identifier; receiving and loading the update data provided by the server, wherein the update data is incremental update data corresponding to the server version identifier.

[0010] In this embodiment, receiving and loading the update data provided by the server includes: loading the local policy data from the local policy storage to the client memory, wherein the local policy data in the client memory includes at least one local policy sub-item and an atomic item version identifier corresponding to each local policy sub-item; parsing the incremental update data to obtain at least one update policy sub-item and an update sub-item version identifier corresponding to each update policy sub-item; comparing each update sub-item version identifier with each atomic item version identifier corresponding to the local policy sub-item in the client memory; when the update sub-item version identifier is inconsistent with the atomic item version identifier, updating the corresponding update policy sub-item in the update data to the client memory; and persistently storing the updated policy data in the client memory to the local policy storage.

[0011] In this embodiment of the application, obtaining the server version identifier corresponding to the target policy identifier from the server further includes the following method: when the client is configured to work in offline mode, reading the pre-stored server version identifier corresponding to the target policy identifier from the local policy storage.

[0012] In this embodiment of the application, the method further includes: when obtaining the server version identifier from the server or failing to perform the update data acquisition and loading operation, retrying according to a preset retry strategy, wherein the retry strategy limits the maximum number of retries.

[0013] A second aspect of this application provides a policy data synchronization method applied to a server. The method includes: in response to a version query request sent by a client, obtaining and returning a corresponding server version identifier, wherein the server version identifier is used for the client to compare with a local version identifier; in response to an update data request sent by the client carrying the server version identifier, obtaining and returning update data corresponding to the server version identifier, wherein the update data is used for the client to perform a policy update based on the server version identifier.

[0014] In this embodiment of the application, the method further includes a policy data distribution process, which includes: in response to a policy data distribution instruction, locking the update operation of the policy data corresponding to the target policy identifier to obtain an update operation lock; retrieving the policy data corresponding to the target policy identifier from persistent storage and writing it to a shared storage area; performing a hash operation on the policy data in the shared storage area to generate the server version identifier; saving the server version identifier to the shared storage area to complete the update of the policy data; and releasing the update operation lock.

[0015] A third aspect of this application also provides a policy data synchronization system, applied to a server and at least one client, comprising: a client configured to execute the policy synchronization method applied to the client; and a server, including a memory and a processor, configured to execute the policy synchronization method applied to the server. A fourth aspect of this application also provides a machine-readable storage medium storing instructions that, when executed by a processor, configure the processor to perform the aforementioned strategy data synchronization method.

[0016] The fifth aspect of this application also provides a computer program product, including a computer program that, when executed by a processor, implements the data synchronization method according to the strategy described above.

[0017] The above technical solution, employing version comparison and incremental synchronization mechanisms, solves the technical problems of low update efficiency and difficulty in ensuring data consistency in the processing methods for policy data distribution and updates in related technologies.

[0018] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0019] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the following detailed description to explain the embodiments of this application, but do not constitute a limitation on the embodiments of this application. In the drawings: Figure 1 This is a flowchart illustrating a policy data synchronization method applied to a client according to an embodiment of the present invention; Figure 2 This is a flowchart of the strategy data loading process control and exception retry process provided in the embodiments of the present invention; Figure 3 This is a flowchart of server-client policy data synchronization provided according to an embodiment of the present invention; Figure 4 This is a policy data synchronization method applied to a server according to an embodiment of the present invention; Figure 5 This is an internal structural diagram of a computer device provided according to an embodiment of the present invention.

[0020] Explanation of reference numerals in the attached figures A01 - Processor; A02 - Network interface; A03 - Internal memory; A04 - Display screen; A05 - Input device; A06 - Non-volatile storage medium; B01 - Operating System; B02 - Computer Program. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0022] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0023] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0024] The acquisition, transmission, storage, use, and processing of data in this application comply with relevant laws and regulations. Furthermore, it should be noted that certain software, components, models, and other existing industry solutions may be mentioned in the embodiments of this application. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solution of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0025] This invention provides a strategy data synchronization method, applied to a client, specifically, as follows: Figure 1 As shown, the synchronization method may include steps S102-S108: Step S102: In response to the policy loading request, obtain the target policy identifier, wherein the policy loading request carries the target policy identifier; Specifically, when the client application (which can be an internal management backend system of an enterprise) starts, its permission management end will proactively initiate a policy loading request. In this step, the upstream management end can manually trigger the policy loading request by clicking the "Deploy" button on the client page. There are no restrictions on how the policy loading request is triggered, as long as the policy loading request includes the target policy identifier. The target policy identifier can be a business primary key used to uniquely identify specific policy data between the client and the server, and is a globally unique identifier for the policy data.

[0026] In one embodiment, step S102 may include steps S111-S112.

[0027] Step S111: Send a version query request to the server, wherein the version query request carries a target policy identifier; The version query request carries a target policy identifier. Specifically, the client sends a version query request to the server based on the target policy identifier.

[0028] Step S112: Receive the server version identifier returned by the server in response to the version query request.

[0029] After receiving the version query request in step S111, the server will return the latest server version identifier. After receiving the version query request returned by the server, the client will parse and obtain the current server version identifier for subsequent comparison with the local version identifier. Specifically, in one embodiment, obtaining the server version identifier corresponding to the target policy identifier from the server includes: obtaining the server version identifier corresponding to the target policy identifier from the server, and further includes the following method: when the client is configured to work in offline mode, reading the pre-stored server version identifier corresponding to the target policy identifier from the local policy storage.

[0030] To enable normal operation of the client in environments without network connectivity, this solution also provides an offline acquisition path. When the SDK integrated on the client is actively configured or automatically detected to enter offline working mode, it no longer initiates network requests to the server. Instead, it directly reads the historical server version identifier, which was pre-stored during successful synchronization and bound to the target policy identifier, from the local policy storage data area. In this step, the client integrating the SDK is deployed independently, with low coupling to the server, and an escape mechanism is provided so that server-side problems will not cause client execution abnormalities.

[0031] Step S104: Obtain the server version identifier corresponding to the target policy identifier from the server and the local version identifier corresponding to the target policy identifier from the local policy storage. Specifically, the client needs to obtain two key version identifiers: a server-side version identifier representing the latest state from the server, and a local version identifier representing the current state from the client's local storage. Based on the target policy identifier, the client initiates a network request to the server to query the latest server-side version identifier for that policy. Subsequently, the client uses the same target policy identifier to query the local persistent storage. This local version identifier is essentially a historical copy of the server-side version identifier stored when the client successfully synchronized the policy from the server last time. It should be noted that the server-side version identifier and the local version identifier are essentially version identifiers corresponding to the same data, but they represent data states at different points in time, and their storage locations are also different.

[0032] Step S106: According to the preset verification rules, compare the server version identifier with the local version identifier and perform one of the following loading operations: If the comparison result is consistent, load the local policy data corresponding to the target policy identifier from the local policy storage. The pre-defined verification rules can be pre-set by the client to determine whether the server-side version identifier and the local version identifier represent the same policy data content. For example, it can be based on comparing and judging the strings of the two version identifiers. After determining the comparison result, the corresponding loading operation is performed based on the comparison result. In this step, if the comparison results are consistent, that is, the strings corresponding to the server-side version identifier and the strings corresponding to the local version identifier are completely identical, the local policy data corresponding to the target policy identifier is further retrieved from the client's local policy storage.

[0033] It should be noted that whether the policy data corresponding to the server version identifier is obtained from the server or the policy data corresponding to the local version identifier is obtained from the local policy storage, the content of this policy data can include application information, service code information, menu information, service code and menu permission relationship information, access control rules (such as: returning a result of deny, alarm only, or allow if a certain rule is met). The version identifier can then be the corresponding version identifier obtained by hash calculation based on a certain application data item contained in this policy data.

[0034] In step S108, if the comparison results are inconsistent, the update data acquisition and loading operation corresponding to the target policy identifier is performed.

[0035] Specifically, if the comparison results in step S106 are inconsistent, it indicates that the server already has a locally updated policy version for the client. At this time, the client abandons loading potentially outdated local cached data and instead executes a well-defined subsequent process, namely, performing the operation of obtaining and loading the update data corresponding to the target policy identifier.

[0036] In one embodiment, step S108 further includes steps S113-114.

[0037] Step S113: Send an update data request to the server, wherein the update data request carries the server version identifier; Specifically, when the version comparison structure in step S106 is inconsistent, the client determines that the local policy data is outdated and needs to obtain an update from the server. At this time, the client needs to send an update data request to the server. The core parameters of this update data request include the latest server version identifier successfully obtained from the server.

[0038] Step S114: Receive and load the update data provided by the server, wherein the update data is incremental update data corresponding to the server version identifier.

[0039] By including a server version identifier in the update data request, the client explicitly requests the incremental update data package corresponding to that specific version from the server. The server can then quickly locate all changes relative to the client's local version identifier (historical old version identifier) ​​within its version management system based on this version identifier, and determine the corresponding incremental update data. Furthermore, upon receiving the incremental update data, the client initiates relevant data parsing and version verification operations.

[0040] Furthermore, in one embodiment, receiving and loading update data provided by the server further includes receiving and loading update data provided by the server, comprising: loading local policy data from local policy storage to client memory, wherein the local policy data in client memory includes at least one local policy sub-item and an atomic item version identifier corresponding to each local policy sub-item; parsing incremental update data to obtain at least one update policy sub-item and an update sub-item version identifier corresponding to each update policy sub-item; comparing each update sub-item version identifier with each atomic item version identifier corresponding to the local policy sub-item in client memory; when the update sub-item version identifier and the atomic item version identifier are inconsistent, updating the corresponding update policy sub-item in the update data to client memory; and persistently storing the updated policy data in client memory to local policy storage.

[0041] Among them, policy data can refer to a collection of control rules and configuration information that need to be executed on the client side. For example, it can include application information: basic attributes of the client's application (such as ID, name, version), service code information: a unique code that identifies a specific backend service or API interface, menu information: function menu items visible on the client's user interface, service code and menu permission relationship information: an authorization mapping relationship that defines whether a user can access a specific service code through a menu, and access control rules: core policy rules that define the operation (deny, alarm only, allow) that should be performed on a certain access request when certain conditions (such as user role, time, IP) are met.

[0042] Based on the aforementioned policy data, the target policy identifier serves as a key or ID to uniquely identify the complete policy dataset between the client and the server. Primarily, the client can use this identifier to query and request specific policy data from the server. The version identifier is also obtained by hashing the policy data content. Any slight change in the data content will change the version identifier accordingly. The policy sub-items and their version identifiers are the smallest logical units after subdividing the policy data structure. For example, an access rule, a menu item, or a service code can all be a policy sub-item, and the corresponding sub-item version identifier is calculated based on these policy sub-items.

[0043] It's important to note that each independent policy sub-item has its own version identifier. The client obtains the server-side version identifier from the server, requests and verifies an incremental data packet containing only the changed content. At this point, the client doesn't directly overwrite with the incremental data packet. Instead, it first loads the complete local policy data into the client's memory as the update baseline. Then, it parses the incremental data packet and updates the sub-item version identifiers based on the comparison results. That is, it compares the new version identifier of each sub-item with the old local version identifier in the client's memory. Only when the versions differ is the sub-item updated in the client's memory. This ensures the accuracy of policy data updates and prevents errors when repeatedly receiving the same update packet. Finally, the complete new policy data integrated in the client's memory is persistently stored, ensuring that the local policy storage data is not corrupted due to update failures. This step, comparing the sub-item version identifiers within the policy sub-items, achieves efficient data state synchronization.

[0044] For the above steps, if the process of obtaining the server version identifier from the server or performing the update data retrieval and loading operation fails, a retry will be performed according to the preset retry policy, wherein the retry policy limits the maximum number of retries.

[0045] Specifically, when the client fails to obtain the server version identifier from the server or fails to perform subsequent update data retrieval and loading operations (e.g., due to network timeout, server error, or data verification failure), a pre-defined intelligent retry strategy will be triggered. Figure 2 As shown in the diagram, the retry mechanism after a failure to retrieve policy data includes the following steps: This flowchart corresponds to the retry mechanism after a failure to retrieve policy data. The specific process is as follows: When a retry is triggered due to a failure to retrieve (or obtain the version identifier), the process starts. The first step is to determine the number of processes currently executing simultaneously. If the number of processes exceeds the set threshold, it enters the "waiting for retry" state and checks the number of processes again later. If the number of processes is within the threshold, it records the loading count (increments the count by 1). Next, it checks whether the current loading count exceeds the threshold. If it does, it exits the retry process directly. If it doesn't exceed the threshold, it executes the "retrieve server-side policy data" operation. During the process of retrieving server-side policy data, if an exception occurs (such as retrieval failure or parsing error), an exception log is recorded, and the process returns to the "waiting for retry" step to restart the entire retry process. If the retrieval and parsing are both successful, the policy data loading is complete, and the retry process ends.

[0046] It should be noted that the retry strategy set above for when the client fails to obtain the server version identifier from the server or when subsequent update data retrieval and loading operations fail can limit the problem of pulling too much policy data at the same time; when the remote policy retrieval is incorrect, log information is recorded to ensure that the problem can be traced; a retry mechanism for remote policy retrieval and policy loading is added; and a limit on the number of retryes is added so that retries are performed within a certain number of times, preventing the program from freezing due to the same problem.

[0047] This invention also provides a strategy data synchronization method, applied to the server side, specifically, such as... Figure 3 As shown, steps S202-S204 are included: Step S202: In response to the version query request sent by the client, obtain and return the corresponding server version identifier, wherein the server version identifier is used for the client to compare with the local version identifier; Specifically, the server receives a version query request from the client and extracts the key target policy identifier from the request. Then, using this target policy identifier as the query key, it locates the corresponding latest policy dataset in the currently active policy data store. Subsequently, based on the current content of this dataset (which, according to previous definitions, may include all information such as applications, menus, and rules), the system calculates its unique identifier in real-time using a hash algorithm or retrieves it from the cache—the server-side version identifier. Finally, the server encapsulates this server-side version identifier and returns it to the client that initiated the request.

[0048] Step S204: In response to the update data request sent by the client carrying the server version identifier, obtain and return the update data corresponding to the server version identifier, wherein the update data is used for the client to perform policy updates based on the server version identifier.

[0049] Specifically, the server receives the update data request initiated by the client and extracts the latest server version identifier obtained by the client in the previous stage (step S202). Then, the server first verifies the identifier, for example, to confirm whether it is the current valid version. Then, the server uses the server version identifier as the query key to query the incremental update data pre-associated with the corresponding server version identifier and returns this incremental update data to the client that initiated the request.

[0050] In one embodiment, steps S202-S204 above are further included in steps S211-S215.

[0051] Step S211, the distribution process includes: in response to the policy data distribution instruction, locking is performed on the update operation of the policy data corresponding to the target policy identifier, and the update operation lock is obtained; When the server receives a policy data distribution instruction targeting a specific policy identifier, the update process begins. Before any substantive data writing or version change operations commence, the server immediately requests and acquires an exclusive lock for the policy data update operation corresponding to that target policy identifier. This locking step is the core guarantee mechanism for the server to execute policy data updates. By introducing a distributed lock mechanism implemented through Redis (an in-memory data storage system), the distribution operation is prevented from causing data discrepancies due to parallel operations, ensuring data consistency and providing an interface for querying policy data.

[0052] Step S212: Obtain the policy data corresponding to the target policy identifier from the persistent storage and write it to the shared storage area; Specifically, after successfully acquiring the lock for the target policy identifier, the server first reads the latest version of the complete policy data corresponding to the target policy identifier from persistent storage. The server then writes this latest version of the complete policy data into a shared storage area, which can be the in-memory data storage system Redis mentioned in the above steps. This shared storage area essentially acts as a publishing area for updated data. Step S213: Perform a hash operation on the policy data of the shared storage area to generate a server version identifier; Specifically, after the policy data is securely written to the aforementioned shared storage area, the server will perform a hash operation on the latest complete policy data within that area. For example, the complete policy data can be encrypted using MD5 (a cryptographic hash function) to generate a corresponding hash value. This calculated hash value will then be used as the server version identifier for this deployment. It should be noted that the use of the MD5 algorithm here is not limited; other hash algorithms can also achieve the same technical effect.

[0053] Step S214: Save the server version identifier to the shared storage area to complete the update of the policy data; Specifically, based on the server version identifier generated in the above steps, the server performs a write operation to save the identifier to the storage location associated with the target policy identifier in the shared storage area, thus completing the update operation of the policy data.

[0054] Step S215: Release the update operation lock.

[0055] Specifically, after confirming that the server version identifier has been successfully saved to the shared storage area, the server releases the aforementioned distributed lock.

[0056] Through the synergistic effect of distributed locks and version number mechanisms in the above steps, various concurrent conflicts that may occur between the server and the client during policy synchronization can be reduced, ensuring the consistency and integrity of policy data in a distributed environment.

[0057] Using the above-described strategy data synchronization method applied to both the client and server, it is possible to achieve synchronization through methods such as... Figure 4 The server-client policy data synchronization flowchart is shown below. Specifically, after the server starts, it enters the policy data maintenance phase, continuously managing the storage and updating of policy data. When the client page triggers the "issue button", the server responds to the policy data issuance instruction, first locking the update operation of the policy data, then retrieving the policy data corresponding to the target policy identifier from persistent storage (database) and writing it to the shared storage area (Redis), then performing a hash operation on the policy data in the shared storage area to generate a server version identifier, saving the version identifier to the shared storage area to complete the data update, and then releasing the lock. Meanwhile, the client (the service integrating the SDK) starts, simultaneously triggering the "full configuration loading" and "background thread startup for incremental configuration loading" processes: The client first responds to the policy loading request carrying the target policy identifier, verifies whether the corresponding JSON file exists in the local policy storage, if it exists, it directly loads the file to obtain the local version identifier, if it does not exist, it requests the target policy data (supports ZIP packages) and the server version identifier from the server through the HTTP interface; then, it compares the server version identifier with the local version identifier according to the preset verification rules, if they match, it loads the corresponding policy data from the local storage, if they do not match, it sends an update data request to the server and loads the corresponding data, and then saves the sorted policy data to memory and persists it to a JSON file in a fixed local path, completing the full configuration loading. Next, the client starts a background timed thread (the default cycle is 3 minutes, but this can be configured) to perform incremental loading: The thread first checks the SDK configuration. If it is set to "read local policy file", it directly reads the local incremental file to obtain the version identifier. Otherwise, it sends a version query request (carrying the target policy identifier) ​​to the server and receives the server's version identifier and corresponding policy data. Then, it queries the version identifier of the currently loaded policy and compares it with the newly obtained version identifier. If they match, the loading is skipped. If they do not match, the client requests and loads the updated data from the server, then updates the new policy data in memory and persists it to a local file. If obtaining the version identifier or loading data fails during this process, it retryes according to the preset retry policy with a maximum number of retries until the client service stops, at which point the entire synchronization process terminates.

[0058] In summary, the above technical solutions and process scheduling effectively addressed the policy distribution and loading issues. An example of downstream systems using this device is as follows: During use, a policy data structure is first defined, including application information, service code information, menu information, service code and menu permission relationship information, and access control rules (e.g., fulfilling a rule to return a denial, alarm-only, or allow result). The server centrally manages the policy data, providing unified access control for resources such as menus / transaction codes in downstream systems, and offering policy distribution and real-time policy data query functions. Downstream systems using this device achieve policy data synchronization from the server to the client. The client then uses the access control rules in the policy information to ensure that only authorized users can access and operate specific resources, effectively preventing unauthorized access and data leakage.

[0059] Advantages and benefits of this plan: 1) Efficiency improvement: Through caching and incremental updates, the time taken for policy synchronization is reduced by more than 40% (actual test data).

[0060] 2) Consistency guarantee: Distributed locks and version control ensure that the data difference rate among multiple clients approaches 0.

[0061] 3) Resource optimization: Invalid updates were reduced by 70%, and peak server load decreased by 50%.

[0062] 4) High availability: Local JSON persistence and fault tolerance strategies ensure that the client can still run normally when the server fails.

[0063] The present invention also provides a policy data synchronization system, the system comprising: at least one client configured to execute the policy synchronization method applied to the client; and a server including a memory and a processor configured to execute the policy synchronization method applied to the server.

[0064] Specifically, during the operation of this policy data synchronization system, the client and server collaborate according to the steps defined in the aforementioned method. Specifically: First, in response to the policy loading request, the client sends a version query request carrying the target policy identifier to the server. The server responds to this request, obtains and returns the corresponding server version identifier. Next, the client obtains the server version identifier and the local version identifier, and compares them according to preset verification rules: if they match, the policy data is directly loaded from the local policy storage; if they do not match, an update data request carrying the server version identifier is sent to the server. Further, the server responds to the update data request, obtains and returns the incremental update data corresponding to the server version identifier; the client receives and loads the update data, which is the incremental update data corresponding to the server version identifier. Finally, the client completes the policy update by loading local policy data from the local policy storage into the client's memory, parsing the incremental update data to obtain the policy sub-items and their updated sub-item version identifiers, performing sub-item-level version comparison, conditionally updating memory, and finally persistently storing the updated data in the local policy storage.

[0065] It should be noted that the above-mentioned client-server interaction process is based on version identifier comparison and uses incremental update data synchronization as an optimization method. Through the synergy between the client's decision based on version identifier and the server's reliable distribution of incremental update data, efficient synchronization and consistency assurance of policy data in a distributed environment can be achieved.

[0066] In one embodiment, the policy data synchronization system may further include the following devices: The first acquisition device is used for the client to acquire the target policy identifier in response to the policy loading request, wherein the policy loading request carries the target policy identifier. The second acquisition device is used for the client to obtain the server version identifier corresponding to the target policy identifier from the server and to obtain the local version identifier corresponding to the target policy identifier from the local policy storage. The execution device is used by the client to compare the server version identifier with the local version identifier according to the preset verification rules, and perform one of the following loading operations: when the comparison result is consistent, load the local policy data corresponding to the target policy identifier from the local policy storage; and when the comparison result is inconsistent, perform the update data acquisition and loading operation corresponding to the target policy identifier.

[0067] The third acquisition device is used for the server to respond to the version query request sent by the client, acquire and return the corresponding server version identifier, wherein the server version identifier is used for the client to compare with the local version identifier; The fourth acquisition device is used for the server to respond to an update data request sent by the client carrying a server version identifier, acquire and return update data corresponding to the server version identifier, wherein the update data is used by the client to perform policy updates based on the server version identifier.

[0068] This invention also provides a machine-readable storage medium storing instructions for causing a machine to execute: a matching method for collection tasks as described above; and / or a strategy data synchronization method as described above.

[0069] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor A01, a network interface A02, a display screen A04, an input device A05, and a memory (not shown) connected via a system bus. The processor A01 provides computing and control capabilities. The memory includes internal memory A03 and a non-volatile storage medium A06. The non-volatile storage medium A06 stores an operating system B01 and a computer program B02. The internal memory A03 provides an environment for the operation of the operating system B01 and the computer program B02 stored in the non-volatile storage medium A06. The network interface A02 is used for communication with external terminals via a network connection. When the computer program is executed by the processor A01, it implements a policy data synchronization method. The display screen A04 can be a liquid crystal display (LCD) or an e-ink display. The input device A05 can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0070] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0071] In one embodiment, the strategy data synchronization system provided in this application can be implemented as a computer program, which can be implemented in various ways, such as... Figure 5 The system runs on the computer device shown. The computer device's memory can store the various program modules that make up the policy data synchronization system. The computer program, composed of the various program modules, causes the processor to execute the steps in the policy data synchronization of the various embodiments of this application described in this specification.

[0072] Figure 5 The computer device shown can perform corresponding steps through the first acquisition device, second acquisition device, execution device, third acquisition device and fourth acquisition device, which are included in the above-described strategy data synchronization system in addition to the server and client. For example, step S102 can be performed by the first acquisition device, step S104 by the second acquisition device, steps S106 and S108 by the execution device, step S202 by the third acquisition device and step S204 by the fourth acquisition device.

[0073] This application provides an apparatus including a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it performs the following steps: in response to a policy loading request, it obtains a target policy identifier, wherein the policy loading request carries the target policy identifier; it obtains a server version identifier corresponding to the target policy identifier from the server and a local version identifier corresponding to the target policy identifier from the local policy storage; according to a preset verification rule, it compares the server version identifier and the local version identifier and performs one of the following loading operations: when the comparison result is consistent, it loads the local policy data corresponding to the target policy identifier from the local policy storage; and when the comparison result is inconsistent, it performs an update data acquisition and loading operation corresponding to the target policy identifier.

[0074] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program having the following method steps: in response to a version query request sent by a client, obtaining and returning the corresponding server version identifier, wherein the server version identifier is used for the client to compare with a local version identifier; in response to an update data request sent by a client carrying the server version identifier, obtaining and returning update data corresponding to the server version identifier, wherein the update data is used for the client to perform policy updates based on the server version identifier.

[0075] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0076] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0077] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0078] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0079] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0080] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0081] Computer-readable media include both permanent and non-permanent, removable and non-removable media, which can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0082] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0083] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A strategy data synchronization method, applied to a client, characterized in that, The method includes: In response to a policy loading request, a target policy identifier is obtained, wherein the policy loading request carries the target policy identifier; Obtain the server version identifier corresponding to the target policy identifier from the server, and obtain the local version identifier corresponding to the target policy identifier from the local policy storage; According to the preset verification rules, the server version identifier is compared with the local version identifier, and one of the following loading operations is performed: If the comparison result is consistent, then the local policy data corresponding to the target policy identifier is loaded from the local policy storage; and If the comparison results are inconsistent, the update data acquisition and loading operation corresponding to the target policy identifier will be performed.

2. The method according to claim 1, characterized in that, The step of obtaining the server version identifier corresponding to the target policy identifier from the server includes: Send a version query request to the server, wherein the version query request carries the target policy identifier; Receive the server version identifier returned by the server in response to the version query request.

3. The method according to claim 1, characterized in that, The update data acquisition and loading operations include: Send an update data request to the server, wherein the update data request carries the server version identifier; Receive and load the update data provided by the server, wherein the update data is incremental update data corresponding to the server version identifier.

4. The method according to claim 3, characterized in that, The process of receiving and loading the updated data provided by the server includes: The local policy data is loaded from the local policy storage into the client memory, wherein the local policy data in the client memory includes at least one local policy sub-item and an atomic item version identifier corresponding to each local policy sub-item; Parse the incremental update data to obtain at least one update strategy sub-item and the update sub-item version identifier corresponding to each update strategy sub-item; The version identifier of each updated sub-item is compared with the version identifier of each atomic item corresponding to the local policy sub-item in the client memory; When the update sub-item version identifier is inconsistent with the atomic item version identifier, the corresponding update strategy sub-item in the update data is updated to the client memory; The updated policy data in the client's memory is persistently stored in the local policy storage.

5. The method according to claim 1, characterized in that, The step of obtaining the server version identifier corresponding to the target policy identifier from the server also includes the following methods: When the client is configured to work in offline mode, it reads the pre-stored server version identifier corresponding to the target policy identifier from the local policy storage.

6. The method according to claim 1, characterized in that, The method further includes: When obtaining the server version identifier from the server or failing to perform the update data acquisition and loading operation, a retry is performed according to a preset retry policy, wherein the retry policy limits the maximum number of retries.

7. A strategy data synchronization method, applied to a server, characterized in that, The method includes: In response to a version query request sent by the client, the corresponding server version identifier is obtained and returned, wherein the server version identifier is used by the client to compare with the local version identifier; In response to an update data request sent by the client carrying the server version identifier, the system obtains and returns update data corresponding to the server version identifier, wherein the update data is used by the client to perform a policy update based on the server version identifier.

8. The method according to claim 7, characterized in that, The method further includes a strategy data distribution process, which includes: In response to the policy data issuance instruction, lock is acquired on the update operation of the policy data corresponding to the target policy identifier, and the update operation lock is obtained. Retrieve the policy data corresponding to the target policy identifier from persistent storage and write it to the shared storage area; Perform a hash operation on the policy data of the shared storage area to generate the server version identifier; The server version identifier is saved to the shared storage area to update the policy data; Release the update operation lock.

9. A strategy data synchronization system, applied to a system including a server and at least one client, characterized in that, The system includes: A client configured to perform the policy synchronization method as described in any one of claims 1 to 6; The server includes a memory and a processor, and is configured to perform the policy synchronization method as described in any one of claims 7 to 8.

10. A machine-readable storage medium storing instructions thereon, characterized in that, When executed by a processor, this instruction causes the processor to be configured to perform the strategy data synchronization method according to any one of claims 1 to 8.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the strategy data synchronization method according to any one of claims 1 to 8.

Images