rebalance 用于将集群中的分片进行均衡，保持各个节点的分片数量大致相等，当集群扩容或缩容，掉一个节点的时候，这过程会自动完成。直观的感觉他应该是在后台默默干活的过程，最多占用带宽和磁盘 io 资源，应该感受不到他的存在，但实际情况是，他可能引起一些意想不到的问题。
这篇文章主要思考分片 relocating 对集群会有哪些影响（基于 v7.7），有下面几个。
分片移动结束后，target 节点会向 master 发起一个 shard-started PRC，该 RPC 具有次高优先级：URGENT， master 对该 RPC 的处理比较慢，尤其是在集群分片数量到几万的级别，从而可能导致一些较低优先级的 RPC 长时间来不及执行，例如 put-mapping，进而导致对业务的明显影响。
由于 rebalance，allocation filtering，forced awareness等任意原因产生的 shard-started RPC 都会存在这个问题，例如扩容集群的时候，如果把 rebalance 并发开的比较大，对 master 的处理能力造成明显影响。因此对于分片数较多的集群，当你想要加大 rebalance 和 recovery 并发的时候要考虑到对 master 的影响。
当一个主分片被 rebalance 或者手工 move 的时候，可以想象必然存在一个时间段该主分片无法写入。
Elasticsearch 对主分片的 relocating 也是直接 move，不会先将主分片资格让给其他副分片，再进行 move，即便如此，也会存在一个时间点进行切换，无法响应写入。
这个时间段从 RPC 的时序来看的话，如下图所示，红色标记的区域为阻塞写入流程的时间段。在该时间段内，客户端的写入请求会被阻塞无返回，直到这部分处理完成。
以手工 move 为例，当一个主分片从 node-idea move 到 node1时，主要有以下几个阶段完成：
阻塞客户端 bulk 写入的阶段，就在 source 节点执行 finalize 阶段时，准备发送 handoff RPC 时开始，直到收到 master 新的集群状态，将该分片标记为 STARTED，每个节点应用集群状态的时间点略有差异，所以每个节点停止阻塞写入的时间点也会有微小差异。
handoff 的 RPC的作用是告知 target 节点该分片可以切换主分片状态，对 handoff RPC 的处理都是一些计算操作，其中涉及到几个锁，一般会很快完成。
整个主分片的 relocating 过程对写入的影响是很复杂的处理过程，我将他们划分为几个阶段，下面是详细过程。
在分片的整个 relocating 过程中，对 target 节点的请求都会被转发到 source 节点，直到 target 节点应用了 master 下发的分片变为 STARTED 的集群状态。
正常写入阶段
起初，写入请求到达 source 节点，像往常一样正常写入到主分片中，直到复制阶段。
复制阶段
此阶段将收到的写请求复制给 target 节点。他从收到 prepare_translog 的 response之后开始，直到 handoff 阶段开始之前。
