A Redis multi-tenant management method, device and server

Abstract

This invention discloses a Redis multi-tenant management method, apparatus, and server. The method includes: obtaining configuration information of a first application, the configuration information including additional information and a listening port, wherein the additional information is unique for different applications; connecting to the Redis node corresponding to the first application based on the configuration information and listening on the listening port, the Redis node operating in cluster mode; obtaining a first instruction from the listening port, the first instruction being an instruction to access the Redis node; adding the additional information to the first instruction; and sending the first instruction with the added additional information to the Redis node. This solution, through a proxy, configures different additional information for different applications and adds corresponding additional information to the access instructions of each application, ensuring that data from different applications in the Redis cluster can be clearly identified based on the added information, without affecting each other.

Description

Technical Field

[0001] This invention relates to the field of Internet technology, and more specifically, to a Redis multi-tenant management method, apparatus, and server. Background Technology

[0002] With the revolutionary development of the Internet, mobile Internet, and mobile communication technologies, caching frequently accessed data using in-memory databases can significantly improve data read speed, system scalability, and overall system capacity. Redis, due to its rich data structures, extremely fast speed, and comprehensive functionality, has become the most widely used in-memory database.

[0003] In the early stages of internet company development, many companies only had virtual machines, not containers. However, many business scenarios required Redis to accelerate performance and leverage its distributed locks to solve concurrency and security issues. Redis clusters are divided into two types: independent clusters, where only one application resides in a single cluster, and mixed clusters, where multiple applications share a single cluster.

[0004] The minimum configuration for a virtual machine is 2 cores and 4GB of RAM. Furthermore, a single Redis cluster in cluster mode requires at least 3 servers, which is extremely wasteful of resources for low-traffic clusters. Using independent clusters for all clusters would not only waste resources but also incur significant operational costs. In a virtual environment, cluster creation, consumption, scaling up, scaling down, and disaster recovery all rely on manual maintenance, and the workload is directly proportional to the number of clusters. Compared to independent clusters, mixed-distribution clusters offer much higher resource utilization, but different applications may interfere with each other, and there is a risk of duplicate cache keys across different applications. Summary of the Invention

[0005] In view of the above, the present invention provides the following technical solution:

[0006] A Redis multi-tenancy management method includes:

[0007] The Redis proxy obtains the configuration information of the first application, which includes additional information and listening port. The additional information of different applications is unique.

[0008] Based on the configuration information, connect to the Redis node corresponding to the first application and listen on the listening port. The Redis node is in cluster mode.

[0009] The first instruction from the first application is obtained from the listening port; the first instruction is an instruction to access the Redis node.

[0010] Add the additional information to the first instruction;

[0011] The first instruction, with added information, is sent to the Redis node.

[0012] Optionally, obtaining the configuration information of the first application includes:

[0013] Based on the basic information of the first application, the configuration information of the first application is retrieved. The basic information includes the application key of the application identifier, and the configuration information is the information determined in advance when applying for a Redis node for the first application in the management backend.

[0014] Optionally, if the configuration information includes a blacklist storing the names of prohibited commands, then before sending the first command with added information to the Redis node, the following steps are also included:

[0015] Determine whether the first instruction with added information belongs to the blacklist;

[0016] If it does not belong to the category, proceed to the step of sending the first instruction with added information to the Redis node.

[0017] Optionally, it also includes:

[0018] If the first instruction is on the blacklist, a notification message prohibiting the first instruction is returned.

[0019] Optionally, it also includes:

[0020] The Redis proxy periodically obtains an updated blacklist.

[0021] Optionally, the updated blacklist is determined by analyzing and locating the problem after monitoring the Redis cluster to confirm that the alarm conditions are met, and the blacklist is determined to be caused by a surge in application traffic due to large keys or hot keys.

[0022] Optionally, the periodic acquisition of updated blacklists includes:

[0023] The list of prohibited commands is periodically updated from the management backend.

