redis源码系列--（二）--multi/exec/eval命令执行流程
本文主要记录multi/exec、eval、redis执行lua脚本的源码流程
redis在exec之前，所有queued的命令是没有执行的，！！！在执行时会通过检测client是否被打上CLIENT_DIRTY_CAS标记来判断[watch后,exec时]时间段内是否有key被修改，如果有，因为此时还没有执行事务中的任何命令，所以是可以不执行任何命令就取消整个事务的（如果是执行过程中有个命令执行是失败，此时已经进入事务执行了，所以即使当前命令失败，redis也会执行完所有的命令，即redis事务要么一条都不执行，要么就全部执行，因为redis是串行执行所有client的，所以redis可以执行事务的所有命令，而不会被其他任何client的命令中断，这也是redis事务原子性的原理）
unwatchAllKeys的实现原理（八九不离十）：有一个keylist存放所有的key，即每个key都有一个watch-client-list，表示所有watch这个key的client，然后client watch这个key时，就在这个key的watch-client-list中插入一个节点，节点的值为当前client，并把这个节点的地址保存到client中，这样unwatchAllKeys中先通过client->watch_keys获取所有client watch的key，然后通过这个key节点，然后再通过这个key节点中保存的地址来获取这个key的watch_client_list，client找到watch-client-list后，然后删除就是先从keylist中摘去本节点，然后再client->watch_keys中摘除这个节点。核心就是client保存了一个指向key对应的节点的指针，即redis保存key的时候不是仅仅保存一个key，而是保存了一个附加了大量其他状态的节点，然后其他地方就直接保留一个指向该节点的指针，这样可以非常方便的通过一个指针找到整个链表或者链表中的某个节点，进而找到这个链表的其他部分，即数据只存一份，其他地方保存一个指向这份数据的指针，可以看unwatchAllKeys函数的实现，很好的体现了这一点。
如果当前客户端的ID是CLIENT_ID_AOF （即这个客户端是在处理AOF的虚拟客户端），那么Redis会执行call(c, CMD_CALL_NONE)，即调用call()时，不进行任何统计、传播或者慢日志记录，只是执行命令。这是因为AOF重放期间不需要记录慢日志或传播到其他从节点。在AOF重写或加载期间，Redis只是想尽快恢复数据集，并不需要执行额外的操作（如更新慢日志、传播命令等）。因此，通过CLIENT_ID_AOF来识别AOF客户端，并简化命令的处理逻辑。如果客户端不是CLIENT_ID_AOF ，即普通客户端，Redis会使用CMD_CALL_FULL来执行命令。这意味着命令执行后会更新慢日志、统计信息，并且如果需要，还会进行AOF或从节点的传播。
！！！watch、multi/exec、eval：redis中eval lua脚本的实现和redis中exec命令的实现原理是一致的，只不过区别在于，multi/exec中，redis在开启multi之后会把exec之前的所有命令都放到命令队列里，直到遇到exec命令才会开始把这期间存储的命令一条一条执行，即multi/exec有一个命令收集的过程，因为有一个收集的过程，而收集过程必定不是原子的，也就是说在multi开始后exec执行时一个key在此期间是有可能被其他client修改的，所以multi/exec事务过程中才需要watch命令,watch是专门与multi搭配的，即在watch后exec之前key被其他client修改了，那么就取消事务，先watch，然后multi，最后exec，注意一旦watch之后，就会开启检测，也就是说watch检测的是watch之后到exec之前所有对watch_key的修改，在此期间一旦有任何其他client修改了key，那么redis都会给client打上CLIENT_DIRTY_CAS标记，也就是说[watch之后，multi之前]，任何对key的修改也会取消【multi后，exec时]之间命令的执行，即会取消整个事务，因为redis执行exec时会检测client是否有CLIENT_DIRTY_CAS标记，如果有，就取消整个事务，但是不会影响[watch之后，multi之前]区间内命令的执行，因为这些命令都是当做普通命令执行，执行时不会检测client是否被打上了CLIENT_DIRTY_CAS标记，相比之下eval命令中却是一次性提交整个脚本，也就是一次性把整个事务过程中所需要的命令都提交给redis，这样就不存在提交命令过程中key被其他client修改，所以eval之前是不需要watch的，eval执行时也不会检测client是否打上了CLIENT_DIRTY_CAS标记，也就是说watch只是一个打标记的功能，至于打好标记以后怎么办则取决于命令的执行函数，如果该函数直接忽略这个CLIENT_DIRTY_CAS标记，那么watch就对他没有任何影响。！！！注意，exec执行完毕后会unwatchall，也就是取消监视所有key，也就是说执行下一次multi/exec之前如果需要watch某些key，必须重新使用watch
！！！redis lua脚本原子执行原理：redis启动的时候就会启动一个lua虚拟机，用lua变量代表，因为lua库对外提供了api，可以让外部调用者向其注册函数，也就是说外部调用者可以像lua虚拟机注册一个函数x，然后这个lua函数x对应调用者的函数y，举个例子：redis会向这个虚拟机注册（“call”,luaRedisCallCommand)函数，这表示lua中新增了一个函数call，这个函数对应的是外部的luaRedisCallCommand函数，这样lua脚本调用redis.call，那么lua虚拟机就会跳转到redis的luaRedisCallCommand，执行eval命令的时候直接把脚本提交给这个lua虚拟机就行了，lua虚拟机是单线程运行的，且直接在主线程中运行，而不是单独起一个线程。redis lua脚本的执行过程和redis exec命令的执行原理本质上是一样的，也是一条一条执行，因为redis是单线程顺序执行的，所以和事务一样，能保证原子性。执行eval时会直接把lua脚本提交给lua虚拟机来解释执行（！！！lua虚拟机是单线程，而且直接在redis主线程里运行，并不是开一个新的线程来运行lua虚拟机），lua虚拟机肯定是按脚本一行一行来执行的，这每一行都是一个get/set命令，这里一行一行执行就相当于exec里一条一条的执行命令队列中的命令，所以说lua脚本原子性的实现本质和multi/exec是一样的。redis会向这个lua虚拟机注册一系列函数，比如上面说的call，这些redis注册的lua api函数可供lua脚本调用，这些是redis环境特有的，如果lua脚本在非redis环境调用，是会报错的，lua虚拟机中调用这些函数的时候，程序控制权就会转到注册的这些函数。lua脚本举例：redis.call(“SET”, “mykey”, “new_value”)，redis向lua虚拟机注册了redis.call这个接口，lua脚本执行到redis.call的时候代码就会跳转到redis的luaRedisCallCommand，这样lua中一行一行执行，实际上就是一个一个的调用对应的redis c函数，每个redis命令都对应一个执行函数，所以lua脚本和redis的exec命令没有本质区别，都是一条一条执行，因为redis是单线程，所以能保证原子性，只是lua脚本提供的功能更复杂更强大。
redis命令xxx对应的函数的名字往往都是xxxCommand的格式，比如multi命令，源码中对应的执行函数就是multiCommand、eval命令对应的执行函数是evalCommand
笔记：redis/deps/lua/src/lua.h：LUA_API int (lua_pcall) (lua_State *L, int nargs, int nresults, int errfunc); LUA_API实际是extern。即第三方库头文件中导出了一个叫做lua_pcall的函数，然后redis中直接通过头文件调用这个函数，因为是extern的，就表明这是外部包，所以说编译的时候不会去编译lua_pcall代码，而是在链接的时候直接去链接第三方lua包，这也是extern的作用。代码编译后，因为lua_pcall是直接链接的第三方包(即.o文件)，就是说只有lua_pcall的声明，而没有lua_pcall的源代码，所以我们lua_pcall打断点进去是没用的。但是我们提前向lua中注册了相关函数，比如这里我们就向lua注册了一个叫做redis.call的函数，绑定的是redis源码中的luaRedisCallCommand函数，这样lua_pcall执行lua脚本时，遇到redis.call函数时就会转到我们的luaRedisCallCommand函数
笔记：lua是栈式虚拟机，所以都是push/pop来传递参数和返回值
笔记（未经证实）：lua脚本是如果对key做了修改，那么就无法通过script kill来杀掉脚本，即此时lua是全部执行，和exec全部执行差不多
multi命令源码流程：
server.call
multi.multiCommand
if (c->flags & CLIENT_MULTI) { multi禁止嵌套
addReplyError(c,"MULTI calls can not be nested");
return;
}
c->flags |= CLIENT_MULTI; #multi命令很简单，就是标记客户端进入了multi状态，然后在此状态时，一切非exec等执行事务的命令，
#他都会存起来放到client.mstate.commands数组中,这就是queued的含义
#！！！这里不会重置CLIENT_DIRTY_CAS，
#！！！也就是说watch开启之后到multi之前任何键的修改都会给client打上CLIENT_DIRTY_CAS的标记，
#！！！因为multi没有清除CLIENT_DIRTY_CAS标志，所以当exec执行时，事务会失败
#！！！也就是说exec检测的是watch之后到exec之前对watch_key的修改
addReply(c,shared.ok);
}
事务冲突打标记，以set为例：
server.call
1：执行命令
t_string.setCommand
t_string.setGenericCommand
db.setKeyWithDictEntry
if !SETKEY_NO_SIGNAL: #如果设置了通知更新，就通知所有watch这个key的所有对象（包括客户端）
db.signalModifiedKey #通知key修改了。
multi.touchWatchedKey #凡是监视这个key的client都被标记为CLIENT_DIRTY_CAS,如果这个key是在某个事务操作中，
#那么CLIENT_DIRTY_CAS这就表示该CAS操作失败了即redis的watch是一种乐观锁的方式
#！！！watch的时候就会注册client要watch这个key，而不是multi时注册
#！！！也就是说exec检测的是watch之后到exec之前对watch_key的修改
for 所有监视这个key的客户端:
c->flags |= CLIENT_DIRTY_CAS #！！！这样multi事务执行exec时就会检测到这个标记，一旦为真说明这个key被其他人修改了，那么就会取消事务
exec命令源码流程：
server.call
multi.execCommand
if (!(c->flags & CLIENT_MULTI)) #如果不是multi状态，直接返回
return
tag=multi.isWatchedKeyExpired #遍历client watch的所有key，看是否有key过期了
for client.watch_keys:
db.keyIsExpired
if (tag) {
c->flags |= (CLIENT_DIRTY_CAS) #key过期和key被修改都是一样的，都一样要取消事务的执行
}
if (c->flags & (CLIENT_DIRTY_CAS | CLIENT_DIRTY_EXEC)): #！！！检测CLIENT_DIRTY_CAS标记，
#！！！一旦为真说明此事务watch的key有些已经被人修改了，所以需要放弃事务
#如果有key出了问题，或者命令queued的时候出错都会放弃事务
networking.addReply #填充响应到发送缓冲区
multi.discardTransaction #取消事务：就是清空命令队列以及清空client的multi、CLIENT_DIRTY_CAS等标记
multi.freeClientMultiState #释放对应的资源，这里就是释放指针以及减少引用计数
#redis用mstate变量即multiState来存储与multi/exec相关的资源
multi.initClientMultiState #重置client.mstate的各个字段，就是都设置为0/null
c->flags &= ~(CLIENT_MULTI|CLIENT_DIRTY_CAS|CLIENT_DIRTY_EXEC) #清除client的multi相关标记
multi.unwatchAllKeys #撤销对key的watch因为multi已经结束而了
#！！！也就是说exec之后就会取消watch，
#也就是说每次执行multi/exec之前都必须watch一次
#逻辑就是：
#1：key是单独存储的，一个key对应一个节点，
#一个key的节点内保存了一个watch-clients-key
#watch-clietnts-list包含了所有watch这个key的clients
#2：client有一个watch_key链表，保存了他watch的所有key
#所以先通过client->watch_key找到watch的key对应的节点的指针，
#然后通过这个指针获取key的watch-clients-key链表，然后从中摘去当前client
#摘完以后再回过头来在client->watch_key中摘去这个key
listRewind(c->watched_keys,&li) #获取client->watch_keys_list
while ln=next(li)&&ln!=nul: #遍历所有client watch的key
wk = listNodeValue(ln); #从client节点获取保存的watch_key指针
clients = watchedKeyGetClients(wk); #通过watch_key节点获取key对应的watch-client-list即clients
listUnlinkNode(clients, watchedKeyGetClientNode(wk)); #从key对应的watch-client-list中摘去当前的client
listDelNode(c->watched_keys,ln); #从client的watch_key链表中摘去当前key
#开始执行事务
c->flags |= CLIENT_DENY_BLOCKING; #redis multi/exec中禁止执行会导致阻塞的命令
multi.unwatchAllKeys #开始执行，执行之前unwatch所有key以节约cpu
for client->mstate.commands #commands保存了事务的所有命令，这里就是遍历数组，顺序执行所有命令
if (c->id == CLIENT_ID_AOF)
server.call(c, CMD_CALL_NONE)
else
server.call(commands[i],CMD_CALL_FULL) #！！！redis是串行处理所有client fd上的事件，
#！！！也就是只有处理完当前client fd后才会处理下一个client fd上的事件
#！！！即在执行这个for循环的时候不会并发执行任何其他client fd上的命令
#！！！因为在执行这个for循环的时候，他也是一条命令接一条命令的执行
#！！！执行完一条才会执行下一条，
#！！！server.call是无返回值的，就是说不管当前命令执行是否成功，
#！！！都会走完整个for循环即执行所有命令而不会中途返回
#！！！所以说：redis的事务，要么就是一条命令也不执行(即执行前检测到冲突就取消整个事务)，
#！！！！要么就是全部执行，所以说可以把redis的multi/exec看成是一个原子指令
#！！！redis中lua脚本是通过eval实现的，
#！！！eval之所以能保证原子性的原理和multi/exec是完全一致的
#！！！redis调用lua虚拟机执行脚本，直到脚本执行完毕才会运行后面的
multi.discardTransaction #所有命令都执行完了，即事务已经完成了，所以可以重置client的状态了，取消事务就是一个重置clint的操作
#！！！也就是说exec一次就会取消watch，也就是说每次执行multi/exec之前都必须watch一次，
#而不是一次watch，多次multi/exec
redis向lua中注册函数：
server.main
server.initServer
eval.scriptingInit
lctx.lua_scripts = dictCreate(&shaScriptObjectDictType) #创建一个map：key=scriptSHA1,value=script，每个执行过的脚本都会存放在这里面
#evalsha命令的实现基础，即根据sha就直接从这个dict找到脚本，就省去了重新编译脚本的过程
script_lua.luaRegisterRedisAPI
lua_pushstring(lua, "call") #向lua注册redis.call
lua_pushcfunction(lua, luaRedisCallCommand) #！！！将lua中redis.call和redis的luaRedisCallCommand函数绑定起来
#！！！这样lua中调用redis.call的时候程序流程就会转到redis源码中的luaRedisCallCommand函数
lua_pushstring(lua, "pcall") #向lua注册redis.pcall
lua_pushcfunction(lua, luaRedisPCallCommand); #同上，call和pcall只是对错误的处理不同，其他都一样
lua_setglobal(lua,"redis") #在lua中注册全局表redis，代码里会把call/pcall注册到redis表，
#这样lua中要调用函数call就是redis.call形式，即redis表的call函数
lua脚本举例：
redis.call('SET', 'k1', 'v1')
local value = redis.call('GET', 'k1')
redis.call('SET', 'k2', 'v2')
return value
“busy-reply-threshold”, “lua-time-limit”，配置文件中这两个参数是一样的，只不过一个是老版本，一个是新版本，但是最终都设置的同一个变量
笔记：阻塞redis
evel流程：
eval.evalCommand
eval.evalGenericCommand
lua=lctx.lua #lctx.lua就是redis中嵌入的lua解释器
script_lua.luaCallFunction
if (server.busy_reply_threshold > 0 && !debug_enabled): #！！！busy_reply_threshold>0表示设置了脚本执行的最长时间，默认5000ms
#！！！如果设置为0，那么就表示不设置。
#！！！注意，这个参数并不会限制脚本的执行时间，而是达到阈值后redis就会进入busy状态
#！！！一旦进入busy状态，除非脚本执行结束或者客户端发来script kill
#！！！或者shutdown nosave命令
#！！！否则redis不会自动结束脚本执行，并且不会响应其他任何命令包括客户端的连接
#！！！如果lua脚本修改了任意key，那么script kill将不起作用，
#！！！此时只能执行shutdown nosave
#！！！因为如果lua脚本执行时间非常长，因为redis是单线程，所以会导致redis无法响应客户端命令
#！！！"busy-reply-threshold"和"lua-time-limit"这两个参数实际是对应同一个变量
#！！！前者是新版本中配置项的名称，后者是旧版本redis中的配置名称
lua_sethook(lua,luaMaskCountHook,LUA_MASKCOUNT,100000) #！！！这个钩子函数非常非常非常重要，是防止redis长时间阻塞于lua脚本的关键
#！！！luaMasCountHook即指定的钩子函数，
#！！！LUA_MASKCOUNT表示lua虚拟机每执行一定条数的指令就调用一次这个钩子函数
#！！！100000表示每次执行10w条指令就调用一次钩子函数
#！！！redis的逻辑是不管你设置脚本超时时间是多久，他都是每隔10w条指令就调用一次钩子函数
#！！！然后在钩子函数里检测一下是否超时，也就是说redis这个超时时间是不精确的
state=script.scriptInterrupt #！！！这个函数非常重要
#这个函数的作用是：1：如果脚本执行时间还没有超时，那么就返回继续执行脚本
#2：如果脚本第一次超时，则给脚本打上SCRIPT_TIMEDOUT标记，表示超时，然后处理其他事件
#注意：这个SCRIPT_TIMEOUT是所有client都可以看见的相当于给全局变量lua打上的标记
#不过此时只能处理script kill/shutdown nosave命令，其他的都会被redis拒绝
#3：如果已经超时，则直接处理其他事件
#即第一次超时和非第一次超时相比，
#第一次超时多了一个打超时标记、打印告警日志的动作、protectClient的操作
if (run_ctx->flags & SCRIPT_TIMEDOUT) { #如果脚本被打上了SCRIPT_TIMEDOUT标记，就表明脚本已经超时了
#当脚本超时时就代表redis进入了busy状态，在eventloop的processCommand中
#此时只能执行含有CMD_ALLOW_BUSY的命令执行(script kill/shutdown nosave)
networking.processEventsWhileBlocked(); #！！！处理一下网络读写，非常重要，后续详解
#！！！whileBlocked表示当前正阻塞于lua脚本执行，
#为了避免redis无法响应其他客户端，所以才有这个函数
#不过此时只能处理script kill强制结束脚本或者shutdown nosave强制结束redis
#！！！如果lua脚本修改了任意key，那么script kill将不起作用，
#！！！此时只能执行shutdown nosave，其他任何命令都会被redis拒绝
return (run_ctx->flags & SCRIPT_KILLED) ? SCRIPT_KILL : SCRIPT_CONTINUE; #！！！处理完后如果客户端调用了
#SCRIPT KILL命令就会打上SCRIPT_KILLED的标记
}
long long elapsed = monotonic.elapsedMs(run_ctx->start_time) #计算自启动该lua脚本开始到目前开始的时间
if (elapsed < server.busy_reply_threshold) { #！！！如果没有超时，则返回继续执行lua脚本
#即lua脚本第一次执行时最长可以连续执行这么长时间
#而不用执行processEventsWhileBlocked
#执行processEventsWhileBlocked就相当于打断了lua脚本的连续执行
#超时以后每隔10w条就要执行一次processEventsWhileBlocked
#！！！注意，只是打算lua脚本的连续执行，但不会终止，
#一旦processEventsWhileBlocked执行完毕又会让lua虚拟机执行10w条指令
#除非processEventsWhileBlocked处理过程中client执行了script killl
#否则一旦陷入死循环，这就是个无限循环，redis此时就完全阻塞了
return SCRIPT_CONTINUE;
}
serverLog(LL_WARNING,"Slow script detected: still in execution after %lld milliseconds. " #打印一条警告信息
"You can try killing the script using the %s command. Script name is: %s.",
elapsed, (run_ctx->flags & SCRIPT_EVAL_MODE) ? "SCRIPT KILL" : "FUNCTION KILL", run_ctx->funcname);
script.enterScriptTimedoutMode #第一次超时，给脚本打上超时标记，SCRIPT_TIMEDOUT表示脚本执行时间过长
run_ctx->flags |= SCRIPT_TIMEDOUT;
networking.protectClient(client *c) #阻止该client继续发送任何命令，直到lua脚本结束或者其他客户端发送script kill
c->flags |= CLIENT_PROTECTED; #给client打上protect标记
if (c->conn):
connSetReadHandler(c->conn,NULL); #！！！清除read_handler，这样redis就不会处理该client fd上的读事件
connSetWriteHandler(c->conn,NULL); #！！！清除write_handler，这样redis就不会处理该client fd上的写事件
#！！！也就是说redis是单线程+顺序执行模型，
#！！！顺序执行的意思是如果上一条命令没有执行完毕或者没有被取消掉
#！！！那么redis保证绝不会处理客户端发来的另一条命令，
#！！！在redis没有执行完当前lua脚本之前，redis绝不会执行任何客户端的命令
#！！！除了script kill和shutdown nosave命令
#！！！即当lua脚本时间超过阈值时甚至陷入死循环时，redis就会进入busy状态
#！！！redis在busy状态时要么等待redis执行完毕，要么由另一个client发送script kill，
#！！！如果是陷入死循环，那么就只能由另一个client发送script kill强制结束
#！！！注意是另一个client，因为当前client已经被清除read/writehandler了
#！！！而且这个其他的客户端必须在redis陷入busy状态前就已经连接了
#！！！因为redis处于busy状态时，只允许客户端发送script kill/shutdown nosave 命令，
#！！！如果lua脚本修改了任意key，那么script kill将不起作用，此时只能执行shutdown nosave
#！！！不会接受任何新连接和处理任何其他命令
networking.processEventsWhileBlocked #第一次超时多了一个打超时标记、打印告警日志的动作、protectClient的操作
#这里就是处理redis其他命令，以免redis无法响应其他客户端
#不过此时只能处理script kill 命令或者shutdown nosave强制结束redis
ae.aeProcessEvents
......
eval.scriptCommand
script.scriptKill
curr_run_ctx->flags |= SCRIPT_KILLED; #执行scriptkill时就会给luactx打上SCRIPT_KILLED标记，
return (run_ctx->flags & SCRIPT_KILLED) ? SCRIPT_KILL : SCRIPT_CONTINUE;
if state==SCRIPT_KILL: #！！！当redis处于busy状态时只有script kill/shutdown nosave命令可以结束他
#一旦检测到SCRIPT_KILL，就结束lua脚本执行，
#这样redis就相当于执行完了这个脚本，就可以接着处理其他未处理的描述符了
lua_sethook(lua, luaMaskCountHook, LUA_MASKLINE, 0) #防止有人用while true循环+pcall阻止redis终止该lua脚本
luaError(lua);
luaPushError(lua,"Script killed by user with SCRIPT KILL") #如果经过scriptInterrupt函数后lua脚本状态为KILL，说明要终止当前脚本的执行
#lua是栈式虚拟机，向lua栈中压入错误，等控制器返回lua时，lua就会检测到然后结束
#如果是pcall则会让用户自己去处理错误，来决定下一步是结束lua脚本还是继续往下执行
lua.lua_pcall #lua.lua_pcall是redis引用的第三方库lua提供的api
#即调用lua解释器执行lua脚本
......
script_lua.luaRedisCallCommand #redis在启动时就绑定了(redis.call，luaRedisCallCommand)
#这样lua执行redis.call的时候实际执行的就是luaRedisCallCommand
#lua中调用一次redis.call就会执行一次luaRedisCallCommand流程
#lua中调用一次redis注册的lua函数，就会执行一次对应的redis函数
#！！！lua脚本肯定是串行执行的，redis exec也是for循环串行执行
#！！！都是一条一条命令的执行，因为redis是单线程模型
#！！！所以lua脚本和exec命令执行期间都不会有任何其他client的命令执行
#！！！所以说lua脚本的执行和exec命令的原子性背后的本质是一样的
#！！！只是lua能提供更复杂的逻辑和功能
script_lua.luaRedisGenericCommand
script.scriptCall
client *c = run_ctx->c #获取client
redisCommand=lookupCommand(c->argv, c->argc) #解析命令，最终是一个redisCommand
#其中保存了相关信息比如命令对应的执行函数
#lua脚本调用redis.call时会传参
#这里就是把参数解析成一个redis命令
#lua脚本：redis.call('SET', 'k1', 'v1')
#c->argc==3
#(char*)c->argv[0]->ptr=="SET"
#(char*)c->argv[1]->ptr=="k1"
#(char*)c->argv[2]->ptr=="v1"
server.lookupCommandLogic(server.commands,argv,argc) #实际就是根据argv和argc查map
#server.commands是一个dict即字典
c->cmd = c->lastcmd = c->realcmd = redisCommand
if (cmd->flags & CMD_WRITE): #CMD_WRITE表示这是一个write命令，会修改数据状态
run_ctx->flags |= SCRIPT_WRITE_DIRTY #给lua虚拟机打上SCRIPT_WRITE_DIRTY标记，标记数据已经修改了
#在数据修改的情况下，一旦redis处于busy状态，
#client只能执行shutdown nosave，redis会拒绝执行script kill
server.call(c) #!!!这里就跳转到server.call了
#下面就是redis具体命令的执行函数了，略
#至此我们就捋清了redis中lua脚本的执行原理
processEventsWhileBlocked源码流程：
networking.processEventsWhileBlocked
iterations=4 #只要aeProcessEvents处理的事件不为0就立即break，否则至多空转4次
while (iterations--):
long long ae_events = aeProcessEvents #！！！aeProcessEvents就是处理一次eventLoop
#！！！此时相当于在主线程的eventloop中再调用一次eventloop
#！！！只不过此时处于脚本timedout状态即redis处于busy状态
#！！！和普通的aeProcessEvents相比，此时只能处理少数含有CMD_ALLOW_BUSY标记的命令
#！！！比如script kill/shutdown now
#！！！此时redis会拒绝任何新的连接
1:client对应的fd上的read事件
fe->rfileProc(fe->clientData) #fe->clientData就是我们保存的conn，这里rfileProc实际是connSocketEventHandler
socket.connSocketEventHandler(conn) #当客户端发来请求时描述符可读，所以调用的是rfileProc，这里rfileProc实际是connSocketEventHandler
connhelpers.callHandler
networking.readQueryFromClient(conn)
......
server.processCommand
if (isInsideYieldingLongCommand() && !(c->cmd->flags & CMD_ALLOW_BUSY)): #！！！当lua脚本超时的时候，只允许部分命令执行
#！！！这些命令都必须打上CMD_ALLOW_BUSY标记
#！！！凡是没有这个标记的，此时都会被拒绝
#！！！此时只有script kill/shutdown nosave可以执行
#！！！一个命令有哪些标记，在commands.def文件中都提前定义好了
#！！！直接ctrl+f查找 CMD_ALLOW_BUSY就可以了
server.rejectCommandFormat
...如果含有CMD_ALLOW_BUSY，就继续往下执行，下面以script kill为例...
......
server.call
eval.scriptCommand #redis的xxx命令对应的处理函数为xxxCommand
..script kill命令中详解..
if ae_events!=0:
break
server.whileBlockedCron #在阻塞期间（比如rdb/aof/lua脚本超时）执行一些定时任务
script kill命令：
server.call
eval.scriptCommand
if argc[1]=="load": #script load命令，略
......
else if argc[1]=="kill": #script kill命令
script.scriptKill
if (curr_run_ctx->flags & SCRIPT_WRITE_DIRTY): #lua脚本执行修改redis数据的命令比如redis.call(set,k1,v1)，
#此时会给lua虚拟机打上SCRIPT_WRITE_DIRTY表示数据有修改
#此时redis选择拒绝执行script kill
addReplyError(c, "-UNKILLABLE Sorry the script already executed write "
"commands against the dataset. You can either wait the "
"script termination or kill the server in a hard way "
"using the SHUTDOWN NOSAVE command.");
return
curr_run_ctx->flags |= SCRIPT_KILLED #script kill只是给lua打上SCRIPT_KILLED标记
#当processEventsWhileBlocked执行完毕后，redis会检测到SCRIPT_KILLED标记，
#所以redis就会主动停止该脚本的执行
addReply(c, shared.ok);