Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

random_slicing

A four-peer in-memory pool using the random-slicing distribution mode, driven with 10,000 synthetic keys to report per-peer ownership. A window into the routing internals.

What it demonstrates

How the dispatcher turns a key into an owning peer, and how the random-slicing distribution mode spreads keys across peers. It builds the ring by hand -- four peers, one rack, one datacenter -- and then asks the dispatcher to plan 10,000 requests, counting where each lands.

#![allow(unused)]
fn main() {
let cfg = PoolConfig {
    dc: "dc1".into(),
    rack: "r1".into(),
    hash: HashType::Murmur3X64_64,
    distribution: Distribution::RandomSlicing,
    ..PoolConfig::default()
};
// ... build four Peers, mark them Normal, rebuild the ring ...
let disp = ClusterDispatcher::new(pool);

for i in 0..10_000 {
    let req = Msg::new(i as u64, MsgType::ReqRedisGet, true);
    let key = format!("key-{i:08x}");
    match disp.plan(&req, key.as_bytes()) {
        DispatchPlan::Replicas { targets, .. } => counts[targets[0].peer_idx as usize] += 1,
        DispatchPlan::LocalDatastore => counts[0] += 1,
        DispatchPlan::NoTargets | DispatchPlan::Drop => {}
    }
}
}

The output is a histogram of ownership -- the same information the operator command dyn-admin distribution-dump reports for a live cluster.

Design decisions and trade-offs

Hand-built pool, no server
This example constructs ServerPool and ClusterDispatcher directly rather than through ServerBuilder. It is studying the routing layer in isolation, so it skips listeners, gossip, and backends entirely.
DispatchPlan exposed
Matching on DispatchPlan::{Replicas, LocalDatastore, NoTargets, Drop} shows the four outcomes the planner can produce for a key. Only the first replica is counted here, which measures primary ownership.
10,000 synthetic keys
Enough to see the distribution shape without being slow. A perfectly even split would be 2,500 per peer; the spread from that is the point of comparing distribution modes.

Road not taken: only consistent hashing

Dynomite ships more than one distribution strategy. Random slicing trades the strict monotonicity of a plain token ring for more even rebalancing when peers are added or removed. This example exists so you can measure that trade-off rather than take it on faith; see Distribution Modes for the full comparison and when each is appropriate.

When to use this pattern

When you want to reason about or test routing and ownership without standing up a cluster: comparing distribution modes, checking that a token assignment balances, or unit-testing changes to the dispatcher.

Where to go next