腾讯云TDSQL高可用技术解决方案介绍

2021-12-14 00:00:00 架构 复制 切换 主机 中心


开始之前，先介绍一下目前主流的分布式数据库两个流派：

个是通过分库分表中间件去完成，通过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，那就需要好好权衡了。

来源：https://mp.weixin.qq.com/s/Wxjlg3QNCo09hurS32bRtg

相关文章