分布式下的MS

好，从现在开始，我们的标题变为：分布式系统下的master-slave复制。

什么是复制？

复制的意思很明显，就是把一份数据复制到指定的节点上。

复制的种类

复制现在主要有两种，一种主从复制，还有一种就是对等复制。

这里主要关注主从复制。

主从复制主要的动作

在主从分布的情况下，你把一份数据复制到多个节点。其中一个节点作为master。这个master是数据的权威同时通常也负责数据的更新。除了master之外的其它节点为slave或者叫secondaries。主从复制过程就是把数据从master同步到slave的过程。

上面这张图是就是数据从master复制到slave。master处理所有的写操作；而读数据可以从master上读也可以从slave上读。

主从复制能够解决哪些问题？

1、提高读取能力

在需要频繁读取数据集的情况下，主从复制可以通过扩展来提高读取性能。你可以通过增加更多的slave节点的方式，通过这种水平扩展的方式，来处理更多的读取请求。并且可以把所有的读取请求都交给slave节点来处理。

2、故障恢复能力

（1）、读取故障恢复能力。

master挂了，slave节点依然可以处理读取。这种优势对于那种大部分情况都是读取的场景是非常有用的。

要想让读取具备故障恢复能力，那么我们就要把写在我们的应用程序里边的“读”的path和“写”的path分开，也就是他们的path必须是不同的，这样你的写操作出现故障时，我们的读取依然坚挺。读写分离怎么搞呢？就是要你通过两个独立的分开的数据库connection来分别提供读和写。这样的能力一些的数据库交互库都是不提供的。当然了，你要开发这样的支持，其实和开发其它的功能是一样的，也是要通过不断的测试来确保这个故障恢复能力的有效性。我们可以把写操作禁用了，然后再试试看是不是能正常的读取。

（2）、写入故障恢复能力。

当master挂了以后，自然就不能提供写入能力了。现在整个集群是一个只提供读取能力的集群。直到出问题的master自己恢复了过来或者一个新的master被选举出来。所以在主从架构下，slave作为master的备份就很关键，这样即使master挂了，我们也可以非常迅速的就从茫茫的slave中选出一个新的master来。

这种快速选出新的master的能力，让主从复制变得很有用，即使没有了提高读取性能的能力。当我们的slave节点专心做备份这一件事情的时候，我们就可以把所有的读取和写入都交给master来做。这样的做法是不是会让你很容易联想到那种热备份的单机方案。这种方案让你既拥有了单机配置的简单又拥有强大的故障恢复能力。

现在再来说说选master的这个事情。master可以手动配置指定，也可以是通过自动选举产生。手动指派的意思就是在你配置集群的时候，就配置一个node作为master。自动指派就是指在你创建了集群了以后，他们就热闹地开始选举了，最后在茫茫的节点中选出一个master来。通过简单的配置就可以在master挂掉后自动的选出新的master，这大大缩短了集群的罢工时间。

主从复制不适合的场景

频繁写入的场景

由于master节点既要负责处理写入请求，又要负责把数据同步到slave节点。自然主从复制模式对于那种频繁写入的场景并不是很适合，虽然这种模式它是分流了一部分的读取请求到slave节点，看起来好像为写入请求也有所帮助。

主从复制不足之处

不一致

主从复制是分布式系统中非常重要的复制方式之一。不一致自然也就是成了分布式系统的主要问题了。或者说在分布式系统中就压根不存在一致性，至少是绝对意义上的一致。所以也只能说说“最终一致”。

在主从复制的模式下，有可能不同的客户端访问不同的slave节点，最后得到不同的value。因为有可能master的同步工作正在做，只同步了一部分节点，另外一部分节点还没有同步完。有一种最尴尬的情况，就是一个客户端刚刚写入一条数据，然后他立马就去读自己写入的这条数据，结果没读到。即使你使用主从复制仅仅是为了做个热备份也会遇到这样的问题，因为如果master挂了，那么任何的更新将不会被同步到slave节点上去。

总结

总之，主从架构，让你的集群拥有了读取的水平扩展和备份的水平扩展能力，同时也让你拥有了failover的能力。

但主从复制也存在不足之处，那就是不具备写入的水平扩展能力，同时复制的时延让集群的一致性变得没有那么绝对。

对于那些不是频繁写入但要求频繁读取的场景是足够而实用的了。