Redis有三种类型的线程:主线程,多个bio线程,后台线程。

Redis Server进程的5个线程,其中第一个是后台线程,中间三个是bio线程,最后是main主线程
Redis执行Lua脚本,已经数据操作本身,都是在主线程中完成的。同时网络相关操作是网络bio线程处理,异步的aof、过期数据清理等操作可以通过后台线程处理。
所以回到本问题,答案就是,Lua脚本执行过程中,其他的数据操作被阻塞,不会执行。
同时这里可以思考,如果不是操作数据的命令是否可以执行呢?比如ping。
我们做个实验,先在lua脚本里写点代码,让redis很长一段时间停不下来。这个期间来做其他操作。由于lua里没有sleep方法,我们用一个复杂的计算来模拟延时,比如阶乘。

用Lua写一个阶乘函数

计算一个非常大的数的阶乘,这样一时半会redis lua执行不完
然后去ping,发现无法执行。

这里可以看到提示脚本执行过程中不能执行,redis处于busy状态
也就是说,LUA脚本执行过程中,除了提示信息中的两个命令(SCRIPT KILL和SHUTDOWN NOSAVE)以外,其他的命令都无法执行。
所以,这个事实要求我们,一定不要在LUA脚本里写太多复杂逻辑。
我们之前做分布式缓存平台的时候,为了数据保持版本一致性,给各个redis写操作命令都加了一个LUA脚本,脚本多了以后,为了考虑各种通用场景和条件判断,加了很多函数、字符串处理、多层循环,后来就发现这个方式虽然使得我们的脚步通用性和可维护性好了不少,但是缓存性能下降了一个数量级,RT从1ms级别到10ms级别,我们预期是3ms级别可以接受。
为什么会这样,因为一次redis内存数据读写就几个指令,如果加上多层循环和字符串操作,这样就会在这个脚本过程执行了上百个指令,注意redis数据操作是单线程的,自然就卡住了其他并发访问的性能。合理的做法就是要让LUA脚本里的操作指令尽量简单。把这些预处理的东西,都放到Java程序里去做,充分利用JVM里的多线程和多机器节点的计算能力。