Method and device for managing authority

Abstract

The present invention discloses a method and device for managing permissions, and relates to the field of computer technology. A specific implementation of the method includes: an instance in a cluster responds to a user's request, determines whether the user's permission information exists in the local cache of the instance; if the user's permission information exists in the local cache: obtain the user's permission information from the local cache; if the user's permission information does not exist in the local cache: obtain the user's permission information from a permission database, and update the local cache using the permission information. This implementation reduces the resource consumption of the remote cache center, improves the utilization rate of local resources and speeds up the response time.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a management method and device. Background Art

[0002] Existing cluster systems, such as content management systems (CMS), store user data in databases and use caches such as Redis or Memcached to establish corresponding remote cache centers. Specifically, databases such as MySQL are used to establish user tables, menu tables, role tables, user-role relationship tables, menu-role relationship tables, etc. When a user needs to log in to the system, the corresponding role and menu information is queried in the database based on the user's login information, and a Redis or Memcached cache is established. Every time a user requests permission, the permission data of the user is pulled from cache centers such as Redis.

[0003] In the process of implementing the present invention, the inventors found that there are at least the following problems in the prior art:

[0004] Each permission request from a user must be queried in the cache center. The permission authentication performance depends on the network quality, which increases network consumption. At the same time, the local performance of the instances in the cluster is not fully utilized, and a large amount of user permission information cache wastes precious Redis resources. When a remote cache center such as Redis fails, the user's permission request cannot be processed, and the system performance drops sharply. Summary of the invention

[0005] In view of this, an embodiment of the present invention provides a method for managing permissions, which can utilize local cache. Each time a user requests permission authentication, the local cache is accessed instead of reading data from a remote distributed cache center, thereby being more efficient and saving network resources. It solves problems such as high network latency and excessive cache space usage. In addition, permission authentication is not strongly dependent on network quality. On the premise of ensuring local performance, it fully utilizes local performance and memory to reduce Redis resource consumption. When a cache center such as Redis fails, the local cache can be used to implement permission authentication for the user without significantly reducing system performance.

[0006] To achieve the above object, according to one aspect of an embodiment of the present invention, a method for managing permissions is provided, which is characterized by comprising:

[0007] An instance in the cluster responds to a user's request and determines whether permission information of the user exists in a local cache of the instance;

[0008] In the case where the user's permission information exists in the local cache:

[0009] Obtaining the permission information of the user from the local cache;

[0010] When the permission information of the user does not exist in the local cache:

[0011] obtaining the permission information of the user from a permission database, and

[0012] Updating the local cache using the permission information;

[0013] The user, the local cache, and the permission database are associated with the instance.

[0014] According to one aspect of an embodiment of the present invention, a method for managing permissions is provided, wherein, when the permission information of the user does not exist in the local cache, the method further comprises:

[0015] Before obtaining the authority information of the user from the authority database, it is determined that the user exists in the authority filter.

[0016] According to one aspect of an embodiment of the present invention, a method for managing permissions is provided, wherein the method further comprises:

[0017] When the permission information of the user changes:

[0018] Updating the local cache by the instance;

[0019] Updating the permission database by the instance;

[0020] The instance sends a permission change message to other instances; and

[0021] After receiving the permission change message, the other instance updates the corresponding local cache.

[0022] According to one aspect of an embodiment of the present invention, a method for managing permissions is provided, wherein the instance and the other instances belong to the same cluster.

[0023] According to one aspect of an embodiment of the present invention, a method for managing permissions is provided, characterized in that it also includes:

[0024] Before the instance sends a permission change message to other instances, information of the other instances is obtained from a registration center.

[0025] According to one aspect of an embodiment of the present invention, a method for managing permissions is provided, characterized in that it also includes:

[0026] Before the instance sends a permission change message to other instances, information of the other instances is obtained from the local cache.

[0027] According to one aspect of an embodiment of the present invention, a method for managing permissions is provided, characterized in that it also includes:

[0028] The instance obtains information of all instances in the cluster from the registration center at a predetermined time interval; and

[0029] The local cache is updated using the obtained information of all instances.

[0030] According to one aspect of an embodiment of the present invention, a method for managing permissions is provided, wherein the information of the other instances includes IP information of the other instances.

