Redis Cluster feature Preview

Redis Cluster is still in Beta andRedis 3.0 will be added, where you can preview the main features and principles first. Refer to "Redis cluster-a pragmatic approach to distribution".

1without a clusterRedis

Rediswith no clustering capabilities, each master-slave master-slave replication is independent of the other nodes, andsharding needs to be controlled in the client such as Jedis . You can use the officially provided Sentinel to monitor the master-slave status for automatic fail-over switching. See Redis master-slave and ha configurationfor details.

2Cluster Topology

All nodes are connected directly to the other nodes, and the port is baseport (6379) +4000. For bandwidth and performance, the communication protocol is binary. The communication between the client and the node is still a normal ASCII protocol.

Although nodes are interconnected and functionally equivalent, there are actually two types of nodes that are divided into master and slave . As shown, each master has two copies, and the copy does not accept write requests. The redis-trib Cluster Manager assigns master and slaveto be on different physical machines as much as possible.

3Request Processing

Redis There are two categories of cluster clients:Dummy and Smart:

? Dummy mode: Single connection, random connection of a node, the existing client code structure has minimal impact.

? Smart mode: Long connect to many nodes, cache a copy of the hashslot=>node routing table on the client when receiving the -moved of the server Updates the table entry when responding. This approach has a low latency, but when the cluster is large, clients maintain many connections, and the client object instance should be shared at this time.

When you add a new node, you can use the redis-trib MIGRATE command to re-sharding.

Redis Cluster feature Preview