Redis Can Do Clusters Now?

Yes! On April 1, 2015, Redis released Version 3.0.0. Among the key features new to the release was the addition of Redis Cluster mode. The latter is a distributed implementation that supports high performance and linear scalability up to 1,000 total nodes, with automatic sharing and significant fault tolerance. The following article will take a glimpse at Redis Cluster mode, its design, and some key capabilities.

Redis Cluster Topology

Nodes in Redis Cluster communicate with one another node-to-node via the Cluster Bus. Redis is currently capable of supporting up to 1,000 nodes, down to a minimal working cluster of three master nodes. The nodes communicate along a TCP connection to form a fully connected network link for cluster operations, such as failure detection, failover authorization, and config updates. The Cluster Bus is a dedicated channel, isolated from normal client connections, for which reason its binary protocol is undocumented.

Reliability and Write Safety

Redis Cluster is highly reliable in that it uses asynchronous replication, without any proxies or merge operations carried out on values, opting instead to have the last available dataset override any replicas. Cluster can also work on any partition where at least the majority of master nodes are reachable, and at least one slave node (if there are any slaves) is reachable for each unavailable master node. Furthermore, Redis employs replicas migration, in which non-slave-replicated master nodes are replicated by another master node that is itself covered by multiple slaves. Cluster’s architecture also takes pains to favor writes performed by clients that are connected to the majority of masters, over those performed on the minority side, as the latter have a much greater timeframe in which to get lost.

Fast Traffic Flow and Timely Error Detection

Redis Cluster information propagation operates by the continuous one-to-one exchange of raw binary PING / PONG packets through same Cluster Bus. Each of these packets transmits vital information from the sender node about the cluster state, e.g. config information or hash slot distribution. To avoid packet overload on the network, nodes generally ping just a handful of other random nodes per second.

Moreover, as a means of regulating the volume of heartbeat packet exchange from one node to another, with a mind to ensure a steady network traffic flow, every node in the cluster will attempt to ping all nodes that have either failed to send out a PING packet, or else have been receiving a PONG packet for longer than half their respective timeout limit. This mechanism further serves to detect failures by attempting to renew TCP connection significantly prior to timeout expiration.

MEET Packets – Safe Incorporation of New Nodes into Existing Clusters

Another key feature of Redis Cluster is the facility it offers in terms of new cluster identification and integration, thanks to the use of MEET packets. These are similar in their binary structure to PING / PONG packets, but designed to accommodate a new sender’s acceptance as a trusted node within an existing cluster. MEET packets are transmitted to cluster nodes to securely introduce a hitherto untrusted sender source to the system, authenticate it as a trustworthy node, and bootstrap it to that cluster. This is highly useful in bootstrapping, as in the absence of this MEET packet, the sender will merely be blindly PONG-ed in reply to its outgoing PING, without any of its other packets being processed.