[0024] The additional information is added to all instruction names in the prohibited instruction list to form a blacklist.

[0025] Optionally, after sending the first instruction with added additional information to the Redis node, the method further includes:

[0026] Receive the response result of the first instruction from the Redis node and return the response result.

[0027] This application also discloses a Redis multi-tenant management device, including:

[0028] The configuration acquisition module is used to obtain the configuration information of the first application. The configuration information includes additional information and listening port. The additional information of different applications is unique.

[0029] The basic preparation module is used to connect to the Redis node corresponding to the first application based on the configuration information and listen to the listening port. The Redis node is in cluster mode.

[0030] The instruction acquisition module is used to acquire a first instruction from the first application from the listening port, wherein the first instruction is an instruction to access the Redis node;

[0031] An information adding module is used to add the additional information to the first instruction;

[0032] The instruction forwarding module is used to send the first instruction with additional information to the Redis node.

[0033] Furthermore, this application also discloses a server, comprising:

[0034] processor;

[0035] Memory for storing the executable instructions of the processor;

[0036] The executable instructions include: obtaining configuration information of a first application, the configuration information including additional information and a listening port, wherein the additional information of different applications is unique; connecting to the Redis node corresponding to the first application based on the configuration information and listening to the listening port, wherein the Redis node operates in cluster mode; obtaining a first instruction of the first application from the listening port, the first instruction being an instruction to access the Redis node; adding the additional information to the first instruction; and sending the first instruction with the added additional information to the Redis node.

[0037] As can be seen from the above technical solution, the present invention discloses a Redis multi-tenant management method, device, and server. The method includes: obtaining configuration information of a first application, wherein the configuration information includes additional information and a listening port, and the additional information of different applications is unique; connecting to the Redis node corresponding to the first application based on the configuration information and listening to the listening port, wherein the working mode of the Redis node is cluster mode; obtaining a first instruction of the first application from the listening port, wherein the first instruction is an instruction to access the Redis node; adding the additional information to the first instruction; and sending the first instruction with the added additional information to the Redis node. The above solution, through a proxy, configures different additional information for different applications and adds corresponding additional information to the access instructions of each application, ensuring that the data of different applications in the Redis cluster can be clearly identified based on the added information and do not affect each other; effectively reducing the cost of Redis clusters, improving production efficiency, and enhancing service stability. Attached Figure Description

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

[0039] Figure 1 This is a flowchart of a Redis multi-tenant management method disclosed in an embodiment of the present invention;

[0040] Figure 2 A flowchart illustrating another Redis multi-tenant management method disclosed in an embodiment of the present invention;

[0041] Figure 3 This is a schematic diagram of the environment structure of the Redis cluster system disclosed in an embodiment of the present invention;

[0042] Figure 4 This is a schematic diagram illustrating the timing of the implementation of the Redis multi-tenant management method disclosed in an embodiment of the present invention;

[0043] Figure 5 This is a schematic diagram of the structure of a Redis multi-tenant management device disclosed in an embodiment of the present invention;

[0044] Figure 6 This is a schematic diagram of the structure of a server disclosed in an embodiment of this application. Detailed Implementation

[0045] For the sake of clarity and citation, the explanations, abbreviations, or acronyms used in the following text are summarized below:

[0046] Redis: short for Remote Dictionary Server, is an open-source, ANSI C-written, network-enabled, in-memory or persistent, log-structured, key-value database that provides APIs for multiple languages.

[0047] Redis Cluster: Redis Cluster is a decentralized cluster where each node maintains connections with other nodes to exchange information. Nodes form a cluster using the `cluster meet` command. The `meet` command allows two nodes to handshake and then exchange information via the gossip protocol.

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

[0049] Figure 1 This is a flowchart illustrating a Redis multi-tenant management method disclosed in an embodiment of the present invention. See also... Figure 1 As shown, Redis multi-tenancy management methods can include:

[0050] Step 101: The Redis proxy obtains the configuration information of the first application. The configuration information includes additional information and listening port. The additional information of different applications is unique.

