Resource permission data processing method and device, electronic equipment and storage medium

Abstract

The application discloses a resource permission data processing method and device, electronic equipment and storage medium, including responding to a data change request of a target resource, updating a resource tree structure in which the target resource is located in a cache based on a content addressing strategy; in response to a permission change request for a target role, updating a compressed bitmap associated with the target role in the cache, the compressed bitmap containing resource identifiers of resources authorized by the target role; in response to a permission judgment request of a target user on a target resource, reading cache role data associated with the target user and obtaining current role data based on a lazy loading mode; comparing the current role data and the cache role data to determine the validity of the permission. The application can avoid write amplification and cascading update storm caused by permission changes, and improve the overall performance of the permission system.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for processing resource access data. Background Technology

[0002] Existing RBAC (Role-Based Access Control) systems typically cache the entire resource tree and user permissions in Redis to support front-end rendering and permission verification. However, this approach suffers from significant performance bottlenecks: First, resource changes trigger a "single-point update, full rebuild," leading to write amplification and wasted computation and I / O. Second, changes to role permissions or allocation relationships require cascading updates to the caches of numerous related users, creating a cache update storm that results in high latency and a surge in system load. The root cause lies in the architecture's reliance on global refresh and its lack of an efficient response mechanism for local changes. Summary of the Invention

[0003] This invention aims to at least solve one of the technical problems existing in the prior art. To this end, this invention proposes a resource permission data processing method, apparatus, electronic device, and storage medium, which can avoid write amplification and cascading update storms caused by permission changes, thereby improving the overall performance of the permission system.

[0004] In a first aspect, embodiments of the present invention provide a resource permission data processing method, including: In response to a data change request for the target resource, update the resource tree structure in the cache containing the target resource based on the content addressing strategy; In response to a permission change request for a target role, update the compressed bitmap associated with the target role in the cache, wherein the compressed bitmap contains the resource identifier of the resource authorized by the target role; In response to a target user's permission request for the target resource, the cached role data associated with the target user is read, and the current role data is obtained based on lazy loading. The validity of the permissions is determined by comparing the current role data with the cached role data.

[0005] According to some embodiments of the present invention, updating the resource tree structure in the cache containing the target resource based on a content addressing strategy in response to a data change request for the target resource includes: In response to a data change request for a target resource, determine the target node after the target resource has been changed; All parent nodes of the target node along the parent path to the root node are identified as nodes to be updated. The content hash values ​​of the nodes to be updated are recalculated sequentially to incrementally update the hash structure of the resource tree; The root hash value of the globally referenced node is updated to the newly generated content hash value of the root node through a single atomic operation.

[0006] According to some embodiments of the present invention, the step of sequentially recalculating the content hash values ​​of the nodes to be updated to incrementally update the hash structure of the resource tree includes: Obtain the business attribute data of the node to be updated; Obtain the content hash values ​​of all child nodes of the node to be updated and perform deterministic sorting to obtain a hash set; The business attribute data is combined with the hash set and subjected to stable serialization processing to obtain the target data; The target data is hashed to obtain the content hash value.

[0007] According to some embodiments of the present invention, updating the compressed bitmap associated with the target role in the cache in response to a permission change request for the target role includes: In response to a permission change request for a target role, read the compressed bitmap associated with the target role from the cache; Based on the permission change request, update the resource identifier in the compressed bitmap and write the updated compressed bitmap back to the cache.

[0008] According to some embodiments of the present invention, updating the compressed bitmap associated with the target role in the cache in response to a permission change request for the target role further includes: Update the character version identifier of the target character.

[0009] According to some embodiments of the present invention, comparing the current role data and the cached role data to determine the validity of the permissions includes: Obtain the current character set from the current character data and the cached character set from the cached character data; Generate a first character hash value based on the current character set, and generate a second character hash value based on the cached character set; The hash values ​​of the first role and the second role are compared to determine role consistency; When the role consistency indicator is consistent, obtain the current version identifier of each role in the current role set, and obtain the cached version identifier of each role in the cached role set; The current version identifier and the cached version identifier of each role are compared to determine the validity of the permissions.

[0010] According to some embodiments of the present invention, after comparing the current role data and the cached role data to determine the validity of the permissions, the method further includes: If the permission validity is indicated as expired, obtain a compressed bitmap of all roles currently associated with the target user; Merge the compressed bitmaps of all the roles and update the permission bitmap data of the target user; Update the cached character data based on the current character data.