[0031] According to one aspect of an embodiment of the present invention, a method for managing permissions is provided, wherein updating the corresponding local cache includes clearing the corresponding local cache.

[0032] According to one aspect of an embodiment of the present invention, a method for managing permissions is provided, wherein the permission filter comprises a Bloom filter.

[0033] According to one aspect of an embodiment of the present invention, a method for managing permissions is provided, wherein the Bloom filter is implemented using Redis.

[0034] According to one aspect of an embodiment of the present invention, a method for managing permissions is provided, wherein the registration center is implemented using Redis.

[0035] According to one aspect of an embodiment of the present invention, there is provided a device for managing permissions, characterized in that it includes:

[0036] Determination module: used for determining whether the permission information of the user exists in the local cache of the instance in response to the user's request;

[0037] an acquisition module: configured to obtain the permission information of the user from the local cache if the permission information of the user exists in the local cache; and to obtain the permission information of the user from a permission database if the permission information of the user does not exist in the local cache; and

[0038] Update module: used to update the local cache using the permission information;

[0039] The user, the local cache, and the permission database are associated with the instance.

[0040] According to one aspect of an embodiment of the present invention, there is provided a device for managing permissions, characterized in that it further comprises:

[0041] Sending module: used to send permission change messages to other instances; and

[0042] Receiving module: used to receive permission change messages sent by other instances; and

[0043] The acquisition module is also used to pull information of other instances in the cluster from the registration center;

[0044] The updating module is further used to update the local cache and the permission database when the permission information of the user changes, and to update the corresponding local cache after receiving a permission change message sent by other instances.

[0045] One embodiment of the above invention has the following advantages or beneficial effects: because local cache technology is adopted, the local cache is accessed instead of the remote cache center each time the user requests permission authentication, thus overcoming the technical problems of the remote cache center's high resource consumption, heavy burden and dependence on network quality, thereby achieving the technical effect of efficient use of network resources and accelerated response.

[0046] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with the specific implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0048] Figure 1 is a schematic diagram of the main process of the method for managing permissions according to an embodiment of the present invention;

[0049] Figure 2 is a schematic diagram of the main process of a method for obtaining user authority information according to an embodiment of the present invention;

[0050] Figure 3A is a schematic diagram of the main process of the synchronization method when starting an instance according to an embodiment of the present invention;

[0051] Figure 3B is a schematic diagram of the main process of the synchronization method for user authority change according to an embodiment of the present invention;

[0052] Figure 4 is a schematic diagram of main modules of an apparatus for managing permissions according to an embodiment of the present invention;

[0053] Figure 5 is an exemplary system architecture diagram to which embodiments of the present invention may be applied;

[0054] Figure 6 It is a schematic diagram of the structure of a computer system of an example device or server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0055] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0056] Figure 1 is a flowchart of a method for authority authentication according to an embodiment of the present invention. Figure 1 As shown, the method for authority authentication includes steps S101, S102, and S103.

[0057] Step S101: In response to a user's request, the instance determines whether the user's permission information exists in the local cache of the instance.

[0058] Existing cluster systems often establish distributed remote cache centers for multiple instances in the cluster. An instance is a machine in the cluster, such as a server or a virtual machine. When a user requests to log in to a distributed system (such as a CMS system), the instance that processes the user's request can be any instance in the cluster. The instance needs to access the remote cache center to query the user's permissions. Only if the user has the corresponding permissions can he log in to the distributed system. In this implementation, as the number of instances in the cluster increases, the number of logged-in users increases, and the remote cache center needs to store the permission information of a large number of users and process the query requests of a large number of instances, which places a heavy burden on the remote cache center.

[0059] In an embodiment of the present invention, upon receiving a user request requiring authorization such as a login request, a query request, or a payment request, the instance for processing user requests first queries its own local cache to determine whether the user's authorization information exists in the local cache.

[0060] In one embodiment, the local cache is implemented using a hash table. In the hash table, a specific entry represents the information of a specific user. The key of the entry is used to identify the user, for example, it can be the identifier of the user, the user name of the user, etc. In one embodiment, the local cache is implemented using Java. In this case, the value of the entry can be implemented using, for example, a soft reference object, which encapsulates specific user information that needs to be cached, including user permissions, user passwords, user access records, etc. When the Java Virtual Machine (JVM) has sufficient memory, the cache entry corresponding to the user will not be recycled, and when the memory is tight, the cache entry corresponding to the user will be automatically recycled by the JVM. When the cache entry is automatically recycled by the JVM, the local cache entry of the user does not exist, that is, the permission information of the user does not exist in the local cache.

