客服微信
开始之前，先介绍一下目前主流的分布式数据库两个流派
第一个是通过分库分表中间件去完成，通过XA去控制，XA是MySQL原生自带的，是由事务的管理器和资源管理器两部分组成。一般，数据库通过B+树的方式进行存储，做多个副本，通过主从半同步复制完成，但是这样的方式性能比较差。
另一个是通过DBPorxy，依靠Percolator去控制，采用分区，存储时LSM树的模式。
然后我们讲讲今天的TDSQL
为了保证数据的安全，可用，TDSQL保证了三种复制方式。
我们从三个方面去分析：
ü 主备数据复制方式
ü 数据强一致性
ü 容灾切换
一般来说，MySQL的原生复制方式，有两种。
异步：主机不等备机应答直接返回客户端成功
半同步：主机在一档条件下等备机应答再返回客户端成功
两种方式都存在丢失数据的可能。
TDSQL复制方式可以实现强同步：主机在等至少一台备机应答再返回客户端成功。
强同步是TDSQL数据不丢失，不会错的最核心保障。强同步实质上是改良了原生异步复制，做了性能改良。主机可读可写，备库只读。任何时候只有一个主机。
那么新的问题来了？如果主机挂了，那么怎么办？原理是主机降级，变成只读，然后根据备机上的binlog日志来判断哪台备机成为新的主机，同时保证数据一致性，整个过程自动化完成，不需人工。
在TDSQL架构当中，我们再来复习一遍，整个流程。
当应用访问，首先通过负载均衡接受转成流量，负载均衡中一般用两台LVS加上一个虚拟IP地址做一个自动切换，保证运行。当流量通过SQL引擎时，解析路由，查看是否需要分片，根据解析结果发到对应的分片上。整个过程依赖zookeeper管理，保证全局一致性。Zookeeper本身带有一定信息的存储，从而调动其他组件协作。
核心功能：容灾切换
主机可读可写，备机只读，任何时候只有一个主机提供服务，宁可拒绝服务，也不提供错误的服务，且整个过程自动化，无需人为干预。切换流程严格，确保切换前后的数据强一致性。当主节点发生宕机，重新选举出新的主节点并提供服务，同时保证数据一致。
推荐的机型配置，如下图
LVS的协议不能跨网段，建议使用物理机。
网关也叫proxy，或SQL引擎，其他不做赘述。
同城单中心架构
当IDC资源紧张，只有一个。业务要最佳性能，不能容忍跨IDC网络延迟，一般作为异地灾备机房。主备节点跨机架。适合开发测试的环境。对IDC的命名尽量有意义，一般“城市+机房+房间+机架号”信息对应。
资源规格和需求
同城两中心架构
此方案，跨中心强同步，zookeeper多数部署在备中心，在主中心宕机后自动切换到备中心，从而实现跨IDC容灾切换，保证数据一致性。但备中心如果发生故障会引起主中心不可用。
因为当主中心挂了以后，备中心启动升级为主，但因为主中心的备机不做异步复制，导致响应时间长而数据丢失。所以在同机房下，做异步复制防止数据丢失。
对于两个数据中心来说，没有很完美的一场自动切换方案，都不能做到任何异常切换
为了解决这个问题
接着继续介绍高可用集群：两地三中心
所谓两地，指的是两个城市之间，三中心指的是同城2个IDC，异地一个IDC。这样的模式组成的经典部署架构，可以做到跨IDC级别的容灾。注意：异地之间复制为异步复制。
这个架构时当前主流金融场景架构，完美解决了之前的方案
两地三中心之上，其实还有更好的架构，就是两地四中心
金融级别的至少是两地，三中心，四中心都可以。
总结一下以上方案。
对于实际意义的异地中心来说，一般推荐距离在500KM以上，在这个举例下，每次ping的延迟超过了10ms，如此走强同步架构，业务么此事务提交等待事件会比较长，所以建议走异步。
对于跨城异地容灾一般建议在异地搭建独立的集群模式，通过异步复制实现同步，主城和备城可以采用不同部署方式，自由组合。
现阶段尽量采用两地三中心的架构，能实现数据中心异常自动切换。
如果只有两个IDC，那就需要好好权衡了。
