这个问题我碰到过，刚好是Redis版本兼容的坑！咱们一步步拆解原因和解决方案：

1. 为什么一开始报错「Write commands not allowed after non deterministic commands」？ #

在Redis 3.0中，脚本的复制机制是脚本整体传播——主节点会把整个Lua脚本原封不动发给从节点执行。但TIME属于非确定性命令（每次执行结果都不一样），如果脚本里先执行TIME再做写操作（比如SETEX、INCR），会导致主从节点执行脚本的结果不一致，所以Redis直接禁止了这种组合写法。

2. 为什么加redis.replicate_commands()还是报错？ #

因为redis.replicate_commands()是Redis 3.2版本才新增的API，它的作用是把脚本复制模式从「脚本传播」切换成「命令传播」——主节点会把脚本里实际执行的每一条命令单独发给从节点，而非整个脚本，这样就能避开非确定性命令导致的主从不一致问题。但你的环境是Redis 3.0，根本没有这个函数，所以调用它就会报「attempt to call field 'replicate_commands' (a nil value)」。

针对Redis 3.0的可行解决办法 #

办法一：客户端生成时间戳，避免脚本里用非确定性命令 #

这是最稳妥且无需升级的方案：在Jedis代码里先生成秒级时间戳，拼接成key后再传入Lua脚本，这样脚本里就没有非确定性命令了，完全符合Redis 3.0的脚本要求。

示例代码：

Java（Jedis）部分：

import redis.clients.jedis.Jedis;
import java.util.Collections;

public class JedisLuaExample {
    public static void main(String[] args) {
        // 客户端生成秒级时间戳（替代脚本里的TIME命令）
        long second = System.currentTimeMillis() / 1000;
        String keyPrefix = "your_key_prefix:";
        String currentKey = keyPrefix + second;

        // 修改后的Lua脚本，不再依赖TIME命令
        String luaScript = "if redis.call('EXISTS', KEYS[1]) == 0 then " +
                          "redis.call('SETEX', KEYS[1], 1, 1) " +
                          "return 1 " +
                          "else " +
                          "return redis.call('INCR', KEYS[1]) " +
                          "end";

        Jedis jedis = new Jedis("localhost", 6379);
        try {
            // 执行脚本，传入拼接好的key作为KEYS参数
            Long result = (Long) jedis.eval(luaScript, Collections.singletonList(currentKey), Collections.emptyList());
            System.out.println("执行结果：" + result);
        } finally {
            jedis.close();
        }
    }
}

为什么这个方案可行？

脚本里的逻辑完全基于传入的确定参数（currentKey），属于确定性脚本，主从节点执行相同的脚本和参数，结果完全一致，Redis不会再限制写操作。

办法二：升级Redis到3.2及以上版本 #

如果业务允许升级Redis，升级到3.2+之后，redis.replicate_commands()就可以正常使用了。只需要保持你原来的Lua脚本不变，Redis会自动切换到命令传播模式，解决非确定性命令后的写操作限制问题。但升级前记得做好备份和兼容性测试哦。

内容的提问来源于stack exchange，提问作者hiway