实际上高可用就是系统能提供的一种无故障服务能力，就是避免宕机出现不能服务的场景。

首先来说对于无状态服务的高可用设计是比较简单的，发现有不能用的就直接停了换别的服务器就行，比如Nginx。这里说一下无状态服务就是不需要记录你的状态、数据等等，各个服务器提供的是一样的服务。mysql分库分表不同服务器能提供的查询服务是不一样的，因为存的东西不一样。

数据库的高可用设计是比较难的，其实最重要的就是冗余。主要有以下几种

• 主从模式的解决方式，就是主机挂了，将服务转移到从节点上，那这个从节点变成新的主机了，其他从节点从这个新主机上拷贝数据
• 分库分表的方式，一个库寄了，那把原本要写到这上的数据写到另一个上就行。但这个其实并不好，因为你分开了表甚至是库肯定是根据一个方式分的，那你把A类写进B类里肯定是不好的
• 融合两种方式，如下图

注意以上的方法都需要完成一个叫VIP（Virtual IP）的东西，即用户访问的ip是可以随意绑定在任何一台服务器上的。因为要让用户直接用起来，当有挂了的主机时，用户刷新一下，你底层直接把这个VIP绑给其他主机就可以返回给用户结果了。但是 VIP 也是有局限性的，仅限于同机房同网段的 IP 设定。如果是跨机房容灾架构，VIP 就不可用了。这时就要用名字服务，常见的名字服务就是 DNS（Domain Name Service）

最后一种新的技术：MGR技术。因为数据库复制的瓶颈在于，只能在一个节点写入数据，然后这个节点再将日志同步给其他节点。这样单点写入会导致数据库性能无法进行扩展。MGR技术之间的数据同步没有采用复制的手段，而是用GCS（Group Communication System）协议的日志同步技术。要求组中的大部分节点都接收到日志，事务才能提交。所以，MRG 是严格要求数据一致的，特别适合用于金融级的环境。并且MGR有两种模式，单主模式只有 1 个节点可以写入，多主模式能让每个节点都可以写入。而多个节点之间写入，如果存在变更同一行的冲突，MySQL 会自动回滚其中一个事务，自动保证数据在多个节点之间的完整性和一致性。但是缺点是有一个节点网络出现抖动或不稳定，会影响集群的性能！！！切记保证网络通畅