[0051] The method described in this embodiment can be implemented using a Redis proxy configured in the Redis cluster. During implementation, the Redis proxy first obtains the configuration information of the first application, determines its data transmission path, and intercepts commands accessing the Redis cluster within that path, processing them accordingly. This allows data between different tenants (applications) in the Redis cluster to be easily identified, preventing mutual interference. Details will be provided later and will not be elaborated upon here.

[0052] The Redis proxy can be configured independently outside the Redis cluster or within the application server of the Redis cluster; this application does not restrict this. The Redis proxy, through processing on the Redis cluster side, enables the data of different tenants within the Redis cluster to be distinguished and identified. This eliminates the need to modify the source code for different applications or clients, and avoids considering the different application or client styles or programming languages. This avoids the problems of requiring separate software development for different applications or clients, and the resulting complexity in operation and maintenance.

[0053] Step 102: Connect to the Redis node corresponding to the first application based on the configuration information and listen to the listening port. The Redis node is in cluster mode.

[0054] After obtaining the configuration information of the first application, the Redis proxy can connect to the Redis node corresponding to the first application based on the configuration information, establish a data path with the first application, and thus transmit the instructions of the first application; moreover, by listening to the monitoring port corresponding to the first application, it can listen for and intercept the instructions of the first application.

[0055] The Redis node operates in cluster mode. Only when it operates in cluster mode can it distinguish data from different applications, thus making it suitable for the Redis multi-tenant management method described in this application.

[0056] Step 103: Obtain the first instruction from the first application from the listening port. The first instruction is an instruction to access the Redis node.

[0057] Since the Redis proxy listens on the listening port corresponding to the first application, when the first application issues an instruction to access the Redis node, the Redis proxy can obtain the first instruction from the listening port.

[0058] Step 104: Add the additional information to the first instruction.

[0059] Adding additional information to the first instruction here can be understood as adding a namespace prefix to the first instruction on the proxy node in SideCar mode. The namespace prefix added by the Redis proxy varies depending on the application. This application's solution adds a namespace prefix to the proxy node in SideCar mode, achieving a unified and low-cost implementation of the namespace prefix function without incurring additional server costs.

[0060] Step 105: Send the first instruction with additional information to the Redis node.

[0061] The first instruction with added information is sent to the Redis node, enabling the Redis nodes in the Redis cluster to clearly identify which application the instruction originated from based on the added information, thereby ensuring that data resources between different tenants do not affect each other.

[0062] The Redis multi-tenant management method described in this embodiment uses a proxy to configure different additional information for different applications and adds the corresponding additional information to the access commands of each application. This ensures that the data of different applications in the Redis cluster can be clearly identified based on the added information and do not affect each other. This effectively reduces the cost of the Redis cluster, improves production efficiency, and enhances service stability.

[0063] In the above embodiments, obtaining the configuration information of the first application may include: retrieving the configuration information of the first application based on its basic information, wherein the basic information includes the application key of the application identifier, and the configuration information is information determined in advance when applying for a Redis node for the first application in the management backend. The configuration information may include, but is not limited to, at least several of the following: namespace, memory size, listening port, Redis type, timeout (optional), and disabling commands (optional).

[0064] Figure 2 This is a flowchart illustrating another Redis multi-tenant management method disclosed in an embodiment of the present invention. See also... Figure 2 As shown, Redis multi-tenancy management methods can include:

[0065] Step 201: The Redis proxy obtains the configuration information of the first application. The configuration information includes additional information and listening port. The additional information of different applications is unique.

[0066] Step 202: Connect to the Redis node corresponding to the first application based on the configuration information and listen on the listening port. The Redis node is in cluster mode.

[0067] Step 203: Obtain the first instruction from the first application from the listening port. The first instruction is an instruction to access the Redis node.

[0068] Step 204: Add the additional information to the first instruction.

[0069] Step 205: Determine whether the first instruction with added information belongs to the blacklist. If yes, proceed to step 206; otherwise, proceed to step 206.

