Shulou(Shulou.com)06/03 Report--

This article introduces the relevant knowledge of "what is the Redis cache used to do in the system". In the operation of actual cases, many people will encounter this dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

First, what is the cache used for in the system?

1. A small amount of data storage, high-speed read and write access. To ensure high-speed access through all the data in-momery, while providing the function of data landing, in fact, this is the most important application scenario of Redis.

two。 Massive data storage, distributed system support, data consistency guarantee, convenient cluster nodes to add / delete. Since then, Redis3.0 has started to support clusters and implemented semi-automatic data sharding, but it needs the support of smart-client.

Second, introduce redis in detail from different angles.

Network model: Redis uses a single-threaded IO reuse model and encapsulates a simple AeEvent event handling framework, which mainly implements epoll, kqueue and select. For simple IO operations, single thread can maximize the speed advantage, but Redis also provides some simple computing functions, such as sorting, aggregation, etc., for these operations, the single-thread model will seriously affect the overall throughput In the process of CPU calculation, the whole IO scheduling is blocked.

Memory management: Redis uses on-site memory application to store data, and rarely uses free-list to optimize memory allocation. To some extent, memory fragmentation exists. Redis and storage command parameters store data with expiration time separately and call them temporary data. Non-temporary data will never be removed, even if there is not enough physical memory. As a result, swap also does not eliminate any non-temporary data (but attempts to eliminate some temporary data), which makes Redis more suitable for storage than cache.

Data consistency: on the issue of consistency, I feel that redis is not as good as memcached. Memcached provides cas commands to ensure the consistency of multiple concurrent access operations to the same data. Redis does not provide cas commands, which is not guaranteed, but Redis provides transactional functionality to ensure the atomicity of a string of commands without being interrupted by any operation.

Support KEY types: Redis in addition to key/value, but also supports list,set,sorted set,hash and many other data structures, provides KEYS for enumerating operations, but can not be used online, if you need to enumerate online data, Redis provides a tool to directly scan its dump file, enumerate all the data, Redis also provides persistence and replication and other functions.

Client support: redis officially provides rich client support, including clients in most programming languages. For example, I chose the officially recommended Java client Jedis for this test. It provides rich interfaces and methods so that developers do not need to relate to internal data slicing, reading data routing, etc., just a simple call, very convenient.

Data replication: starting from 2.8.The Slave will periodically (once per second) initiate an Ack to confirm the progress of the replication stream (replication stream). The detailed process of Redis replication is as follows:

1. If a Slave is set, it issues a SYNC command whether it connects for the first time or reconnects to the Master

two。 When Master receives the SYNC command, it does two things:

A) Master executes BGSAVE: writes data to disk in the background (rdb snapshot)

B) Master also buffers newly received commands for writing and modifying datasets (non-query class)

3. When Master saves the data to the snapshot file in the background, Master transfers the snapshot file to Slave, and Slave clears the memory and loads the file into memory

4. And Master will also forward the commands previously collected into the buffer to Slave,Slave to execute these commands in the form of Reids command protocol to achieve synchronization with Master.

5. Since then, Master/Slave will continue to synchronize commands asynchronously to achieve the same synchronization of the final data.

6. It should be noted that any reconnection between Master and Slave will trigger a full synchronization operation. But after 2.8, it may also be a partial synchronization operation.

At first, when the connection between Master and Slave is broken, continuous replication can be used instead of full synchronization between them.

The Master side maintains a memory buffer (in-memory backlog) for the replication stream to record the most recently sent replication stream commands; at the same time, both Master and Slave maintain a replication offset (replication offset) and the current Master server ID (Masterrun id).

When the network is disconnected and Slave tries to reconnect:

a. If the MasterID is the same (that is, it is still the Master server before the disconnection), and the historical commands from the time of disconnection to the current moment still exist in the memory buffer of Master, then Master will send all commands for the missing period to Slave for execution, and the replication work can continue.

b. Otherwise, a full copy operation is still required.

Read-write separation: redis supports read-write separation and is easy to use. You only need to configure the redis read server and write server in the configuration file. Multiple servers are separated by commas as follows:

Horizontal dynamic expansion: after three years, we have finally come to look forward to the Redis 3.0. The new version mainly implements the function of Cluster, and data migration will be carried out automatically after adding and deleting cluster nodes. The core of online reconfiguration of Redis clusters is the ability to move slots from one node to another. Because a hash slot is actually a collection of keys, what a Redis cluster really needs to do when it rehash is to move some keys from one node to another.

