Nginx限流:
网关限流:
面试题:
你们项目中有没有做过限流?怎么做的?
1.先来介绍业务,什么情况下去做限流,需要说明QPS具体多少
我们当时有一个活动,到了假期就会抢购优惠券,QPS最高可以达到2000,平时10-50之间,为了应对突发流量,需要做限流。
常规限流,为了防止恶意攻击,保护系统正常运行,我们当时系统能够承受最大的QPS是多少(压测结果)
2.nginx限流
控制速率(突发流量):使用漏桶算法来实现过滤,让请求以固定的速率处理请求,可以应对突发流量
控制并发数,限制单个ip的链接数和并发链接的总数
3.网关限流
在spring cloud gateway中支持局部过滤器RequestRateLimiter来做限流,使用的是令牌桶算法
可以根据ip或路径进行限流,可以设置每秒填充平均速率,和令牌桶总容量
分布式系统理论:
解释一下CAP和BASE理论
CAP:
一致性:
用户访问分布式系统中的任意节点,得到的数据必须一致。
可用性:
用户访问集群中的任意健康节点,必须能得到响应,而不是超时或拒绝。
分区容错:
分区:因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接,形成独立分区。
容错:在集群出现分区时,整个系统也要持续对外提供服务
结论:
分布式系统节点之间肯定是需要网络连接的,分区(P)是必然存在的
如果保证访问的高可用性(A),可以持续对外提供服务,但不能保证数据的强一致性--> AP
如果保证访问的数据强一致性(C),就要放弃高可用性 --> CP
BASE :
BASE理论是对CAP的一种解决思路,包含三个思想:
Basically Available(基本可用):分布式系统在出现故障时,允许损失部分可用性。即保证核心可用
Soft State(软状态):在一定时间内,允许出现中间状态,比如临时的不一致状态。
Eventually Consistent(最终一致性):虽然无法保持强一致性,但是在软状态结束后,最终达到数据一致
面试题:
分布式事务解决方案:
Seata框架:
Seata事务管理中有三个重要的角色:
TC - 事务协调者:维护全局和分支事务的状态,协调全局事务提交或回滚
TM - 事务管理器:定义全局事务的范围,开始全局事务、提交或回滚全局事务
RM - 资源管理器:管理分支事务处理的资源,与TC交谈以注册分支事务或报告分支事务的状态,并驱动分支事务提交或回滚。
seata的XA模式:
CAP中的CP,保证数据的强一致性。
seata的AT模式:
TCC模式:
MQ分布式事务:
面试题:
你们采用哪种分布式事务解决方案?
简历上写的微服务,只要是发生了多个服务之间的写操作,都需要进行分布式事务控制。
描述项目中采用的哪种方案(seata|MQ)
1.seata的XA模式,CP,需要互相等待各个分支事务提交,可以保证强一致性,性能差 银行业务
2. seata的AT模式,AP,底层使用undo log实现,性能好 互联网业务
3. seata的TCC模式,AP,性能较好,不过需要人工编码实现 银行业务
4.MQ模式实现分布式事务,在A服务写数据的时候,需要在同一个事务内发送消息到另外一个事务,异步,性能最好 互联网业务
分布式服务的接口幂等性:
幂等:多次调用方法或者接口不会改变业务状态,可以保证重复调用的结果和单次调用的结果一致。
需要幂等场景:
用户重复点击(网络波动)
MQ消息重复
应用使用失败或超时重试机制
接口幂等:
解决接口不幂等方案:
1.数据库索引
2.token + redis
3.分布式锁
面试题:
分布式服务的接口幂等性如何设计?
幂等:多次调用方法或者接口不会改变业务状态,可以保证重复调用的结果和单次调用的结果一致
如果是新增数据,可以使用数据库的唯一索引
如果是新增或者修改数据
分布式锁,性能较低
使用token+redis来实现,性能较好
第一次请求,生成一个唯一的token存入redis,返回给前端
第二次请求,业务处理,携带之前的token,到redis进行验证,如果存在,可以执行业务,删除token;如果不存在,则直接返回,不处理业务。
分布式任务调度:
xxl-job路由策略有哪些:
1.ROUND(轮询)
2.FAILOVER(故障转移):按照顺序依次进行心跳检测,第一个心跳检测成功的机器选定为目标执行器并发起调度。
3.SHARDING_BROADCAST(分片广播):广播触发对应集群中所有机器执行一次任务,同时系统自动传递分片参数;可根据分片参数开发分片任务。
xxl-job任务执行失败怎么解决:
故障转移+失败重试,查看日志分析---->邮件告警
如果有大数据量的任务同时都需要执行,怎么解决?
执行器集群部署时,任务路由策略选择分片广播情况下,一次任务调度将会广播触发对应集群中所有执行器执行一次任务。
面试题: