当前位置: 首页 > news >正文

【黑马 微服务面试篇】

分布式事务

cap定理-Availability

image-20250424211345100

image-20250424212308607

CAP定理-Partition tolerance

image-20250424213159648

BASE理论

BASE理论是对CAP的一种解决思路,包含三个思想:
BasicallyAvailable(基本可用):分布式系统在出现故障时,允许损失部分可用性,即保证核心可用。
SoftState(软状态):在一定时间内,允许出现中间状态,比如临时的不一致状态。
EventuallyConsistent(最终一致性):虽然无法保证强一致性,但是在软状态结束后,最终达到数据一致。

而分布式事务最大的问题是各个子事务的一致性问题,因此可以借鉴CAP定理和BASE理论:
·CP模式:各个子事务执行后互相等待,同时提交,同时回滚,达成强一致。但事务等待过程中,处于弱可用状态。
·AP模式:各子事务分别执行和提交,允许出现结果不一致,然后采用弥补措施恢复数据即可,实现最终一致。

AT模式的脏写问题

AT模式原理

image-20250424214352293

image-20250424215550463

AT模式的写隔离

image-20250424221050569

image-20250424221446350

TCC模式

TCC模式与AT模式非常相似,每阶段都是独立事务,不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法:
·Ty:资源的检测和预留;
·Confirm:完成资源操作业务;要求Ty成功Confirm一定要能成功。
·Cancel:预留资源释放,可以理解为try的反向操作。

image-20250425120732328

image-20250425121431252

TCC模式的每个阶段是做什么的?
·Ty:资源检查和预留
·Confirm:业务执行和提交
Cancel:预留资源的释放
TCC的优点是什么?
一阶段完成直接提交事务,释放数据库资源,性能好
,相比AT模型,无需生成快照,无需使用全局锁,性能最强
不依赖数据库事务,而是依赖补偿操作,可以用于非事务型数据库
TCC的缺点是什么?
有代码侵入,需要人为编写try、Confirm和Cance接口,太麻烦
软状态,事务是最终一致
需要考虑Confirm和Cancel的失败情况,做好幂等处理

最大努力通知

image-20250425124709762

注册中心

环境隔离

image-20250425125153579

image-20250425125303861

image-20250425125811140

分级模型

image-20250425130857455

image-20250425131426462

Eureka与Nacos

image-20250425133308810

image-20250425134015302

远程调用

负载均衡原理

image-20250425134745469

image-20250425184927782

image-20250425185104375

切换负载均衡算法

image-20250425192007778

服务保护

image-20250425194759148

Sentinel的线程隔离与Hystix的线程隔离有什么差别?

问题说明:考察对线程隔离方案的掌握情况
难易程度:一般
参考话术:
答:线程隔离可以采用线程池隔离或者信号量隔离。
HySx默认是基于线程池实现的线程隔离,每一个被隔离的业务都要创建一个独立的线程池,线程过多会带来额外的
CPU开销,性能一般,但是隔离性更强。
Sentinell则是基于信号量隔离的原理,这种方式不用创建线程池,性能较好,但是隔离性一般。

滑动窗口计数器算法

固定窗口计数器算法

当在第4到第5秒的时候来了3个请求,在第5到第6秒的时候来了3个请求,都可以被放行,

但是有一种情况是这样子的,4-5的这3个请求发生在4500毫秒到5000毫秒之间,5000-6000毫秒的这3个请求发生在5000-5500毫秒之间,相当于1秒钟来了6个请求,超出了阈值!!!

相当于早上吃3个包子,中午吃3个包子,晚上吃3个包子,变成了一下吃9个,吃不下…

image-20250425203013972

滑动窗口计数器算法

image-20250425201222346

漏桶算法

image-20250425204300154

image-20250425204405557

image-20250425204742819

令牌通算法

image-20250425210206661

Sentinel的限流与Gateway的限流有什么差别?

问题说明:考察对限流算法的掌握情况
难易程度:难
参考话术:

限流算法常见的有三种实现:滑动时间窗口、令牌桶算法、漏桶算法。Gateway!则采用了基于Redis3实现的令牌桶算法

而Sentinel内部却比较复杂
默认限流模式是基于滑动时间窗口算法,另外Sentinel中断路器的计数也是基于滑动时间窗口算法
限流后可以快速失败和排队等待,其中排队等待基于漏桶算法
而热点参数限流则是基于令牌桶算法


http://www.mrgr.cn/news/100044.html

相关文章:

  • AI之FastAPI+ollama调用嵌入模型OllamaBgeEmbeddings
  • 【torch\huggingface默认下载路径修改】.cache/torch/ 或 .cache/huggingface
  • 金仓数据库征文-政务领域国产化数据库更替:金仓 KingbaseES 应用实践
  • General Spark Operations(Spark 基础操作)
  • 一天学完Servlet!!!(万字总结)
  • 杨立昆:卷积神经网络创始者,人工智能领路人
  • redis特性及应用场景
  • Android killPackageProcessesLSP 源码分析
  • RabbitMQ 基础核心概念详解
  • Ubuntu22学习记录
  • 【数据可视化-22】脱发因素探索的可视化分析
  • TensorFlow深度学习实战(14)——循环神经网络详解
  • Ubuntu / WSL 安装pipx
  • 【Linux】基本指令(下)
  • pycharm2024.3.2项目解释器选择问题
  • docker 配置代理
  • 面试之消息队列
  • http协议、全站https
  • 2025第十六届蓝桥杯python B组满分题解(详细)
  • 每天学一个 Linux 命令(30):cut