分布式系统的知识点-架构设计

前言

天天说分布式分布式，那么我们是否知道什么是分布式，分布式会遇到什么问题，有哪些理论支撑，有哪些经典的应对方案，业界是如何设计并保证分布式系统的高可用呢？

架构设计

这一节将从一些经典的开源系统架构设计出发，来看一下，如何设计一个高质量的分布式系统；

而一般的设计出发点，无外乎

• 冗余：

简单理解为找个备胎，现任挂掉之后，备胎顶上

• 拆分：

不能让一个人承担所有的重任，拆分下，每个人负担一部分，压力均摊

1.1 主备架构

给现有的服务搭建一个备用的服务，两者功能完全一致，区别在于平时只有主应用对外提供服务能力；而备应用则只需要保证与主应用能力一致，随时待机即可，并不用对外提供服务；当主应用出现故障之后，将备应用切换为主应用，原主应用下线；迅速的主备切换可以有效的缩短故障时间

基于上面的描述，主备架构特点比较清晰

• 采用冗余的方案，加一台备用服务

• 缺点就是资源浪费

其次就是这个架构模型最需要考虑的则是如何实现主备切换？

• 人工

• VIP (虚拟 ip) + keepalived 机制

1.2 主从架构

主从一般又叫做读写分离，主提供读写能力，而从则只提供读能力

鉴于当下的互联网应用，绝大多数都是读多写少的场景；读更容易成为性能瓶颈，所以采用读写分离，可以有效的提高整个集群的响应能力

主从架构可以区分为：一主多从 + 一主一从再多从，以 mysql 的主从架构模型为例进行说明

主从模式的主要特点在于

• 添加从，源头依然是数据冗余的思想

• 读写分离：

  主负责读写，从只负责读，可以视为负载均衡策略

• 从需要向主同步数据，所若有的从都同步与主，对主的压力依然可能很大；

所以就有了主从从的模式

关键问题则在于

• 主从延迟

• 主的写瓶颈

• 主挂之后如何选主

1.3 多主多从架构

一主多从面临单主节点的瓶颈问题，那就考虑多主多从的策略，同样是主负责提供读写，从提供读；

但是这里有一个核心点在于多主之间的数据同步，如何保证数据的一致性是这个架构模型的重点

如 MySql 的双主双从可以说是一个典型的应用场景，在实际使用的时候除了上面的一致性之外，还需要考虑主键 id 冲突的问题

1.4 普通集群模式

无主节点，集群中所有的应用职能对等，没有主次之分（当下绝大多数的业务服务都属于这种），一个请求可以被集群中任意一个服务响应；

这种也可以叫做去中心化的设计模式，如 redis 的集群模式，eureka 注册中心，以可用性为首要目标

对于普通集群模式而言，重点需要考虑的点在于

资源竞争：

如何确保一个资源在同一时刻只能被一个业务操作

如现在同时来了申请退款和货物出库的请求，如果不对这个订单进行加锁，两个请求同时响应，将会导致发货又退款了，导致财货两失

数据一致性：

如何确保所有的实例数据都是一致的，或者最终是一致的

如应用服务使用 jvm 缓存，那么如何确保所有实例的 jvm 缓存一致？

如 Eureka 的分区导致不同的分区的注册信息表不一致

1.5 数据分片架构

这个分片模型的描述可能并不准确，大家看的时候重点理解一下这个思想

前面几个的架构中，采用的是数据冗余的方式，即所有的实例都有一个全量的数据，而这里的数据分片，则从数据拆分的思路来处理，将全量的数据，通过一定规则拆分到多个系统中，每个系统包含部分的数据，减小单个节点的压力，主要用于解决数据量大的场景

比如 redis 的集群方式，通过 hash 槽的方式进行分区

如 es 的索引分片存储.

总结

这一节主要从架构设计层面对当前的分布式系统所采用的方案进行了一个简单的归类与小结，并不一定全面，欢迎各位大佬留言指正

基于冗余的思想：

• 主备
• 主从
• 多主多从
• 无中心集群

基于拆分的思想：

• 数据分片

对于拆分这一块，我们常说的分库分表也体现的是这一思想

喜欢软件测试的小伙伴们，如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一 键三连哦！