Lab4B push or pull

[llf333]

博主您好！关于分片迁移的push模式我想问一下，以下这种case是如何解决的，是否会发生呢？groupA和groupB在ConfigNum为1时，B需要发送shard数据给A，并且A接收成功，B发送成功了，然后A和B正常运行到达了更高的ConfigNum，之后若A在没有persist数据时宕机重启了，ConfigNum重置为0了，当它再次到达ConfigNum为1时，是否会一直阻塞在此呢，因为B已经不会再给它发送数据了。换句话说，ConfigNum是否需要连续递增？能否直接query到高版本的Config，然后进行数据迁移？

[OneSizeFitsQuorum]

按照这个 case 应该是 A 必须得持久化之后再返回接收成功，否则 B 就不能在这个时候自增 configNum

[llf333]

万分感谢！

[goldwind-ting]

不是很明白，configNum = 1时， 当B push数据给A，Group A的leader接收到push来的数据之后，不是会先交给raft进行group内复制吗，同样，当A宕机重启后，之前push来的数据还在raft的log里，接着重放log内的数据就行了，为什么会一直阻塞呢？
@llf333

[llf333]

不是很明白，configNum = 1时， 当B push数据给A，Group A的leader接收到push来的数据之后，不是会先交给raft进行group内复制吗，同样，当A宕机重启后，之前push来的数据还在raft的log里，接着重放log内的数据就行了，为什么会一直阻塞呢？ @llf333

你说的是对的。的确是交由raft层达成一致（持久化）后，才能算作接收数据成功，然后再给B回复RPC消息。