高可用架构（下）

上次说到了理论，接口层面，数据库层面如何实现高可用，但是，这远远是不够得。为了面对更大的灾害，如：洪水，地震等，还要在机房层面做出高可用。当然，也不仅仅是为了面对自然灾害，也可以是用于备份等，接下来就让我们从存储方式，机房层面说一下高可用架构。

一. 数据存储方式

在我们用集群存储数据的时候，有多种的存储方式，有时候会把数据存在一个节点上，有时候又会把数据分散存储。如 Redis 集群，将数据存储在不同的节点上。这样就带来了两次数据存储的讨论。分别是：数据集中式存储集群和数据分区存储集群。

1.1 数据集中存储集群

数据集中存储集群主要是把数据集中在一点存储，例如：一主多从、一主多备。这样的场景都是将数据通过主节点，主节点做操作，在同步到从节点。除了主从、主备带来的问题外，还引入了新的问题。由于有多个从节点，导入从节点数据不一致问题。如何处理，取舍是我们在做架构设计的时候需要考虑到的点。

1.2 数据分散存储集群

数据分散集群，就是把数据分散存储在集群的节点上。由于是分散存储，有些东西是我们不得不考虑的。分别是：均衡性、容错性、可伸缩性。

1.2.1 均衡性

分散存储的过程中，可能会导致数据集中存储在一个节点，就会导致一个节点的请求量，或者热量增加，导致出现意外的情况。如：在一致性 hash 中，我们会引入虚拟节点，防止单节点数据过多。

1.2.2 容错性

由于某些原因，导致集群中的一个节点出现故障，集群能否将数据合理的分配到集群中的其他节点。这个还是和一致性 Hash 很像，当某一个节点故障，将数据存入顺时针的下一个节点。

1.2.3 可伸缩性

这个是当集群中的数据过多，或出现热点数据的时候，添加新节点的时候，能否自动将部分新数据分配到新节点上。

1.3 不同点

数据存储和数据分散两种集群差别较大。因为在数据分散储存中，我们可以看出，每个节点都可以对外提供服务，而不同与集中存储的主节点。但是，在数据分散存储中，还是需要一个**''主节点"来分配节点数据，但是这里的"主节点"**和集中存储的主节点是不一样的。

二. 异地多活

上面说的情况一般都是针对同一个机房的情况，在一些极端情况下，例如：水灾、地震、机房失火等，都会造成这个机房服务出现故障，修复服务就需要很长时间。为了面对这种情况，缩短服务修复时间，则就需要选择异地多活了。

2.1 概念

异地多活，看名字就能有大概了解。核心就是异地，多活。异地是指，不同的地方，可以是一个城市，不同的地方，或者是不同的城市。多活是指：在不同的地方访问系统，都能对外提供服务。这些概念有点像我们老俗话说的，不要把鸡蛋放在同一个篮子里。

2.2 多活架构

从目前大多数场景来看，多活的架构主要有这几种方式，分别是：同城异地、跨城异地、两地三中心、跨国异地。当然，不同的地方也是有区别的。我们来好好分析一下。

2.2.1 同城异地

同城异地一般说的是，在同一个城市中，在不同的区域部署多个机房。比如：在深圳，我司就有两个机房，一个是在福田，一个是在西丽，两个机房通过专线，两个机房可以很快通信。

同城机房一般都可以应对大多数的灾难情况了，通过同城高速专线，数据同步几乎可以做到实时，可以用来面对大多数的场景。而且由于数据延迟低，就降低了开发的难度和成本问题（如：很快，就不需要考虑数据不同步带来的延迟问题）。

2.2.2 跨城异地

跨城异地说的是：在不同的城市建设机房。一般情况下，这两个城市就相对较远。比如：一个在北京，一个在广州。不会是一个在深圳，一个在广州。由于距离较远，不会在这么原理距离开通专线，那么就带来了上述说过的问题--网络延时带来的数据不同步问题。 这是一个很致命的问题。举个例子：某商场搞秒杀，共 50 个商品，A 城市秒杀完 50 个，数据由于网络延迟没有同步或晚几秒同步给 B 城市，B 城市也被秒杀 50 个，这样最后就会导致超卖的情况，如果还有 C,D,E 城市呢？或者在金融场景呢？。 所以一般在数据强一致场景，不会用上跨城异地。或者说，用上强一致算法，保证一个节点写入，其他节点复制。当然，这样也就脱离了多活的范围了。

2.2.3 两地三中心

说完上面两个，我们就可以说说什么是两地三中心了，两地三中心的核心思想还是同城异地。只是在同城异地的基础上，在异城多了一个数据备份。这样我们就可以完美的避免一个城市特大水灾，地震等极端情况带来的问题啦。也解决了数据延迟的问题。

2.2.4 跨国异地

跨国异地多活有点不一样，跨国异地多活主要是针对不同的区域的用户提供服务。例如：把一份机房部署在海外，然后只针对海外的用户，在国内的用户是无法用国内的账号登录海外的。同理，国内的用户也是。跨国会导致数据延迟更加大，所以一般不适合做有修改的业务。最好是只读业务，并且对数据实时性不是特别敏感的。如：发布一个新闻，在国内 12 点发布，在英国是 12.05， 这样其实是不影响游用户的阅读的。

2.3. 设计技巧

在我们设计多活的时候，有很多时候有一个误区，就是要保证所有数据，业务都要多活。这样其实是浪费资源的，耗费了大量的人力、财力带来的效益并不好，所以我们在设计多活的时候，需要有以下几个思维。

2.3.1 保证核心业务多活

我们没有必要保证所有的业务都采取多活，只需要保证核心业务即可。如：下单，在 A 中心故障后，切换到 B 中心，可以下单，保证核心业务的运行。对于用户注册，我们就没必要多活，因为可能带来数据冲突问题，而且收益不大。

2.3.2 保证核心数据最终一致性

异地多活的核心就是冗余数据，通过多个中心来对外提供服务。在多中心的情况下，还会有网络带来的延时问题。所以我们在同步时，需要注意一下几点来减少时延

1. 尽可能搭建高速线路，提高数据同步效率（提高速度）

2. 只做核心业务核心数据的多活（减少数据量）

完成以上方法后，我们在通过最终一致性保证数据一致即可。

2.3.3 采用多种手段同步数据

多活在同步数据的时候，我们需要采取多种手段来保证渠道的通行。单一的通道可靠性不能保证，所以我们就需要多种方式。主要方式有几种，分别是：1. 原生自带，如 Mysql 的 binlog，2. 消息队列，我们可以把消息丢到消息队列，通过消息队列的特性保证数据不丢失，并且可以可靠同步。3. 多次读取，访问 A 服务没有，可以尝试 B 服务，C 服务，在到 A 服务。

2.3.4 保证大部分用户多活

在系统中，可以适当放弃一点点用户保证绝大多数用户的多活。这样对小部分用户体验不好，但是可以保证绝大多数用户可用。针对小部分用户我们可以通过其他方式补偿。如：通过公告告知，事后对用户进行补偿，如：发 5 元现金券。在根据一些具体情况，优化客户体验。

三 总结

自此，我们学习完了在高可用设计方面的知识，包含理论，接口，数据库，机房等方面。总结下来，就是：通过多种手段，保证多数用户，核心系统可用。如果达到这个目的，我们就基本算成功了。剩下的就需要通过人力，财力，物力解决。

如果有什么问题，欢迎讨论，指正，谢谢！