这个文档中指出，split 过程中会有一些 propose 的 raft log 被 skip 掉，报错 epochNotMatch
这个流程在 merge 过程中类似，但是文档：
中描述， Target Region 无服务不可用时间
Target Region 在 apply CommitMerge 的时候，epoch version 也递增了，为何避免了 split 类似的问题呢？
2 个赞
在 TiDB 中，当进行 Region 的合并（merge）操作时，确实不会出现服务不可用的时间。这是因为在 merge 过程中，TiKV 会使用一种称为 “Atomic Region Merge” 的机制来保证数据的一致性和可用性，从而避免了服务不可用的情况。
在 Atomic Region Merge 机制中，TiKV 会将 merge 操作分为多个阶段，并在每个阶段中执行一系列的操作来保证数据的正确性。其中，关于 Region epoch 的变化，是在 merge 过程的第一个阶段中进行的。
具体来说，当进行 merge 操作时，TiKV 会将目标 Region（target region）的 epoch 增加，并将其设置为一个特殊的值。这个特殊的 epoch 值表示该 Region 正在进行 merge 操作，并且不会被其他操作所影响。同时，TiKV 会将源 Region（source region）的 epoch 设置为一个较大的值，以确保在 merge 过程中，源 Region 不会被其他操作所影响。
通过这种方式，TiKV 在 merge 过程中保持了 target region 的可用性，同时避免了 epochnotmatch 错误的发生。因为在 merge 过程中，TiKV 会根据 epoch 的变化来判断是否允许对 Region 进行操作，从而保证了数据的一致性。
需要注意的是，虽然 merge 过程中不会出现服务不可用的时间，但在 split 过程中可能会有一段时间的服务不可用。这是因为在 split 过程中，需要将一个 Region 分割为多个子 Region，这涉及到数据的重新分布和调整，因此可能会导致一段时间的服务不可用。
TiKV 会根据 epoch 的变化来判断是否允许对 Region 进行操作
这个可能需要再详细一些，merge 过程中，
1、merge 过程中， region epoch version 同样也会增加，TIKV 是如何比较 region epoch version 和 propose 的 region epoch version 的，这个判断逻辑和 split 有何不同，为何避免了 epochnotmatch 错误
2、如果判断不允许，又不报 epochnotmatch 错误，那接下来的流程是什么呢
当进行 merge 操作时，TiKV 会将目标 Region（target region）的 epoch 增加，并将其设置为一个特殊的值。这个特殊的 epoch 值表示该 Region 正在进行 merge 操作
这个逻辑好像没有在文档里面表现出来
Target Region 在 apply CommitMerge 的时候，epoch version 也递增了，为何避免了 split 类似的问题呢？
CommitMerge apply 成功会导致 epoch 增加，也会有类似 split 的问题。
不过这个我认为不算可用性问题，客户端更新 epoch 信息后重试一下就行了，通常在 10～100ms 之间吧。
1 个赞
学习了
TiDB的源码还真的没有看过，学习了。
不论是merge 还是 split ，所有的 version 都和 TSO 有关，这样可以保证
TiKV 会使用一种称为 “Atomic Region Merge” 的机制来保证数据的一致性和可用性
另外调度的发起是 PD，PD 中有所有 region 的信息，而且会有心跳来保持这个信息的持续更新
Tikv 和 PD 的事件都是异步的，只有达成条件就会触发，如果要问条件是什么，我也答不上来，太复杂了… 
举个例子：
tikv compaction 也是异步事件，触发的条件和生效的条件就无比复杂…