select + set_keepalive 组合操作引起的数据读写错误

在高并发编程中，必须 要使用 连接池技术，通过减少建连、拆连次数来提高通讯速度。

错误示例代码：

  1. local redis = require("resty.redis")
  2. local red   = redis:new()
  4. red:set_timeout(1000) -- 1 sec
  6. -- or connect to a unix domain socket file listened
  7. -- by a redis server:
  8. --     local ok, err = red:connect("unix:/path/to/redis.sock")
  10. local ok, err = red:connect("127.0.0.1", 6379)
  11. if not ok then
  12.     ngx.say("failed to connect: ", err)
  13.     return
  14. end
  16. -- ???
  17. ok, err = red:select(1)    -- 这里会是一个坑
  18. if not ok then
  19.     ngx.say("failed to select db: ", err)
  20.     return
  21. end
  22. -- ???
  24. ngx.say("select result: ", ok)
  26. ok, err = red:set("dog", "an animal")
  27. if not ok then
  28.     ngx.say("failed to set dog: ", err)
  29.     return
  30. end
  32. ngx.say("set result: ", ok)
  34. -- put it into the connection pool of size 100,
  35. -- with 10 seconds max idle time
  36. local ok, err = red:set_keepalive(10000, 100)
  37. if not ok then
  38.     ngx.say("failed to set keepalive: ", err)
  39.     return
  40. end

如果单独执行这个用例，没有任何问题，用例是成功的。但是这段 “没问题” 的代码，却导致了诡异的现象。

大部分 Redis 请求的代码应该是类似这样的：

  1. local redis = require("resty.redis")
  2. local red = redis:new()
  4. red:set_timeout(1000) -- 1 sec
  6. -- or connect to a unix domain socket file listened
  7. -- by a redis server:
  8. --     local ok, err = red:connect("unix:/path/to/redis.sock")
  10. local ok, err = red:connect("127.0.0.1", 6379)
  11. if not ok then
  12.     ngx.say("failed to connect: ", err)
  13.     return
  14. end
  16. ok, err = red:set("cat", "an animal too")
  17. if not ok then
  18.     ngx.say("failed to set cat: ", err)
  19.     return
  20. end
  22. ngx.say("set result: ", ok)
  24. -- put it into the connection pool of size 100,
  25. -- with 10 seconds max idle time
  26. local ok, err = red:set_keepalive(10000, 100)
  27. if not ok then
  28.     ngx.say("failed to set keepalive: ", err)
  29.     return
  30. end

这时候第二个示例代码在生产运行中，会出现 cat 偶会被写入到数据库 1 上，且几率大约 1% 左右。

出错的原因在于 错误示例代码使用了 select(1) 操作，并且使用了长连接，并且还潜伏在了连接池中。

当下一个请求刚好从连接池中把它选出来，这里又没有重置数据库的 select(0) 操作，所以后面所有的数据操作就都会默认触发在数据库 1 上了。

怎么解决这个问题？

  1. 谁制造问题，谁把问题遗留尾巴擦干净；
  2. 处理业务前，先把 “前辈” 的尾巴擦干净；

这里明显是第一个好，对吧。