[0061] Step S102: when the permission information of the user exists in the local cache: obtaining the permission information of the user from the local cache.

[0062] In this step, the instance processing the user request determines that the user's permission information exists in the local cache, and reads the user's permission information. Continuing with the above example, a hash table is used to implement local caching. In this example, the key in the cache hash table is searched based on keywords such as the user's identifier, and the value of the entry is read using the key, and the user information is parsed from the value. In an implementation method of implementing local caching in Java, the soft reference object of the entry is parsed, and the permission information in the soft reference object is obtained.

[0063] Step S103: when the permission information of the user does not exist in the local cache: obtaining the permission information of the user from a permission database.

[0064] Continuing with the above example, if the user information is parsed to be empty, it means that there is no local cache of the user's permission information. In the implementation method of local caching using Java, if the user information is parsed to be empty, it means that in the local cache, the soft reference object representing the user is recycled by the JVM, or the local cache of the user has not been established, or the user does not exist in the system (that is, the user does not have any permissions to the system). At this time, the instance processing the user request queries the permission database, and if the user's rights exist in the permission database, the user's permission information is obtained in the permission database.

[0065] If the user does not exist in the system, querying the database is a waste of resources and delays the response time. To further improve efficiency, a filter can be used to filter out users that do not actually exist before querying the permission database. In one embodiment, the filter can be implemented using a Bloom filter. Figure 2 Detailed instructions for the steps shown.

[0066] Step S104: Update the local cache using the permission information.

[0067] In step S103, the instance of the user request is processed to query the permission database, and the permission information of the user is obtained in the permission database and stored in the local cache. In the implementation of the hash table implemented in Java, the obtained user permission information is encapsulated into a soft reference object, and the key representing the user is found in the hash table representing the local cache, and the soft reference object is stored in the value corresponding to the entry to update the local cache. The permission database can be implemented by a database such as MySQL, for example.

[0068] It should be noted that the above examples of implementing the local cache and the authority database are only examples, and the embodiments of the present invention may also be implemented in any other manner.

[0069] Figure 2 FIG. 1 is a flow chart of a method for obtaining user authority information according to an embodiment of the present invention. Figure 2 As shown, the method for obtaining user authority information includes steps S201, S202, S203 and S204.

[0070] Step S201: Query the filter to see whether the user exists.

[0071] As described above, after determining in step S101 that the user's permission information does not exist in the local cache of the instance, step S201 is entered. The user's permission information does not exist in the local cache, which is reflected in the local cache hash table, that is, there is no entry corresponding to the user in the hash table, or there is no permission value in the entry corresponding to the user. In the implementation method of local caching in Java, there is no entry corresponding to the user in the local cache hash table, which may be because the user does not exist, the user's cache has expired, the cache entry is automatically recycled by the JVM, or the cache information of the user has not yet been established; there is no permission value in the entry corresponding to the user, which may be because the permission information for the user has not yet been recorded in the local cache.

[0072] It should be noted that if the user does not exist in the system, querying the database cannot obtain the user's permission information. Directly querying the database is also a waste of resources and delays the response. Specifically, different users may have different permissions such as browsing permissions, access permissions, read and write permissions, payment permissions, etc. Preferably, you can use a filter to perform pre-filtering first, and directly filter out users without any permissions, rather than directly querying the permission database.

[0073] In one implementation, the filter may be implemented using a Bloom filter, which is configured according to requirements, and generally has an error control of, for example, 0.0001. The Bloom filter may be implemented using, for example, Redis, or any other method.

[0074] Step S202: Obtain the authority information of the user from a authority database.

[0075] Filters such as Bloom filters will filter out most of the users who do not have permissions in the database, which is equivalent to a fast failure mechanism. If a user does not have the corresponding permissions, the Bloom filter can be used to quickly determine without querying the database. For users who have permissions but no local cache, a local cache can be established for them after a database query, and the permission verification speed will be greatly improved. The permission database can be implemented in MySQL, for example, or in any other way.

