pipeline压缩请求数量
通常情况下，我们每个操作redis的命令都以一个TCP请求发送给redis，这样的做法简单直观。然而，当我们有连续多个命令需要发送给redis时，如果每个命令都以一个数据包发送给redis，将会降低服务端的并发能力。如果我们可以把所有单次请求，压缩到一起那就非常棒了，pipeline。pipeline机制将多个命令汇聚到一个请求中，可以有效减少请求数量，减少网络延时。
local cjson = require "cjson"
local comm = require "mysql_redis.comm"
local redis = comm:connectRedis(0)
redis:init_pipeline()
redis:set("cat", "Lichen")
redis:set("horse", "Xiejl")
redis:get("cat")
redis:get("horse")
local results,err = redis:commit_pipeline()
if not results then
ngx.say("failed to commit the pipelined requests: ", err)
return
else
ngx.say(cjson.encode(results))
end
正确使用pipeline对性能的提升十分明显。我们曾经某个后台应用，逐个处理大约100万条记录需要几十分钟，经过pileline压缩请求数量后，最后时间缩小到20秒左右。做之前能预计提升性能，但是没想到提升如此巨大。（来自网络）
script压缩复杂请求
我们知道对于多个简单的redis命令可以汇聚到一个请求中，提升服务端的并发能力。然而，在有些场景下，我们每次命令的输入需要引用上个命令的输出，甚至可能还要对第一个命令的输出做一些加工，再把加工结果当成第二个命令的输入。pipeline难以处理这样的场景。庆幸的是，我们可以用redis里的script来压缩这些复杂命令。
script的核心思想是在redis命令里嵌入Lua脚本，来实现一些复杂操作，感兴趣的同学可以到这里查阅，openresty中已经对redis的所有原语操作进行了封装。下面我们以EVAL为例，来看一下openresty中如何利用script来压缩请求：
--EVAL script numkeys key [key ...] arg [arg ...]
--EVAL的第一个参数script是一段 Lua 脚本程序。 这段Lua脚本不需要（也不应该）定义函数
--EVAL的第二个参数numkeys是参数的个数
--后面的参数key(从第三个参数)表示在脚本中所用到的那些Redis键(key),这些键名参数可以在Lua中通过全局变量KEYS数组,用1为基址的形式访问(KEYS[1],KEYS[2]以此类推)
--在命令的最后,那些不是键名参数的附加参数arg[arg ...],可以在Lua中通过全局变量ARGV数组访问,访问的形式和KEYS变量类似(ARGV[1]、ARGV[2],诸如此类)
--如 eval "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 first second
local id = 6055
local cjson = require "cjson"
local comm = require "mysql_redis.comm"
local redis = comm:connectRedis(0)
local ok_res,err = redis:eval([[
local info = redis.call('get',KEYS[1])
info = cjson.decode(info)
local g_info = redis.call('get',info.gid)
return g_info
]], 1, id)
ngx.say(ok_res)
这样我们就可以把两个get放到一个TCP请求中，做到减少TCP请求数量，减少网络延时的效果啦。
当然这只是eval的用法，还有好几个api可以实现更复杂的逻辑，待研究，，redis对lua的支持真是赞。