[0070] To more accurately ensure the isolation of data resources between different tenants in a Redis cluster, this embodiment uses a blacklist to restrict access to certain commands. The blacklist stores command names with additional information. The Redis proxy can filter out commands that cannot be allowed based on the blacklist.

[0071] Step 206: Return a notification message that disables the first instruction.

[0072] Step 207: Send the first instruction with additional information to the Redis node.

[0073] If the incoming command is a command recorded in the blacklist, it is directly intercepted and returned; if the incoming command is not a command recorded in the blacklist, the first command with additional information is sent to the Redis node for normal access operation.

[0074] In this embodiment, the blacklist filtering method more accurately isolates unrelated application commands and Redis nodes, which can further avoid mutual interference between resources of different tenants in the Redis cluster, improve production efficiency, and enhance service stability.

[0075] Based on the above embodiments, the Redis multi-tenant management method may further include: the Redis proxy periodically obtaining an updated blacklist. Periodically updating the blacklist makes the interception strategy more accurate.

[0076] The updated blacklist is determined through monitoring the Redis cluster to identify alarm conditions and pinpointing issues caused by a surge in application traffic due to large or hot keys. Large keys are typically judged by a combination of key size and the number of members within the key. Examples include: an excessively large key size (e.g., a String key with a value of 5MB); too many members (e.g., a ZSET key with 10,000 members); or excessively large member data (e.g., a Hash key with only 1,000 members but a total value of 100MB). Hot keys are typically determined by the frequency of requests received to them. Examples include: high QPS (queries per second) concentrated on a specific key (e.g., a Redis instance with a total QPS of 10,000, but one key receiving 7,000 requests per second); and high bandwidth utilization concentrated on a specific key (e.g., sending a large number of HGETALL requests per second to a 1MB HASH key with thousands of members). CPU usage is concentrated on a specific key: sending a large number of ZRANGE operation requests per second to a key (ZSET type) with tens of thousands of members.

[0077] Specifically, the periodically updated blacklist may include: periodically obtaining an updated list of prohibited commands from the management backend; and adding the additional information to all command names in the list of prohibited commands to form a blacklist.

[0078] In other implementations, after sending the first instruction with added information to the Redis node, the method may further include: receiving the response result of the first instruction from the Redis node and returning the response result.

[0079] In a specific implementation, the environment structure diagram of a Redis cluster system is as follows: Figure 3 As shown. Combined with Figure 3 As shown, a Redis cluster system can include: a Redis management backend, a Redis proxy, and a Redis cluster.

[0080] The Redis management backend primarily includes tenant management, a monitoring module, and an alarm module. Tenant management mainly configures the Redis proxy, including: the listening port, Redis cluster address, Redis type (cluster mode, single-node mode), namespace, read / write timeout, prohibited commands, and allocated memory size. The monitoring module collects Redis proxy node metrics (including memory usage, CPU utilization, machine load, node RPS (Requests per Second), etc.) and Redis cluster metrics (including RPS, hot keys, memory utilization, etc.), and generates relevant reports based on these metrics. The alarm module sets thresholds based on the collected metrics and sends relevant alarms.

[0081] The Redis proxy mainly consists of three modules: namespace, prohibition command, and request forwarding. The namespace module adds a prefix to received request commands. The prohibition command is essentially a command blacklist; if a received request command is in the prohibited command list, the prohibition result is directly responded to. The request forwarding module receives requests from clients, parses the protocol commands, processes them through the namespace and prohibition command (if no match is found), forwards the new request to the Redis cluster, waits for the Redis cluster's response, and then writes the response back to the client. It should be noted that the request forwarding module can be configured according to the Redis type in the Redis management backend, supporting different Redis modes. There are four Redis modes: single-node mode, master-slave mode, sentinel mode, and cluster mode. The management backend can configure different modes based on the capabilities and needs of the proxy node. For example, in scenarios where only caching is used, cluster mode or single-node mode can be selected; in scenarios requiring concurrency lock control and storage, sentinel mode can be selected. If it is Redis Cluster mode, it forwards directly. In Redis single-node mode, consistent hashing is performed based on new commands, routing them to different Redis nodes, which also ensures high availability of the cache.

