写点什么

高可用架构(下)

用户头像
编号94530
关注
发布于: 2 小时前
高可用架构(下)

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

一. 数据存储方式

在我们用集群存储数据的时候,有多种的存储方式,有时候会把数据存在一个节点上,有时候又会把数据分散存储。如 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 元现金券。在根据一些具体情况,优化客户体验。

三 总结

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


如果有什么问题,欢迎讨论,指正,谢谢!

发布于: 2 小时前阅读数: 3
用户头像

编号94530

关注

你的每一个点赞我都当成了喜欢 2020.04.29 加入

gcs

评论

发布
暂无评论
高可用架构(下)