[0011] Secondly, embodiments of the present invention provide a resource access control data processing apparatus, comprising: The first response module is used to respond to a data change request for the target resource and update the resource tree structure of the target resource in the cache based on the content addressing strategy. The second response module is used to update the compressed bitmap associated with the target role in the cache in response to a permission change request for the target role. The compressed bitmap contains the resource identifier of the resource authorized by the target role. The third response module, in response to the target user's permission judgment request for the target resource, reads the cached role data associated with the target user and obtains the current role data based on lazy loading; The permission comparison module is used to compare the current role data with the cached role data to determine the validity of the permissions.

[0012] Thirdly, embodiments of the present invention provide an electronic device, including a processor and a memory, wherein the memory stores a computer program, and the processor, when running the computer program, implements the above-described resource permission data processing method.

[0013] Fourthly, embodiments of the present invention provide a storage medium storing a computer program, which, when run, implements the resource permission data processing method described above.

[0014] The embodiments of the present invention have at least the following beneficial effects: In response to data change requests for target resources, the resource tree structure of the target resource in the cache is updated based on the content addressing strategy, which avoids a full cache update and effectively saves computing and I / O resources. In response to permission changes for target roles, the compressed bitmap associated with the target role in the cache is updated, which avoids a broadcast-style forced cache update to all users associated with the target role. When responding to a permission judgment request from a target user for a target resource, the cached role data associated with the target user is read and the current role data is obtained based on lazy loading, which effectively avoids write amplification and cascading update storms caused by role permission changes, reduces write operation overhead, reduces the risk of cache invalidation avalanche, and helps improve the overall performance of the permission system.

[0015] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0016] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a flowchart illustrating the steps of the resource permission data processing method according to an embodiment of the present invention. Figure 2 This is a schematic block diagram of the resource permission data processing device according to an embodiment of the present invention; Figure 3 This is a schematic block diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0017] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0018] In the description of this invention, "several" means one or more, "multiple" means two or more, "greater than," "less than," "exceeding," etc. are understood to exclude the stated number, and "above," "below," "within," etc. are understood to include the stated number. If "first," "second," etc. are used in the description, they are only for the purpose of distinguishing technical features and should not be construed as indicating or implying relative importance or implicitly indicating the number of indicated technical features or the order of the indicated technical features.

[0019] In modern software systems, the Role-Based Access Control (RBAC) model is widely used because it simplifies access control. This model decouples permissions from users by assigning permissions (such as access and operation permissions for resources like menus and buttons) to roles, and then assigning roles to users.

[0020] Existing technologies for implementing RBAC (Restricted Access Control) systems typically construct one or more complete resource trees in a cache (such as Redis) to support efficient rendering of the front-end interface. Simultaneously, to accelerate the permission verification process, the system also caches the set of permissions possessed by users or roles. However, this common implementation approach suffers from significant performance bottlenecks: Write amplification occurs when a resource in the system changes (e.g., its name is modified, its parent node is moved). To ensure data consistency, the system must query the database again, rebuild the complete resource tree in memory, and then write the serialized large object (resource tree) to the cache. This "single-point update, full reconstruction" pattern results in a significant waste of computational and I / O resources.

[0021] Cascading Update Storm: When a role's permissions change, or a role is assigned to a large number of users, the system needs to update the permission caches of all related users in a cascading fashion. If a role is associated with tens of thousands of users, a single role change can trigger tens of thousands of user cache rebuild operations, forming a "cache update storm." This can lead to high latency, spikes in CPU and I / O load, and severely impact system stability and responsiveness.

[0022] Therefore, there is an urgent need in this field for a new technical solution to effectively address the write amplification and cascading update storm problems caused by data changes in existing access control systems, thereby improving the overall performance and scalability of the system.

