doc: 阅读redis ASK redirection文档

中间件/redis/redis.md

@@ -221,6 +221,7 @@
         - [MIGRATE](#migrate)
           - [`CLUSTER GETKEYSINSLOT`](#cluster-getkeysinslot)
           - [MIGRATE](#migrate-1)
+      - [ASK redirection](#ask-redirection)
 
 
 # redis
@@ -3503,5 +3504,24 @@ MIGRATE target_host target_port "" target_database id timeout KEYS key1 key2 ...
 
 当迁移过程结束之后，`SETSLOT <slot> NODE <node-id>`命令将会被发送给涉及迁移的两个节点，从而将slots重新设置回其正常状态（之前状态为MIGRATING/IMPORTING）。通常情况下，该命令也会被发送给其他所有节点，从而避免`new configuration`在集群间的传播耗费太长时间。
 
+#### ASK redirection
+在如上章节中，介绍了`MOVED`和`ASK`两种重定向方式，其区别如下：
+- `MOVED`响应代表hash slot永远由其他节点负责，`应该将后续的所有请求`都发送给指定节点
+- `ASK`则是代表`只将下一个请求`发送给指定节点
+
+`ASK`的重定向机制在`slot migration`过程中是很重要的。就上章节的示例而言，在`slot migration`的过程中，对`slot 8`中的key进行查找时，该key极可能在A也可能在B，故而在slot迁移的过程中，`总是应该先查询A再查询B`。
+
+再client也要遵循上述行为，应确保slot从A迁移到B时：
+- 若查询slot中的key，应首先查询A节点再查询B节点
+- 若slot的状态为`IMPORTING`，代表该节点为slot迁移的目标节点，client在针对该节点的`IMPORTING slot`进行查询时，应首先发送`ASKING`命令
+
+> 基本上，`ASKING`是一个`仅一次有效`的flag，在client发送`ASKING`命令后，能够访问node的`IMPORTING slot`
+
+ASK重定向的语义如下：
+- 如果client接收到`ASK`重定向，那么仅将`被重定向的请求`发送给指定的目标节点，但是`后续针对该slot的节点仍应发送给原节点`
+- 将被重定向的请求发送给目标节点时，首先应发送`ASKING`命令
+- 此时，`ASK`重定向并不会导致client本地的`slot-node map`被更新
+
+一旦关于`slot`的迁移完成，`A`节点后续针对该`slot`的请求将返回`MOVED error`，client将永久的将`slot`映射到`B`节点。