[0082] The Redis cluster can be in Redis Cluster mode or in single-node mode.

[0083] Figure 4 This is a schematic diagram illustrating the timing of the Redis multi-tenant management method disclosed in this embodiment of the invention. (Combined with...) Figure 4 As shown, the entire processing flow can include:

[0084] The first step is to prepare a Redis cluster, assuming that the Redis cluster is in cluster mode.

[0085] The second step is to apply for a Redis instance for the application in the management backend. The required information includes: namespace, memory size, listening port, Redis type, timeout (optional), and prohibited commands (optional). The namespace, such as namespace="ns1", will be added as a prefix to all Redis keys in the Redis proxy's namespace module. The memory size is the required Redis memory for the application, such as 4GB. The listening port is the port the Redis proxy listens on when it starts, such as 6379. The application service connects to it via localhost:6779. There are cluster mode and single-node mode. The timeout includes connection timeout, read timeout, and write timeout, with a default of 1 second. Prohibited commands are commands that prohibit client access, such as "getkey2". After submitting the application, the administrator will assign an application ID and key, for example, application ID "app1" and key "123456".

[0086] The third step is to start the Redis agent on the application server. The startup configuration parameters are: application ID "app1" and key "123456". The Redis agent uses the application ID and key to retrieve the configuration from the management backend. After successful authentication, the management backend returns configurations such as namespace, listening port, Redis type, timeout, prohibited commands, and Redis cluster address. The Redis agent then connects to the Redis cluster based on these configurations and starts listening on port 6379, waiting for Redis clients from the application server to connect. Simultaneously, the Redis agent starts a timer that periodically (e.g., every 60 seconds) retrieves the list of prohibited commands to local memory and adds a namespace prefix to the commands, such as changing "getkey2" to "getns1:key2".

[0087] Fourthly, assuming the application service is developed in Java and the selected Redis client is RedisCluster, when the application service starts, the Redis Cluster client connects to the Redis proxy via "localhost:6379". If the command "setkey1 abc" is executed, the Redis proxy's namespace will automatically add the namespace to the original key, making the command "setns1:key1 abc". The request forwarding module will then forward the command "setns1:key1 abc" to the Redis cluster. This allows the namespace to distinguish data from different applications within the Redis cluster. If the command is "get key2", the Redis proxy, after adding the namespace, will make the command "getns1:key2". The command prohibition module will then verify that the command is prohibited and directly encapsulate the prohibited command result to return to the client.

[0088] In this way, the data of different applications in the Redis cluster can be distinguished based on the namespace.

[0089] To prevent resources from interfering with each other, this can be addressed through, but is not limited to, monitoring, alerts, root cause analysis, and scaling / disabling commands.

[0090] 1) Monitoring: The Redis management console collects data such as Redis cluster RPS (Requests Per Second), hot key commands, and memory usage. RPS is a measure of the amount of traffic a specific query server processes within a given time. Monitoring this metric, along with other metrics, helps determine whether the Redis service is being monitored.

[0091] 2) Alarms: mainly monitor memory usage.

[0092] Memory usage has reached 80%, triggering a Level 1 alarm.

[0093] Memory usage has reached 85%, triggering a Level 2 alarm.

[0094] Memory usage reached 90%, triggering a Level 3 alarm.

[0095] 3) Root cause identification

[0096] When an alarm reaches level 1, the administrator needs to analyze the cause of the alarm. First, run the "RDB memory analysis tool" to analyze which application's traffic surge is causing the memory shortage, and then analyze whether it is caused by bigkey or by a large number of requests.

[0097] 4) Expansion / Disable Commands