[0023] Please refer to Figure 1 This embodiment discloses a resource permission data processing method, including steps S100 to S400. It should be noted that the steps in this embodiment are numbered only for ease of review and understanding, and not to limit the execution order of the steps. The content of each step is described in detail below: S100. In response to the data change request of the target resource, update the resource tree structure of the target resource in the cache based on the content addressing strategy; For example, content addressing refers to the process where a unique identifier (i.e., address or key) for a data object is generated from the object's content using a deterministic hash function. This ensures that the same content always corresponds to the same identifier, and any change to the content will result in a change to the identifier. When a target resource undergoes a data change—for example, an administrator moves a menu resource named "Monthly Report" (the target resource) from its parent node to parent node B via a user interface—in response to the data change request, the following operations are performed: the parent node reference (e.g., parent_id) of the target resource in the metadata store is updated. Then, based on the content addressing strategy, the content hash values ​​of each node on the path from the node corresponding to the target resource to the root node are recursively recalculated from bottom to top, thereby achieving an incremental update of the resource tree. During this process, only the affected path nodes need to have their content hash values ​​recalculated, while other unchanged branches remain unchanged. Since the content addressing strategy only needs to calculate and cache nodes at the tree height level (i.e., the path length from the modified node to the root node), and the computation and I / O cost of the write operation is proportional to the height of the resource tree, the content addressing strategy has lower time complexity than rebuilding the entire resource tree, effectively reducing the computational burden and cache synchronization overhead of the permission system.

[0024] S200. In response to a permission change request for the target role, update the compressed bitmap associated with the target role in the cache. The compressed bitmap contains the resource identifiers of the resources authorized by the target role. For example, a compressed bitmap is created and maintained for at least one target role (such as an administrator, financial manager, or ordinary employee) in the permission system. The compressed bitmap uses a Roaring Bitmap data structure to record all resource permissions authorized by the target role in the form of bit indices. Each resource is identified by a globally unique Resource Identifier (RID), and the resource identifier corresponds one-to-one with the position of a bit in the compressed bitmap. When a permission change event for a target role is detected, the corresponding bit operation is performed on the target role's compressed bitmap according to the resource identifier contained in the permission change event to add or remove the corresponding resource permission. The update operation of the compressed bitmap only applies to the target role itself and does not require modification of the permission cache data of any users associated with the target role, thereby limiting the impact of role permission changes to the role level and avoiding triggering cascading updates to associated users.

[0025] S300: In response to the target user's permission judgment request for the target resource, read the cached role data associated with the target user and obtain the current role data based on lazy loading; For example, when a target user initiates an operation request for a target resource (such as viewing, editing, or triggering), the permission system triggers a permission judgment request for the target user and the target resource. In response to the permission judgment request, cached role data associated with the target user is read from the cache. This cached role data consists of role-related information pre-aggregated and stored in the cache for permission verification, including but not limited to a list of roles bound to the target user and their corresponding permission status identifiers. It should be noted that in this embodiment, the resource tree structure, the role permission compression bitmap, and the user-level cached role data are stored independently in the cache, each with its own independent update strategy and lifecycle.

[0026] In conventional permission systems, changes to the target resource structure (such as resource movement) or target role permissions (such as authorization or revocation) typically trigger cascading updates to the cached role data of all associated users to ensure immediate consistency of the permission view. However, this approach can easily lead to a "cache update storm" in high-concurrency, large-scale user scenarios, resulting in significant write amplification and a surge in system load. Compared to conventional permission systems, resource tree changes and role permission changes in this embodiment do not actively trigger updates to the cached role data of any associated users. Therefore, before performing permission checks, it is necessary to verify whether the user roles in the cache are still valid. This embodiment obtains the current role data based on lazy loading, changing the consistency maintenance of permission status from "synchronization at write time" to "on-demand verification at read time," effectively avoiding large-scale cascading update storms caused by resource changes or role permission changes. This helps reduce cache write pressure and system resource consumption while ensuring the eventual consistency of authentication results.

[0027] S400: Compare the current role data with the cached role data to determine the validity of the permissions.

[0028] For example, after the permissions of a target resource or role change, the changed data is usually persisted to the database. When permission validity verification is required, the latest current role data is read and compared with the cached role data to determine the validity of the permissions.

[0029] Thus, in response to data change requests for target resources, updating the resource tree structure of the target resource in the cache based on the content addressing strategy can avoid a full cache update, effectively saving computation and I / O resources. In response to permission changes for target roles, updating the compressed bitmap associated with the target role in the cache can avoid broadcasting forced cache updates to all users associated with the target role. When responding to permission judgment requests from target users for target resources, reading the cached role data associated with the target user and obtaining the current role data based on lazy loading can effectively avoid write amplification and cascading update storms caused by role permission changes, reduce write operation overhead, reduce the risk of cache invalidation avalanche, and improve the overall performance of the permission system.

