Go client for Redis



Build Status GoDoc

Redigo is a Go client for the Redis database.




Install Redigo using the "go get" command:

go get github.com/gomodule/redigo/redis

The Go distribution is Redigo's only dependency.

Related Projects




Redigo is available under the Apache License, Version 2.0.

  • gomod


    Fixes #366 (I think).

    Once merged, additional tags need to be added to the repo:

    • redis/v3.0.0
    • redisx/v3.0.0

    This will make this repo support go modules, and follows the official guidance of bumping the major version when there are released tags that are not actually for go mod.

    It maybe worth considering not having the redis and redisx modules in the same repo. Before taking this change might be a good opportunity to do that since consumers will have to change the import path, anyway.

    At the very least, it may be worthwhile to move the redisx package out of this repo, since it's intended to be experimental and should probably remain v0.

    opened by dcormier 45
  • what is the 'ERR :0' meaning?

    what is the 'ERR :0' meaning?

    I got a lot of errors , which are 'ERR :0' or 'ERR :1', I got them from my log file. cmds and errors:

    log.2015-01-24.001:2015/01/24 11:26:35 [EE] db.go:59 handleDBQueue(): [asyncDB {233 0xc208f28980 HSET [user:233:accepted_quest:254 step 8]} ERR :0]
    log.2015-01-24.001:2015/01/24 14:07:49 [EE] db.go:59 handleDBQueue(): [asyncDB {301 0xc208386ec0 HSET [user:301:baseInfo shenshou_curr 23]} ERR :0]
    log.2015-01-24.001:2015/01/24 21:13:14 [EE] db.go:59 handleDBQueue(): [asyncDB {557 0xc208fa3a80 HSET [user:557:guides drawcard 999]} ERR :0]
    log.2015-01-25.001:2015/01/25 08:27:21 [EE] db.go:59 handleDBQueue(): [asyncDB {150 0xc208f7ee40 HSET [user:150:baseInfo exp 293]} ERR :0]
    log.2015-01-25.001:2015/01/25 13:10:19 [EE] db.go:59 handleDBQueue(): [asyncDB {63 0xc208880d40 HSET [user:63:guanqiaDetail:69 simpleCanWipe 1]} ERR :1]
    log.2015-01-25.001:2015/01/25 13:25:01 [EE] db.go:59 handleDBQueue(): [asyncDB {688 0xc208d21500 HSET [user:688:guides employ 999]} ERR :1]
    log.2015-01-25.001:2015/01/25 17:37:42 [EE] db.go:59 handleDBQueue(): [asyncDB {752 0xc208f9c700 HSET [user:752:baseInfo shenshou_curr 0]} ERR :1]
    log.2015-01-25.001:2015/01/25 19:31:19 [EE] db.go:59 handleDBQueue(): [asyncDB {0 <nil> LPUSH [opcode:133 2927603]} ERR :178]
    log.2015-01-25.001:2015/01/25 19:31:19 [EE] db.go:59 handleDBQueue(): [asyncDB {679 0xc208742c80 HSET [user:679:accepted_quest:5 step 1]} ERR :0]
    log.2015-01-26.001:2015/01/26 02:29:02 [EE] db.go:59 handleDBQueue(): [asyncDB {0 <nil> LPUSH [opcode:9 2915959]} ERR :8805]
    log.2015-01-26.001:2015/01/26 02:29:05 [EE] db.go:59 handleDBQueue(): [asyncDB {11 0xc2091b80c0 HSET [user:11:accepted_quest:175 step 4]} ERR :0]
    log.2015-01-26.001:2015/01/26 07:42:15 [EE] db.go:59 handleDBQueue(): [asyncDB {0 <nil> LPUSH [opcode:16 8901047]} ERR :415]
    log.2015-01-26.001:2015/01/26 11:30:00 [EE] db.go:59 handleDBQueue(): [asyncDB {0 <nil> LPUSH [opcode:108 6737109]} ERR :874]
    log.2015-01-27.001:2015/01/27 01:59:51 [EE] db.go:59 handleDBQueue(): [asyncDB {0 <nil> LPUSH [opcode:134 8056353]} ERR :1041]
    log.2015-01-27.001:2015/01/27 09:35:45 [EE] db.go:59 handleDBQueue(): [asyncDB {945 0xc208537280 HSET [user:945:baseInfo exp 318]} ERR :0]
    log.2015-01-27.001:2015/01/27 15:52:24 [EE] db.go:59 handleDBQueue(): [asyncDB {218 0xc20870b400 HSET [user:218:accepted_quest:119 finish 1]} ERR :0]
    log.2015-01-28.001:2015/01/28 00:42:08 [EE] db.go:59 handleDBQueue(): [asyncDB {1034 0xc2086737c0 HSET [user:1034:baseInfo armUpgradeStone 76]} ERR :0]
    log.2015-01-28.001:2015/01/28 02:24:20 [EE] db.go:59 handleDBQueue(): [asyncDB {1070 0xc208838b40 HSET [user:1070:baseInfo login_arm 0]} ERR :0]
    log.2015-01-28.001:2015/01/28 10:51:24 [EE] db.go:59 handleDBQueue(): [asyncDB {205 0xc20d31f140 HSET [user:205:baseInfo power 16]} ERR :0]
    log.2015-01-28.001:2015/01/28 15:06:34 [EE] db.go:59 handleDBQueue(): [asyncDB {614 0xc208838ec0 HSET [user:614:accepted_quest:142 step 6]} ERR :0]
    log.2015-01-28.001:2015/01/28 18:33:58 [EE] db.go:59 handleDBQueue(): [asyncDB {105 0xc208e129c0 SADD [user:105:arms 432]} ERR :1]
    log.2015-01-28.001:2015/01/28 22:06:15 [EE] db.go:59 handleDBQueue(): [asyncDB {1134 0xc208c8d040 HSET [user:1134:guides drawcard 999]} ERR :0]
    log.2015-01-29.001:2015/01/29 14:09:00 [EE] db.go:59 handleDBQueue(): [asyncDB {124 0xc208556b40 HSET [user:124:baseInfo pkCount 5]} ERR :0]
    log.2015-01-29.001:2015/01/29 18:28:22 [EE] db.go:59 handleDBQueue(): [asyncDB {0 <nil> LPUSH [opcode:6 10966403]} ERR :21811]

    what does this mean? where does it come from ? It happend sometimes and I couldn't get it in my test.

    opened by linshibo 29
  • Issue#405 Support for SLOWLOG GET command

    Issue#405 Support for SLOWLOG GET command

    This PR provides support for SLOWLOG GET command results. A new struct SlowLog has been added which contains the details of the SlowLogs obtained by calling the helper SlowLog

    // SlowLog represents a redis SlowLog
    // slowLogID - A unique progressive identifier for every slow log entry.
    // unixTimeStamp - The unix timestamp at which the logged command was processed.
    // executionTime - The amount of time needed for its execution, in microseconds.
    // args - The array composing the arguments of the command.
    // clientIPAddressAndPort - Client IP address and port (4.0 only).
    // clientName - Client name if set via the CLIENT SETNAME command (4.0 only).
    type SlowLog struct {
    	SlowLogID              int64
    	UnixTimeStamp          int64
    	ExecutionTime          int64
    	Args                   []string
    	ClientIPAddressAndPort string
    	ClientName             string

    Addresses: #405

    opened by rammantripragada 25
  • Support for redis sentinel

    Support for redis sentinel

    Briefly, the SentinelClient supplied by sentinel.go represents a connection to a bundle of sentinels. While only one connection is active at a time, the SentinelClient will failover its internal connection to all configured sentinels before failing any individual operation.

    The SentinelClient has a Dial method, which connects to the sentinel, and DialMaster and DialSlave methods, which connect to the named master or slaves of the named master, respectively.

    The SentinelAwarePool supplied in pool.go is extremely simple. I wanted to avoid an overly-complex implementation here, because I don't have a lot of operational experience with the Pool. The only differences are the addition of a TestOnReturn entry point, which is designed to test returned connections for role changes, and a method to update the internal accounting of the master's address. (Role detection and test wrappers are supplied in sentinel.go). The only meaningful operational difference to the SentinelAwarePool is the ability to purge all idle connections if the master's configuration changes. (active connections will be handled by TestOnReturn).

    An example of usage of the SentinelAwarePool is supplied in pool.go.

    I believe I have supplied sufficient capability here for a barebones but fully capable sentinel configuration, and enough tools and flexibility for a user to build a more complex setup (including using Sentinel pubsub, which is not included here.)

    I've tested this (both pool and standalone connections) on a new 2.8 cluster and an older 2.6-era cluster which does not have CLIENT kill. I would appreciate additional testing and validation if possible, especially on the new 3.0 cluster which I do not have access to.

    opened by hbcheng 24
  • Support Go Modules

    Support Go Modules

    This repo was moved from here from garyburd/redigo. At the time of the move, I made some minor breaking changes to the API and tagged a v2.0.0 release.

    The v2.0.0 release turned out to be a problem when Go Modules were introduced. It's now clear that I should have deleted previous v1.x.x releases from the repo and tagged a new v1.0.0 release.

    I was my intent that this repo have one major semantic version until the next breaking API change is made. Let's call the major semantic version as of today as version N.

    ~~It's possible that users who employ a dependency management tool are using the tags copied over from garyburd/redigo. These users are on major version N-1.~~ Edit: These versions do not compile because they have a package import comment for garyburd/redigo. It's safe to assume that there are no users of these versions.

    Users of Go 1.5+ who do not employ a dependency management tool should continue to get the latest of major version N. This works today and should continue to be supported until Go Modules is widely adopted.

    Users who opt into Go Modules should not need to change their code.

    Because I expect Go Modules to be widely adopted before major version N+1 of this package is created, it's acceptable to require a dependency management tool to get version N+1.

    Adding a go.mod file to a v2.x.x release changes the path of the package to github.com/gomodule/redigo/v2. This requires a change to all importers of the packages and does not work for users on Go 1.8 and earlier.

    See previous discussion in #365 and #363.

    Help wanted 
    opened by garyburd 23
  • Feature request:  add support for context.Context

    Feature request: add support for context.Context

    The use of context.Context is recommended for cancellation and deadlines. It would be helpful if redigo could support context.Context and be able to cancel early when needed.

    opened by wuman 23
  • New maintainers needed

    New maintainers needed

    I am stepping down as maintainer of of Redigo on May 1st. Use this issue to suggest and discuss new maintainers for the project. I want to have some consensus on the new maintainers before handing the project off.

    Help wanted 
    opened by garyburd 20
  • cannot load github.com/gomodule/redigo

    cannot load github.com/gomodule/redigo

    build command-line-arguments: cannot load github.com/gomodule/redigo: module github.com/gomodule/[email protected] found (v2.0.0+incompatible), but does not contain package github.com/gomodule/redigo

    can anyone help? go version 1.13.11

    opened by lovegnep 18
  • #480 broke Heroku Redis

    #480 broke Heroku Redis

    #480 broke compatibility with Heroku Redis. Before 1.8.2 I was able to connect to Heroku Redis by using the DialURL method. I guess #480 broke this because I started seeing this error after upgrading redigo to 1.8.2: ERR wrong number of arguments for 'auth' command. This is just an assumption but yeah... Will investigate further if I have a bit more time on my hands.

    Waiting for response 
    opened by lukasmalkmus 18
  • Support for context-aware connection

    Support for context-aware connection

    Similar to the ConnWithTimeout interface that implements the Do/Receive methods with an extra time.Duration parameter, I think it would be useful to add in a ConnWithContext interface that takes an extra context.Context parameter. Many other Golang libraries are starting to adopt context.Context usage for cancellation since it was put into the standard library. Additionally, this proposed change shouldn't make any breaking changes to this package's public API. I am happy to implement this feature if I get the green light from whoever maintains this package - I just wanted to start up a discussion first per https://github.com/gomodule/redigo/blob/master/.github/CONTRIBUTING.md.

    opened by smotes 18
  • Consider blocking on request for connection from pool when exhausted

    Consider blocking on request for connection from pool when exhausted

    Presently, if a connection from a pool is requested with pool.Get() and the number of connections active has reached MaxActive then Get() will return the error errPoolClosed.

    I feel its more expected by the application developer to always get a connection when calling pool.Get() -- unless the server is down or something. If a function needs to get/set data to redis, then it needs to do that, if the pool is exhausted because of high load on the application, then should it just keep looping asking for a connection until it's not exhausted anymore?

    Perhaps having an async (as it is now) and sync Get() for requesting a connection.. like: pool.Get() to be synchronous and pool.GetOrFail() as async. Perhaps the sync Get() should also return an error after X time of waiting. pool.Get(&redis.Wait{5}) .. and a default config option on the pool struct.

    I wonder how application developers are using redigo's Pool{} stuff, I can imagine most are leaving MaxActive as 0 and just hoping the max number of connections on their system or server never hits. Considering that, there should be a default for MaxActive, not infinity. And MaxIdle should be some reasonable number as well. I wonder how other database drivers do it...? ie. database/sql.

    I think it keeps it much simpler and expected for the app developer. At least for me..

    Enhancement Help wanted 
    opened by pkieltyka 18
  • fix: respect ctx in cmds run within DialContext

    fix: respect ctx in cmds run within DialContext

    The new DialContext() function currently does not respect the ctx timeouts when configuring auth/clientName/db during connection creation. If the Redis server is unresponsive, this can cause DialContext() to run for a very long time (instead of cancelling when the deadline is exceeded). DoContext should be used for these cmds.

    Repro steps:

    1. Make Redis unresponsive: CLIENT PAUSE 36000000 ALL
    2. Attempt to DialContext() with a 1sec timeout
    3. Command is unexpectedly blocked for a long time
    opened by mitchsw 0


    Redis Latency Monitor is very useful tool for performance investigations with Redis. We needed an ability to parse results of LATENCY LATEST and LATENCY HISTORY commands to build a monitoring tool for Redis.

    Please review an attached PR https://github.com/gomodule/redigo/pull/614. We've already implemented this functionality at our client side, but it makes more sense to share it with wider community via this patch.

    opened by dmitri-lerko 0
  • Redigo client connection does NOT reused/returned to the Pool post close() call.

    Redigo client connection does NOT reused/returned to the Pool post close() call.

    Ask questions at https://stackoverflow.com/questions/ask?tags=go+redis

    We have specific use case where we are using redis-graph which uses redigo connections underlying. We are using redigo Pools for achieving concurrency. However, seems for every Close() call for the redigo connection, connections are NOT getting returned back to the Pool.

    As, per documentation of redigo API reference, the application shall close() the redigo connection, once usage is done. This behavior seems to re-create the new underlying network level connection with redis server in the even though from the Pool().

    Redigo Pool implementation does NOT provide a way to return the used redigo connections back to Pool, so that next time those can be reused.

    opened by JayShahSTL 1
  • OpenTelemetry tracing manual instrumentation support

    OpenTelemetry tracing manual instrumentation support

    In the same way as seen on the OpenTelemetry instrumentation forgo-redis it would be extremely beneficial to create a similar package for redigo. Not only we can track the overhead of the client code, but we can also precisely trace errors/latency spikes/timeouts/etc...

    Some further info:

    Important Note: Semantic conventions to follow while preparing a package for manual instrumentation.

    While this is not mandatory, we should aim for standardization across clients/languages/DBs. Here's the spec on DB semantic conventions:


    PS: will gladly contribute to this matter.

    opened by filipecosta90 0
  • v1.8.8(Jan 4, 2022)

  • v1.8.7(Jan 4, 2022)

  • v1.8.6(Dec 2, 2021)

  • v1.8.5(Jun 10, 2021)

  • v1.8.4(Feb 18, 2021)

  • v1.8.3(Nov 24, 2020)

    New Features

    • Add TLS Handshake timeout support (#530)


    • Typo in Float64 documentation (#515)
    • GetContext must return errorConn (#494)
    • Correct type in Ints documentation (#528)
    • Open connection count (#527)
    • Add end of terms and conditions in LICENSE (#531)
    • Revert "fix: go get example in README.md (#488)" (#497)
    • travis-ci: Remove older versions of go (#516)
    • go get example in README.md (#488)


    • Remove unneeded ctx == nil check (#498)
    • Remove unneeded loop check (#524)
    • Improve ScanStruct performance (#523)
    • Improve readability of lazyInit (#522)

    Thanks to the following contributors to this release: Hanjun Kim, Homer Huang, Jeremy Wiebe, Rohan Verma, Stan Hu, ppphp and xyb

    Source code(tar.gz)
    Source code(zip)
  • v1.8.2(Jun 10, 2020)

    New Features

    • Context dial support (#476)
    • Support for ACL logins (#480)
    • Support for Anonymous field pointers to AddFlat (#490)
    • Scanner support for ScanSlice (#489)


    • Handle pool get ctx cancellation promptly (#470)


    • Simplify Pool.Get (#478)
    • Remove deprecated sudo setting. (#481)
    • Add new go versions to travis (#483)
    Source code(tar.gz)
    Source code(zip)
  • v1.8.1(May 6, 2020)

  • v1.8.0(Apr 30, 2020)

  • v1.7.2(Apr 30, 2020)

  • v1.7.1(Apr 29, 2020)


    • Add CLIENT SETNAME to dial options
    • Add wait statistics to pools
    • Support DialContext on Pool
    • Add ptr support for scan and flatten
    • Add helper to parse SLOWLOG GET command
    • Add Uint64Map and Uint64s(#453)
    • Support go mod (#440)


    • Handle error and simple strings in array Scan
    • Handle nil source values in Scan
    • Handle nil value conversion in scan
    • Explicitly mention Close() in concurrency doc
    • tiny spelling mistake; (#402)
    • DialURL ignores opaque url
    • Support Scan into pointer to RedisScan
    • addflat: respect RedisArg presence
    • Correct typo in deprecated NewPool function (#463)
    • Uint64s and Uint64Map tests (#469)
    • Formatting issues on tip (#471)


    • Drop support for Go 1.6 and earlier
    • Simplify string reply check (#457)
    • Remove validation against go prior to 1.9.x (#465)
    Source code(tar.gz)
    Source code(zip)
GoBigdis is a persistent database that implements the Redis server protocol. Any Redis client can interface with it and start to use it right away.

GoBigdis GoBigdis is a persistent database that implements the Redis server protocol. Any Redis client can interface with it and start to use it right

Riccardo 5 Apr 27, 2022
Bxd redis benchmark - Redis benchmark tool for golang

使用 redis benchmark 工具, 测试 10 20 50 100 200 1k 5k 字节 value 大小,redis get set 性能。 r

bingxindan 0 Jan 22, 2022
redis client implement by golang, inspired by jedis.

godis redis client implement by golang, refers to jedis. this library implements most of redis command, include normal redis command, cluster command,

piaohao 104 Jun 21, 2022
Go client for Redis

Redigo Redigo is a Go client for the Redis database. Features A Print-like API with support for all Redis commands. Pipelining, including pipelined tr

null 9.2k Jun 24, 2022
Type-safe Redis client for Golang

Redis client for Golang ❤️ Uptrace.dev - distributed traces, logs, and errors in one place Join Discord to ask questions. Documentation Reference Exam

null 14.8k Jul 1, 2022
Go Redis Client

xredis Built on top of github.com/garyburd/redigo with the idea to simplify creating a Redis client, provide type safe calls and encapsulate the low l

Raed Shomali 18 Jan 23, 2022
godis - an old Redis client for Go

godis Implements a few database clients for Redis. There is a stable client and an experimental client, redis and exp, respectively. To use any of the

Simon Zimmermann 86 Apr 16, 2022
Google Go Client and Connectors for Redis

Go-Redis Go Clients and Connectors for Redis. The initial release provides the interface and implementation supporting the (~) full set of current Red

Joubin Houshyar 441 Jun 15, 2022
Redis client library for Go

go-redis go-redis is a Redis client library for the Go programming language. It's built on the skeleton of gomemcache. It is safe to use by multiple g

Alexandre Fiori 45 Jul 15, 2020
Type-safe Redis client for Golang

Redis client for Golang ❤️ Uptrace.dev - distributed traces, logs, and errors in one place Join Discord to ask questions. Documentation Reference Exam

null 14.8k Jun 30, 2022
Redisx: a library of Go utilities built on the redigo redis client library

redisx redisx is a library of Go utilities built on the redigo redis client libr

null 1 Dec 24, 2021
Redis client for Golang

Redis client for Golang To ask questions, join Discord or use Discussions. Newsl

null 0 Dec 23, 2021
Redis client for Golang

Redis client for Golang Discussions. Newsletter to get latest updates. Documentation Reference Examples RealWorld example app Other projects you may l

null 0 Dec 30, 2021
High-performance framework for building redis-protocol compatible TCP servers/services

Redeo The high-performance Swiss Army Knife for building redis-protocol compatible servers/services. Parts This repository is organised into multiple

Black Square Media 414 Jun 22, 2022
Simple key-value store abstraction and implementations for Go (Redis, Consul, etcd, bbolt, BadgerDB, LevelDB, Memcached, DynamoDB, S3, PostgreSQL, MongoDB, CockroachDB and many more)

gokv Simple key-value store abstraction and implementations for Go Contents Features Simple interface Implementations Value types Marshal formats Road

Philipp Gillé 440 Jun 25, 2022
Redis Sorted Sets Benchmark

redis-zbench-go Redis Sorted Sets Benchmark Overview This repo contains code to trigger load ( ZADD ) or query (ZRANGEBYLEX key min max) benchmarks, w

filipe oliveira 3 May 18, 2021
Use Redis' MONITOR to draw things in a terminal

Redis Top Redistop uses MONITOR to watch Redis commands and shows per command and per host statistics. Because MONITOR streams back all commands, its

Factory 29 Jun 21, 2022
Examples and code to assign a name to your MongoDB, MySQL, PostgreSQL, RabbitMQ, and redis connection.

your connection deserves a name ?? When your app interacts with an external system, assign a name to the connection. An external system in this contex

Andy Grunwald 25 Feb 15, 2022
redis protocol server for go.

redigosrv what redis server侧的golang版本实现。 why 作为后端RD,你开发的,维护的最多的应该就是你的server,作为服务的提供方来说,想要和客户端进行有效的交互,首先要要能理解信息的含义,因此一套通信协议是必须的。 为什么选择redis协议,应用层有很多成熟的

Saner 7 Nov 30, 2021