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

This article will explain the method of redis cluster for you in detail. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

Redis Sharding cluster

Redis Sharding is a client-side Sharding sharding technology.

Redis Sharding can be said to be a multi-Redis instance clustering method commonly used in the industry before Redis Cluster came out. The main idea is to use the hash algorithm to hash the key of Redis data. Through the hash function, a specific key will be mapped to a specific Redis node.

In this way, the client knows which Redis node to manipulate the data to, and it is important to note that this is done on the client side.

Java redis client jedis, which already supports the Redis Sharding feature, that is, ShardedJedis and ShardedJedisPool combined with cache pools. The Redis Sharding implementation of Jedis has the following characteristics:

1. Use consistent hash algorithm (consistent hashing)

Hash key and node name at the same time, and then map and match. The algorithm is MURMUR_HASH. The main reason for consistent hashing is that when nodes are added or decreased, there is no rehashing caused by rematching. The consistent hash only affects the key allocation of neighboring nodes, and the impact is small. For more introduction to consistent hashing algorithms, please refer to: http://blog.csdn.net/cywosp/article/details/23397179/

2. Virtual node

For each Redis node, ShardedJedis virtualizes 160 virtual nodes by name for hashing. By mapping and matching with virtual nodes, when adding or decreasing Redis nodes, the movement of key in each Redis node is more evenly distributed, rather than only neighboring nodes are affected. As shown in the figure, Redis node 1 is virtualized into NODE1-1 and NODE1-2, on the hash ring. In this way, when object1 and object2 hash, the nearest nodes NODE1-1 and NODE1-2 are selected, and NODE1-1 and NODE1-2 are the virtual nodes of the NODE node, that is, they are actually stored on the NODE node.

Adding virtual nodes can ensure balance, that is, each Redis machine stores about the same amount of data, rather than one machine stores more data and the other less.

3. ShardedJedis supports keyTagPattern mode.

Extract a part of the keyTag of the key to sharding, so that by reasonably naming the key, you can put a group of associated key into the same Redis node to avoid cross-node access. That is, the client stores the key value of the same rule on the same Redis node.

When adding or decreasing nodes?

Redis Sharding adopts the client-side Sharding mode, and the server-side Redis is a relatively independent Redis instance node. At the same time, we do not need to add additional intermediate processing components, which is a very lightweight and flexible Redis multi-instance clustering solution.

Of course, this lightweight and flexible approach is bound to make compromises in other capabilities of the cluster. For example, when you want to add Redis nodes, although consistent hash is used, then different key is distributed to different Redis nodes.

When we need to expand capacity, add machines to the sharding list. At this time, the client will fall on a different machine according to the key calculation, so that if you want to take a certain value, you will not be able to get it.

In this case, the general practice is to reload the data directly from the back-end database after it can not be fetched, but sometimes it will cause great pressure on the system access by breaking through the cache layer and directly accessing the database layer.

The author of Redis gives an idea-- presharding.

It is a method of online capacity expansion. The principle is to run multiple Redis instances with different ports on each physical machine. If there are three physical machines and each physical machine runs three Redis instances, then there are actually nine Redis instances in our shard list. When we need to expand capacity, add one physical machine as follows:

1. Run Redis-server on the new physical machine

2. The Redis-server belongs to a Redis-Server (assumed to be RedisA) in the (slaveof) sharding list.

3. After the master-slave replication (Replication) is completed, change the IP and port of RedisA in the client shard list to the IP and port of Redis-Server on the new physical machine.

4. Stop RedisA

This is equivalent to transferring a Redis-Server to a new machine. However, it still depends on the replication feature of Redis itself. If the snapshot data file of the main database is too large, the replication process will take a long time, and it will also put pressure on the master Redis. Therefore, it is best to choose the low peak period of business access for this split process.

When a node fails

It is not only the addition and deletion of Redis nodes that cause the problem of key value loss, the bigger obstacle comes from the sudden downtime of Redis nodes.

In order not to affect the performance of Redis, try not to enable AOF and RDB file saving features, so you need to construct the Redis master / slave mode, the master Redis goes down, the slave Redis keeps a backup, and the data will not be lost.

The Sharding evolves as follows:

In this way, our architecture model is changed into a Redis node slice containing a master Redis and a standby Redis, and the master and standby together form a Redis node, which ensures the high availability of the node through automatic failover.

Redis Sentinel Sentinel

Functions such as Redis monitoring and failover in active and standby mode are provided to achieve high availability of the system.

Separation of reading and writing

Under high access time, even if Sharding sharding is used, a single node still bears a lot of access pressure, so we need to further decompose it.

In general, reading is often several times as much as writing, so we can separate reading from writing and provide more instances. The master-slave mode is used to realize the separation of reading and writing, the master is responsible for writing, the slave is responsible for read-only, and one master hangs multiple slaves at the same time. Under the monitoring of Redis Sentinel, it can also ensure the automatic monitoring of node faults.

This is the end of the method of redis cluster. I hope the above content can be helpful to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

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.