在大型互联网场景中，数据库的高可用性显得尤为重要，为了保证稳定性，一般需要采用强化的架构模式，以保证数据层能够提供持续有效的稳定支撑。
每个服务对应一个存储服务实例（基本是数据库单实例模式），使用 IP+Port 进行连接和调用，这就是大家常见的数据库直连。
用户计算服务（svc） 配置IP+端口指向数据库实例地址，进行访问和操作。
互联网场景下，理论上访问量和数据量都是不断膨胀的过程。随着数据量的增大，数据库一般要进行纵向（Scale Up）和 横向（Scale Out） 的拆分，
分库分表之后可能会将数据拆分到不同的数据库实例，甚至不同的IDC上，这样可以 降低数据量，提高执行性能的目的。详细参考笔者这篇《MySQL全面瓦解28：分库分表》。
如上图，库表拆分之后，使用不同的条件可以路由到不同的IP，这样来实现业务上的数据隔离，这种条件可以是用户的角色，业务的类别，
甚至直接对数据取模或者hash，只要确保链接到对应的数据库上即可。这边举个例子：（value % 2 == 0） = condition1，（value % 2 == 1） = condition2
。
以上只是解决了数据库大容量的问题，将数据库的风险降低，性能提升。并没有实质的解决可用性问题，如果其中一个数据库实例出现故障，
依然会造成大面积的不可用。
在互联网架构中，比较常见的一种方式就是，使用 双主或者主从同步 + keepalived + vip的模式来保证存储层的好可用性：
如上图，两个库（主主或者主从）使用相同的虚拟IP，当主库挂掉的时候，虚ip自动转移到另一个主库（或者转移到从库上，并将从库切为主库），这个切换过程对业务应该是透明无感的，也不会造成使用上的异常，以此保证数据库的高可用性。
可以继续从2.3演化出分片分库模式下的高可用架构，如下：
如果数据库继续膨胀，流量继续扩展，还可以继续扩容，找到最恰当的分片模式。
MHA（Master High Avaliable） 是一款 MySQL 开源高可用程序，MHA 在监测到主实例无响应后，会自动将同步最靠前（即数据偏移量最少）的 Slave 提升为 Master，然后其他所有的 Slave 重新指向新 Master。架构模式如下：
PXC（Percona XtraDB Cluster）是一种开源的 MySQL 高可用解决方案。它将 Percona Server、Percona XtraBackup 与 Galera 库集成在一起，以实现多主复制的 MySQL 集群。
缺点是只支持InnoDB引擎模式，且多主数据同步必然会有性能损耗、同步延迟和数据差异风险。
另外，这种多主同步模式具有典型的木桶效应，系统的吞吐被最差的节点左右。
架构如下：
MySQL 5.7 退出了高可用的的模式 MGR（MySQL Group Replication），他具备了多节点数据写入和强一致性的特点，这一点跟与 PXC 相似。同时采用Group Communication System（GCS协议）进行数据同步来保证消息的原子性。
MGC需要使用到InnoDB Cluster模式，才能实现真正的高可用，高可用架构图参考下面：
备注：图片来自官网，就不再画了。
互联网大流量场景下我们经常会发现存储层容易出现瓶颈，这个时候就需要扩容。
相对于停服扩容来说，无损、透明、平滑的数据库扩容才是我们实际追求的目标。
步骤如下：
数据库存储层实现可用性有很多种办法。除了最基本的 主从/主主 + Keepalived 架构 之外，还有 MHA 、 PXC 、MGR/InnoDB Cluster 等，后面我们一一拆解。
实现高可用，意味着后续的迁移、扩容、业务调整，都应该是可以平滑的，对业务无感的。
当数据库集群的某个节点由于故障无法对外提供服务，若此时集群内还存在其它可用节点，则将故障节点上的会话连接自动迁移到目标节点上，客户端无需再次发出连接请求，仍然可以继续执行数据库操作。