方案背景
随着互联网业务快速发展，多IDC的业务支撑能力和要求也逐步提升，行业内的“两地三中心”方案较为流行 。
其中两地是指同城、异地；三中心是指生产中心、同城容灾中心、异地容灾中心 。
在早期，比较典型的是国内外银行多采用“两地三中心”建设方案 。这种模式下，多个数据中心是主备关系，即存在主次，业务部署优先级存在差别，针对灾难的响应与切换周期非常长，RTO与RPO目标无法实现业务零中断，资源利用率低下，投资回报无法达到预期 。两地三中心本质上是一种通过简单资源堆砌提高可用性的模式，对高可用的提高、业务连续性的保证仍然只是量变，业务连续性及容灾备份一直没有实质性的跨越 。
目前，以银行为代表的、包括政府、公共交通、能源电力等诸多行业用户，开始将关注点转向“分布式多活数据中心”
通过双活的方案，具有两类特点 。一是多IDC中心之间地位均等，在正常模式下协同工作，并行的为业务访问提供服务，实现了对资源的充分利用，避免一个或两个备份中心处于闲置状态，造成资源与投资浪费，通过资源整合，多活数据中心的服务能力往往双倍甚至数倍于主备数据中心模式；二是在一个数据中心发生故障或灾难的情况下，其他数据中心可以正常运行并对关键业务或全部业务实现接管，达到互为备份的效果，实现用户的“故障无感知” 。
结合公司目前的业务运营情况，IDC机房主要在xxxx,xxx,同时在xxxx区域部署有一些IDC机房，其中数据中心主要以xxx为主，所以在两地三中心方案中，同城双活较为符合发展的趋势 。
而两地三中心方案的设计，不光需要数据库层基于分布式进行改造，同时在业务层，系统层，网络层都需要相关的方案适配 。
文章插图
目标和计划：
ü 两地三中心的设计原则为同城双活，异地容灾，其中同城暂定为HB30,HB21,异地容灾暂定为华中或华东的IDC节点
ü 改造设计需要和业务端进行密切配合，从业务场景出发选择合适的方案
ü 考虑跨机房的支持，需要引入consul方案，实现service_name的高可用管理
ü 同城双活的数据要求为最终一致性，异地容灾暂不对业务开放，在30分钟内可以快速恢复业务
ü 可以设定短期目标和长期目标，短期目标可以充分借助开源红利和业务场景进行落地，在落地过程中不断的迭代改进；长期目标可以选择更为通用，技术挑战较大，业务效果好的方案（如异地多活） 。
ü 为了确保方案的有效，需要定期进行演练
方案简介
两地三中心方案中，基于设定的短期目标可以明确同城双活和异地容灾的方案组合 。
则设计重点为同城双活，即在同城的数据中心之间，一般通过高速光纤相连，在网络带宽有保障的前提下，网络延迟一般在可接受范围内，两个机房之间可以认为在同一个局域网内 。
在设计上可以和应用层结合起来，有两种部署模式：分为应用层双活和数据库双活，应用层双活和数据库单活 。
1）
.应用层双活和数据库单活方案：
应用层双活，数据库单活：两个机房的应用程序同时对外提供服务，但是只有一个机房的数据库提供读写，另外一个机房的应用程序需要跨机房访问数据库，数据库之间单向复制 。该模式在网络延迟相对低的同城环境下表现良好，但是如果距离超过100 公里，机房之间的网络延迟就会超过2ms（或者更高），此时对于跨机房访问的数据库请求，性能有较大影响 。
针对同城网络延迟低，可以看作是同一个局域网的特点，对于应用双活+数据库单活的方案，应用跨机房访问数据库，一旦某个机房故障，则将另外一个机房的应用访问请求切换到本机房的数据库，从而实现同城任何一个数据中心出现故障，都不会影响到整体业务的运行 。
由于同城之间网络条件相对较好，MySQL 数据库原生的复制模式能够满足大部分业务场景，MySQL 5.7 推出的并行复制可以有效解决容灾机房日志回放慢的问题，在5.7.17推出的MGR/InnoDB Cluster则可以实现数据的强一致需求 。
方案一：MGR集群多活架构
整个架构是基于分布式方案来设计，节点通信基于协议Paxos，MGR作为InnoDB Cluster的核心组件，目前支持单主模式和多主模式，本方案优先采用单主模式，节点数至少2-9个节点 。
推荐阅读
- 100% 展示 MySQL 语句执行的神器-Optimizer Trace
- MySQL,合理的使用索引结构和查询
- MySQL进阶篇 | 合理的使用索引结构和查询
- 减肥茶的危害,三叶减肥茶的副作用
- 百慕大三角有外星人吗 百慕大的三角洲是否真的有外星人
- 圆角龙和三角龙图片 关于三角龙的介绍及图片
- 峨眉山三宵洞 1937年峨眉山三霄娘娘显灵案后续
- 做人流之后牢记远离三大禁忌
- 决明子养生保健茶推荐,为您推荐三款秋季养生保健茶
- 收入|全球手游收入TOP10：国内包揽前三、《王者荣耀》狂揽2.72亿美元！