A Redis Web Visualization Client and Device

Abstract

The present invention relates to the field of software technology, and specifically provides a Redis Web visualization client, which is a Redis visualization client adopting a BS architecture and consists of a front end, a back end, and a Redis client. The front end is separated from the back end, and the back end provides interfaces. When in use, the front end first inputs the Redis address, port, and password to connect to the Redis server. Compared with the prior art, the present invention can be accessed and used by anyone, providing another way for developers or operation and maintenance personnel to access Redis and making the operation more convenient.

Description

Technical Field

[0001] The present invention relates to the field of software technology, and specifically provides a Redis Web visualization client and device. Background Art

[0002] Netty is a non-blocking I / O client-server framework, mainly used for developing Java network applications, such as protocol servers and clients. An asynchronous event-driven network application framework and tool is used to simplify network programming, such as TCP and UDP socket servers.

[0003] Spring Boot is a project built on top of the Spring framework. It provides a simpler and faster way to set up, configure, and run simple and web-based applications.

[0004] Vue (pronounced / vjuː / , similar to view) is a progressive framework for building user interfaces, an open-source JavaScript framework for creating user interfaces, and also a web application framework for creating single-page applications.

[0005] Currently, existing Redis visualization clients have problems such as charging, stopping updates, and incomplete functions. How to solve some problems existing in the current Redis client visualization is an urgent matter for those skilled in the art. Summary of the Invention

[0006] The present invention aims at the above-mentioned deficiencies of the prior art and provides a Redis Web visualization client with strong practicability.

[0007] A further technical task of the present invention is to provide a Redis Web visualization device with reasonable design, safety and applicability.

[0008] The technical solution adopted by the present invention to solve its technical problems is as follows:

[0009] A Redis Web visualization client, a Redis visualization client adopting a BS architecture, is composed of a front end, a back end, and a Redis client. The front end is separated from the back end, and the back end provides an interface;

[0010] When the front end is used, the Redis address, port, and password are first input to connect to the Redis server.

[0011] Furthermore, the Redis client can generate a pair of public and private keys before startup. The private key is saved on the server side, and the public key is saved on the front end or on the back end and obtained by the front end through the interface;

[0012] When establishing a connection, if the user enters an authentication password, the password needs to be encrypted with the public key before transmitting the Redis client connection information, and then transmitted. The Redis password saved in the browser is also encrypted. After the backend receives the connection information, it determines whether there is a password. If there is, the private key needs to be used to decrypt the password;

[0013] After connecting to the server, the server information is displayed.

[0014] Furthermore, when the Redis client is reopened, the front-end will obtain all the historical connection information from the browser's localStorage and display it in the left-side list. When the user double-clicks on a connection, the front-end will transmit the saved connection information to the backend, and the backend will establish a connection with the Redis server;

[0015] The Redis client can connect to multiple Redis servers simultaneously. Therefore, when operating on a Redis server, the front-end needs to send the Redis server for each operation to the backend, and the Redis address and port need to be sent.

[0016] Furthermore, the backend is implemented based on Spring Boot, responsible for establishing a connection with the Redis server, encapsulating the front-end requests into Redis commands, converting the Redis commands to the Redis protocol RESP, interacting with the Redis server, and providing corresponding RESTful interfaces for the front-end to use.

[0017] Furthermore, the Redis client may connect to multiple Redis servers simultaneously. Therefore, the backend needs to save multiple Redis connections in memory, with HOST+PORT as the key;

[0018] If the client connects to the same Redis server simultaneously, then the backend will not establish a duplicate connection with this Redis server again, but reuse the subsequent connection. Each connection will also record a connection counter to record the number of connections between the client and the Redis server.

[0019] Furthermore, after a certain period of time, if there is no further interaction between the client and the Redis server, or the front-end actively closes the connection, the backend will determine whether the connection counter is 0. If it is 0, the connection will be disconnected and resources will be released;

[0020] After the client closes the connection with Redis due to inactivity for a long time, when continuing to operate, the backend will return a response to the front-end to close the connection. The front-end needs to send the saved connection information to the backend, and the backend will re-establish a connection with the Redis server and then perform subsequent operations.

