在主从架构中，你将数据复制到多个节点，一个节点被指定为主，其他的都是从。主节点通常负责处理数据的更新，并启动单独的进程将数据同步到从节点。
    94BDBBEF0C0B73462E401044981AE058.jpg
    当你有很多读请求，但是写请求比较少的时候，主从复制架构就显得十分有用了。你可以通过水平拓展——即增加更多的从节点处理更多的读请求，并确保所有的读请求由从节点来处理。

    不过如果主节点宕机了，则整个系统不能响应写请求了。除非主节点恢复了或者重新指定一个主节点。由于有多个从节点作为主节点的备份，因此主节点的恢复可以加快——我们可以指定一个从节点变为主节点。因为在主节点出现故障的时候，可以指定一个从节点变成主节点，所以即使你并不需要向外拓展主从复制也是非常有用的。在这种情况下，所有读写请求可以由主节点处理而从节点仅仅作为一个热备份。在这种情况下，你可以认为系统是一个有热备份的单个服务器存储。你拥有单服务器的方便，而且可以妥善应对服务器的故障

    我们可以通过手动或者自动的方式指定主节点。手动指定通常意味着，当你配置整个集群时设置一个节点作为主。自动方式意味着，在你创建集群时，它们自己选出主。除了配置更简单，自动方式意味在主节点宕机时，集群可以自动指定一个新的主，这将减少停机时间。

    为了得到主从架构的好处，你需要确保你的应用程序的读写请求发送给不同的服务器，这样在写请求失败时，读请求仍然可以成功。这包括诸如通过不同的数据库连接处理读写请求。和其他功能一样，你必须通过测试来验证这项功能的有效性：让写失败，并检验读此时仍然是成功的。

    主从复制看起来优点很多，但也有缺点——主从之间的数据不一致。不同的客户端，如果从不同的从节点那读取数据，会看到不同的值，因为值的改变可能还没有传播到从节点。在最坏的情况下，这可能意味着，客户端无法读取到它刚写入的值。即使你使用主从复制只是作为热备份,这也可能是一个问题，因为如果主服务器失败，没有传递到从节点的数据更新都将丢失。