接下来还是以我们的“山推“为例，看看一个group如何完成数据同步。假设，现在我有一个请求要写一个数据，由于只有Group Master能写，那么Group Master将接受这个写请求，并加入写的队列，然后Group Master将通知所有Group Slave来更新这个数据，之后这个数据才真正被写入File System。那么现在就有一个问题，是否应等所有Group Slave都更新了这个数据，才算写成功了呢？这里涉及一些NWR的概念，我们作一个取舍，即至少有一个Group Slave同步成功，才能返回写请求的成功。这是为什么呢？因为假如这时候Group Master突然挂掉了，那么我们至少可以找到一台Group Slave保持和Group Master完全同步的数据并顶替它继续工作，剩下的、其它的Group Slave将“异步”地更新这个新数据，很显然，假如现在有多个读请求过来并到达不同的Group Slave节点，它们很可能读到不一样的数据，但最终这些数据会一致，如前所述。我们做的这种取舍，叫“半同步”模式。那之前所说的强一致性系统应如何工作呢？很显然，必须得等所有Group Slave都同步完成才能返回写成功，这样Group Master挂了，没事，其它Group Slave顶上就行，不会丢失数据，但是付出的代价就是，等待同步的时间。假如我们的group是跨机房、跨地区分布的，那么等待所有Group Slave同步完成将是很大的性能挑战。所以综合考虑，除了对某些特别的系统，采用“最终一致性”和“半同步”工作的系统，是符合高并发线上应用需求的。而且，还有一个非常重要的原因，就是通常线上的请求都是读>>写，这也正是“最终一致性”符合的应用场景。
好，继续。刚才我们曾提到，如果Group Master宕机挂掉，至少可以找到一个和它保持同不的Group Slave来顶替它继续工作，其它的Group Slave则“尽量”保持和Group Master同步，如前文所述。那么这是如何做到的呢？这里涉及到“分布式选举”的概念，如Paxos协议，通过分布式选举，总能找到一个最接近Group Master的Group Slave，来顶替它，从而保证系统的可持续工作。当然，在此过程中，对于最终一致性系统，仍然会有一小段时间的写服务中断。现在继续假设，我们的“山推”已经有了一些规模，而负责“山推”推文的这个group也有了五台机器，并跨机房，跨地区分布，按照上述设计，无论哪个机房断电或机器故障，都不会影响这个group的正常工作，只是会有一些小的影响而已。
那么对于这个group，还剩2个问题，一是如何知道Group Master挂掉了呢？二是在图中我们已经看到Group Slave是可扩展的，那么新加入的Group Slave应如何去“偷”数据从而逐渐和其它节点同步呢？对于问题一，我们的方案是这样的，另外提供一个类似“心跳”的服务（由谁提供呢，后面我们将讲到的Global Master将派上用场），group内所有节点无论是Group Master还是Group Slave都不停地向这个“心跳”服务去申请一个证书，或认为是一把锁，并且这个锁是有时间的，会过期。“心跳”服务定期检查Group Master的锁和其有效性，一旦过期，如果Group Master工作正常，它将锁延期并继续工作，否则说明Group Master挂掉，由其它Group Slave竞争得到此锁（分布式选举），从而变成新的Group Master。对于问题二，则很简单，新加入的Group Slave不断地“偷”老数据，而新数据总由于Group Master通知其更新，最终与其它所有结点同步。（当然，“偷”数据所用的时间并不乐观，通常在小时级别）