[0030] In some application examples, step S100, in response to a data change request for the target resource, updates the resource tree structure of the target resource in the cache based on the content addressing strategy, including: In response to a data change request for the target resource, determine the target node after the target resource has been changed; Identify all parent nodes of the target node along the parent path to the root node as nodes to be updated; The content hash values ​​of the nodes to be updated are recalculated sequentially to incrementally update the hash structure of the resource tree; The root hash value of the global reference is updated to the newly generated content hash value of the root node through a single atomic operation.

[0031] For example, taking the "Monthly Report" menu resource as an example of the target resource, when the target resource moves from parent node A to parent node B, a data change request for the target resource is triggered. In response to this request, the target node after the change is determined. For example, the parent node identifier (parent_id) of the target resource is updated first, and then the target node where the target resource is located and its old and new parent nodes are identified through an asynchronous update event. Starting from the target node, the content hash value is recalculated, and the content hash values ​​of all parent nodes along the parent path of the target node from bottom to top to the root node are recalculated. This achieves incremental update of the hash structure of the resource tree. The root hash value of the globally referenced node is updated to the newly generated content hash value of the root node through an atomic instruction (such as SET system:root new_root_hash), which helps to ensure the consistency of data updates in a distributed high-concurrency environment. In this way, the number of nodes to be updated can be reduced through incremental updates. Compared with the full update of the prior art, this embodiment can significantly reduce the write operation overhead and effectively save computing and I / O resources.

[0032] The above steps involve recalculating the content hash values ​​of the nodes to be updated sequentially to incrementally update the hash structure of the resource tree, including: Retrieve the business attribute data of the node to be updated; Obtain the content hash values ​​of all child nodes of the node to be updated and perform deterministic sorting to obtain a hash set; The business attribute data is combined with the hash set and then subjected to stable serialization to obtain the target data; Perform a hash calculation on the target data to obtain the content hash value.

[0033] For example, resource tree data is typically persisted to a database (such as MySQL). The business attribute data of the node to be updated refers to the latest set of key attributes of the node to be updated under the current database state. Key data includes multiple references to the parent node, resource name, resource type, resource path, and enabled status. The content hash values ​​of all child nodes of the node to be updated are obtained by querying the resource metadata table. Since the storage order of child nodes in the database may be unstable (e.g., insertion order, pagination), deterministic sorting is used to eliminate the uncertainty of the child node order, avoiding differences in content hash calculations caused by non-semantic differences, thus obtaining a hash set containing the content hash value of each node to be updated. The business attribute data of the node to be updated and the hash set are combined into a standardized data structure, and this data structure undergoes stable serialization processing. Stable serialization means that the same logical content always generates the exact same byte sequence, for example, through methods such as JSON canonical form or Protocol Buffers (data description language), to obtain the target data, and then a hash calculation is performed on the target data to obtain the content hash value.

[0034] In some application examples, step S200, in response to a permission change request for a target role, updates the compressed bitmap associated with the target role in the cache, including: In response to a permission change request for the target role, read the compressed bitmap associated with the target role from the cache; Based on the permission change request, update the resource identifier in the compressed bitmap and write the updated compressed bitmap back to the cache.

[0035] For example, in a specific example, when an administrator adds viewing permissions for 10 reports to the target role of "Finance Manager", the backend service of the permission system assigns unique, monotonically increasing and non-reusable resource identifiers to these 10 reports, updates the role-resource relationship table in the database, and triggers a permission change request for the target role. In response to the request, the compressed bitmap associated with the target role of "Finance Manager" is read from the cache, and an "add" operation is performed to add the resource identifiers of the 10 reports to the compressed bitmap. The updated compressed bitmap is then serialized and written back to the cache. This process does not involve any changes to the user data associated with the role of "Finance Manager".

[0036] Alternatively, in another specific application example, when the target resource undergoes data changes (especially a change in the parent node), to ensure proper permission control, the permission system will restore the target resource's permissions to the default "no permissions" state, awaiting the administrator to reassign permissions to each role for the target resource. When the target role's permissions change (e.g., adding new resource permissions or deleting old resource permissions), the compressed bitmap associated with the target role is read from the cache. The compressed bitmap contains the resource identifiers of the resources authorized by the target role. For example, if the target role has access to resource A (recorded as 1) but no access to resource B (recorded as 0), this can be recorded in the compressed bitmap as A:1;B:0. Based on the permission change request, the resource identifiers in the compressed bitmap are updated, for example, A:1;B:0 → A:0;B:1. Then, the updated compressed bitmap is written back to the cache. Because compressed bitmaps have excellent compression ratios and bit operation performance on both sparse and dense integer sets, the storage and merging of large-scale permission sets are efficient and feasible; moreover, permission changes for the target role are independent of any user associated with the target role, so that the cache update of permission changes is completely decoupled from the user cache, thereby avoiding the cache update storm caused by cascading updates in conventional technologies.

