GitHub user Aetherance added a comment to the discussion: Proposal: Keyspace Notifications for Kvrocks
Thanks @jihuayu. I've reworked the design based on your feedback. The new approach no longer writes markers into the `WriteBatch` — instead it derives `set`/`del` from records already in the WAL, so nothing extra is added to the WAL or the replication stream. Primary and replica run the same derivation at different points (the primary after its write, the replica reusing the iteration already done in `parseWriteBatch`), so events are identical on both. The scope stays `set`/`del` only, and everything else matches the proposal. The one behavioral change vs. the proposal: since events are now derived from storage effects rather than written per-command, `set`/`del` are broader than the literal commands: - `set` fires for any write to a string key — `SET`/`APPEND`/`INCR`/`SETRANGE`/`GETSET`, and even `GETEX` (which only touches the TTL). It can't be narrowed to the literal `SET` command, since the original command isn't recoverable from the WAL. - `del` fires for any key removal — including a collection being emptied — not just the `DEL` command. This matches Redis ([docs](https://redis.io/docs/latest/develop/pubsub/keyspace-notifications/#events-generated-by-different-commands)). Is this broadening acceptable for the initial scope? If so, I'll update the proposal accordingly and implement it in two PRs (primary/standalone first, then replica). GitHub link: https://github.com/apache/kvrocks/discussions/3533#discussioncomment-17386894 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
