Command Reference
RESP2 (Redis-compatible)
Section titled “RESP2 (Redis-compatible)”| Command | Description |
|---|---|
ACL <subcommand> ... | Redis-flavored alias over RBAC: SETUSER, DELUSER, LIST, and LOG (the auth-failure audit trail). See ACL for details. |
AUTH [username] password | Authenticate with the server password. See AUTH for details. |
COMMAND <subcommand> ... | Command introspection: COUNT, DOCS, INFO, LIST, HELP. RESP2-only server capability discovery. See COMMAND for details. |
DEL key | Delete a key. Replies with the number of keys removed (0 or 1). See DEL for details. |
GET key | Retrieve a value, or a nil reply if the key doesn’t exist or has expired. See GET for details. |
PING [message] | Health check. Replies PONG or echoes the message. See PING for details. |
ROLE <subcommand> ... | Manage roles and users for role-based access control. See ROLE for details. |
SET key value [EX seconds | PX milliseconds] | Set a value, optionally with a TTL. Returns OK on success. See SET for details. |
STARTTLS | Upgrade a plaintext RESP2 connection to TLS 1.3 in place (requires --resp-starttls). See STARTTLS for details. |
Native binary protocol
Section titled “Native binary protocol”The binary protocol exposes the same operations as typed Go calls via the
client package, rather than as a text command line:
| Client call | Equivalent to |
|---|---|
c.Auth(password, scratch) | AUTH — authenticate after Dial when --require-pass is set. See AUTH for details. |
c.AuthUser(username, password, scratch) | AUTH <username> <password> — authenticate with RBAC when --rbac-config is set. |
c.Get(key, scratch) | GET — see GET |
c.Set(key, value, ttlMs, scratch) | SET with a millisecond TTL (0 = no expiry) — see SET |
c.Delete(key, scratch) | DEL — see DEL |
c.RoleCreate(...), c.RoleSetUser(...), … | ROLE subcommands. See ROLE for details. |
c.AclSetUser(...), c.AclDelUser(...), c.AclList(...), c.AclLog(...) | ACL subcommands, including the auth-failure log. See ACL for details. |
See Architecture for how the binary protocol and RESP share the same underlying storage engine.
Performance Considerations
Section titled “Performance Considerations”- All commands are designed for maximum performance with zero-copy operations where possible.
- The binary protocol is the fastest path for applications that can integrate directly with Go.
- RESP2 provides compatibility with existing Redis tools and client libraries.
On the roadmap
Section titled “On the roadmap”RESP3, INCR, EXPIRE, MULTI/EXEC, and commands operating on
list/set/hash types are planned for later phases — the storage engine stores
only byte-string values today (see
Data Model). See the
roadmap for what’s coming and when.