昨天，我们聊了存储集群的分工和协作。今天，我们继续这个话题。
节点间数据传递
Leader节点接收到新的信息后，怎么传递给其他节点呢。这个信息可能是新插入的数据，可能是数据的更新，也可能是删除一些数据。一种传递的方式是把指令信息本身传递给其他节点，其他节点接收到指令后，再重新执行一下。这种方式实现上比较简单，但是问题是有可能会造成数据的不一致，比如数据库的SQL指令会用到now函数，两次执行的效果是不一样的。
另外一种传递方式是将变化后数据完全同步出来，这种方式也有问题，就是可能需要传递的数据特别多。比如我们将一个字段的数值做了更新，因为影响了所有数据，这就意味着我们要把所有数据发送出来。
我们可以综合两种方式，取长补短，根据指令不同来选择不同的传播方式。
另外，我们需要格外注意，节点间这种信息同步任务，是需要占用节点计算资源和存储的。我们不能让同步任务影响到正常的对外服务，两类任务需要做好隔离。一般我们会把同步信息记录在操作日志里，同时，每个节点都要有独立的端口和线程来处理两类任务。
最终一致性
我们看到，Leader节点把信息同步到整个集群是需要时间的，这个时间段内集群内部的信息是不一致的。如果这时候访问到集群的非Leader节点，拿到的数据可能是旧的。
这个问题怎么解决。首先需要看我们使用数据的场景。如果信息及时性要求不高，允许一定程度的延迟。那我们就不需要做额外的处理。我们只需要保证数据最终是一致的就可以。
如果及时性要求很高，我们就需要想办法解决了。比如针对这种特殊情况，我们可以在业务代码中强制只从Leader节点读取数据。但这么做不太优雅，业务代码中会耦合这种非功能性逻辑，侵入性比较高。我们可以把这部分代码抽取出来，自动检测哪些数据正在被更新，更新的这个阶段，对这部分数据的请求只从Leader节点读取。大家可以再想想有没有更好的方式。
业务分工
我们可以看到，存储集群是通过Leader节点来统一协调的。这样做的好处是信息传递的效率比较高，只要Leader确认了就可以，再由他去通知大家。但是，当数据量日益增加，集群规模越来越大，Leader节点会越来越力不从心。就像人一样，每个管理者都有他的管理半径，节点越多，需要同步和管理的代价就越大。
那怎么办呢？我们可以继续按照业务进行垂直分工。一个大的集群分工成多个小的集群，每个小集群再由各自的Leader节点来组织。
按照什么原则来分工呢？一个简单的原则就是耦合度。首先是业务耦合度，就是说这两个业务从逻辑上是否分类合理；另外就是数据耦合度，就是这两块的数据是否经常会关联在一起查询。
无论怎么分工，可能总会有一些数据分布在不同的集群，但是偶尔需要关联查询，那怎么办。一种办法就是在计算集群中去做，由业务代码分别读取各自数据，然后在内存中进行拼装。这种办法因响应比较及时，但是无法处理大量的数据。
另外一种办法就是通过离线计算来做，离线计算的话题以后我们再聊。但是这种方式的及时性不够好。需要计算完成后，把中间结果数据放到其他存储集群中来实时访问。大家需要跟进自己的业务特点来自己选择。
总结一下，存储集群通过日志记录在各个节点中同步信息，达到数据的最终一致性。随着集群节点规模的增大，需要根据业务做集群划分，降低超大集群的管理成本。
