Brief introduction to redis cache cluster

This is the back-end small class of the monastery. Each article is shared from

[background introduction] [knowledge analysis] [common problems] [solutions] [coding practice] [extended thinking] [more discussion] [References]

Eight aspects of in-depth analysis of back-end knowledge / skills. This article shares:

[brief introduction to redis cache cluster]

[Java class of Xiuzhen academy] brief introduction to redis cache cluster

Hello, I'm the 11th java student of Zhengzhou branch of it Academy. I'm an honest, pure and kind java programmer.

Today, I'd like to share with you a brief introduction to redis cache cluster.

1. Background introduction

Redis is a key value storage system. Similar to memcached, it supports more types of stored values, including string, list, set, Zset, sorted set, and hash. Redis largely compensates for the lack of key / value storage such as memcached, and can be a good supplement to relational databases in some cases.

Redis cluster is a facility that can share data among multiple redis nodes. Integrate multiple redis instances to form a cluster, that is, distribute the data to multiple machines in the cluster. When the amount of data is too large for a host, it is necessary to partition the data, calculate the key according to certain rules, and allocate the value corresponding to the key to the specified redis instance. This mode is referred to as redis cluster for short.

2. Knowledge analysis

Three cache strategies for redis master-slave replication

In master-slave replication, databases are divided into two types: master database and slave database. The master database can perform read-write operations. When data changes due to read-write operations, the data will be automatically synchronized to the slave database. The slave database is generally read-only, and the data synchronized from the master database is ended. A master can have more than one slave, but a slave can only correspond to one master.

When the slave is started, it actively sends the sync command to the master. After receiving the sync command, the master saves the snapshot in the background (RDB persistence) and cache the command to save the snapshot, and then send the saved snapshot file and cached command to the slave. After the slave receives the snapshot file and command, load the snapshot file and cached execution command. After replication initialization, each write command received by the master will be sent to the slave synchronously to ensure the consistency of master-slave data.

Redis three cache strategies - sentry

Sentinels are used to monitor the operation of the redis system. Their functions include: monitoring whether the master-slave database is running normally, automatically converting slave to master in case of master failure, automatic monitoring between sentinels in case of multi sentinel configuration, and multiple sentinels can monitor the same redis

The sentinel system composed of one or more sentinel instances can monitor any number of master servers and all slave servers under these master servers, and automatically upgrade a slave server under the offline master server to a new master server when the monitored master server enters the offline state.

Redis three cache strategies - cluster

Redis cluster is characterized by dividing the key space into 16384 slots, and each node is responsible for some of them. Redis provides a certain degree of availability and can continue to process commands when a node is down or unreachable. There is no central node or proxy node in the redis cluster

To sum up, the cluster features supported by redis include: automatic node discovery, online fragmentation, cluster fault tolerance, and configuration based cluster management

3. Frequently asked questions

1) Specific construction of redis cluster

4. Coding practice

5. Expand thinking

Redis cluster fragmentation mechanism.

Redis cluster does not use consistency hash, but introduces the concept of hash slot. A redis cluster contains 16384 hash slots. Each key in the database belongs to one of the 16384 hash slots. The cluster uses the formula CRC16 (key)% 16384 to calculate which slot the key belongs to. The CRC16 (key) statement is used to calculate the CRC16 checksum of the key. After each key is verified by CRC16, take the mold of 16384 to determine which slot to place Each node of the cluster is responsible for a part of the hash slot. This structure is easy to add or delete nodes, and no matter adding, deleting or modifying a node, it will not cause the cluster to be unavailable.

When is the entire cluster unavailable

1) If any master of the cluster hangs up and the current master does not have a slave The cluster enters the fail state, which can also be understood as entering the fail state when the slot mapping [0-16383] of the cluster is incomplete ps : redis-3.0. 0.rc1 add the cluster require full coverage parameter. It is closed by default. Opening the cluster compatibility section fails. 2) If more than half of the cluster masters hang up, the cluster will enter the fail state regardless of whether there is a slave or not

6. References

7. More discussion

1) Differences between redis and mongodb

Redis mainly stores data in memory. The nature of its "cache" is much greater than that of its "data storage". The addition, deletion, modification and query of data is just as simple as variable operation. It is suitable for the performance and operation of small amount of data.

Mongodb is a "data storage" system. Adding, deleting, modifying and querying can add many conditions, which is as flexible as SQL database, and the access efficiency of massive data is improved.

2) Does redis support transactions?

Transaction is supported. Either all commands are executed or not executed. However, it can only ensure that the operations in the transaction are executed in order.

3) Does the redis cluster have a core node?

Redis cluster adopts a decentralized structure. Each node saves data and the entire cluster state, and each node is connected to all other nodes. All redis nodes are interconnected (ping-pong mechanism), and binary protocols are used internally to optimize transmission speed and bandwidth. The client is directly connected to the redis node and does not need an intermediate proxy layer The client does not need to connect all nodes in the cluster, but any available node in the cluster.

Ppt link video link