Data elimination strategy: when the redis memory dataset size rises to a certain size, the data elimination strategy will be implemented. Redis provides 6 data elimination strategies:

Volatile-lru: select the least recently used data elimination from the dataset with an expiration time set (server. DB [I]. Obsolete).

Volatile-ttl: select the expired data from the dataset (server. DB [I]. Expires) that will expire.

Volatile-random: arbitrarily select data elimination from a dataset with an expiration time set (server. DB [I]. Expires).

Allkeys-lru: select the least recently used data elimination from the dataset (server. DB [I]. Dict).

Allkeys-random: data elimination from any selection of the dataset (server. DB [I]. Dict)

No-enviction (expulsion): prohibition of eviction data

3. Cluster (i.e. distributed)

The following is a detailed description of the clustering function of redis, which has been supported since version 3.0, that is, it has been distributed in a real sense.

Redis cluster is a distributed (distributed), fault-tolerant (fault-tolerant) Redis implementation, and the functions that can be used by clusters are a subset of the functions that can be used by ordinary stand-alone Redis (subset).

There are no central nodes or proxy nodes in the Redis cluster, and one of the main design goals of the cluster is to achieve linear scalability (linear scalability).

Redis cluster sacrifices part of fault tolerance in order to ensure consistency (consistency): the system will maintain data consistency as much as possible on the premise of limited (limited) resistance to network disconnection (netsplit) and node failure (node failure).

Cluster characteristics:

(1) all redis nodes are interconnected with each other (PING-PONG mechanism), and binary protocol is used internally to optimize transmission speed and bandwidth.

(2) the fail of a node takes effect only when more than half of the nodes in the cluster detect failure.

(3) the client is directly connected to the redis node and does not need an intermediate proxy layer. The client does not need to connect to all the nodes in the cluster, but to any of the available nodes in the cluster.

(4) redis-cluster maps all physical nodes to [0-16383] slot, and cluster is responsible for maintaining nodeslotvalue.

The subset of functions implemented by the Redis cluster:

The Redis cluster implements all commands that deal with a single database key in a stand-alone Redis. The complex computing operations for multiple database keys, such as set union operation and collection operation, are not implemented, and those commands that theoretically need to use multiple database keys of multiple nodes are not implemented. In the future, users may be able to perform read-only operations on multiple database keys in the compute node (computation node) of the cluster through the MIGRATE COPY command, but the cluster itself will not implement complex multi-key commands that need to move multiple database keys to and from multiple nodes.

Redis clusters do not support multiple databases like stand-alone Redis. Clusters only use the default database number 0 and cannot use the SELECT command.

Clients and servers in the Redis cluster protocol:

Nodes in a Redis cluster have the following responsibilities:

1. Hold key-value pairs of data.

two。 Record the status of the cluster, including the mapping of keys to the correct node (mappingkeys to right nodes).

3. Automatically discover other nodes, identify abnormal nodes, and select a new master node from the slave nodes if necessary.

To perform the tasks listed above, each node in the cluster establishes a "cluster connection" (cluster bus) with other nodes, which is an TCP connection that communicates using the binary protocol.

The Gossip protocol is used between nodes to do the following:

1. Propagate information about the cluster to discover new nodes.

two。 Send PING packets to other nodes to check whether the target node is functioning properly.

3. Send cluster information when a specific event occurs.

4. In addition, cluster connections are also used to publish or subscribe information in the cluster.

Because cluster nodes cannot proxy command requests, clients should forward command requests to other nodes themselves when the node returns a-MOVED or-ASK redirection (redirection) error. Because the client is free to send command requests to any node in the cluster, and can forward the command to the correct node based on the information provided by the redirection error when necessary, in theory, the client does not need to save the cluster state information. However, if the client can save the mapping information between keys and nodes, it can effectively reduce the number of redirections that may occur, thus improving the efficiency of command execution.

Bond distribution model

The key space of the Redis cluster is divided into 16384 slot, and the maximum number of nodes in the cluster is 16384.

The recommended maximum number of nodes is about 1000. Each master node is responsible for handling some of the 16384 hash slots.

When we say that a cluster is in a "stable" state, it means that the cluster is not performing a reconfiguration operation, and each hash slot is handled by only one node. Reconfiguration refers to moving one / some slots from one node to another. A master node can have any number of slave nodes, which are used to replace the master node when the master node is disconnected or the node fails.

