阅读杨建荣老师的高可用方案概览，记录笔记内容以便学习，文章引用自https://mp.weixin.qq.com/s?__biz=MjM5ODEzNDA4OA==&mid=2650313518&idx=2&sn=d4b6290fea9c774bc532c3d55e1ff742&chksm=bec35b0989b4d21f685a764f4771c40b89f06f0361beaae6332884cb9d7ab93e00b8f3448343&mpshare=1&scene=1&srcid=03044P5L7uCurO1SWYiMn7l9#rd

高可用应该具备的特征信息

1.数据库对前端业务透明，业务不会因为数据库的故障产生中断。
2.非主节点的数据应该和主节点的数据实时或者最终保持一致。
3.当业务因高可用机制发生数据切换时，切换切后的数据库内容应保持一致，不会因为数据缺失或者数据不一致而影响业务。

业内常用的高可用架构类型：

1.主从或者主主半同步复制，通过依赖mysql本身的复制，master制作一个或者多个热副本，再Master故障时，将服务切换至热副本，从而达到高可用的效果。
2.MHA+多节点集群：基于MHA的集群方案，通常和其他第三方方案组合实现。
3.分布式协议（paxos） 基于分布式协议的高可用方案，常见的有Garela Cluester，PXC和MGR
4.基于共享存储方案：如san存储，这种方案可以实现网络中不同服务器的网络共享，共享存储能够为数据库服务器和存储解耦。
5.基于磁盘复制方案：如DRBD，DRBD是一个以linux内核模块方式实现的块级别同步复制技术，它通过网卡将主服务器的每个快复制到另外一个服务器块设备上，并在主设备提交块之前记录下来。类似共享存储解决方案。

    高可用方案的建议

1) 行业内多活的设计目标不是多写，需要先实现跨机房的高可用容灾和计划内的机房间数据切换
2) 引入consul的域名管理，解决VIP方案带来的一些潜在瓶颈（域名的业务属性，实现单机多实例，读写分离的域名配置）
3) 对于consul的整体定位不局限于集群环境，在单实例，集群，分布式中间件方向都可以采用，consul是作为一种通用的基础域名服务。
4) 同机房高可用方案的落地，需要和应用方对接程序端对域名的支持情况，在不同语言的客户端侧会有一些配置的差异。
5) 在已有高可用方案MHA基础上平滑过渡和改进，在后续新业务尝试引入MGR的方案
6) consul 业务API的开发，对数据库层面的业务可持续性访问（服务注销，服务发现）做一些补充和定制，保证consul服务的技术可控
7) 异机房高可用实现应用无缝切换，计划内切换，会有业务中断/延时，保证可控的基础上，应用端无须修改连接配置，需要测试DNS的域名转发等策略，计划外切换，需要做确认才可完成。
8) 对已有的分布式方案，可以采用MGR,中间件，consul的组合方案，实现读写分布式扩展。