Redis集群里Lua脚本的那些事儿，怎么写怎么用还挺复杂

综合参考了Redis官方文档、多位开发者的技术博客分享以及像《Redis设计与实现》这类技术书籍中的相关章节）

在单机版的Redis里,使用Lua脚本是一件挺爽快的事情，你把一堆操作写在一个脚本里，然后一次性发给Redis，它能保证这些操作像打包一样，一个接一个地执行，中间不会被别的命令插队，这就是所谓的原子性，而且因为脚本是在Redis服务器上直接跑，避免了网络来回的开销，速度也快。

一旦你踏进了Redis集群的世界,Lua脚本这事儿就立刻变得“复杂”起来了，这个复杂，主要就复杂在Redis集群是把数据分片存储在不同的节点上的。

第一个大麻烦：所有Key必须在同一个节点上

这是Redis集群对Lua脚本最核心、也是最让人头疼的限制，Redis集群规定，一个Lua脚本里操作的所有Key，必须被哈希到同一个哈希槽（Hash Slot），并且最终由同一个节点来处理，如果脚本里的Key散落在了不同的节点上，Redis会直接给你抛出一个错误，脚本根本执行不了。

为什么这么规定？想象一下，如果你的脚本要同时修改Node A上的user:100和Node B上的order:200，集群就需要在两个节点之间协调这个脚本的执行，以确保原子性，这就会引入复杂的分布式事务问题，比如两阶段提交，这会极大地牺牲性能和增加复杂性，Redis集群的设计哲学是简单和高效，所以它干脆就不支持跨节点的脚本原子性。

那怎么办呢？这就引出了一个叫hash tag的玩意儿，它不是一种新的标签语法，而是对Key本身的一种“作弊”设计，Redis计算Key属于哪个槽时，默认是用整个Key字符串的部分来计算哈希值，你可以故意把你的Key设计成类似{user100}.profile和{user100}.orders这样，虽然看起来是两个不同的Key，但因为里的内容user100是一样的，它们就会被分配到同一个槽、同一个节点，这样，你的Lua脚本就可以同时操作它们了，但这需要你在设计Key的时候就有预见性，算是一种前期规划上的“复杂”。

第二个麻烦：脚本的传播问题

在单机Redis里,你加载一个脚本，它就在那一个服务器上，但在集群里，你有多个主节点，你的脚本很可能需要在所有主节点上都存在，以备不时之需（比如故障转移后，新的主节点也需要能执行这个脚本）。

当你使用SCRIPT LOAD命令把一个脚本预加载到集群时，你会发现一个“坑”：这个命令默认只会把脚本加载到你当前连接的那个节点上，而不会自动同步到其他节点，如果你后续使用EVALSHA命令（通过脚本的SHA1校验和来执行脚本，比每次传完整脚本更省带宽），而请求又被路由到了另一个没有预先加载该脚本的节点，那个节点就会报错，说脚本不存在。

解决这个问题,通常有两种笨办法：

1. 手动同步：写个脚本或者程序，挨个连接集群里的每个主节点，都执行一遍SCRIPT LOAD，这很麻烦，尤其是节点很多或者脚本经常更新的时候。
2. 降级使用：放弃使用EVALSHA，每次都使用EVAL命令把完整的Lua脚本源码发过去，这样能保证无论请求落到哪个节点，它都能执行，但代价就是网络传输的数据量变大了，失去了EVALSHA节省带宽的优势，这是一种用性能换便利的权衡。

第三个麻烦：调试和错误的棘手性

Lua脚本在集群里出错了,排查起来也更困难，因为脚本的执行环境是在某个特定的数据节点上，错误信息也是从那个节点返回的，如果你的应用客户端连接的是集群的入口，然后请求被转发到了某个节点，你得到的错误信息可能不够直观，在集群环境下，你很难像在单机环境下那样，去模拟和复现一个涉及多个Key的脚本执行场景，因为你的测试环境可能和生产环境的集群拓扑结构不同。

脚本执行是有超时限制的（默认5秒），如果一个脚本在集群的某个节点上执行时间过长，不仅会导致这个脚本被强制终止，更严重的是，它会阻塞这个节点上所有其他客户端的请求，因为Redis是单线程的，在集群中，一个节点的阻塞可能会引发连锁反应，比如导致客户端超时、连接池被占满，进而影响到整个应用的稳定性。

总结一下

在Redis集群里使用Lua脚本,你不能再像在单机环境下那样“随心所欲”，你必须时刻绷紧一根弦：我的脚本里的Key在哪？ 你需要通过hash tag来巧妙地“绑架”Key，让它们待在同一个节点，你需要操心脚本如何在所有节点间“安家落户”，并在传输效率和部署便利性之间做抉择，你还需要对脚本可能引起的性能瓶颈和调试难度有更高的警惕。

所以说,Redis集群里的Lua脚本，虽然强大依旧，但确实从“怎么写”到“怎么用”都增添了不少的复杂性和需要考虑的细节，它从一个简单的性能加速器，变成了一个需要精心设计和运维的分布式组件。