Cluster node attributes:

Each node has a unique ID in the cluster, which is a hexadecimal representation of a 160-bit random number generated by / dev/urandom when the node is first started.

The node saves its ID to the configuration file, and the node will continue to use the ID as long as the configuration file is not deleted. The node ID is used to identify each node in the cluster. A node can change its IP and port number without changing the node ID. The cluster can automatically recognize the change in the IP/ port number and broadcast this information to other nodes through the Gossip protocol.

The following is the associated information that each node has, and the node sends this information to other nodes:

1. The IP address and TCP port number used by the node.

two。 The flag of the node (flags).

3. The node is responsible for handling the hash slot.

4. The last time a node sent a PING packet (packet) using a cluster connection.

5. The last time the node received an PONG packet in the reply.

6. The time the cluster marks the node as offline.

7. The number of slave nodes for this node.

8. If the node is a slave node, it records the node ID of the master node. If this is a master node, the ID column of the master node has a value of 0000000.

Some of the above information can be obtained by sending CLUSTER NODES commands to any node in the cluster (master or slave).

Node handshake:

The node always accept the connection request from the cluster connection port and replies to the received PING packet, even if the PING packet comes from an untrusted node. However, with the exception of PING, the node rejects all other packets that are not from the cluster node. There are only two ways to get one node to admit that another node belongs to the same cluster:

1. One node can force the receiving node to admit that the sending node is a member of the cluster by sending MEET information to another node. One node sends CLUSTER MEET ipport information to another node only if the administrator explicitly sends it a MEET command.

two。 If a trusted node propagates the information of a third-party node to another node, the node that receives the information will also identify the third-party node as a member of the cluster. That is, if A knows B, B knows C, and B propagates information about C to A, then A will also identify C as a member of the cluster and try to connect to C.

This means that if we add one / some new nodes to a cluster, the new nodes will eventually be connected to all other nodes already in the cluster.

This means that as long as the administrator explicitly specifies the trust relationship using the CLUSTER MEET command, the cluster can automatically discover other nodes. This node identification mechanism makes the cluster more robust by preventing different Redis clusters from mix due to IP address changes or other network events. When a node is disconnected from the network, it will actively connect to other known nodes.

MOVED turns to:

An Redis client can send command requests to any node in the cluster, including slave nodes. The node analyzes the command request, and if the command is a command that can be executed by the cluster, the node looks for the slot in which the key to be processed by the command is located. If the hash slot you are looking for happens to be handled by the node that received the command, then the node executes the command directly. On the other hand, if the slot being found is not handled by the node, the node will view its own internal hash slot to node ID mapping record and reply a MOVED error to the client.

Even if the client waits so long before resending the GET command that the cluster changes the configuration again so that node 127.0.0.1 GET 6381 no longer handles slot 3999, when the client sends the MOVED command to node 127.0.0.1, the node will return a MOVED error to the client indicating that the node is now responsible for processing slot 3999.

Although we use ID to identify the nodes in the cluster, in order to make the client's redirection operation as simple as possible, the node directly returns the IP and port number of the target node in the MOVED error instead of the ID of the target node. However, a client should record (memorize) the message that "slot 3999 is handled by node 127.0.0.1 vig 6381", so that when another command needs to be executed on slot 3999, the client can speed up finding the right node.

Note that when the cluster is in a stable state, all clients eventually keep a hash slot-to-node mapping record (map of hash slots to nodes), making the cluster very efficient: the client can send command requests directly to the correct node without having to redirect, agent, or any other entity (entiy) that may have a single point of failure (single point failure).

In addition to MOVED redirection errors, a client should be able to handle ASK redirection errors described later.

Cluster online reconfiguration:

Redis clusters support adding or removing nodes while the cluster is running. In fact, the addition of a node and the deletion of a node can be abstracted into the same operation, that is, moving a hash slot from one node to another: adding a new node to the cluster. it is tantamount to moving the slots of other existing nodes into a new blank node. Removing a node from the cluster is equivalent to moving all the slots of the removed node to other nodes in the cluster.

Therefore, the core of implementing online reconfiguration of Redis clusters is the ability to move slots from one node to another. Because a hash slot is actually a collection of keys, what a Redis cluster really needs to do when it rehash is to move some keys from one node to another.