[0021] Further, the Redis client is customized based on Netty. Netty enables the client to establish communication with the Redis Server and provides interfaces for the backend to use. RESP serializes different data types. The commands and parameters requested by the client are sent to the Redis server in the form of a string array. The Redis server responds with the data type for a specific command. The Redis server receives commands composed of different parameters, and after receiving the commands, it processes the commands and sends a reply back to the client.

[0022] Further, RESP can represent a null value using a special variant of a bulk string or array specified later. In RESP, different parts of the protocol are always terminated with "\r\n";

[0023] Netty provides the Redis protocol RESP codec RedisDecoder and RedisEncoder, aggregators RedisBulkStringAggregator and RedisArrayAggregator. After receiving the message returned by the Redis server, it is necessary to determine the type of the message. Netty encapsulates the data types defined in RESP.

[0024] A Redis Web visualization device includes: at least one memory and at least one processor;

[0025] The at least one memory is used to store machine-readable programs;

[0026] The at least one processor is used to call the machine-readable program to execute a Redis Web visualization client.

[0027] Compared with the prior art, a Redis Web visualization client and device of the present invention have the following outstanding beneficial effects:

[0028] Anyone can access and use the present invention, providing another way for developers or operation and maintenance personnel to access Redis and making the operation more convenient. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the following drawings are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0030] Attached Figure 1 is a schematic flow diagram of a Redis Web visualization client;

[0031] Appended Figure 2 It is a schematic diagram of a new connection page in a Redis Web visualization client. Specific implementation manner

[0032] In order to enable those skilled in the art to better understand the solution of the present invention, the present invention will be further described in detail below in conjunction with specific implementation manners. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of the present invention.

[0033] The following gives an optimal embodiment:

[0034] Such as Figure 1 、 2 As shown, a Redis Web visualization client in this embodiment is a Redis visualization client adopting a BS architecture, which consists of a front end, a back end and a Redis client. The front end is separated from the back end, and the back end provides interfaces;

[0035] When the front end is used, the Redis address, port and password are first input to connect to the Redis server.

[0036] The front end will store the Redis connection information that has been logged in into the localStorage of the browser for convenient use next time. The Redis password is private data, and it cannot be in plain text whether it is stored in the browser or transmitted over the network, otherwise there will be security problems.

[0037] The Redis client can generate a pair of public and private keys before starting. The private key is saved on the server side, and the public key is saved on the front end, or it can also be saved on the back end and obtained by the front end through the interface. When establishing a connection, if the user enters an authentication password, the password needs to be encrypted with the public key before transmitting the Redis connection information and then transmitted. The Redis password saved in the browser is also encrypted.

[0038] After the back end receives the connection information, it judges whether there is a password. If there is, the private key needs to be used to decrypt the password, and the server information is displayed after connecting to the server.

[0039] When the Redis client is reopened, the front-end will retrieve all historical connection information from the browser's localStorage and display it in the left-side list. When the user double-clicks on a connection, the front-end will transmit the saved connection information to the back-end, which will establish a connection with the Redis server. Since the Redis client can connect to multiple Redis servers simultaneously, when operating on a Redis server, the front-end needs to send the Redis server for each operation to the back-end, including the Redis address and port.

[0040] The back-end is implemented based on Spring Boot and is responsible for establishing a connection with the Redis server, encapsulating the front-end requests into Redis commands, converting the Redis commands to the Redis protocol RESP, interacting with the Redis server, and providing corresponding RESTful interfaces for the front-end to use. Since the Redis client may connect to multiple Redis servers simultaneously, the back-end needs to save multiple Redis connections in memory, using HOST+PORT as the key. If the client connects to the same Redis server simultaneously, the back-end will not establish a duplicate connection to this Redis server but will reuse the subsequent connection. Each connection also records a connection counter to record the number of connections between the client and the Redis server. After a certain period of time, if the client and the Redis server do not interact again, or the front-end actively closes the connection (such as closing the tab page), the back-end will determine whether the connection counter is 0. If it is 0, the connection will be disconnected and resources will be released.

[0041] After the client closes the connection with Redis due to inactivity for a long time and then continues to operate, the back-end will return a response to the front-end to close the connection. The front-end needs to send the saved connection information to the back-end, and the back-end will re-establish a connection with the Redis server and then perform subsequent operations. This process does not require user intervention.

