doc: 阅读redis文档

中间件/redis/redis.md

@@ -171,6 +171,8 @@
         - [evalsha in context of pipelining](#evalsha-in-context-of-pipelining)
         - [Script Cache Semantics](#script-cache-semantics)
       - [Script Command](#script-command)
+      - [Script Replication](#script-replication)
+      - [Replicating commands instead of Scripts](#replicating-commands-instead-of-scripts)
 
 
 # redis
@@ -2807,3 +2809,30 @@ redis> EVALSHA ffffffffffffffffffffffffffffffffffffffff 0
 - `SCRIPT KILL`: 该命令是打断`long-running script`的唯一方式。当script的执行时长超过限制（默认为5s）时，如果该脚本执行时未对数据进行任何修改，则可以通过`SCRIPT KILL`命令来终止
 - `SCRIPT DEBUG`: 用于控制`redis lua scripts debugger`的使用
 
+
+#### Script Replication
+在standalone部署场景下，单个master实例管理整个database，而在集群部署模式下，至少会存在3个masters共同管理database。对于master实例，redis会使用replication来维护一个或多个replicas。
+
+由于scripts可能会修改数据，故而redis需要保证所有由script执行的写操作都要被同步给replicas，从而replicas的数据一致性。
+
+在script replication方面，存在如下两种方法：
+- `verbatim replication`：master会将script的source code发送给replicas，replicas再执行接收到的脚本。这种模式能够节省replication brandwith，因为在循环场景下短脚本能够产生大量的命令。
+  - 但是，这种模式下，replicas会对master的工作进行redo，即使针对读指令，这将会浪费资源，并且要求脚本中的写操作具有确定性
+- `effects replication`: 只有脚本中对数据造成修改的命令才会被同步，replicas针对`被同步的写指令`进行执行，并不会像前一个模式一样重新执行脚本。
+  - 这这种模式下，关于replication的brandwith会增加，但是该模式本质上的确定的，无需写操作具有确定性
+
+> 在redis 3.2之前，`verbatim script replication`是唯一受支持的模式，直到Redis 3.2加入`effects replication`。
+
+#### Replicating commands instead of Scripts
+从redis 3.2开始，可以选择`effects replication`的同步方式，该方式会`replicate commands generated by the script`。
+
+> 从redis 5.0开始，script effects replication为默认模式，并不需要显式启用。
+
+在该模式下，当lua脚本被执行时，redis会收集`all the commands executed by Lua scripting engine that actually modify the dataset`。当脚本执行完成之后，commands sequence将会被封装到`multi/exec`中，并且被发送给replcias和AOF。
+
+该种replication方式在如下用例场景下具有优势：
+- script的计算速度很慢，但是最终script的修改能够被统计为较少的write commands
+- 当启用script effects replication时，`non-determinstic function`校验将会被移除。故而，可以在脚本中自由的使用`TIME`或`SRANDMEMBER`这类非确定性的指令
+- The Lua PRNG in this mode is seeded randomly on every call
+
+