[0098] Once the problem is identified, scaling up or disabling commands can be used to ensure the Redis cluster is not overwhelmed by the surge in traffic.

[0099] a. If it's due to normal business growth, you can directly apply for capacity expansion in the Redis management backend.

[0100] Large / hot keys cause issues. When a new key for a prohibited command is added in the management backend, the management backend pushes the prohibited command to the Redis proxy node. The proxy node matches the prohibited command key in the prohibited command module, intercepts it directly, and does not forward the request to the Redis cluster. Instead, it directly responds with an error result.

[0101] This application solution assigns different additional information to applications through a proxy mechanism. Monitoring and alerting functions, along with measures such as capacity expansion and disabling commands, ensure that resources between tenants do not interfere with each other. This effectively achieves the goals of reducing costs, increasing production efficiency, and improving service stability. Furthermore, the proxy model solves the high development and integration costs associated with multi-language systems, achieving zero intrusion into the application system.

[0102] For the foregoing method embodiments, in order to simplify the description, they are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0103] The methods described in the above-disclosed embodiments of the present invention are detailed in terms of their specific implementation. The methods of the present invention can be implemented using various forms of devices. Therefore, the present invention also discloses a device, and specific embodiments are given below for detailed description.

[0104] Figure 5 This is a schematic diagram of the structure of a Redis multi-tenant management device disclosed in an embodiment of the present invention. See also... Figure 5 As shown, the Redis multi-tenant management device 50 may include:

[0105] The configuration acquisition module 501 is used to obtain the configuration information of the first application. The configuration information includes additional information and listening port. The additional information of different applications is unique.

[0106] The basic preparation module 502 is used to connect to the Redis node corresponding to the first application based on the configuration information and listen to the listening port. The working mode of the Redis node is cluster mode.

[0107] The instruction acquisition module 503 is used to acquire a first instruction from the first application from the listening port, wherein the first instruction is an instruction to access the Redis node.

[0108] The information adding module 504 is used to add the additional information to the first instruction.

[0109] The instruction forwarding module 505 is used to send the first instruction with added information to the Redis node.

[0110] The Redis multi-tenant management device described in this embodiment configures different additional information for different applications through a proxy and adds the corresponding additional information to the access commands of each application. This ensures that the data of different applications in the Redis cluster can be clearly identified based on the added information and do not affect each other. This effectively reduces the cost of the Redis cluster, improves production efficiency, and enhances service stability.

[0111] The specific implementation of the Redis multi-tenant management device and its various modules can be found in the corresponding sections of the method embodiments, and will not be repeated here.

[0112] Any of the Redis multi-tenant management devices described in the above embodiments includes a processor and a memory. The configuration acquisition module, basic preparation module, instruction acquisition module, information addition module, instruction forwarding module, etc. in the above embodiments are all stored as program modules in the memory, and the processor executes the above program modules stored in the memory to realize the corresponding functions.

[0113] The processor contains a kernel, which retrieves the corresponding program modules from memory. One or more kernels can be configured, and the processing of backtracking data can be achieved by adjusting kernel parameters.

[0114] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0115] In an exemplary embodiment, a computer-readable storage medium is also provided, which can be directly loaded into the internal memory of a computer and contains software code. After being loaded and executed by the computer, the computer program can implement the steps shown in any of the embodiments of the Redis multi-tenant management method described above.

[0116] In an exemplary embodiment, a computer program product is also provided, which can be directly loaded into the internal memory of a computer and contains software code. After being loaded and executed by the computer, the computer program can implement the steps shown in any embodiment of the Redis multi-tenant management method described above.

[0117] Furthermore, this embodiment of the invention provides a server. Figure 6 This is a schematic diagram of the structure of a server disclosed in an embodiment of this application. See also... Figure 6 As shown, the server includes at least one processor 601, at least one memory 602 connected to the processor, and a bus 603; wherein the processor and the memory communicate with each other through the bus; the processor is used to call program instructions in the memory to execute the Redis multi-tenant management method described above.

