Redigo

Implementing Redigo Scanner interface on a struct's field

由 偶尔善良 提交于 2019-12-13 07:37:16
问题 I have a struct that looks like this: type authEnum int const ( never authEnum = iota sometimes always ) type Attrs struct { Secret string `redis:"secret"` RequireSecret authEnum `redis:"requireSecret"` UserID string `redis:"userId"` } func (e *authEnum) RedisScan(src interface{}) error { // This never gets called! if e == nil { return fmt.Errorf("nil pointer") } switch src := src.(type) { case string: if src == "false" || src == "never" { *e = never } else if src == "sometimes" { *e =

golang + redis concurrency scheduler performance issue

由 六眼飞鱼酱① 提交于 2019-12-13 04:52:49
问题 I write a simple concurrency scheduler, but it seems to have a performance issue at a high level concurrency. Here is the code (scheduler + concurrent rate limiter test): package main import ( "flag" "fmt" "log" "os" "runtime" "runtime/pprof" "sync" "time" "github.com/gomodule/redigo/redis" ) // a scheduler is composed by load function and process function type Scheduler struct { // query channel reqChan chan interface{} // max routine maxRoutine int // max routine chanSize int wg sync

Is Redigo Redis Pool really supposed to be a global variable?

由 雨燕双飞 提交于 2019-12-08 18:23:25
In the example here Redigo Docs for Pool the redis pool is set as a global variable in func main. Is that a kosher way to do things? Should you really be using global varibales left and right or is there a better, more preferred way of accomplishing the same thing? VonC The only other solution have I seen, for instance in " Passing Context to Interface Methods " is: create a struct that accepts an embedded context and our handler type, and we still satisfy the http.Handler interface thanks to ServeHTTP . In your case, the struct would include the pool , and the handler function. type

Is Redigo Redis Pool really supposed to be a global variable?

由 大兔子大兔子 提交于 2019-12-08 04:54:49
问题 In the example here Redigo Docs for Pool the redis pool is set as a global variable in func main. Is that a kosher way to do things? Should you really be using global varibales left and right or is there a better, more preferred way of accomplishing the same thing? 回答1: The only other solution have I seen, for instance in "Passing Context to Interface Methods" is: create a struct that accepts an embedded context and our handler type, and we still satisfy the http.Handler interface thanks to

golang的全局声明的生命周期

由 放肆的年华 提交于 2019-11-29 10:19:08
场景: 当我们要进行redis操作或者其他中间件操作的时候，为了少发起服务端的连接，我们会在main函数外先建立连接，以减少服务端的连接次数 真相： 事实上，很多中间件的连接只是一个语法声明，其实并没有进行真正的连接，比如下面的代码 package main import ( "fmt" "github.com/garyburd/redigo/redis" "github.com/spf13/cast" "math/rand" "time" ) var ( rds, errxx = redis.Dial("tcp", "1.1.1.1:3333") ) func Do(i int) { fmt.Println("开始进行redis操作...") act, err := rds.Do("SET", "name" + cast.ToString(i), i) fmt.Println(act, "--------", err) } func main() { ticker := time.NewTicker(3 * time.Second) defer ticker.Stop() for { select { case <-ticker.C: Do(rand.Intn(1000)) } } } 事实上每一个操作redis的时候，都会对redis重新发起一次连接，并没有起到减少连接的作用
订阅 Redigo