Package Usage: go: github.com/mediocregopher/radix/v3
Package radix implements all functionality needed to work with redis and all
things related to it, including redis cluster, pubsub, sentinel, scanning,
lua scripting, and more.
For a single node redis instance use NewPool to create a connection pool. The
connection pool is thread-safe and will automatically create, reuse, and
recreate connections as needed:
If you're using sentinel or cluster you should use NewSentinel or NewCluster
(respectively) to create your client instead.
Any redis command can be performed by passing a Cmd into a Client's Do
method. Each Cmd should only be used once. The return from the Cmd can be
captured into any appopriate go primitive type, or a slice, map, or struct,
if the command returns an array.
FlatCmd can also be used if you wish to use non-string arguments like
integers, slices, maps, or structs, and have them automatically be flattened
into a single string slice.
Cmd and FlatCmd can unmarshal results into a struct. The results must be a
key/value array, such as that returned by HGETALL. Exported field names will
be used as keys, unless the fields have the "redis" tag:
Embedded structs will inline that struct's fields into the parent's:
The same rules for field naming apply when a struct is passed into FlatCmd as
an argument.
Cmd and FlatCmd both implement the Action interface. Other Actions include
Pipeline, WithConn, and EvalScript.Cmd. Any of these may be passed into any
Client's Do method.
There are two ways to perform transactions in redis. The first is with the
MULTI/EXEC commands, which can be done using the WithConn Action (see its
example). The second is using EVAL with lua scripting, which can be done
using the EvalScript Action (again, see its example).
EVAL with lua scripting is recommended in almost all cases. It only requires
a single round-trip, it's infinitely more flexible than MULTI/EXEC, it's
simpler to code, and for complex transactions, which would otherwise need a
WATCH statement with MULTI/EXEC, it's significantly faster.
All the client creation functions (e.g. NewPool) take in either a ConnFunc or
a ClientFunc via their options. These can be used in order to set up timeouts
on connections, perform authentication commands, or even implement custom
pools.
All interfaces in this package were designed such that they could have custom
implementations. There is no dependency within radix that demands any
interface be implemented by a particular underlying type, so feel free to
create your own Pools or Conns or Actions or whatever makes your life easier.
Errors returned from redis can be explicitly checked for using the the
resp2.Error type. Note that the errors.As function, introduced in go 1.13,
should be used.
Use the golang.org/x/xerrors package if you're using an older version of go.
Implicit pipelining is an optimization implemented and enabled in the default
Pool implementation (and therefore also used by Cluster and Sentinel) which
involves delaying concurrent Cmds and FlatCmds a small amount of time and
sending them to redis in a single batch, similar to manually using a Pipeline.
By doing this radix significantly reduces the I/O and CPU overhead for
concurrent requests.
Note that only commands which do not block are eligible for implicit pipelining.
See the documentation on Pool for more information about the current
implementation of implicit pipelining and for how to configure or disable
the feature.
For a performance comparisons between Clients with and without implicit
pipelining see the benchmark results in the README.md.
21 versions
Latest release: almost 3 years ago
360 dependent packages
View more package details: https://packages.ecosystem.code.gouv.fr/registries/proxy.golang.org/packages/github.com/mediocregopher/radix/v3