记录线上环境碰到的问题:
-
新版本上线如何切换版本?
-
蓝绿发布?
-
Spring Task定时任务弊端有哪些?怎么解决?
弊端:
- 会有时间差,导致程序不严谨。
10.01下单,11点定时检查超过一小时未付款的订单,此时还差一分钟,需要等到12点定时查询才能删除。 - 不支持集群
假设使用10台机器,每次就会运行十次。
解决方案:使用Quarz - 会对数据库全表搜索,影响数据库性能。
select * from order where status = 1; 查询状态为1(未支付)的订单。因为状态未设置索引,则全表扫描。
定时任务只适用于小型轻量级项目,传统项目。
如何解决?
- 使用MQ消息队列,建立延时任务(队列)
10.12下单,11.12检查,状态如果还是未支付则删除。
- 会有时间差,导致程序不严谨。
-
对于超卖问题如何解决?
并发较小的项目(用户量小,传统项目):
- 在方法上加上synchronized (性能低下)
- 乐观锁 (性能低下,数据库连接有限,数据库层面也有锁)
// sql
update order set count = count - #{ buyCount } where id = #{ id } and count > #{ buyCount }
//java
int result = decr(id,buyCount);
if( result != 1){
throw new RunTimeException("库存不够!");
}
-
并发量较大:
分布式锁-> zookeeper,redis
-
Mybatis 分页插件嵌套查询BUG怎么解决?
Mybatis官方阐述。
解决方案:- 前端懒加载(前端先查询主表,再根据主表ID查询附表)
- 后端懒加载(后端先查询主表,再根据主表ID查询附表)
- mybatis select属性(select为查询id对应 ,column 传参,从上级select参数中获取 )
-
谈一谈分布式会话session
-
spring aop 嵌套切入的问题怎么解决?
原因:
public String say(String a) {
say2(a); // this.say2() ,并不会使用切面中的代码
}
public String say2(String a) {
return a + a;
}
- 解决方案一:
// 注入自己
@Autowired
private A a;
public String say(String a) {
a.say2(a);
}
public String say2(String a) {
return a + a;
}
- 解决方式二:
//使用AopContext.currentProxy())
public String say(String a) {
((OneBean)AopContext.currentProxy()).say2(a) ;
}
public String say2(String a) {
return a + a;
}
-
信息脱敏,跨域,防盗链
- 信息脱敏:根据相应算法对信息替换成*
- 跨域:后端配置
- 防盗链:防止其他网站盗用图片、视频等资源,可配置nginx (server块)
-
分布式session?
-
jwt中为啥用refresh_token去刷新access_token,直接把access_token的有效期设置长一点不行吗?
- access_token为了安全设置的有过期时间,refresh_token解决的是用户还在操作过程中access_token过期情况;
- 对用户体验好
-
并发刷新Token如何解决?
前端方案:请求拦截
由于前端请求都是异步的,只有一个请求的时候,刷新 Token 是比较好处理的,但并发请求下刷新 Token 处理起来有点麻烦。我们需要考虑在多个请求几乎同时发起并且 Token 都失效的情况,当第一个请求进入 Token 刷新流程时,其他请求必须等待第一个请求完成 Token 刷新后再使用新 Token 进行重试。
简单地讲,就是同一时间有多个请求且 Token 都失效,在第一个请求进行 Token 刷新时,其他请求必须处于等待状态,直到 Token 刷新完成,才能携带新 Token 进行重试。后端方案:利用 Redis 缓存
当同时发起多个请求时,第一个接口刷新了 Token,后面的请求仍然能通过请求,且不造成 Token 重复刷新。那么,后端在用户第一次登录时,需要将生成的 Token 数据(token 和 createTime)缓存一份到 Redis 中。
当 Token 过期时,重新生成新的 Token 数据并更新 Redis 缓存,同时在 Redis 中设置一条 Token 过渡数据并设置一个很短的过期时间(比如 30s)。如果后面的请求发现 Token 已经被刷新了,就判断 Redis 中是否存在 Token 过渡数据,存在就放行,这样同一时间的请求都可以通过。 -
负载均衡hash算法宕机会出现什么问题?新增机器会出现什么问题? 一致性hash算法又是如何解决?
-
redis key过期删除策略?
- 定期删除过期key。
- 惰性删除:过期后再次访问,删除过期key。
- 被动删除:内存到达阈值,删除过期key。
- 以上三种组合使用。
-
如何保证前端请求顺序执行?
case:
购物车 ± 商品:现有一件
+1 -1 -1 = 0 网络问题导致==》-1-1+1 = 1
暂未完成,继续寻找问题。