[0076] After filtering in step S201, it can be determined that the user exists, which greatly improves the success rate of querying the database to obtain the authority information. In this step, the authority database is queried to obtain the authority information of the user.

[0077] Step S203: Update the local cache using the permission information.

[0078] In step S203, the instance processing the user request updates the obtained user permission information to the local cache. In an implementation of the hash table implemented in Java, the obtained user permission information is encapsulated into a soft reference object, a key representing the user is found in the hash table representing the local cache, and the soft reference object is stored in the value corresponding to the entry to update the local cache.

[0079] It should be noted that the above examples of implementing the local cache and the authority database are only examples, and the embodiments of the present invention may also be implemented in any other manner.

[0080] Figure 3A and Figure 3B3 is a flow chart of a method for instance synchronization according to an embodiment of the present invention. As shown in FIG3 , the method for instance synchronization includes steps S301 , S302 , S303 and S204 .

[0081] Figure 3A This is a flowchart of the synchronization method when the instance is started.

[0082] like Figure 3A As shown, when each instance in the cluster is started, it registers its own information with the registration center, and at the same time pulls the information of other registered instances and caches it locally. The instance information may include IP address, MAC address, instance type, registration time information, etc. Preferably, the instance can only register its own IP address information with the registration center, and also only pull the IP address information of other instances, and store it locally as the IP list of the cluster. In one embodiment, the IP list of the cluster can be stored in a local cache. When the registration center is unavailable, the instance can obtain the IP information of other instances in the cluster from the local IP list to avoid communication failures.

[0083] In one embodiment, the instance maintains the IP list of the entire cluster locally and updates the list at a predetermined time interval, which may be, for example, 1 minute, 5 minutes, 10 minutes, etc.

[0084] In one embodiment, the registration center can be implemented using zookeeper or Redis. Take Redis as an example: Redis sets a common key for recording IP information, and the type is, for example, a collection type. Each instance in the cluster pulls all the IP information in the collection when it starts; or pulls all the IP information in the collection at a predetermined time interval after startup. If the instance finds that there is no IP information of its own in the collection, it writes its own IP address to the collection. At the same time, the instance maintains a list of IP information corresponding to the collection in the local cache to prevent the IP information of other instances in the cluster from being obtained when Redis is unavailable, which can also save resources.

[0085] Figure 3B This is a flowchart of the synchronization method for changing user permissions.

[0086] Step S301: the user's authority information changes.

[0087] The previous article discussed the steps to obtain user access rights to the system when the user needs to log in. Different users can have different access rights to the system, such as browsing only rights, the ability to read and write documents in the system, administrator rights, etc.

[0088] In one embodiment, the permissions of user A in the cluster have changed. The permission change of user A can be triggered by the system administrator or user A. User A and the administrator may log in to the system through different terminals respectively, and randomly access different instances in the background. Therefore, the instance that processes the login of user A may be different from the instance that processes the login of the administrator. In the case where the administrator triggers the permission change of user A, instance 1 accessed by the administrator is used as the permission change instance to initiate the permission synchronization process. In the case where user A triggers the permission change of user A, instance 2 accessed by user A is used as the permission change instance to initiate the permission synchronization process.

[0089] Step S302: The instance updates the local cache and permission database

[0090] After receiving the instruction of the permission change of user A, the instance that initiates the permission synchronization process first updates its local cache, for example, by deleting and rebuilding the cache entry corresponding to user A, modifying the permission information in the cache entry corresponding to user A, etc., to update the permissions of user A in the local cache.

[0091] Subsequently, the instance that initiated the permission synchronization process triggers the modification of the permission database, and updates the permission information of user A in the database to the latest permission.

[0092] It should be noted that the order of updating the local cache and updating the authority database can be interchanged and is not limited to the order described in this embodiment.

[0093] Step S303: Send permission change message to other instances in the cluster

[0094] Preferably, the instance that initiates the permission synchronization process pulls information about other instances in the cluster from the registration center, such as IP address information. Alternatively, if the registration center is unavailable, or in order to obtain a faster response time, the instance can directly use the cluster instance IP list cached in the local cache. After obtaining the IP information of other instances in the cluster, instance A uses the IP addresses of other instances to send messages about the permission change of user A to other instances.

