MySQL机房多活的初步设想

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

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

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

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

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

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

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

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

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

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

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

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