面试官的最爱问的“分布式”核心设计问题,没掌握的不妨来看看

ε祈祈猫儿з 提交于 2020-10-04 10:28:15

现在什么技术最火?

大数据、人工智能、区块链、边缘计算、微服务 ,但是这么多前沿技术的底层全部依赖于分布式。

分布式的核心:拆

微服务和分布式的区别

  • 分布式:不管是横向拆分还是纵向拆分,拆了就行
  • 微服务:纵向拆分(根据业务逻辑拆分,电商:用户、支付、购物……)、最小化拆分

横向拆分:jsp/servlet , service,dao 在不同层面的拆分,纵向拆分:根据业务逻辑拆成独立的小项目

CAP理论

任何一个分布式系统 都必须重点考虑的原则。

  • C:一致性(强一致性):所有子节点中的数据 时刻保持一致
  • A:可用性:整体能用
  • P:分区容错性 :允许部分失败

CAP理论: 在任何分布式系统中,C\A\P不可能共存,只能存在两个。

基础知识: 一般而言,至少要保证P可行,因为分布式 经常会出现 弱网环境。因此 就需要在C和A之间二选一。

举个例子:

当计算机A故障,分区容错性满足,如果一致性满足,那必须回滚,否则计算机B有数据,A没有,这样就不满足数据一致性。

file

BASE理论

BASE理论的目的: 为了弥补CAP的不足。

要理解的概念:

  • 强一致性(时时刻刻一致、短时间内一致)
  • 最终一致性(只要最后一致即可)
  • 软状态: 多个节点时,允许中间某个时刻数据不一致。

尽最大努力 近似的实现 CAP三者:最终一致性 代替强一致性C

BASE理论:首选满足A\P, 因此不能满足C。但是可以用 最终一致性 来代替C。

BASE:Basically Available 基本可用

分布式缓存

file

缓存问题

file

缓存击穿:

某一个热点数据过期,造成大量用户请求直奔DB的现象。

解决:

  • 监控线程
  • 提前设置好时间,保证热点数据在 高峰期 不过期

缓存雪崩:

大量缓存全部失效 (给大量缓存设置了相同的过期时间 ; 缓存服务器故障)

解决:

  • 合理分配缓存的过期时间
  • 搭建缓存集群

缓存穿透:

恶意攻击。一般而言,不会缓存一些无意义的数据。但是如果恶意工具,就可以利用一些无意义的数据 反复发起请求。

解决:

将无意义的数据也进行缓存,并且将过期时间设置的相对短一些。

以上的本质都是“缓存失效”,通用的解决方案:二级缓存(分布式缓存)。

一般而言,本地缓存是一级缓存,分布式缓存是二级缓存。

一致性hash

hash算法:映射

字符串、图片、对象 转换为 数字

hash(a.png ) 转换为 12312313

一致性hash最初用于解决分布式缓存问题

file

以上 将 数据 映射到 某个缓存服务器的做法 有一个问题: 当服务器个数发生改变时,缓存会失效。

file

解决“服务器个数改变导致的问题”:一致性hash

file

hash偏斜问题

file

解决hash倾斜问题:虚拟节点

在换上生成多个 虚拟节点,后续 请求先找虚拟节点,然后再通过虚拟节点找到对应的真实节点。

file

缓存一致性

最容易想到,但也不推荐的做法: 当DB更新后,立刻更新缓存 ; 先删除缓存,在更新DB。

推荐: 当DB更新后,立刻删除缓存

分析:(反例)

当DB更新后,立刻更新缓存(不推荐)

问题:

如果线程A先更新,线程B后更新,最终的结果 可能是A的结果。原因:线程的执行速度可能不一致。

推荐: 当DB更新后,立刻删除缓存 。因为:对于删除来说,没有速度的先后问题(没有速度不一致的问题)

(这种推荐的方式,仍然会存在 一个极小概率的错误情况)

file

以上就是这个推荐方式的一个错误情况,但发生的概率是极小的:1.发生在“缓存失效”的前提下 2.发生的前提:写线程的速度 要 快于 读线程,基本不可能。