[0095] In one embodiment, the instance that initiates the permission synchronization process can initiate a thread to send a permission change message to the IP address of each instance in the cluster. The message sending can be implemented, for example, using an HTTP request or a TCP request. In another embodiment, the message synchronization mechanism can also be implemented through the broadcast function of a message queue (MQ). The instance that initiates the permission synchronization process sends a permission change broadcast to all instances in the cluster. After all instances hear the permission change message, they actively update the local cache to achieve the effect of timely cache update.

[0096] Step S304: Other instances in the cluster update their local caches.

[0097] After receiving the permission change message from user A, other instances in the cluster update their local caches with the new permission information of user A. Updating one's own local cache can be achieved by clearing the entire local cache, or by updating only the entry corresponding to user A. After the local caches of all instances in the cluster are updated, the permission information of the entire cluster is synchronized. The message synchronization solution solves the problem that the local cache of each instance cannot be updated in time. It can promptly and effectively notify each instance to update the local cache, ensuring that changes in user permissions can take effect in a timely manner and avoiding delays in effectiveness caused by cache problems.

[0098] Figure 4 is a schematic diagram of the main modules of the apparatus for managing permissions according to an embodiment of the present invention, such as Figure 4 As shown, the apparatus for managing permissions includes modules 401 , 402 , 403 , 404 and 405 .

[0099] Module 401: a determination module, configured to determine, in response to a user's request, whether the permission information of the user exists in the local cache of an instance in the cluster;

[0100] Module 402: an acquisition module, used to obtain the permission information of the user from the local cache if the permission information of the user exists in the local cache; and to obtain the permission information of the user from the permission database if the permission information of the user does not exist in the local cache; and to pull information of other instances in the cluster from the registration center for communication between instances in the cluster.

[0101] Module 403: An updating module, configured to update the local cache using the permission information; and to update the local cache and the permission database when the permission information of the user changes.

[0102] Module 404: a sending module, used to send communication messages between clusters such as permission change messages to other instances; and

[0103] Module 405: a receiving module, used for communication between instances in the cluster, receiving messages from other instances and messages from any other instances, such as receiving permission change messages sent by other instances, for updating the corresponding local cache.

[0104] Figure 5 An exemplary system architecture 500 is shown to which the method for managing permissions or the apparatus for managing permissions according to an embodiment of the present invention can be applied.

[0105] like Figure 5 As shown, the system architecture 500 may include terminal devices 501, 502, 503, a network 504, and servers 505, 506, 507 in a cluster. The network 504 is used to provide a medium for communication links between the terminal devices 501, 502, 503 and the server cluster. The network 504 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0106] Users can use terminal devices 501, 502, 503 to interact with server 505 through network 504 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 501, 502, 503, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only as examples).

[0107] The terminal devices 501 , 502 , and 503 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, and the like.

[0108] The server 505 may be a server that provides various services, such as a backend management server (for example only) that provides support for shopping websites browsed by users using terminal devices 501, 502, and 503. The backend management server may analyze and process the received data such as login requests, and feed back the processing results (such as target push information, product information - for example only) to the terminal device. The server cluster includes, for example, server instances 505, 506, and 507.

[0109] It should be noted that the management authority method provided in the embodiment of the present invention is generally executed by a server in a cluster, such as instance 506 in the cluster. Accordingly, the management authority device is generally set in a server in the cluster, such as instance 506 in the cluster.

[0110] It should be understood that Figure 5 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to the implementation requirements.

[0111] Reference below Figure 6 , which shows a schematic diagram of the structure of a computer system 600 of a terminal device suitable for implementing an embodiment of the present invention. Figure 6 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0112] like Figure 6As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage part 608 into a random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the system 600 are also stored. The CPU 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0113] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed, so that a computer program read therefrom is installed into the storage section 608 as needed.

[0114] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 609, and / or installed from the removable medium 611. When the computer program is executed by the central processing unit (CPU) 601, the above-mentioned functions defined in the system of the present invention are executed.

[0115] It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0116] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0117] The modules involved in the embodiments of the present invention may be implemented in software or hardware. The modules described may also be set in a processor. For example, they may be described as follows: a processor includes a sending module, an obtaining module, a determining module, an updating module, and a receiving module. The names of these units do not, in some cases, constitute limitations on the module itself. For example, the sending module may also be described as a "module for sending permission change messages to other instances in the cluster."

[0118] As another aspect, the present invention further provides a computer-readable medium, which may be included in the device described in the above embodiment; or may exist independently without being assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device includes:

[0119] An instance in the cluster responds to a user's request and determines whether permission information of the user exists in a local cache of the instance;

[0120] In the case where the user's permission information exists in the local cache:

[0121] Obtaining the permission information of the user from the local cache;

[0122] When the permission information of the user does not exist in the local cache:

[0123] obtaining the permission information of the user from a permission database, and

[0124] Updating the local cache using the permission information;

[0125] The user, the local cache, and the permission database are associated with the instance.

[0126] In the case that the authority information of the user does not exist in the local cache, before obtaining the authority information of the user from the authority database, it is determined that the user exists in the authority filter.

[0127] When the permission information of the user changes:

[0128] Updating the local cache by the instance;

[0129] Updating the permission database by the instance;

[0130] The instance sends a permission change message to other instances; and

[0131] After receiving the permission change message, the other instance updates the corresponding local cache.

[0132] Before the instance sends a permission change message to other instances, the information of the other instances is obtained from a registration center or from the local cache.

[0133] The instance obtains information of all instances in the cluster from the registration center at a predetermined time interval; and updates the local cache using the obtained information of all instances.

[0134] According to the technical solution of the embodiment of the present invention, it is possible to utilize local cache, and access local cache instead of remote cache center each time the user requests permission authentication, thereby being more efficient and saving network resources. In addition, permission authentication is not strongly dependent on network quality. On the premise of ensuring local performance, it fully utilizes local performance and memory to reduce Redis resource consumption. When a cache center such as Redis fails, local cache can be used to implement permission authentication for users without significantly reducing system performance.

[0135] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A method for managing permissions, characterized in that: include: An instance in the cluster responds to a user's request and determines whether permission information of the user exists in a local cache of the instance; The request represents a request to be authenticated; In the case where the user's permission information exists in the local cache: Obtaining the permission information of the user from the local cache; When the permission information of the user does not exist in the local cache: obtaining the permission information of the user from a permission database, and Updating the local cache using the permission information; wherein the user, the local cache, and the permission database are associated with the instance; When the permission information of the user changes: Updating the local cache by the instance; Updating the permission database by the instance; The instance sends a permission change message to other instances; and After receiving the permission change message, the other instance updates the corresponding local cache; The instance obtains information of all instances in the cluster from the registration center when it is started or obtains information of all instances in the cluster from the registration center at predetermined time intervals after it is started; and updates the local cache using the obtained information of all instances.

2. The method according to claim 1, characterized in that In the case that the permission information of the user does not exist in the local cache, the method further includes: Before obtaining the authority information of the user from the authority database, it is determined that the user exists in the authority filter.

3. The method according to claim 1, characterized in that The instance and the other instances belong to the same cluster.

4. The method according to claim 1, characterized in that: Also includes: Before the instance sends a permission change message to other instances, information of the other instances is obtained from a registration center or the local cache.

5. The method according to claim 1, characterized in that The information of the other instances includes IP information of the other instances.

6. The method according to claim 1, characterized in that The updating of the corresponding local cache includes clearing the corresponding local cache.

7. A device for managing permissions, characterized in that: include: Determination module: used to determine whether the user's permission information exists in the local cache of the instance in the cluster in response to the user's request; The request represents a request to be authenticated; Acquisition module: used to obtain the permission information of the user from the local cache if the permission information of the user exists in the local cache; and to obtain the permission information of the user from the permission database if the permission information of the user does not exist in the local cache; obtain the information of all instances in the cluster from the registration center when the instance is started or obtain the information of all instances in the cluster from the registration center at a predetermined time interval after the instance is started; as well as Update module: used to update the local cache using the permission information; update the local cache using the information obtained from the instance; wherein the user, the local cache, and the permission database are associated with the instance; Sending module: used to send permission change messages to other instances; as well as The updating module is further used to update the local cache and the permission database when the permission information of the user changes, and to update the corresponding local cache after receiving a permission change message sent by other instances.

8. The device according to claim 7, characterized in that Also includes: Receiving module: used to receive permission change messages sent by other instances; And the obtaining module is also used to pull information of other instances in the cluster from the registration center.

9. An electronic device for managing permissions, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 6.

10. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images