[0042] There are many Redis clients in the Java language. Here, a custom Redis client is developed based on Netty. Developing a Redis client requires a deep understanding of Redis and also an understanding of the protocol RESP (REdisSerialization Protocol) between the client and the server. Netty is used to implement the communication between the client and the Redis Server and provides interfaces for the back-end to use.

[0043] RESP can serialize different data types, such as integers, strings, and arrays. Errors also have specific types. The commands and arguments requested by the client are sent to the Redis server as an array of strings. For example, if the client wants to execute "SET foo bar", this statement will be converted to ["SET", "foo", "bar"]. The Redis server responds with the data type for a specific command.

[0044] The Redis server receives commands consisting of different parameters. After receiving a command, it will process the command and send a reply back to the client. This is the simplest model, but there are two exceptions:

[0045] (1) Pipelining. The client can send multiple commands at the same time and then wait for the reply.

[0046] (2) When a Redis client subscribes to a Pub / Sub channel, the protocol changes its semantics and becomes a push protocol, i.e., the client no longer needs to send commands because the server will automatically send them to the client immediately after receiving a new message (for the channel subscribed by the client).

[0047] Except for the above two exceptions, the Redis protocol is a simple request-response protocol.

[0048] RESP is actually a serialization protocol that supports the following data types: simple strings, errors, integers, strings, and arrays. The way it is used as a request-response protocol in Redis is as follows:

[0049] The client sends a command to the Redis server as an array of RESP bulk strings;

[0050] The server replies with one of the RESP types according to the command. In RESP, the type of some data depends on the first word;

[0051] For a simple string, the first word of the reply is "+";

[0052] For an error, the first word of the reply is "-";

[0053] For an integer, the first word of the reply is ":";

[0054] For a string, the first word of the reply is "$";

[0055] For an array, the first word of the reply is "*".

[0056] In addition, RESP can represent null values using special variants of bulk strings or arrays specified later. In RESP, different parts of the protocol are always terminated with "\r\n" (CRLF).

[0057] Netty is a network framework. Network programming requires encoding and decoding data and also needs to handle the problems of package sticking and unpacking. Netty solves these problems. Netty provides the Redis protocol RESP codec RedisDecoder and RedisEncoder, aggregators RedisBulkStringAggregator and RedisArrayAggregator. Messages need to be processed when sending them.

[0058] The code is as follows:

[0059] / / Send the message to the Redis service

