Modules
Route keys and batches of items to sharded pools.
Behaviour for pool adapters.
Adapter for Ecto repos. Requires the optional :ecto dependency.
Adapter for any pool: you provide the child spec and the ref.
Adapter for Redis via Redix. Requires the optional :redix dependency.
Ref of a Redix shard pool with pool_size > 1: the connection names.
Result of Shardex.group/4: items grouped by shard, plus every item that
could not be routed with its reason. Items keep their input order.
Raised by Shardex.run_batch/5 with on_error: :raise when items cannot be routed.
Raised by the bang routing functions (ref!/3, run!/4).
One pool of a shard for a given role. ref is what callers receive
(a repo module, a registered name, ...). meta is adapter-specific.
A shard: a routing target with one pool per role (:primary, :replica, ...).
Behaviour for routing keys to shard names.
Caches another strategy's results in ETS. Useful for directory strategies that query a database.
Default strategy: :erlang.phash2(key, shard_count) over the configured
shard list. Adding or removing a shard remaps most keys; use
Shardex.Strategy.JumpHash if the shard count will grow.
Jump consistent hash (Lamping & Veach, 2014). Appending a shard to the end of the shard list moves only ~1/n of the keys, all of them to the new shard. Always append new shards; reordering or removing shards remaps keys.
Routes from a fixed map: {Shardex.Strategy.Static, map: %{key => shard}, default: shard}.
Without :default, unmapped keys are {:error, :unassigned}. Handy in tests.
Telemetry events emitted by Shardex. Every event's metadata includes :instance.