分布式数据中的坑（一）Master-Slave架构

前言

Master-slave 架构可以说是最常用的架构，关系型数据库诸如：mysql，postgreSql，oracle，Nosql诸如：MongoDb，消息队列诸如：Kafka，RabbitMQ等都使用了这种架构，本文将先简要介绍此种架构并介绍高可用Master-slave架构中的一些坑，以及应对之策。

Master-Slave架构的原理

如上图所示，Master-slave可以说是最常见的架构：

• 副本之一会被指定为Leader，或者是主库，写入请求会发送给主库，主库会将数据写入自己的本地
• 每当主库写完后，会将变更的日志发送从库，从库按照主库更新的顺序应用所有写入
• 客户端可以从任何库读取数据

同步复制和异步复制

如图中所示，Follower 1是同步复制，Follower 2是异步复制。 同步复制的优点是，从库可以保证与主库一致的最新副本，如果主库挂了，可以从从库找到一致的数据。缺点是，如果从库挂了，没有响应，那么所有的写入操作都将无法处理，直到从库恢复为止。

所以通常情况下，这种架构一般都是用完全异步的方式进行同步，这种情况下，如果主库失效，那么所有还没有被复制的数据就可能会被丢失；但是如果从库失效，主库依然可以继续处理写入操作。

主从复制的底层实现

基于语句

主库会记录每个请求的sql，并且将这些sql：insert select update等发送至从库执行，虽然听上去没什么问题，但是：

• 有一些非确