[0037] The above step S200, in response to the permission change request for the target role, updates the compressed bitmap associated with the target role in the cache, and further includes: updating the role version identifier of the target role.

[0038] For example, to ensure the reliability of access control, a corresponding role version identifier is maintained for each role. After an update operation occurs in the compressed bitmap associated with the target role, the role version identifier of the target role is updated synchronously. For example, the role version identifier is an integer version number, which is incremented by one with each update, thereby achieving auto-incrementing updates of the role version identifier and ensuring its uniqueness. The role version identifier can be used to identify the role version of the target role in the cache, thereby ensuring the validity of the permission version of the target role in the cache, and to perform verification using the role version identifier to ensure the accuracy of permission judgment in a distributed high-concurrency environment.

[0039] Step S400 above compares the current role data with the cached role data to determine the validity of permissions, including: Retrieve the current set of characters from the current character data and the cached set of characters from the cached character data; Generate the first character hash value based on the current character set, and generate the second character hash value based on the cached character set; The hash values ​​of the first role and the second role are compared to determine the consistency of the roles; When the role consistency indicator is consistent, obtain the current version identifier of each role in the current role set, and obtain the cached version identifier of each role in the cached role set; The current version identifier and cached version identifier of each role are compared to determine the validity of the permissions.

[0040] For example, when a target user is assigned multiple roles (e.g., "financial manager" and "ordinary employee") and initiates an access request to the target resource, the set of roles currently associated with the target user and the role version identifier are first obtained from the current role data, denoted as the current role set and the current version identifier, respectively. The current role set can be represented as an ordered or unordered list of role identifiers, such as ["financial manager", "ordinary employee"].

[0041] Because this embodiment adopts a permission-state decoupled architecture, changes to the resource tree structure or updates to role permissions do not actively trigger a refresh of the user-level cache. Therefore, the user cached role data stored in the cache may be outdated. To verify the validity of the cached role data, the cached role data of the target user is read from the cache. The cached role data includes a set of cached roles and a cache version identifier corresponding to each role. In some implementations, the cached role data may also include a second role hash value pre-calculated based on the set of cached roles.

[0042] Subsequently, a two-level consistency check is performed: First, calculate the hash value of the first role based on the current role set, and calculate the hash value of the second role based on the cached role set; compare the hash value of the first role with the hash value of the second role; if they are inconsistent, it is determined that the user's role binding relationship has changed and the cache is invalid. If the two match, then the current version identifier and cached version identifier of each role are compared item by item; if the current version identifier and cached version identifier of any role do not match (for example, the current version identifier of the "financial manager" role is 10, while the cached version identifier is 9), then it is determined that the user's permission status has expired and the cache is invalid.

[0043] The current version identifier can be obtained synchronously during the acquisition of the current role set, or it can be executed as a separate step later. Similarly, the cached version identifier can be extracted when reading the cached role set, or it can be obtained through a separate query. Through the above two-level consistency verification, the validity of user cached permissions can be determined efficiently and accurately without loading the complete permission bitmap. This avoids blind cache reconstruction caused by changes in role allocation or updates to role permissions, which helps reduce the computational overhead and cache access latency on the authentication path, and at the same time provides triggering conditions for subsequent on-demand permission synthesis.

[0044] Step S400: Compare the current role data with the cached role data to determine the validity of the permissions. This step also includes: If the permission validity is indicated as expired, obtain a compressed bitmap of all roles currently associated with the target user; Merge the compressed bitmaps of all roles and update the permission bitmap data of the target user; Update cached character data based on current character data.

[0045] For example, after determining that the user permission cache has expired, an on-demand permission compositing operation is triggered. Specifically, the compressed bitmaps corresponding to all roles currently associated with the target user are obtained; based on a logical "OR" operation, the compressed bitmaps are merged bit-by-bit to generate the target user's final permission bitmap data; subsequently, the final permission bitmap data is written to the cache, and the user's cached role data is updated synchronously, so that the cached role data includes the current set of roles and the latest permission version identifier corresponding to each role.