To understand how a Redis cluster moves slots from one node to another, we need to introduce the subcommands of the CLUSTER command, which are responsible for managing the slot translation table (slots translation table) of the cluster nodes.

The following subcommands are available for the CLUSTER command:

The first two commands ADDSLOTS and DELSLOTS are used to assign (assign) or remove nodes to nodes, respectively, and when slots are assigned or removed, nodes propagate this information to the entire cluster through the Gossip protocol. The ADDSLOTS command is usually used as a means of quickly assigning individual slots to individual nodes when a new cluster is created.

The CLUSTERSETSLOT slot NODE node subcommand assigns the specified slot slot to the node node.

As for the CLUSTER SETSLOTslot MIGRATING node command and the CLUSTER SETSLOTslot IMPORTING node command, the former is used to migrate the slot slot in the given node node out of the node, while the latter is used to import the given slot slot into the node node:

When a slot is set to MIGRATING, the node that used to hold the slot will continue to accept command requests for the slot, but the node will process the command request only if the key handled by the command still exists in the node.

If the key used by the command does not exist with the node, the node returns a-ASK redirection (redirection) error to the client, telling the client to send the command request to the migration target node of the slot.

When a slot is set to the IMPORTING state, the node accepts the command request for the slot only after it has received the ASKING command.

If the client does not send an ASKING command to the node, the node uses the-MOVED redirection error to redirect the command request to the node that is really responsible for handling the slot.

The above instructions about MIGRATING and IMPORTING are a little difficult to understand, so let's use a practical example to illustrate it.

Suppose now that we have two nodes An and B, and we want to move slot 8 from node A to node B, so we:

Send the command CLUSTER SETSLOT 8 IMPORTING A to Node B

Send the command CLUSTER SETSLOT 8 MIGRATING B to node A

Whenever the client sends a command request about hash slot 8 to other nodes, these nodes return redirection information to node A to the client:

If the key to be processed by the command already exists in slot 8, the command will be handled by node A.

If the key to be processed by the command does not exist in slot 8 (for example, to add a new key to the slot), the command is handled by node B.

This mechanism will cause node A to no longer create any new keys for slot 8.

At the same time, a special client redis-trib and the Redis cluster configuration program (configuration utility) move the keys in slot 8 in node A to node B.

The move operation of the key is performed by the following two commands:

CLUSTERGETKEYSINSLOT slot count

The above command causes the node to return keys in count slot slots, and for each key returned by the command, redis-trib sends a MIGRATE command to node A, which atomic the specified key from node A to node B. during the move key, both nodes are blocked to avoid contention conditions.

The following is how the MIGRATE command works:

MIGRATEtarget_host target_port key target_database id timeout

The node that executes the MIGRATE command connects to the target node and sends the serialized key data to target, and once the target returns OK, the node deletes its own key from the database.

From the perspective of an external client, at some point in time, the key key exists either on node An or on node B, but not on both node An and node B.

Because the Redis cluster only uses database 0, when the MIGRATE command is used to perform cluster operations, the value of target_database is always 0.

The target_database parameter exists to make the MIGRATE command a generic command that can act on other functions outside the cluster.

We have optimized the MIGRATE command to remain efficient even when transferring complex data such as list keys containing multiple elements.

However, although MIGRATE is very efficient, for a cluster with a large number of keys and a very large amount of key data, cluster reconfiguration can take a lot of time and may cause the cluster to be unable to adapt to applications that have strict response time requirements.

ASK turns to:

In the previous introduction to MOVED steering, we said that in addition to MOVED steering, there is another ASK steering. When a node needs a client to permanently a command request for one slot to another node, the node returns a MOVED redirection to the client. On the other hand, when the node needs to redirect the client to another node only in the next command request, the node returns the ASK redirection to the client.

For example, in the example of slot 8 listed in the previous section, because the keys contained in slot 8 are scattered in node An and node B, when the client does not find a key in node A, it should turn to node B. but this shift should affect only one command query Instead of letting the client find node B directly every time: before all the keys belonging to slot 8 held by node An are migrated to node B, the client should access node A before accessing node B. Because this shift is targeted at only one of the 16384 slots, the performance loss caused by the shift to the cluster is acceptable.

For the above reasons, if we want to continue looking for node B after finding node A, then the client should send an ASKING command before sending a command request to node B, otherwise the command request for the slot with IMPORTING status will be rejected by node B. The node that receives the client ASKING command sets an one-time flag (flag) for the client so that the client can execute a command request for the slot in the IMPORTING state. From the client's point of view, the full semantics (semantics) of the ASK turn is as follows:

