之前关注了很多高可用方面的事情，但是似乎有一点我们忽略了，那就是我们所谓的高可用关注的更多是一种临界状态，更多是为了数据一致性和完整性努力，而对于切换时长存在一些问题，对于业务来说，这就会导致服务中断过长，服务不可用。对很多业务（除了一些交易系统）来说，能够最快恢复也许是重中之重，而在这个基础上能够延迟修复数据或者补数据，对于多方来说是一种性价比最高的事情。比如正常情况下，我们考虑了很多的异常，恢复业务需要10秒钟，但是如果我们采取最折中的方式，使得最快的切换方式保持在1秒或者毫秒，那么从这个层面我们可做的事情就很多了，所以有了这篇文章和两个相关方案，在此我们更多聊的是关于如何快速切换的方案。
1.方案概览
为了保证业务的可持续性，高可用方案主要覆盖三类场景：故障转移和主动切换和容灾切换。
分类 | 事件时间 | 切换预置条件 | 影响时长 | 适用场景 | 备注 |
故障切换 | 计划外， 不确定性 | 需要做故障预判和故障确认 | 秒级~分钟级 | 服务器故障，数据库宕机，网络异常 | 最大程度保证数据可用，可能存在部分数据丢失风险 |
主动切换 | 计划内 | 主动发起，故障预判和确认前置 | 秒级 | 更换OS硬件设备，更换存储，网络异常数据库重大配置变更（数据库重启）数据库升级，数据迁移 | 最大程度降低风险 |
容灾切换 | 重大决策 | 涉及前后端联动 | 分钟级+ | 机房故障 | 最大程度保证服务可用， 可能存在部分数据丢失风险 |
其中，
故障转移方案具有不确定性，需要做故障预判和故障确认后方可进行故障切换，预计影响时长在分钟级；
而快速切换可以作为高可用的补充方案，是主动发起的方案，属于计划内任务，预计影响时长可以控制在秒级；
容灾切换方案属于决策方案，在重大故障时需要前后端联动完成。
其中主动切换方案是该方案讨论的重点，主要有以下的一些预设条件
l 业务低峰期
l 数据延迟控制在1s以内
l 应用层具有自动重连机制
l MySQL基于异步复制模式
切换前，整个服务状态如下，其中主库可读写，从库只读，通过Consul服务访问至主库
2.快速切换参考方案1
1）建立双向复制关系，主从均开启读写，但是从库无业务数据写入
2）主库置为Read_only状态，业务写入失败，业务读依然可用
3）Consul域名服务切换到从库，取消之前的双向复制改为单向
3.快速切换参考方案2：
1）将主库置为Read_only状态，业务数据写入失败，但是依然可以查询
2）检测从库的数据延迟，检测N次，偏移量稳定无变化
3）配置数据库双向复制，从库置为可写状态
4）Consul域名切换到从库
小结：两个方案中，第1个方案比第2个要少一个步骤，而且建立反向复制的过程可以提前验证，相对来说更加便捷和和有效。
转文至此。
