[skip ci] remove useless tag (#7591)

Signed-off-by: ThyeeZz <jialian.ji@zilliz.com>

docs/design_docs/dataservice_recovery_design.md

@@ -1,67 +1,61 @@
 ### timetick 相关改动
 
-Datanode发送timetick msg需要有channel的信息，DataCoord根据channel来检查segment是否可以seal和flush
+Datanode 发送 timetick msg 需要有 channel 的信息，DataCoord 根据 channel 来检查 segment 是否可以 seal 和 flush
-
-
 
 ### 服务发现
 
-DataCoord启动时检查是否有新的或重启过的DataNode，如果有重启过的，重新注册channel，并seek到上次记录的位置
+DataCoord 启动时检查是否有新的或重启过的 DataNode，如果有重启过的，重新注册 channel，并 seek 到上次记录的位置
 
-通过watch机制监听DataNode的状态，如果DataNode下线，其注册的channel重新分配到其他node，并seek到上次的位置（重新分配不一定现在做）
+通过 watch 机制监听 DataNode 的状态，如果 DataNode 下线，其注册的 channel 重新分配到其他 node，并 seek 到上次的位置（重新分配不一定现在做）
 
-如果监听到DataNode重新上线，向其注册channel，并seek到上次记录的位置
+如果监听到 DataNode 重新上线，向其注册 channel，并 seek 到上次记录的位置
 
-如果监听到有新的DataNode注册，记录其状态，后续向其注册channel或进行load balance（load balance不一定现在做）
+如果监听到有新的 DataNode 注册，记录其状态，后续向其注册 channel 或进行 load balance（load balance 不一定现在做）
 
-DataNode如果由于网络原因与etcd断开，应该重启服务发现，DataCoord会去重新注册channel，DataNode不能重复监听相同channel
+DataNode 如果由于网络原因与 etcd 断开，应该重启服务发现，DataCoord 会去重新注册 channel，DataNode 不能重复监听相同 channel
 
 ### 需要记录的信息
 
-1. cluster信息（包括Datanode的节点及其上面的channel）
+1. cluster 信息（包括 Datanode 的节点及其上面的 channel）
-2. segment 分配信息（最后一次分配的过期时间，segment的上限等）
+2. segment 分配信息（最后一次分配的过期时间，segment 的上限等）
-3. stats 和 segment flush channel最后位置
+3. stats 和 segment flush channel 最后位置
-4. DataNode向DataCoord发送channel的最后位置
+4. DataNode 向 DataCoord 发送 channel 的最后位置
 
 ### 重启恢复流程
 
 1. 内存状态恢复：
-   1. 基本组件启动（meta， etcd等）
+   1. 基本组件启动（meta， etcd 等）
-   2. 恢复segment allocator和cluster状态
+   2. 恢复 segment allocator 和 cluster 状态
-   3. 
+2. 与 DataNode 节点交互：
-2. 与DataNode节点交互：
-   1. 启动stats/segment flush channel，并seek到上次记录的位置
-   2. 启动timetick channel
 
-3. 与Master交互：
+   1. 启动 stats/segment flush channel，并 seek 到上次记录的位置
-   1. 启动时不需要和Master交互，Collection信息为空，需要用到时向Master请求并缓存
+   2. 启动 timetick channel
-   2. 启动new segment channel
+
+3. 与 Master 交互：
+
+   1. 启动时不需要和 Master 交互，Collection 信息为空，需要用到时向 Master 请求并缓存
+   2. 启动 new segment channel
 
 4. 启动服务发现
 
-目前channel注册是segment allocation驱动的，每次请求segment时，检查其channel有没有被注册，没有则将其注册到DataNode，并保存到本地。这里有个问题，如果channel注册成功，DataCoord挂掉了，那么在重启后，DataCoord并不知道已经注册成功，来一个新的请求，还是会去注册，而且可能注册到不同的DataNode上面。类似Transaction的情况，需要有一套机制保证原子性在多节点写入，目前不太好解决。可以用以下步骤临时解决：
+目前 channel 注册是 segment allocation 驱动的，每次请求 segment 时，检查其 channel 有没有被注册，没有则将其注册到 DataNode，并保存到本地。这里有个问题，如果 channel 注册成功，DataCoord 挂掉了，那么在重启后，DataCoord 并不知道已经注册成功，来一个新的请求，还是会去注册，而且可能注册到不同的 DataNode 上面。类似 Transaction 的情况，需要有一套机制保证原子性在多节点写入，目前不太好解决。可以用以下步骤临时解决：
 
-1. 在etcd上记录分配方法entry，状态是未完成
+1. 在 etcd 上记录分配方法 entry，状态是未完成
-2. 向DataNode注册
+2. 向 DataNode 注册
-3. 在etcd上将entry标记为完成
+3. 在 etcd 上将 entry 标记为完成
 
-重启时/分配时，如果发现有未完成的entry，重新向DataNode注册，需要DataNode保证幂等性。
+重启时/分配时，如果发现有未完成的 entry，重新向 DataNode 注册，需要 DataNode 保证幂等性。
-
-这样保证了一个channel只向一个DataNode注册，如果DataNode挂掉或者与etcd断开，如果需要重新分配到其他DataNode，这些entry也跟着变。
-
-
-
-DataCoord模块中，有些策略是可能频繁改变的，比如channel对DataNode的分配策略，可以是随机/顺序/平均/根据collection分散等等策略，比如检测到DataNode创建和下线，可能会不处理/balance/将下线节点的channel转移到其他节点等。比如segment allocation可能会根据文件大小/条数等来确定是否关闭。实现应该把这些策略相关抽出来，方便以后修改。
 
+这样保证了一个 channel 只向一个 DataNode 注册，如果 DataNode 挂掉或者与 etcd 断开，如果需要重新分配到其他 DataNode，这些 entry 也跟着变。
 
+DataCoord 模块中，有些策略是可能频繁改变的，比如 channel 对 DataNode 的分配策略，可以是随机/顺序/平均/根据 collection 分散等等策略，比如检测到 DataNode 创建和下线，可能会不处理/balance/将下线节点的 channel 转移到其他节点等。比如 segment allocation 可能会根据文件大小/条数等来确定是否关闭。实现应该把这些策略相关抽出来，方便以后修改。
 
 ### TODO:
 
-1. segment allocation信息持久化及恢复
+1. segment allocation 信息持久化及恢复
-2. cluster信息（datanode及channel信息）改动+持久化及恢复
+2. cluster 信息（datanode 及 channel 信息）改动+持久化及恢复
-3. channel与datanode分配策略实现（可选load balance）
+3. channel 与 datanode 分配策略实现（可选 load balance）
-4. stats/segment flush channel记录位置及重启时seek 
+4. stats/segment flush channel 记录位置及重启时 seek
 5. 服务注册与发现，以及对应事件的处理逻辑
-6. timetick channel的改动以及segment关闭逻辑改动
+6. timetick channel 的改动以及 segment 关闭逻辑改动
-7. datanode上报的binlog信息持久化及恢复 
+7. datanode 上报的 binlog 信息持久化及恢复
-