线上问题集锦(1)

最新推荐文章于 2023-02-09 08:25:16 发布

架构路上

最新推荐文章于 2023-02-09 08:25:16 发布

阅读量279

点赞数

分类专栏： java 文章标签： java 后端

本文链接：https://blog.csdn.net/weixin_41725792/article/details/109740915

版权

java 专栏收录该内容

29 篇文章 1 订阅

订阅专栏

记录线上环境碰到的问题：

新版本上线如何切换版本？
蓝绿发布？
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