业务应用对数据库的数据请求分写请求（增删改）和读请求（查）。当存在大量读请求时，为避免读请求阻塞写请求，数据库会提供只读实例方案。通过主实例+N只读实例的方式，实现读写分离，满足大量的数据库读取需求，增加应用的吞吐量。
对于只读实例，如果采用单机无备节点作备份的方案，当实例出现故障或有重建需求的时候，会出现较长时间的不可用，通常需要客户做业务连接上的调整或是创建新只读实例等繁琐操作。单机只读架构如下所示，一旦单机只读发生故障，则业务中断，直至故障修复实例复位。
RDS for MySQL只读节点稳定性解决方案
为了保证业务的连续性及稳定性，RDS for MySQL在原来单机只读的基础上，推出了“高可用只读”。高可用只读在故障的容错能力、异常的应对能力方面具有比较大的优势。相比较单机只读动辄小时级的中断，高可用只读在故障倒换时，仅有秒级中断。
高可用只读架构图如下，异常发生时（比如数据库异常，虚拟机异常等），HA组件可将主只读节点的VIP（虚拟IP）自动切换到备只读节点上，从而快速恢复业务。
除高可用只读方案外，多只读实例Proxy轮询的方案也有相同效果。即购买多个只读实例，并开启数据库代理（proxy）的方案，在发生异常情况时，数据库代理自动把流量切换到其他正常只读实例，从而避免出现业务中断发生。Proxy方案架构图如下：
单机只读、高可用只读、多只读+ proxy，在应用并发连接数、异常反应、成本方面的对比如下：
以上的多方案给用户提供了灵活的可选择性，用户可以基于业务量、成本、业务运行效率等方面综合评估选择适合自己的方案。这篇文章中将重点介绍下高可用只读，未来我们还会基于proxy做一期介绍，敬请期待。
高可用只读使用办法