[0060] public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) {

[0061] / / Split the string instruction

[0062] String[] commands = ((String) msg).split("\\s+");

[0063] List <redismessage>children = new ArrayList <redismessage>(commands.length);

[0064] for (String cmdString : commands) {

[0065] / / Convert each string command into a binary command for transmission

[0066] children.add(new

[0067] FullBulkStringRedisMessage(ByteBufUtil.writeUtf8(ctx.alloc(), cmdString)));

[0068] RedisMessage request = new ArrayRedisMessage(children);

[0069] / / Send the command

[0070] ctx.write(request, promise);

[0071] Convert the command and its parameters into an array and then process the array later.

[0072] String[] commands = ((String) msg).split("\\s+");

[0073] After receiving the message returned by the Redis server, it is necessary to determine the type of the message. Netty encapsulates the data types defined in RESP and provides message types such as SimpleStringRedisMessage, ErrorRedisMessage, IntegerRedisMessage, FullBulkStringRedisMessage, ArrayRedisMessage, etc. The following is the judgment of the message type in the sample and the simple printing of the response message.

[0074] / / Print the message received from the Redis service

[0075] private static void printAggregatedRedisResponse(RedisMessage msg)

[0076] / / Determine the message type

[0077] / / If it is a string response

[0078] if (msg instanceof SimpleStringRedisMessage) {

[0079] / / Print the message

[0080] System.out.println(((SimpleStringRedisMessage) msg).content());

[0081] / / If it is an error response

[0082] } else if (msg instanceof ErrorRedisMessage) {

[0083] / / Print the error message

[0084] System.out.println(((ErrorRedisMessage) msg).content());

[0085] / / If it is a numeric response

[0086] } else if (msg instanceof IntegerRedisMessage) {

[0087] System.out.println(((IntegerRedisMessage) msg).value());

[0088] / / If it is a batch string response

[0089] } else if (msg instanceof FullBulkStringRedisMessage) {

[0090] System.out.println(getString((FullBulkStringRedisMessage) msg));

[0091] / / If it is a multi - Redis message

[0092] } else if (msg instanceof ArrayRedisMessage) {

[0093] / / Traverse and print the message

[0094] for (RedisMessage child : ((ArrayRedisMessage) msg).children())

[0095] printAggregatedRedisResponse(child);

[0096] / / Unknown message type, throw an exception

[0097] } else {

[0098] throw new CodecException("unknown message type:" + msg);

[0099] Currently, the Redis client already supports connections to single - node servers and master - slave modes, and supports most data operations, such as SET, GET, LPUSH, HGET, HSET, HMSET, EXPIRE, etc. Subsequently, the client will support message communication in Redis Sentinel and cluster modes.

[0100] Based on the above method, a Redis Web visualization device includes: at least one memory and at least one processor;

[0101] The at least one memory is used to store machine - readable programs;

[0102] The at least one processor is used to call the machine - readable program and execute a Redis Web visualization client.

[0103] The above - mentioned specific embodiments are only specific cases of the present invention. The patent protection scope of the present invention includes but is not limited to the above - mentioned specific embodiments. Any appropriate changes or substitutions made by any person of ordinary skill in the art that meet the claims of a Redis Web visualization client and device of the present invention shall fall within the patent protection scope of the present invention.

[0104] Although the embodiments of the present invention have been shown and described, for those of ordinary skill in the art, it can be understood that various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.< / redismessage> < / redismessage>

Claims

1. A Redis Web visualization client, characterized in that, The Redis visualization client adopting the BS architecture consists of a front end, a back end, and a Redis client. The front end is separated from the back end, and the back end provides interfaces. When the front end is used, it first inputs the Redis address, port, and password to connect to the Redis server. Before the Redis client starts, a pair of public and private keys is generated. The private key is saved on the server side, and the public key is saved on the front end or on the back end and obtained by the front end through the interface. When establishing a connection, if the user enters an authentication password, the password needs to be encrypted with the public key before transmitting the Redis client connection information and then transmitted. The Redis password saved in the browser is also encrypted. After the back end receives the connection information, it determines whether there is a password. If there is, the password needs to be decrypted with the private key. After connecting to the server, the server information is displayed. When the Redis client is reopened, the front end will obtain all the historical connection information from the browser localStorage and display it in the list on the left. When the user double-clicks on a connection, the front end will transmit the saved connection information to the back end, and the back end will establish a connection with the Redis server. The Redis client can connect to multiple Redis servers simultaneously. Therefore, when operating on a Redis server, the front end needs to send the Redis server for each operation to the back end, and the Redis address and port need to be sent. The back end is implemented based on Spring Boot and is responsible for establishing a connection with the Redis server, encapsulating the front-end requests into Redis commands, converting the Redis commands into the Redis protocol RESP, interacting with the Redis server, and providing corresponding RESTful interfaces for the front end to use. The Redis client may connect to multiple Redis servers simultaneously. Therefore, the back end needs to save multiple Redis connections in memory with HOST+PORT as the key. If the client connects to the same Redis server simultaneously, the back end will not establish a duplicate connection with this Redis server but reuse the subsequent connection. Each connection also records a connection counter to record the number of connections between the client and the Redis server. After a certain period of time, if the client and the Redis server do not interact again, or the front end actively closes the connection, the back end will determine whether the connection counter is 0. If it is 0, the connection will be disconnected and the resources will be released. After the client closes the connection with Redis due to inactivity for a long time and then continues to operate, the back end will return a response to the front end to close the connection. The front end needs to send the saved connection information to the back end, and the back end will re-establish a connection with the Redis server and then perform subsequent operations. The Redis client is customized based on Netty. Netty enables the client to establish communication with the Redis Server and provides interfaces for the backend to use. RESP serializes different data types. The commands and parameters requested by the client are sent to the Redis server in the form of a string array. The Redis server responds with the data type of a specific command. The Redis server receives commands composed of different parameters. After receiving a command, it processes the command and sends a reply back to the client; RESP can represent a null value using a special variant of a bulk string or array specified later. In RESP, different parts of the protocol are always terminated with "\r\n"; Netty provides the Redis protocol RESP codec RedisDecoder and RedisEncoder, aggregators RedisBulkStringAggregator and RedisArrayAggregator. After receiving the message returned by the Redis server, it is necessary to determine the type of the message. Netty encapsulates the data types defined in RESP.

Images