[0118] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0119] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0120] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0121] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A Redis multi-tenant management method, characterized in that, Applied to Redis proxies, the method includes: The Redis proxy obtains the configuration information of the first application, which includes additional information and a listening port. The additional information of different applications is unique. The different tenants in the multi-tenant system are the different applications. The additional information includes a namespace prefix. The configuration information includes a blacklist. Based on the configuration information, connect to the Redis node corresponding to the first application and listen to the listening port corresponding to the first application. The working mode of the Redis node is cluster mode. The first instruction from the first application is obtained from the listening port; the first instruction is an instruction to access the Redis node. Add the additional information to the first instruction; Determine whether the first instruction with added information belongs to the blacklist; the blacklist stores the names of prohibited instructions with added information. If it does not belong to the Redis node, a first instruction with additional information will be sent to the node. The Redis agent periodically obtains an updated list of prohibited commands from the management backend; Add the additional information to all instruction names in the prohibited instruction list to create an updated blacklist.

2. The Redis multi-tenant management method according to claim 1, characterized in that, Obtaining the configuration information of the first application includes: Based on the basic information of the first application, the configuration information of the first application is retrieved. The basic information includes the application key of the application identifier, and the configuration information is the information determined in advance when applying for a Redis node for the first application in the management backend.

3. The Redis multi-tenant management method according to claim 1, characterized in that, Also includes: If the first instruction is on the blacklist, a notification message prohibiting the first instruction is returned.

4. The Redis multi-tenant management method according to claim 1, characterized in that, The updated blacklist is determined by analyzing and locating problems after monitoring the Redis cluster to confirm that the alarm conditions are met, and identifying the blacklist as being caused by a surge in application traffic due to large or hot keys.

5. The Redis multi-tenant management method according to claim 1, characterized in that, After sending the first instruction with added information to the Redis node, the process also includes: Receive the response result of the first instruction from the Redis node and return the response result.

6. A Redis multi-tenant management device, characterized in that, Applied to a Redis proxy, the device includes: A configuration acquisition module is used to obtain configuration information of a first application. The configuration information includes additional information and a listening port. The additional information of different applications is unique. The different tenants in the multi-tenant system are the different applications. The additional information includes a namespace prefix. The configuration information includes a blacklist. The basic preparation module is used to connect to the Redis node corresponding to the first application based on the configuration information and listen to the listening port corresponding to the first application. The working mode of the Redis node is cluster mode. The instruction acquisition module is used to acquire a first instruction from the first application from the listening port, wherein the first instruction is an instruction to access the Redis node; An information adding module is used to add the additional information to the first instruction; The instruction forwarding module is used to determine whether the first instruction with added information belongs to the blacklist; the blacklist stores the names of prohibited instructions with added information; if it does not belong to the blacklist, the first instruction with added information is sent to the Redis node. The Redis proxy is also used to periodically obtain an updated list of prohibited commands from the management backend; and to add the additional information to all command names in the list of prohibited commands to form an updated blacklist.

7. A server, characterized in that, The server is configured with a Redis proxy and includes: processor; Memory for storing the executable instructions of the processor; The executable instructions include: obtaining configuration information of a first application, the configuration information including additional information and a listening port, wherein the additional information of different applications is unique; different tenants in a multi-tenant system are the different applications; the additional information includes a namespace prefix; the configuration information includes a blacklist; connecting to the Redis node corresponding to the first application based on the configuration information and listening to the listening port corresponding to the first application, the Redis node operating in cluster mode; obtaining a first instruction of the first application from the listening port, the first instruction being an instruction to access the Redis node; adding the additional information to the first instruction; determining whether the first instruction with added additional information belongs to the blacklist; the blacklist storing the names of prohibited instructions with additional information; if it does not belong, sending the first instruction with added additional information to the Redis node; periodically obtaining an updated list of prohibited instructions from the management backend; adding the additional information to all instruction names in the list of prohibited instructions to form an updated blacklist.

Images