《分布式存储系统》--总结②
本章承接上一章的总结①，本章详细的讲述了分布式复制、容错等关键技术。
4 复制
顾名思义，“复制”就是我们常说将数据复制多份存入到不同的机器节点中。分布式存储系统要求确保多个副本之间数据要有一致性。
一般来说复制分为两种：“强同步复制”与“异步复制”。下面我就具体来讲述上述两种复制。
强同步复制——即主备服务器均同时同步成功即返回OK。具体实现的方法为同步操作日志。即主服务器将操作日志同步到备用服务器中，然后备用服务器回放日志，完成后通知主服务器。但是若备用服务器gg了，那么久出现阻塞写操作的情况了。所以作为改进，我们可以将这个过程修改为：当有一个备用服务器通知主服务器返回成功即给客户端返回OK。
异步复制——主副本不需要等待备副本的回应，只需要本地修改成功就可以回应客户端OK。然后主副本则单独通过异步机制复制线程将客户端的修改操作通知备副本。然而，倘若主副本在通知之前故障了，那么就会丢失最后一步的操作。
在回复服务器的过程中，我们使用了检查点的概念。系统定期将内存状态以检查点的形式dump到磁盘中，配合操作日志进行回放，这样就不需要回放所有日志了。
5 故障检测与恢复
故障对于计算机来说是不可避免的，由于硬件、网络等原因会引起各种各样的故障问题，所以这里对故障的检测与恢复问题也就显得尤为重要。首先我们在这里介绍故障检测的方法与注意事项。
分布式的故障检测说白了就是检测我的slave机器是否还活着。最初的解决方案是这样：主机器A向从机器B发送心跳包，当B收到心跳包后予以回应。当A发送一定数量心跳包后仍没有收到回应，那么A就可以认为B已经停止服务。
但是细心的同学就可以发现，倘若我的B不是宕机了，而是网络问题或者他太忙了不愿意搭理A怎么办？所以上述方案有些小的漏洞，并不是很完善的方案。此时我们就可以使用租约机制（lease）来解决问题。简单来说就是A向B每隔一定时间发送一个租约授权，当B快超时的时候则向A申请“续约”。所以使用这样的解决方案的好处就是当我的B因为网络问题或者过于忙碌的问题出现无法正常续约时，我们的A机器就比较确认B此时无法进行正常服务，也就是意味着B的服务可以被安全的专业到其他机器上。
下面我们来讨论一下故障恢复的问题。下面是故障恢复的示意图。
故障恢复示意图
在这个图中我们可以看到对于故障恢复，这里提出了两种解决方案——单层结构与两层结构。简单来说，单层结构就是我的一个总控节点中有三台主机（节点123），而A1、B1、C1为三个副本，且分布作为主副本存入节点123中。当某个节点故障了之后我们就动态的调换到其他节点的对应位置。此时的故障分为临时故障与永久故障。临时故障就等待重新上线即可，而永久故障则需要增加副本操作。
而两层结构相当于我们在原来的节点的基础上添加了共同享用的分布文件系统，节省了存储空间，但是我觉得这样反而更为复杂，在第二层中其实同样需要考虑上述问题。
