前几天，在首席群里讨论，某些人已经实现了在常去的城市都有房产了，出差都有自己的房住（当然有没有其他的目的就不得而知了）。相较于外出住酒店，两种方式各有优劣：
- 自有房产是自己的，住着安全放心
- 自有房产需要持续维护：平时需要打扫卫生，交物业费，装修家具等等
- 在不同城市的自有房产水平不同：房屋面积，装修家具水平，交通，周边等等
- 酒店不是自己的，可能有安全风险
- 酒店不需要持续投入，随到随住
- 酒店可以提供更多的选择
- …
上面的内容借用德哥今天公众号结尾的一句话“其实这段内容（原文为：这篇文章）的内容和标题是匹配的, 只是我还没想好到底有什么关联”。
数据库的高可用究竟是什么，我觉得还是得从实际需求场景来：
- 如果你的业务不允许中断，那么数据库的高可用目标就是能够持续提供数据库能力
- 如果你的业务允许短时间中断，那么数据库的高可用目标就是能够快速恢复拉起的能力
- 如果你的业务允许较长时间中断，那么数据库高可用的目标就是有办法能够恢复数据库即可
- 如果你的业务无关紧要，那么数据库高可用的目标就是…可以算没有目标
（Oracle Maximum Availability Architecture (MAA)）
那么从我个人角度以尽可能高的要求来看看数据库的高可用。
1 主从架构
（MySQL Replication）
主从架构是我们用的比较多的高可用架构，除了上图MySQL Replication，Oracle有(Active) DataGuard，PostgreSQL也有类似的主从架构。主从架构的优点其实是架构简单，大多数主从架构除了可以实现异地的数据容灾以外，也可以提供读写分离的能力（即主写备读），提升数据库整体性能表现。
主从架构主要需要考虑的问题是在switchover或failover后，应用能够正确连接到正确角色的数据库上，在这一点上MySQL提供了MySQL Router，三方开源则有MHA和Orchestrator等；Oracle则有TAC和GDS等。
2 集群
这里说的集群要区分于分布式架构，主要涉及MySQL Group Replication（MGR）和Oracle RAC架构等。
（Oracle Real Application Cluster (RAC)）
这里的集群主要是在实例级别提供高可用，即集群内部分实例故障，不影响数据库提供服务。但在RAC架构中仍可能有存储的单点故障，因此存储侧也应该实现高可用。当然在集群之上也可以和主从架构配合使用，提供异地容灾能力。
（Oracle RAC+DG）
3 分布式
无论是Redis、MongoDB还是大量的国产数据库，都提供了分布式数据库架构。
（OceanBase 4.x）
其实简单来看，就是每个分片内以主从或者副本的方式，分片每个节点可以在不同的地域，实现高可用。而数据库的访问接口则一般通过分布式集群本身来管理并提供服务。分布式架构中，只要不是某个分片的所有节点全挂的情况出现，理论上不会出现数据库异常。
4 误区
前两天一朋友的数据库通过主从架构上线实现了国产数据库的上线，本是一件好事，但是有些人却说，不是分布式，高可用不行啊。其实反观下整体架构，这些人为啥看不到，别人用1+1的节点解决了分布式需要10+台服务器才能解决的问题。不得不说，分布式数据库在高可用上看似非常美好，但是节点数量的提升带来的管理压力提升、元数据维护增加、网络压力增大等，而且分布式不一定适合所有应用场景产生的数据结构和业务场景（这里还不考虑业务代码变更）。
5 光是数据库？
举个栗子，数据库实现异地容灾，且前端应用可以自动连接到对应角色的实例。但是业务应用程序却只部署在了一个地方，那么如果这个地方整个IDC出现异常，那么前端业务同样不可能实现容灾切换，所以应用程序也需要多地部署。
总结
本期浅谈了一下数据库的高可用，我认为一切还是从需求出发，结合可接受成本来做高可用。
老规矩，知道写了些啥。