问:这个极小的错误情况,能否避免?

答:能!以上错误发生的大前提:读操作和写操作交叉执行。

解决思路:让二者不要交叉。 加锁,或者读写分离。 但是一般建议,不用解决。

能否调换顺序:删除缓存 , 再DB更新后

反例:

file

以上出错的前提:写慢,读快。因此发生的概率较大。

分布式锁

file

分布式锁:数据库的唯一约束、redis、Zookeeper

在架构开发: 没有最好,只有比较合适的。

使用Zookeeper实现分布式锁

zookeeper:分布式协调框架, 组成结构是 一个颗树(类似于DOM树)

树种包含很多叶节点,在分布式锁中使用的 叶节点类型: 临时顺序节点。

zookeeper提供了以下两种支持:

  • 监听器:可以监听某个节点的状态,当状态发生改变时 则触发相应的事件
  • 临时节点的删除时机:当客户端与访问的临时节点 断开连接时

锁:同一个时间内,只能有一个线程/进程访问

file

分布式事务

本地事务:一个事务对于一个数据库连接。(事务:连接 = 1: 1)

凡是不符合上述1:1关系的,都不能使用本地事务,举例如下(以下都无法使用本地事务):

1.单节点中存在多个数据库实例。在本地 建立了2个数据库: 订单数据库、支付数据库。

下单操作 = 订单数据库+支付数据库

2.分布式系统中,部署在不同节点上的多个服务访问同一个数据库。

通过以上两点说明:本地事务的使用性 十分有限。

分布式事务实现

示例

下单操作 = 订单数据库 +支付数据库

服务器A: 下单操作 , 订单数据库

服务器B: 支付数据库

模拟分布式事务:下单操作

begin transaction:

1.执行 订单数据库;

2.执行 支付数据库

commit/rollback ;

以上,在分布式环境中存在问题:

begin transaction:

1.在本地(服务器A) 执行 订单数据库;

2.远程调用服务器B上的 支付数据库

commit/rollback ;

以上的错误情况:如果本地的订单服务 成功、远程的支付也成功,但是在 响应时由于网络等问题 无法响应,就会让用户以为 下单失败。

file

以上,本地事务无法操作的情况,就可以使用分布式事务。

使用2PC实现分布式事务

2pc:2 phase commit ,由一个协调者 和多个 参与者组成 (类似master-slave结构)

协调者: 事务管理器,TM

参与者: 资源管理器,RM

两阶段指的是:

准备阶段(Prepare阶段):当事务开始时,协调者向所有的参与者发送 Prepare消息,请求执行事务。参与者接收到消息后,要么同意,要么拒绝。如果同意,就会在本地执行事务,记录日志,但是不提交。

提交阶段(commit阶段):如果所有的参与者都同意,协调者再次给全部参与者发送 提交请求。否则进行回滚。

file

总体思路: 将一个任务(多个步骤) 进行2步操作: 1.请求各个节点执行 ; 2.如果大家都同意,请求一起提交

2pc缺点:1.分布式事务在执行期间是阻塞式的,因此会带来延迟 2.如果协调在第“5”步遇到弱网环境,可能造成一部分节点 没有commit的情况。 3.中心化架构,单点灾难。

其他分布式事务解决方案:三阶段提交,使用TCC实现分布式事务,使用消息队列实现分布式事务

注意:如果要严格的保证事务一致性:paxos算法。 google chubby作者

分布式认证 &分布式授权

认证方式:系统自己开发 、 三方平台

系统自己开发:分布式认证

三方平台:分布式授权 (SSO单点认证)

分布式授权: OAuth2.0授权协议 ,该协议的流程如下:

file

原文链接: https://blog.csdn.net/qq_41620020/article/details/106010665 文源网络,仅供学习之用,如有侵权,联系删除。

我将面试题和答案都整理成了PDF文档,还有一套学习资料,涵盖Java虚拟机、spring框架、Java线程、数据结构、设计模式等等,但不仅限于此。

关注公众号【java圈子】获取资料,还有优质文章每日送达。

file

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!