1. If the client receives an ASK redirection, the sending object of the command request is adjusted to the specified node.

two。 Send an ASKING command before sending a real command request.

3. There is no need to update the slot 8-to-node mapping recorded by the client: slot 8 should still be mapped to node A, not node B.

Once the migration of Node A for slot 8 is completed, when Node A receives the command request for slot 8 again, it returns the MOVED turn to the client and forwards the command request for slot 8 to Node B for a long time.

Note that even if the client has Bug and maps slot 8 to node B prematurely, as long as the client does not send an ASKING command, the client will encounter a MOVED error when sending a command request and turn it back to node A.

Fault tolerance:

Node failure detection, the following is the implementation method of node failure detection:

1. When one node sends a PING command to another node, but the target node fails to return a reply to the PING command within a given time limit, the node that sent the command marks the target node as PFAIL (possible failure, which may be invalid). The time limit for waiting for a reply from the PING command is called the Node timeout period (node timeout), which is a node option (node-wise setting).

two。 Every time a node sends a PING command to another node, it randomly broadcasts the information of three nodes it knows, one of which is whether the node has been marked as PFAIL or FAIL.

When a node receives information from other nodes, it records those nodes that are marked as invalid by other nodes. This is called a failure report (failure report).

3. If a node has marked a node as PFAIL, and according to the failure report received by the node, most other master nodes in the cluster also think that the node has entered the failure state, then the node will mark the status of that failed node as FAIL.

4. Once a node is marked as FAIL, information about the failure of that node is broadcast to the entire cluster, and all nodes that receive this information mark the failed node as FAIL.

To put it simply, if a node wants to mark another node as invalid, it must first consult other nodes and get the consent of most of the master nodes. Because expired failure reports are removed, the primary node must be based on the recently received failure report if it wants to mark a node as FAIL.

Slave node election: once a master node enters the FAIL state, if one or more slave nodes exist in the master node, one of the slave nodes will be upgraded to the new master node, while the other slave nodes will begin to copy the new master node.

The new master node is elected by all the slave nodes under the offline master node. The following are the election conditions:

1. This node is the slave node of the offline master node.

two。 The number of slots handled by the offline master node is not empty.

3. The data of the slave node is considered to be reliable, that is, the disconnection time of the replication connection (replication link) between the master and slave nodes cannot exceed the product of the node timeout period (nodetimeout) multiplied by the redis _ CLUSTER_SLAVE_VALIDITY_MULT constant.

If a slave node meets all the above conditions, the slave node will send an authorization request to the other master nodes in the cluster, asking them if they are allowed to upgrade to the new master node.

If the slave node that sent the authorization request meets the following attributes, the master node will return FAILOVER_AUTH_GRANTED authorization to the slave node and agree to the upgrade requirements of the slave node:

1. The authorization request is sent by a slave node, and the master node to which it belongs is in the FAIL state.

two。 Of all the slave nodes of the offline master node, the node ID of this slave node is the smallest in sorting.

3. This slave node is in a normal running state: it is not marked as FAIL, nor is it marked as PFAIL.

Once a slave node is authorized by most of the master nodes within a given time limit, it begins to perform the following failover operations:

1. Tell the other nodes through the PONG packet (packet) that this node is now the master.

two。 Tell other nodes through the PONG packet that this node is an upgraded slave node (promoted slave).

3. Claiming all hash slots handled by the offline master node.

4. Explicitly broadcasts a PONG packet to all nodes, accelerating the progress of other nodes in identifying this node instead of waiting for a timed PING / PONG packet.

All other nodes update the configuration accordingly according to the new primary node:

All slots taken over by the new master node will be updated.

All slaves of the offline master node will notice the PROMOTED flag and begin to copy the new master node.

If the offline master node comes back online, it will detect the PROMOTED flag and adjust itself to the slave node of the current master node.

You can get a high-quality video of Java architecture advanced technology. (high concurrency + Spring source code + JVM principle analysis + distributed architecture + micro-service architecture + multithreaded concurrency principle + BATJ interview treasure book)

During the life cycle of the cluster, if a master node with the PROMOTED identity becomes a slave node for some reason, then the node will lose its PROMOTED identity.

This is the end of the content of "what is the Redis cache used in the system"? thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.