[0046] The compressed bitmap employs a data structure that supports efficient bitwise operations, enabling the aggregation of multi-role permissions to be completed in memory with a constant time complexity of O(1). The updated content of the cached role data includes at least: a list of roles currently bound to the user, and the permission version identifier of each role at the time of synthesis, for example, recorded in a version mapping table as {Finance Manager: 10, Ordinary Employee: 5}. After completing permission synthesis and cache update, permission judgment for the target resource is performed based on the final permission bitmap data: if the Resource Identifier (RID) corresponding to the target resource is set (e.g., set to 1) in the final permission bitmap, access is authorized; otherwise, access is denied.

[0047] If the current role data is determined to be consistent with the cached role data during the permission validity verification phase, it indicates that the user's permission status has not changed. The final permission bitmap data in the cache can be directly reused to perform permission judgment without performing any bitmap loading or merging operations.

[0048] In this way, by using an on-demand synthesis mechanism, permission calculation is transformed from "broadcast on write" to "on-demand triggering on read," with the synthesis operation performed only once when the cache expires. Moreover, the synthesis cost is only related to the number of roles associated with a user, and is independent of the total number of users. As a result, not only are large-scale cache cascading updates caused by changes in role permissions avoided, but low-latency response is also ensured in high-frequency authentication scenarios, significantly improving the system's scalability and resource utilization efficiency.

[0049] Please refer to Figure 2 This embodiment provides a resource permission data processing device, including: The first response module 110 is used to respond to a data change request for the target resource and update the resource tree structure where the target resource is located in the cache based on the content addressing strategy. The second response module 120 is used to respond to a permission change request for the target role by updating the compressed bitmap associated with the target role in the cache. The compressed bitmap contains the resource identifier of the resource authorized by the target role. The third response module 130 responds to the target user's permission judgment request for the target resource by reading the cached role data associated with the target user and obtaining the current role data based on lazy loading. The permission comparison module 140 is used to compare the current role data with the cached role data to determine the validity of the permissions.

[0050] The inventive concept of this resource permission data processing device embodiment is the same as that of the resource permission data processing method embodiment described above. Content not covered in this resource permission data processing device embodiment can be referred to in the resource permission data processing method embodiment described above, and will not be repeated here. In response to a data change request for a target resource, the resource tree structure of the target resource in the cache is updated based on the content addressing strategy, avoiding a full cache update and effectively saving computation and I / O resources. In response to a permission change for a target role, the compressed bitmap associated with the target role in the cache is updated, avoiding a broadcast-style forced cache update to all users associated with the target role. When responding to a permission judgment request from a target user for a target resource, the cached role data associated with the target user is read, and the current role data is obtained based on lazy loading. This effectively avoids write amplification and cascading update storms caused by role permission changes, reduces write operation overhead, reduces the risk of cache invalidation avalanche, and helps improve the overall performance of the permission system.

[0051] Please refer to Figure 3This embodiment provides an electronic device, including a processor 210 and a memory 220. The memory 220 stores a computer program, and the processor 210 executes the computer program to implement the resource permission data processing method described above. The specific details of the resource permission data processing method are described above and will not be repeated here. In response to a data change request for a target resource, the resource tree structure of the target resource in the cache is updated based on a content addressing strategy, avoiding a full cache update and effectively saving computational and I / O resources. In response to a permission change for a target role, the compressed bitmap associated with the target role in the cache is updated, avoiding a broadcast-style forced cache update to all users associated with the target role. When responding to a user's permission judgment request for a target resource, the cached role data associated with the target user is read, and the current role data is obtained based on lazy loading. This effectively avoids write amplification and cascading update storms caused by role permission changes, reduces write operation overhead, reduces the risk of cache invalidation avalanche, and helps improve the overall performance of the permission system.

