上一篇，我们把后端服务分为计算和存储两大职能，同时聊了计算集群的分工和协作。今天，我们继续聊一下存储集群的部分。

二次确认

相对计算集群来说，存储集群多了一点很重要的职责，就是要保障各个节点之间的数据一致。类比我们日常工作中的团队，怎么保证传递的信息，团队其他成员都能理解。这的确是个很头疼的问题。

大部分情况，我们以为自己说清楚了，对方应该明白。但是实际对方不明白，或者理解成了另外的样子。那怎么解决呢，我们常用的方式是，让对方再复述一下，看看他说的是否跟我想要表达的是一致的。如果不一致就再说一遍。这叫二次确认。

同样的道理，当我们存储一个数据的时候，可以让存储节点给我们二次确认，这样来保障这个节点的数据一致。这其实就是事务的概念。举个例子，多个数据库之间的操作，我们想保持在一个事务内，就是采用二次提交的方式。第一次提交就是通知大家新的信息，然后大家操作完毕后，再反馈操作后的结果。只有大家都成功了，才开始第二次真正的提交。如果其中有一方失败了，大家都要回滚到之前的数据状态。

团队Leader

大家可以看到，这种二次确认的方式代价是很大的。尤其是对一个大的团队而言，要传递每个信息都要每个人二次确认，这是没有办法做到的。那怎么来做呢，现实生活中，我们会给这个大的团队找一个领导，所有信息的传递，我们都保证跟这个领导确认好，再由这个领导将信息传达给各个组员。

在计算机集群中，依然可以采用这种方式。我们可以在一个大的集群中，选取一个Leader节点。首先由他来确认信息，然后再通过他传递给其他节点。

这里就有两个问题要解决。第一，这个Leader怎么选举，当Leader出现故障后怎么办；第二，Leader的信息怎么有效的传递给各个节点。

Leader选举

先说第一个问题，首次的Leader我们可以直接指定。主要是集群运行过程中，如果Leader发生了故障怎么办。这时候就需要从其他节点中选择一个新的出来。

在解决这个问题之前，我们首先得解决怎么实时获取节点状态的问题。如果我们没有办法第一时间捕获故障信息，那再好的办法也已经太晚了。怎么判断这个节点还活着呢。类比我们自己，我们通过摸心跳来判断一个人是否还活着。集群节点也可以这样，节点可以固定频率的向外发送心跳信息。只要心跳在，节点就还活着。

再来看一下，当Leader节点故障后，我们怎么来重新选择一个。还是类比我们工作中的团队，如果一个Leader离职，怎么办。要么上一级领导再指定一个；要么大家自发选举一个，一人一票，得票多者当选。

计算机集群也可以采用类似的办法。一种方式是领导指定。我们先得在集群内或外部找一个领导。这个领导接收每个节点的心跳信息。当Leader节点发生故障后，领导通过规则重现指派一个Leader节点出来。那新选举出来的节点怎么让外界知道呢？我们得让外界对集群的访问，首先通过领导。通过领导来获取集群状态，然后再访问实际的节点。这种方式的缺点是领导节点也得是一个集群，不然就是个单点。大家可以深入研究下通过zookeeper来组建集群的方式，有类似的原理。

另外一种方式就是自发的选举。选举者得先知道可以选谁，这就要求每个节点要把心跳信息发送出来。到底发给谁，一种方式是广播出来，大家都可以接收，每个节点维护一个整个集群的状态信息。一种方式是把心跳发送给一个中立的节点，由这个节点维护整个集群的状态。

当Leader节点故障后，因为Leader心跳停止，其他节点就可以按照固定的规则从自己维护的节点信息中选举一个出来。当发现自己应该被当选后，就向其他节点发送推举自己的请求。当过半数节点同意后，新的Leader节点就确定下来了。

这里面有一个问题需要我们注意。因为网络的原因，可能某个节点的心跳信息会有丢失。这样每个节点维护的集群列表可能会不一样。这样每个节点的选举虽然规则相同，但是因为节点列表不一样，也可能选举结果会不一致。这就会造成同一时间，可能会有两个或多个节点请求大家推举自己。那怎么来办，我们就需要重新选举了。因为第一次选举的时候，大家已经把自己维护的节点列表周知出来。这时候，第二次选举可能就成功了。

总结一下，我们通过二次确认，可以保证一个事务的严格执行。但是对大的集群来说代价过大，我们可以选举出Leader作为代表，代理整个集群。下一篇我们继续来说这一块。