这是学习笔记的第 2043 篇文章
今天和同事聊了下两地三中心的一些理解,后续会在MySQL和Redis方向的高可用架构方案上做一些东西。这算是一个讨论的开始吧。
首先需要明确下概念的边界,我们初步的共识是:同城双活,异地灾备。
而要实现同城双活,在整个方案中则是重中之重,同时要实现双活,必然需要和业务架构结合起来,而找到一个适中的平衡点。
我们可以在行业里看到很多的伪双活的设计,从设计上来说也没有问题,但是会存在一些局限性。我们主要从数据延迟和数据冲突来展开,如下是一个多IDC架构的设计方案,可以把两个不同的业务整合起来,做到schema级别的隔离,然后业务侧可以实现多写。
这种情况下,使用MySQL的主主复制也是一种方案,因为跨IDC的缘故,所以必然存在一些延迟,而且在数据的冲突的方式上,这种方案因为做到了schema级别的隔离,所以也是各自安好,这种方案是一种初步的设计方案,对于我们来说,MySQL的MGR是一种很好的借鉴方式,核心的字眼就是分布式,我们是需要借鉴分布式的思想。
不同的是,MGR是强一致的设计方式,对于业务吞吐量来说必然会因为数据同步而产生处理延迟。比如北京顺义和亦庄可以作为同城机房,但是因为地域距离,必然会产生延迟,其实对于有些业务来说,如果为了追求数据强一致性,那么吞吐量就会打折,所以如果是数据写入,那么理想的情况应该是数据写入应该成功,数据的复制关系应该是异步模式,难点就在于如何合理的把握分布式设计的度。
要实现下面的方式,我们就需要剥离开已有的复制模式。
所以我们需要一种模式能够支撑这种数据关系,我们可以设想出两个组件,一个是发布端,一个是接收端。 我们不能以偏概全,而是应该细化的梳理业务场景,比如是数据写入的场景,那么这种情况下的分布式设计会增加更加轻量。而难点在于update和delete部分,需要考虑数据冲突的检测机制。
这样一来我们的组件就可以作为一个中继节点,实现分布式的队列消费任务了,类似如下的这种方式。
如果我们把pub,sub组合起来,成为一个组件,那么这个中继节点就会成为整个流程的重心,是需要考虑它的高可用的,我们可以设计为下面的形式。
而要引入这种模式,我们必然要考虑分布式ID的设计方案,而设计中的一个难点就是对于冲突机制的处理。