关于限流实现的思考

当将 Lua 脚本复制到附属节点， 或者将 Lua 脚本写入 AOF 文件时， Redis 需要解决这样一个问题： 如果一段 Lua 脚本带有随机性质或副作用， 那么当这段脚本在附属节点运行时， 或者从 AOF 文件载入重新运行时， 它得到的结果可能和之前运行的结果完全不同。

考虑以下一段代码， 其中的 get_random_number() 带有随机性质， 我们在服务器 SERVER 中执行这段代码， 并将随机数的结果保存到键 number 上：

# 虚构例子，不会真的出现在脚本环境中
redis> EVAL "return redis.call('set', KEYS[1], get_random_number())" 1 number
OK
redis> GET number
"10086"
复制代码

现在， 假如EVAL 的代码被复制到了附属节点 SLAVE ， 因为 get_random_number() 的随机性质， 它有很大可能会生成一个和 10086 完全不同的值， 比如 65535 ：

# 虚构例子，不会真的出现在脚本环境中
redis> EVAL "return redis.call('set', KEYS[1], get_random_number())" 1 number
OK
redis> GET number
"65535"
复制代码

可以看到， 带有随机性的写入脚本产生了一个严重的问题： 它破坏了服务器和附属节点数据之间的一致性。

当从 AOF 文件中载入带有随机性质的写入脚本时， 也会发生同样的问题。

只有在带有随机性的脚本进行写入时， 随机性才是有害的。

如果一个脚本只是执行只读操作， 那么随机性是无害的。比如说， 如果脚本只是单纯地执行 RANDOMKEY 命令， 那么它是无害的； 但如果在执行 RANDOMKEY 之后， 基于 RANDOMKEY 的结果进行写入操作， 那么这个脚本就是有害的。

和随机性质类似， 如果一个脚本的执行对任何副作用产生了依赖， 那么这个脚本每次执行所产生的结果都可能会不一样。

为了解决这个问题， Redis 对 Lua 环境所能执行的脚本做了一个严格的限制 —— 所有脚本都必须是无副作用的纯函数（pure function）。

为此，Redis 对 Lua 环境做了一些列相应的措施：

• 不提供访问系统状态状态的库（比如系统时间库）。
• 禁止使用loadfile 函数。
• 如果脚本在执行带有随机性质的命令（比如RANDOMKEY ），或者带有副作用的命令（比如TIME ）之后，试图执行一个写入命令（比如SET ），那么 Redis 将阻止这个脚本继续运行，并返回一个错误。
• 如果脚本执行了带有随机性质的读命令（比如SMEMBERS ），那么在脚本的输出返回给 Redis 之前，会先被执行一个自动的字典序排序，从而确保输出结果是有序的。
• 用 Redis 自己定义的随机生成函数，替换 Lua 环境中 math 表原有的math.random 函数和math.randomseed 函数，新的函数具有这样的性质：每次执行 Lua 脚本时，除非显式地调用 math.randomseed ，否则 math.random 生成的伪随机数序列总是相同的。

经过这一系列的调整之后， Redis 可以保证被执行的脚本：

1. 无副作用。
2. 没有有害的随机性。
3. 对于同样的输入参数和数据集，总是产生相同的写入命令。

Note: starting with Redis 5, the replication method described in this section (scripts effects replication) is the default and does not need to be explicitly enabled.

Starting with Redis 3.2, it is possible to select an alternative replication method. Instead of replication whole scripts, we can just replicate single write commands generated by the script. We call this script effects replication .

In this replication mode, while Lua scripts are executed, Redis collects all the commands executed by the Lua scripting engine that actually modify the dataset. When the script execution finishes, the sequence of commands that the script generated are wrapped into a MULTI / EXEC transaction and are sent to replicas and AOF.

This is useful in several ways depending on the use case:

• When the script is slow to compute, but the effects can be summarized by a few write commands, it is a shame to re-compute the script on the replicas or when reloading the AOF. In this case to replicate just the effect of the script is much better.
• When script effects replication is enabled, the controls about non deterministic functions are disabled. You can, for example, use theTIMEorSRANDMEMBER commands inside your scripts freely at any place.
• The Lua PRNG in this mode is seeded randomly at every call.

In order to enable script effects replication, you need to issue the following Lua command before any write operated by the script:

redis.replicate_commands()
复制代码

The function returns true if the script effects replication was enabled, otherwise if the function was called after the script already called some write command, it returns false, and normal whole script replication is used.