前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >MySQL机房多活的初步设想

MySQL机房多活的初步设想

作者头像
jeanron100
发布2019-07-22 16:50:37
1.2K0
发布2019-07-22 16:50:37
举报
文章被收录于专栏:杨建荣的学习笔记

这是学习笔记的第 2043 篇文章

今天和同事聊了下两地三中心的一些理解,后续会在MySQL和Redis方向的高可用架构方案上做一些东西。这算是一个讨论的开始吧。

首先需要明确下概念的边界,我们初步的共识是:同城双活,异地灾备。

而要实现同城双活,在整个方案中则是重中之重,同时要实现双活,必然需要和业务架构结合起来,而找到一个适中的平衡点。

我们可以在行业里看到很多的伪双活的设计,从设计上来说也没有问题,但是会存在一些局限性。我们主要从数据延迟和数据冲突来展开,如下是一个多IDC架构的设计方案,可以把两个不同的业务整合起来,做到schema级别的隔离,然后业务侧可以实现多写。

这种情况下,使用MySQL的主主复制也是一种方案,因为跨IDC的缘故,所以必然存在一些延迟,而且在数据的冲突的方式上,这种方案因为做到了schema级别的隔离,所以也是各自安好,这种方案是一种初步的设计方案,对于我们来说,MySQL的MGR是一种很好的借鉴方式,核心的字眼就是分布式,我们是需要借鉴分布式的思想。

不同的是,MGR是强一致的设计方式,对于业务吞吐量来说必然会因为数据同步而产生处理延迟。比如北京顺义和亦庄可以作为同城机房,但是因为地域距离,必然会产生延迟,其实对于有些业务来说,如果为了追求数据强一致性,那么吞吐量就会打折,所以如果是数据写入,那么理想的情况应该是数据写入应该成功,数据的复制关系应该是异步模式,难点就在于如何合理的把握分布式设计的度。

要实现下面的方式,我们就需要剥离开已有的复制模式。

所以我们需要一种模式能够支撑这种数据关系,我们可以设想出两个组件,一个是发布端,一个是接收端。 我们不能以偏概全,而是应该细化的梳理业务场景,比如是数据写入的场景,那么这种情况下的分布式设计会增加更加轻量。而难点在于update和delete部分,需要考虑数据冲突的检测机制。

这样一来我们的组件就可以作为一个中继节点,实现分布式的队列消费任务了,类似如下的这种方式。

如果我们把pub,sub组合起来,成为一个组件,那么这个中继节点就会成为整个流程的重心,是需要考虑它的高可用的,我们可以设计为下面的形式。

而要引入这种模式,我们必然要考虑分布式ID的设计方案,而设计中的一个难点就是对于冲突机制的处理。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-07-18,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 SQL Server
腾讯云数据库 SQL Server (TencentDB for SQL Server)是业界最常用的商用数据库之一,对基于 Windows 架构的应用程序具有完美的支持。TencentDB for SQL Server 拥有微软正版授权,可持续为用户提供最新的功能,避免未授权使用软件的风险。具有即开即用、稳定可靠、安全运行、弹性扩缩等特点。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档