mirror of https://github.com/hanzokv/go.git synced 2026-09-24 00:31:51 +00:00

Files

T

zeekay 6994cf05aa kv, not redis: rename the package, the extras and the URL scheme

We do not use Redis. The client was a go-redis fork and still said so
everywhere: `package redis`, `redis.NewClient`, `redis://`, `extra/redisotel`.
Consumers wrote `redis.Client` against a Valkey-backed store called KV.

  package redis            -> package kv          (93 decls)
  redis.X                  -> kv.X                (2,794 call sites)
  "redis: …" errors        -> "kv: …"             (206)
  extra/redis{otel,cmd,prometheus,census} -> extra/kv{otel,cmd,prometheus,census}
  redis:// , rediss://     -> kv:// , kvs://      (ParseURL)
  Redis*/‌*Redis* idents    -> KV*/*KV*
  REDIS_VERSION, REDIS_ENDPOINTS_CONFIG_PATH -> KV_*

I previously argued this rename was unsafe because much of it was "wire
contract". That was wrong, and the categorisation shows why: RESP command names
are GET/SET/HSET — they never contain the word. Of 5,771 occurrences only two
kinds were server-visible at all: the ParseURL scheme (we choose what we pass;
our configs already use kv://) and the CLIENT SETINFO lib-name label, which the
server merely records. Nothing here changes a byte of protocol.

Two things deliberately keep the old spelling:
  RediSearch  — names a specific external module the FT.* commands map to.
  StoreDist   — contains the letters by accident (sto-reDis-t), not the word.

Breaking for consumers by design: every import site must move redis.X -> kv.X.
Minor bump, never a major — this module stays v9 forever.

2026-07-26 08:34:19 -07:00

2.2 KiB

Raw Permalink Blame History

Maintenance Notifications

Seamless KV connection handoffs during cluster maintenance operations without dropping connections.

⚠️ Important Note

Maintenance notifications are currently supported only in standalone KV clients. Cluster clients (ClusterClient, FailoverClient, etc.) do not yet support this functionality.

Quick Start

client := kv.NewClient(&kv.Options{
    Addr:     "localhost:6379",
    Protocol: 3, // RESP3 required
	MaintNotificationsConfig: &maintnotifications.Config{
        Mode: maintnotifications.ModeEnabled,
    },
})

Modes

ModeDisabled - Maintenance notifications disabled
ModeEnabled - Forcefully enabled (fails if server doesn't support)
ModeAuto - Auto-detect server support (default)

Configuration

&maintnotifications.Config{
    Mode:                       maintnotifications.ModeAuto,
    EndpointType:               maintnotifications.EndpointTypeAuto,
    RelaxedTimeout:             10 * time.Second,
    HandoffTimeout:             15 * time.Second,
    MaxHandoffRetries:          3,
    MaxWorkers:                 0,    // Auto-calculated
    HandoffQueueSize:           0,    // Auto-calculated
    PostHandoffRelaxedDuration: 0,    // 2 * RelaxedTimeout
}

Endpoint Types

EndpointTypeAuto - Auto-detect based on connection (default)
EndpointTypeInternalIP - Internal IP address
EndpointTypeInternalFQDN - Internal FQDN
EndpointTypeExternalIP - External IP address
EndpointTypeExternalFQDN - External FQDN
EndpointTypeNone - No endpoint (reconnect with current config)

Auto-Scaling

Workers: min(PoolSize/2, max(10, PoolSize/3)) when auto-calculated Queue: max(20×Workers, PoolSize) capped by MaxActiveConns+1 or 5×PoolSize

Examples:

Pool 100: 33 workers, 660 queue (capped at 500)
Pool 100 + MaxActiveConns 150: 33 workers, 151 queue

How It Works

KV sends push notifications about cluster maintenance operations
Client creates new connections to updated endpoints
Active operations transfer to new connections
Old connections close gracefully

2.2 KiB Raw Permalink Blame History Unescape Escape