[kv] Run MultiGet outside the KV lock with snapshot read views #4767

Search before asking

• I searched in the issues. Related: [kv] Improve point lookup concurrency with KV writes #4057 proposes splitting the mutation and state locks; this issue proposes a snapshot-based read view without restructuring the write-side locking.

Motivation

KvTablet.multiGet() holds the KV read lock across RocksDB MultiGet and result conversion. Large batches and block-cache misses extend this critical section and delay puts and flushes on the same tablet.

The goal is to shorten the critical section while preserving committed-data visibility, batch consistency, and safe RocksDB shutdown. This is a read/write contention improvement, not an unconditional point-read acceleration.

Solution

Acquire a RocksDB snapshot and a ResourceGuard.Lease under the existing KV read lock, then release the lock before MultiGet. Use the captured snapshot through dedicated ReadOptions, release the native read resources after MultiGet, and convert the returned values outside the lock.

Required properties:

• Capture the view while serialized with logical flushes, so a lookup cannot observe an intermediate segment of a flush.
• Preserve input order, duplicate keys, missing-key nulls, and committed RocksDB visibility.
• Keep RocksDB alive until the native read and snapshot cleanup finish; close/drop must wait for existing leases and reject new reads.
• Release the snapshot, read options, and lease on success and failure.
• Preserve the existing write-side lock ordering.

This can reuse the read-resource lifecycle protections in #4749.

Anything else?

JMH evaluation on Apple M4, ARM64 JDK 11, RocksDB JNI 11.8.1-fluss-3 used 262,144 keys, 256-byte values, partitioned index/filter, and HyperClockCache. The experiment covered 150 independent JVM forks; each comparison used five paired forks.

For 256-key reads with seven readers and one writer targeting 100 atomic 32-key write batches/s:

The pure single-key hot-cache read throughput regressed 6.39% (paired 95% interval: -8.25% to -4.50%), with approximately 144 additional Java heap bytes per batch. Pure 256-key reads showed no statistically clear change. Saturated-writer results change the accepted write load and must not be presented as same-load read speedups.

The writer exercises the native KV critical section, not Fluss WAL, RPC, or replication. Small-cache misses may hit the OS page cache. These results do not predict end-to-end cluster throughput. The single-key tradeoff needs review before merging.

Willingness to contribute

• I'm willing to submit a PR!