暂无图片
暂无图片
3
暂无图片
暂无图片
暂无图片

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

云贝教育 2021-09-26
1658

点击蓝色字体关注我们吧


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

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



文章转载自云贝教育,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论