接随笔一，我们讨论系统容灾备份问题。
坦率的讲，多副本是系统容灾的几乎唯一手段，因为单机总是不可靠的，这个是客观事实，当然没有绝对有效的容灾手段，其实我们在赌博，我们赌在不同空间的多台机器同时发生故障的概率，如果这个概率足够低，同时这个也是基于成本考虑的平衡，这里的成本包括但不限于时间成本，维护成本，存储成本，能源成本，人力成本。
系统容灾备份包含了两个基本问题：
1. 故障检测和故障恢复
2. 多个副本之间的数据一致性
首先讨论一下故障检测。一个节点（抽象概念）是否已经故障需要借助外部的其他的节点，组件来检测，这里就存在两个问题，一个问题是检测节点或者组件检测到一个节点故障是否意味这这个节点确实故障了，显然我们不能准确确定这一点，如何对于一个节点故障在系统内达成一致是一个复杂的问题，比较常见的做法有租约机制，心跳机制，哨兵探活机制，需要说明的是当系统内部对一个节点是否故障达成一致并不意味着这个节点真的故障了，但是系统必须作出相应的动作处理这个事件。分布式系统复杂就复杂在我们对于一个实体的状态存在不确定性和滞后性，并且确认的成本很高以至于我们必须采用一些折中或者间接的方式降低确认成本。
当系统检测到故障时，就需要及时对故障进行处理，处理的方式无非就是丢弃这个节点，补充新的节点。这个看似简单的过程一点儿也不轻松，对于一个无状态的节点故障，故障处理的逻辑一般很简单，替换补充的成本很低，我们可以肆无忌惮的干，基本也没啥问题。但是对于有状态节点，则没那么轻松，记得我们在随笔一中提到的分片迁移的描述了吗。补充新的节点，意味着需要从其他的健康的副本上的数据复制一份到新的节点，当分片比较大的时候这个过程代价也很高。因为我看到很多系统对于这部分的描述中提供了一个折中的方案，那就是我们基于经验，发现大部分故障都是暂时的，一段时间之后可以自行恢复，比如网络故障，那么当数据备份可靠的前提下，我们等一段时间（这个时间是一个经验值，不同的系统不同，不同的基础实施不同），如果可以自行恢复那么我们就不用大费周折的复制数据了。
故障恢复期间如何保证系统服务不中断，这又是一个头痛的问题，多节点写带来的写冲突问题以及数据合并数据一致性问题几乎不可能解决，即使强如paxos协议，在生产环境中也是指定一个leader节点唯一负责写，因此系统设计的时候一般写都是指定一个主，由它负责一个分片（一般都是一个分片）的写。假如故障节点正好是负责写入的节点，那么服务至少会出现短暂的中断，系统需要依靠一些机制重新指定新的主分片继续写，这里必须解决系统在某一个时刻存在多个主节点的问题，一般会引入租约机制，逻辑主机制等解决，这里不展开讲。
前面也说了多副本是应对系统灾难的唯一有效手段，那么如何保证多个副本之间数据的一致性呢，经典的主从复制模型（也有一些变种）是一个很好的方案，但是这种模型灵活行太差，要么不能完全保证数据一致（最终一致），要么保证了数据一致但是可用性很差，后来就有了Paxos一致性复制协议以及变种raft协议，这个协议可以保证数据的强一致。paxos协议非常复杂（鄙人才疏学浅，看不懂，虽然这个协议被数学严格证明是正确的），很少有公司能实现它，并且即使实现了也很难证明是绝对正确的。raft协议则相对比较简单，工程实践比较容易，有很多开源的实现都不错，但是raft牺牲了性能（串行apply raft log）换来了足够简单。对于一致性复制协议我想多数几句，拿raft举例，raft协议中leader会定期给所有的follower发送心跳以确保其leader的地位，在工程实践中，如果我们采用小分片模式，同时一个分片的副本放在一个raft group中，我们需要考虑心跳带来的巨大网络IO，另外还有一个问题就是高级语言中的GC，如果GC导致进程长时间停顿，那么会造成leader不能正常发送心跳导致引发重新选举，这个问题很严重，大量的分片几乎同时开始选举，造成服务中断，这个问题在我们的实践中需要引起足够的重视。
另外提一点，副本之间的数据复制协议一般要求写入的数据顺序复制到其他的副本（数据的先后顺序很多时候很重要，比如事务数据），这就制约了复制的吞吐，进而制约了分片的吞吐，如果分片很大，那么集群的吞吐就会收到限制，这个也是我们在优化系统写吞吐的时候需要考虑的问题。
总之还是那句话凡有收益必有代价，当我们看到一个解决方案带来的好处的时候一定要想想它的代价是什么，是否值得我们这样做。
网友评论