go-redis

go-redis is the official Redis client for the Go programming language, maintained by Redis and offering a complete, idiomatic interface for talking to a Redis server or cluster. It wraps every core Redis command family (strings, hashes, sets, sorted sets, streams, geo, HyperLogLog, scripting) behind a single typed Client, handling connection pooling, retries, and RESP protocol encoding so application code never touches raw sockets.

Beyond basic commands, the library ships production features that most Go Redis wrappers leave out: automatic and manual pipelining, MULTI/EXEC transactions, Pub/Sub, Redis Sentinel and Redis Cluster clients with the same API surface as a standalone client, and client-side caching. This version tracks the v8 module line (github.com/go-redis/redis/v8), the long-lived release series that predates the project’s move to the redis/go-redis module path and v9 major version.

What You Get

• A typed Client/ClusterClient/SentinelClient covering the full Redis command set (strings, hashes, lists, sets, sorted sets, streams, geo, HyperLogLog, scripting) behind one consistent API
• Automatic connection pooling with configurable pool size, idle timeouts, and health checks baked into every client
• Pipelining and MULTI/EXEC transaction support for batching multiple commands into a single round trip
• Native Pub/Sub client for publish/subscribe messaging patterns
• Redis Sentinel support for automatic master discovery and failover in high-availability deployments
• Redis Cluster client that transparently handles slot routing, redirects (MOVED/ASK), and resharding
• Lua scripting helpers (Eval/EvalSha) with script caching for atomic server-side logic

Common Use Cases

• Application caching layer - services store and invalidate cached query results or computed values in Redis to cut database load
• Session storage - web backends keep user session state in Redis so any server instance can serve a logged-in request
• Rate limiting and counters - APIs use Redis INCR/expire semantics via go-redis to enforce per-user or per-IP request limits
• Pub/Sub messaging between services - lightweight event fan-out between Go microservices without a dedicated message broker
• Distributed locks and coordination - services use Redis-backed locks (often paired with companion libraries like redislock) to coordinate exclusive access across replicas

Under The Hood

Architecture The client is built around a shared baseClient embedded by Client, ClusterClient, Ring, and SentinelClient in redis.go and cluster.go, so every deployment topology reuses the same command execution, hook, and pipeline machinery while only the connection-resolution strategy differs (a single pool for Client, slot-aware routing across per-node pools for ClusterClient). A Hook interface (DialHook/ProcessHook/ProcessPipelineHook) lets callers wrap command execution for tracing or retries without touching internals, and connections themselves are managed by a dedicated pool package (internal/pool) that separates dialing, health-checking, and checkout/return logic from the command layer above it. Commands are generated onto the client via large per-datatype files (string_commands.go, hash_commands.go, sortedset_commands.go, etc.), keeping the RESP encoding/decoding (internal/proto) isolated from command definitions.

Tech Stack Written in idiomatic Go with zero required third-party runtime dependencies beyond small internal-use libraries (cespare/xxhash for cluster hashing, golang.org/x/sys for platform syscalls); optional integrations exist for OpenTelemetry tracing (extra/redisotel) and structured logging. The module targets modern Go versions and uses Go modules exclusively, with Docker Compose used to spin up real Redis/Sentinel/Cluster topologies for integration testing rather than mocking the protocol.

Code Quality The repository carries an unusually large test suite for a Go library — dozens of _test.go files covering unit tests, race-detector runs, and full integration suites (cluster routing, Sentinel failover, pipelining edge cases) exercised against dockerized Redis. CI runs golangci-lint, CodeQL static analysis, and govulncheck on every change, and errors are returned as typed Go errors rather than swallowed, consistent with idiomatic Go error handling throughout the command layer.

What Makes It Unique What distinguishes go-redis from lighter Redis wrappers is that Cluster, Sentinel, and standalone clients all share one command API — application code written against *redis.Client mostly works unchanged against *redis.ClusterClient — while pipelining, transactions, and Pub/Sub are first-class rather than bolted on. As the official client maintained directly by Redis, it also tracks new server-side command additions closely and is the reference implementation most Go tooling and tutorials assume.