Redis hard
In a Redis Cluster, why do nodes include state information about *other* random nodes within their own `PING/PONG` heartbeat packets?
- A To artificially inflate network bandwidth usage to ensure the underlying hardware stays in a high-power state.
- B To enable Failure Detection via Gossip; sharing 'views' allows the cluster to reach failure consensus efficiently.
- C To provide a backup routing path for cross-shard data requests if the primary master node is temporarily unreachable.
- D To synchronize the physical hardware clocks of all nodes to within a 1-microsecond window to prevent drift errors.
Answer: B. To enable Failure Detection via Gossip; sharing 'views' allows the cluster to reach failure consensus efficiently.
Every node doesn't need to ping every other node. If Node A pings Node B and says 'I haven't seen Node C in 10s', Node B records that 'opinion'. When enough nodes agree Node C is down (Quorum), a failover is triggered.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- If the Redis memory limit is reached, what specific behavior is exhibited by the `allkeys-lru` eviction policy?
- What is the defining characteristic of a Redis 'Set' data type compared to a standard Redis 'List'?
- In the context of Redis messaging, what is the functional definition of the 'Pub/Sub' feature?
- How does the Redis background snapshotting process (`BGSAVE`) leverage the operating system's `fork()` mechanism to minimize memory overhead?
- Why does Redis proactively disconnect a Pub/Sub client that exhibits high 'output buffer' usage relative to its ingestion rate?
- How does a 'Sorted Set' (ZSET) manage its internal membership and ordering differently from a plain Set?