Labs 导读
服务的可用性就是网络的平均无故障率。对于一个平台来讲，这是非常重要的指标之一。当前主要使用的可用率为4个9，即99.99%。也意味着每年最多只能有52分钟的故障时间。
Part 01 双活、多活解决的问题
虽然通过负载均衡等方式，可以应对单节点故障。但当出现小概率不可抗力的时候（自然灾害、停电、挖断光缆等情况），整个机房不可用的情况依然会出现。近年来，支付宝、微博、B站等均出现过机房级的故障，因此一个或者多个便于快速切换的机房就成了backup（备用）。同时，多活的一个次要条件就是可以部署在不同的位置，通过物理上的距离减少，来提升响应速度。分机房部署也可以大大地减少单机房资源的需求。
Part 02 同城备份还是同城双活？
同城进行部署服务的最大好处就是机房空间距离小，通过专线进行连接，机房间时延可以稳定到3ms以内，因此服务可以跨机房访问数据。
于是，最简单的双活方式如下：我们可以称之为同城备份，数据库放在机房A，并定期将数据库内数据同步至机房B。好处是实现简单、方便横向的服务拓展。如果发生机房级别的灾害，可以尽快从机房B将数据恢复。但是问题也出在这里：机房B并没有数据库，无法完全接替机房A的作用。
图一 同城备份
为了解决上述的问题，可以在机房B内放置数据库从库，并将机房A的数据实时同步到机房B：即A机房中的数据库为主库，机房B中为从库。若发生机房A故障，则可以将流量切到B机房，并停止实时同步，把机房B中的数据库置为主库。
图二 同城同步
该机房的主要问题是需要人工干预较多。除了数据库和DNS的切换之外，还需要修改大量数据库的配置。总体上，该架构可以以较快时间恢复服务，对于同城的多机房，已经足够。
Part 03 异地多活的新问题
异地多活不同于同城的情况，首先就是机房间哪怕使用专线，延时的问题也无法解决（想要异地访问数据库几乎不可能）。
首先我们想到的是，有没有一种方法可以尽量避免信息的同步？那就是下图的方式：通过地理、用户哈希、设备id哈希等方式，将请求在DNS层分流到多个机房。每个机房处理固定用户请求，从而可以将两个机房间数据同步减少到最少，也将每个机房的数据量减少到最少的量。但是数据同步只能靠业务进行同步，而不是数据库工具进行同步。
分治的方式看起来很理想，但实际上也会有其他的问题。比如，使用地理方式进行划分（即使用ip进行划分）的方案，用户位置发生变化导致请求到其他机房，如何进行数据同步？使用用户id哈希进行分片的方案，需要进行横向扩容时，旧数据如何处理？发生故障时，其他机房如何短时间内同步其他分片数据等等。
总之，分片方式并非是完美的解决方法。
图三 异地双活
Part 04 异地同步数据
到这里，我们已经发现了，多个机房间的数据一定是需要同步的，这是异地多机房的必由之路。
数据的同步方式可以通过业务方式，也可以通过数据库中间件进行。下图中的方式就是机房间进行同步，这种方式确实增大了业务的复杂性，并且会随着机房的拓展，机房间同步的情况会更加复杂。
图四 网状同步
在上述的架构中，如果设置一个中心的数据节点，所有机房通过中心数据节点来进行同步，数据流就会从“网状”变成“星状”。大大减少同步工作和复杂性。但是这一方案，实质上是与我们追求的分布式部署理念的一种背离。
图五 网状星状同步
Part 05 分布式数据库，是银弹吗？
不仅是在多机房部署的情况下，随着数据量的急剧增大，针对Mysql的分库分表，开发人员对JDBC Proxy还有DB Proxy进行了深入的实战。大家越来越发现，承认数据库分片是很有必要的。在该基础上，许多分布式数据库如cockroach、TiDB随之产生。分布式数据库天生支持多集群、多机房的部署，这与异地多活的需求不谋而合。
通过分布式数据库，既可以实现数据的横向拓展，也可以减少业务上数据同步的复杂性，几乎可以说是一举多得。
此外，数据库对于资源的需求也很高，一个三集群的TiDB，至少需要9台物理机，10个万兆网卡以及之间的3条专线。
另外的缺点是改架构对于分布式数据库集群间的延时，相对苛刻，这也阻碍了改架构在较广域的地区无限扩容。
图六 分布书数据库多机房
Part 06 总结
多机房部署相对于单个机房，其难度、开发、资源开销都是级数上升。因此具体的架构需要根据实际需求来选择。本文旨在介绍多机房部署的几种类型，开拓大家的思路。实际的多机房部署形式可能也与上述的都不一样，但是思路大体是相同的。
