陈老师:1415968548 乐老师:354331153
客服热线:
19941464235

客服微信

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

作者:云贝学院
发布时间:2021-09-17 13:08
浏览量:219

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

image.png

第一个是通过分库分表中间件去完成,通过XA去控制,XA是MySQL原生自带的,是由事务的管理器和资源管理器两部分组成。一般,数据库通过B+树的方式进行存储,做多个副本,通过主从半同步复制完成,但是这样的方式性能比较差。

另一个是通过DBPorxy,依靠Percolator去控制,采用分区,存储时LSM树的模式。

 

然后我们讲讲今天的TDSQL

 

为了保证数据的安全,可用,TDSQL保证了三种复制方式。

我们从三个方面去分析:

ü  主备数据复制方式

ü  数据强一致性

ü  容灾切换


一般来说,MySQL的原生复制方式,有两种。

异步:主机不等备机应答直接返回客户端成功

半同步:主机在一档条件下等备机应答再返回客户端成功

两种方式都存在丢失数据的可能。

TDSQL复制方式可以实现强同步:主机在等至少一台备机应答再返回客户端成功。

强同步是TDSQL数据不丢失,不会错的最核心保障。强同步实质上是改良了原生异步复制,做了性能改良。主机可读可写,备库只读。任何时候只有一个主机。

那么新的问题来了?如果主机挂了,那么怎么办?原理是主机降级,变成只读,然后根据备机上的binlog日志来判断哪台备机成为新的主机,同时保证数据一致性,整个过程自动化完成,不需人工。

 image.png

在TDSQL架构当中,我们再来复习一遍,整个流程。

 image.png

当应用访问,首先通过负载均衡接受转成流量,负载均衡中一般用两台LVS加上一个虚拟IP地址做一个自动切换,保证运行。当流量通过SQL引擎时,解析路由,查看是否需要分片,根据解析结果发到对应的分片上。整个过程依赖zookeeper管理,保证全局一致性。Zookeeper本身带有一定信息的存储,从而调动其他组件协作。

 

核心功能:容灾切换

主机可读可写,备机只读,任何时候只有一个主机提供服务,宁可拒绝服务,也不提供错误的服务,且整个过程自动化,无需人为干预。切换流程严格,确保切换前后的数据强一致性。当主节点发生宕机,重新选举出新的主节点并提供服务,同时保证数据一致。

 

推荐的机型配置,如下图

image.png

LVS的协议不能跨网段,建议使用物理机。

网关也叫proxy,或SQL引擎,其他不做赘述。

 

同城单中心架构

当IDC资源紧张,只有一个。业务要最佳性能,不能容忍跨IDC网络延迟,一般作为异地灾备机房。主备节点跨机架。适合开发测试的环境。对IDC的命名尽量有意义,一般“城市+机房+房间+机架号”信息对应。

资源规格和需求

 image.png

同城两中心架构

此方案,跨中心强同步,zookeeper多数部署在备中心,在主中心宕机后自动切换到备中心,从而实现跨IDC容灾切换,保证数据一致性。但备中心如果发生故障会引起主中心不可用。

因为当主中心挂了以后,备中心启动升级为主,但因为主中心的备机不做异步复制,导致响应时间长而数据丢失。所以在同机房下,做异步复制防止数据丢失。

对于两个数据中心来说,没有很完美的一场自动切换方案,都不能做到任何异常切换

 image.png

为了解决这个问题

接着继续介绍高可用集群:两地三中心

所谓两地,指的是两个城市之间,三中心指的是同城2个IDC,异地一个IDC。这样的模式组成的经典部署架构,可以做到跨IDC级别的容灾。注意:异地之间复制为异步复制。

这个架构时当前主流金融场景架构,完美解决了之前的方案

image.png

两地三中心之上,其实还有更好的架构,就是两地四中心

金融级别的至少是两地,三中心,四中心都可以。

image.png

总结一下以上方案。

对于实际意义的异地中心来说,一般推荐距离在500KM以上,在这个举例下,每次ping的延迟超过了10ms,如此走强同步架构,业务么此事务提交等待事件会比较长,所以建议走异步。

对于跨城异地容灾一般建议在异地搭建独立的集群模式,通过异步复制实现同步,主城和备城可以采用不同部署方式,自由组合。

现阶段尽量采用两地三中心的架构,能实现数据中心异常自动切换。

如果只有两个IDC,那就需要好好权衡了。