什么是高可用？

我理解的高可用，就是在机器当机，机房网络不通，服务进程挂掉，不影响业务层的继续。对于数据库来讲，就是数据不丢，数据准确。可横向动态扩展，理论上通过加机器就可实现性能的提高，但是做起来却是很难的一件事~~

常见的架构

一、 master-slave架构，读写分离

1. 优点：
   1. 部署简单
   2. 单向同步方式，基本上不会出现冲突。
   3. 读写分离，可提高读性能
2. 缺点：
   1. master存在单点写问题
   2. slave与master之间的同步可能存在延迟造成脏读等问题

二、 master-master架构，双主双写双向同步

1. 优点：
   1. 读写性能都能提高
   2. 在一台master故障时，流量可通过keepalived等手段切到另外一台master
   3. 当故障master恢复时，会自动同步数据，达到数据一致
2. 缺点：
   1. 发生冲突的概率比较高。例如存在这种情况，客户端访问后台服务写入一条数据，请求到了master-A所在机房，master-A已经写入数据，但是在回包给客户端时，丢包或是其他原因造成客户端没收到响应， 于是重发请求，这一次请求却到了master-B，master-B此时还未与master-A进行同步，master-B也写入了这条数据，如果数据有做唯一键约束，在同时时就会报duplicate key之类的错误

引入延迟从

在这台作为延迟从的slave机器上，配置master_delay，延迟1小时同步masterA，这样在不小心删除了主库时，实时同步的B可能已经执行了删库操作，但是还有这个延迟从有拘留的余地

存在问题：如果刚好删库的时候，延迟从也同步了masterA的数据，那就悲剧了，延迟从也执行了删库操作。

2-3个延迟从

这种方案还是存在问题，如果在写入master成功之后，master所在机器突然挂了（假设已经返回业务层写入成功），那这时如果写入的数据还没来得及被slave同步（msyql的replication默认是异步的，为了提高master性能），此时所有slave上并没 有这些数据的存档，当业务流量切到slave之后就会查找不到这个写入的结果，对客户侧的感知就相当于，我明明存了100元，你告诉我存入成功，但是现在我查余额，100元不见了~~

半同步

半同步是从mysql5.6+版本开始通过插件的方式支持，当master开启了半同步支持，且至少有一台slave支持半同步复制方式时，若有事务提交至master，此请求会被block，直到master写入binlog，且至少有一台slave将事务相关的events写入自己的relay log并flush到磁盘上。或者在写入master之后，等待slave回复ok时超时了（默认是10s)，这时又会自动转成异步复制的方式，直到有一台支持半同步方式的slave重新与master连接上。

1. 优点：
   1. 保证了数据的完整性
   2. 容灾性更强大，且支持自动切换半同步和异步方式
2. 缺点：
   1. 加大请求延迟（视master-slave之间的网络情况），影响写入的性能