LoginSign Up
← Back to all sparks
D

Dragonfly

INFRA · APIS
Velocity5.0

In-memory datastore compatible with Redis and Memcached

www.dragonflydb.io ↗

Dragonfly fixes dropped writes during slot migration and rebalances slot-based sharding.

in-memory datastoreclusteringdata consistencyperformancerelease maintenance
◆Current state
Dragonfly is maintaining two incremental lines, 1.40 and 2.0, with small, targeted releases. The 2.0 line fixed a slot-migration bug that silently dropped journal writes into empty buckets and changed experimental slot-based sharding to Fibonacci hashing so keys spread evenly. The 1.40 line received BLMOVE and Sidekiq queue-placement optimizations.
◆Where it's heading
Most of the work is in cluster mode: migrations, slot placement and topology replies. That suggests the 2.x line is being hardened for multi-node deployments, while 1.40 still gets backports and small performance fixes.
◆Prediction
The slot-based sharding flag looks likely to stay experimental for a while, with more balancing and migration fixes before it becomes a default.

◆Recent moves

  1. 8d ago

    i1.40.13: Sidekiq queues placed on the same shard

    A cherry-picked change maps Sidekiq's private and public queues to the same shard on the 1.40 line. It is a narrow placement tweak for one workload.

    View source ↗
  2. 8d ago

    i2.0.5: Fibonacci hashing evens out slot-based sharding

    With the experimental slot-based sharding flag, keys are now spread across shard threads with Fibonacci hashing instead of slot modulo shard count, which could pile structured key sets onto one thread. It is another step in tuning 2.x cluster mode.

    View source ↗
  3. 8d ago

    i1.40.12: single-shard BLMOVE completes in one hop

    A single-shard BLMOVE now completes in one hop when data is already available. It is a small latency fix on the 1.40 maintenance line.

    View source ↗
  4. 8d ago

    i2.0.4: slot migration no longer drops writes to empty buckets

    Slot migration now visits empty buckets, so writes landing in them during a migration are no longer silently dropped on the target. It is a data-consistency fix for cluster users, ported to the 2.0 line.

    View source ↗
  5. 9d ago

    i2.0.3: storage read-lifetime fix backported

    A backported fix for read lifetimes in the TS storage path, carried onto the 2.x incremental line. It continues the 2.x pattern of correctness work ahead of any new capability.

    View source ↗
  6. 9d ago

    i1.40.11: storage read-lifetime fix backported

    The same TS storage read-lifetime fix, shipped to the 1.40 line at the same moment as i2.0.3. Paired releases confirm 1.40 is still actively maintained alongside 2.x.

    View source ↗