黑马Java面试笔记之 微服务篇（业务）
一. 限流
你们项目中有没有做过限流?怎么做的?
为什么要限流呢?
一是并发的确大(突发流量)
二是防止用户恶意刷接口
限流的实现方式:
- Tomcat:可以设置最大连接数
可以通过maxThreads设置最大Tomcat连接数,实现限流,但是适用于单体架构
- Nginx:漏桶算法
- 网关,令牌桶算法
- 自定义拦截器
1.1 Nginx限流
- 控制速率(突发流量)
- 控制并发连接数
1.2 网关限流
yml配置文件中,微服务路由设置添加局部过滤器RequestRateLimiter
令牌桶:
令牌桶和漏桶的区别:
令牌桶存储的是令牌,漏桶存储的是请求,两者都可以应对突发的流量.不同的是二者的速率,不管请求量有多大,漏桶都是以固定的速率往外露出请求,以恒定的速率进行放行;而令牌桶可能会超出令牌生成的速度
总结
限流常见的算法有哪些?
对令牌桶和漏桶进行分析,并解释二者的区别
二. 分布式系统理论
解释一下 CAP 和 BASE
- 分布式事务方案的指导
- 分布式系统设计方向
- 根据业务指导使用正确的技术选择
2.1 CAP
1998年,加州大学的计算机科学家 Eric Brewer提出,分布式系统有三个指标:
- Consistency(一致性)
用户访问分布式系统中的任意节点,得到的数据必须一致
- Availability(可用性)
用户访问集群中的任意健康节点,必须能得到响应,而不是超时或拒绝
- Partition tolerance(分区容错性)
Partition(分区):因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接,形成独立分区.
tolerance(容错):再集群出现分区时,整个系统也要持续对外提供服务
Eric Brewer说,分布式系统无法同时满足这三个指标.
这个结论就叫做CAP定理.
结论
- 分布式系统节点之间肯定是需要网络连接的,分区(P)是必然的
- 如果保证访问的高可用性(A),可以持续对外提供服务,但不能保证数据的强一致性 --> AP
- 如果保证访问的数据强一致性(C),就要放弃高可用 --> CP
2.2 BASE理论
BASE理论是对CAP的一种解决思路,包含三个思想:
- Basically Available(基本可用):分布式系统在出现故障时,允许损失部分可用性,即保证核心可用.
- Soft State (软状态):在一定时间内,允许出现中间状态,比如临时的不一致状态
- Eventually Consistent(最终一致性):虽然无法保证强一致性,但是在软状态结束后,最终达到数据一致.
总结
三. 分布式事务解决方案
你们采用哪种分布式事务解决方案?
3.1 Seata架构
Seata事务管理中有三个重要的角色:
- TC(Transaction Coordinator) - 事务协调者:维护全局和分支事务的状态,协调全局事务提交或回滚.
- TM(Transaction Manager) - 事务管理器:定义全局事务的范围,开始全局事务,提交或回滚全局事务
- RM(Resource Manager) - 资源管理器:管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚.
3.2 模式1 seata的XA模式
3.3 模式2 AT模式原理
3.4 TCC模式原理
3.5 MQ分布式事务
总结
根据自己的业务跟面试官进行陈述
四. 分布式服务接口幂等性
4.1 接口幂等
基于RESTful API 的角度对部分常见类型请求的幂等性进行特点分析
解决幂等性有三种方案:
- 数据库唯一索引 (新增)
- token+redis (新增,修改)
- 分布式锁 (新增,修改)
4.2 token+redis
创建商品,提交订单,转账,支付等操作
4.3 分布式锁
总结
五. 分布式任务调度
你们项目中使用了什么分布式任务调度?
首先,要先描述但是实在什么场景使用了任务调度
5.1 xxl-job路由策略有哪些?
5.2 xxl-job 任务执行失败会怎么样
故障转移+失败重试,查看日志分析 ---> 邮件告警
5.3 如果有大数据量的任务同时都需要执行,怎么解决?
执行器集群部署时,任务路由策略选择分片广播情况下,一次任务调度将会广播触发对应集群中所有执行器执行一次任务
总结