[0052] This embodiment provides a storage medium storing a computer program. When the computer program is run, it implements the resource permission data processing method described above. The specific details of the resource permission data processing method are detailed above and will not be repeated here. In response to a data change request for a target resource, the resource tree structure of the target resource in the cache is updated based on a content addressing strategy. This avoids a full cache update and effectively saves computation and I / O resources. In response to a permission change for a target role, the compressed bitmap associated with the target role in the cache is updated. This avoids a broadcast-style forced cache update to all users associated with the target role. When responding to a user's permission judgment request for a target resource, the cached role data associated with the target user is read, and the current role data is obtained based on lazy loading. This effectively avoids write amplification and cascading update storms caused by role permission changes, reduces write operation overhead, reduces the risk of cache invalidation avalanche, and helps improve the overall performance of the permission system.

[0053] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.

Claims

1. A method for processing resource permission data, characterized in that, include: In response to a data change request for the target resource, update the resource tree structure in the cache containing the target resource based on the content addressing strategy; In response to a permission change request for a target role, update the compressed bitmap associated with the target role in the cache, wherein the compressed bitmap contains the resource identifier of the resource authorized by the target role; In response to a target user's permission request for the target resource, the cached role data associated with the target user is read, and the current role data is obtained based on lazy loading. The validity of the permissions is determined by comparing the current role data with the cached role data.

2. The resource permission data processing method according to claim 1, characterized in that, The step of updating the resource tree structure in the cache containing the target resource in response to a data change request for the target resource, based on a content addressing strategy, includes: In response to a data change request for a target resource, determine the target node after the target resource has been changed; All parent nodes of the target node along the parent path to the root node are identified as nodes to be updated. The content hash values ​​of the nodes to be updated are recalculated sequentially to incrementally update the hash structure of the resource tree; The root hash value of the globally referenced node is updated to the newly generated content hash value of the root node through a single atomic operation.

3. The resource permission data processing method according to claim 2, characterized in that, The step of recalculating the content hash values ​​of the nodes to be updated in turn to incrementally update the hash structure of the resource tree includes: Obtain the business attribute data of the node to be updated; Obtain the content hash values ​​of all child nodes of the node to be updated and perform deterministic sorting to obtain a hash set; The business attribute data is combined with the hash set and subjected to stable serialization processing to obtain the target data; The target data is hashed to obtain the content hash value.

4. The resource permission data processing method according to claim 1, characterized in that, The step of updating the compressed bitmap associated with the target role in the cache in response to a permission change request for the target role includes: In response to a permission change request for a target role, read the compressed bitmap associated with the target role from the cache; Based on the permission change request, update the resource identifier in the compressed bitmap and write the updated compressed bitmap back to the cache.

5. The resource permission data processing method according to claim 1 or 4, characterized in that, The step of updating the compressed bitmap associated with the target role in the cache in response to a permission change request for the target role further includes: Update the character version identifier of the target character.

6. The resource permission data processing method according to claim 5, characterized in that, The step of comparing the current role data and the cached role data to determine the validity of permissions includes: Obtain the current character set from the current character data and the cached character set from the cached character data; Generate a first character hash value based on the current character set, and generate a second character hash value based on the cached character set; The hash values ​​of the first role and the second role are compared to determine role consistency; When the role consistency indicator is consistent, obtain the current version identifier of each role in the current role set, and obtain the cached version identifier of each role in the cached role set; The current version identifier and the cached version identifier of each role are compared to determine the validity of the permissions.

7. The resource access control data processing method according to any one of claims 1 to 4 or 6, characterized in that, The step of comparing the current role data and the cached role data to determine the validity of the permissions also includes: If the permission validity is indicated as expired, obtain a compressed bitmap of all roles currently associated with the target user; Merge the compressed bitmaps of all the roles and update the permission bitmap data of the target user; Update the cached character data based on the current character data.

8. A resource access control data processing device, characterized in that, include: The first response module is used to respond to a data change request for the target resource and update the resource tree structure of the target resource in the cache based on the content addressing strategy. The second response module is used to update the compressed bitmap associated with the target role in the cache in response to a permission change request for the target role. The compressed bitmap contains the resource identifier of the resource authorized by the target role. The third response module is used to respond to the target user's permission judgment request for the target resource, read the cached role data associated with the target user, and obtain the current role data based on lazy loading. The permission comparison module is used to compare the current role data with the cached role data to determine the validity of the permissions.

9. An electronic device comprising a processor and a memory, wherein the memory stores a computer program, characterized in that, When the processor runs the computer program, it is used to implement the resource permission data processing method as described in any one of claims 1 to 7.

10. A storage medium storing a computer program, characterized in that, When a computer program is run, it implements the resource permission data processing method as described in any one of claims 1 to 7.

Images