常见的mysql集群架构
根据业务发展阶段和业务代码部署情况不同，对于扩展单数据库可以使用以下几种部署架构模型
单地域高可用架构
- 单地域高可用架构的构成
- dbproxy数据库代理: 主要处理:读写分离，主从切换等。
- 主库（高可用）：处理业务写流量。
- 从库（多实例，可选高可用）：处理业务读流量。
- 单地域高可用的架构可以处理
- 业务流量在单地域的的业务结构
- 可用性：可以处理：dbproxy主备切换（proxy失败），主库主备切换（主库失败），添加从库（读流量扩容）
- 单地域高可用架构不能处理
- 本地域机房失效。
- 单地域架构需要关注的指标
- 地域服务器报警
- 写流量报警（通过主库主备切换恢复）
- 读流量报警（通过新增从库扩容）
- binlog延迟报警
- 说明
现实中这种架构的服务器比较少，一般为了稳定性，会把业务代码进行多地域部署，这样下面这种架构数据库就更加适应这种多地域业务部署的情况。
多地域高可用架构
- 多地域高可用架构的构成
- dbproxy数据库代理: 主要处理读写分离，主从切换，地域切主。
- 地域主库，负责本地域内的主从复制。
- 真实主库，负责整个业务的写流量。
- 地域从库，负责本地域的数据库读流量。
- LVS，隐藏dbproxy主备细节，因为mysql访问者一般是业务代码。因此这里的LVS是内网负载均衡.
- 多地域高可用架构可以处理
- 单地域服务器报警。
- 业务流量在多地的业务。
- 可用性：dbproxy主备切换，主库主备切换，主库地域切换，添加从库，添加地域。
- 多地域高可用架构需要关注
- 地域服务器报警
- 写流量报警（通过主库主备切换恢复）
- 读流量报警（通过新增从库扩容）
- binlog延迟报警
- 地域级服务可用性报警。
- 说明
这种架构主要处理单库多地域扩展性的问题。很明显这种架构因为写流量集中在主库，这里会成为瓶颈，可能需要分库做进一步的扩展。
by：zhangfeng