开发中可能碰到的问题

淡淡的烟草味﹌ 2023-10-03 21:10 70阅读 0赞

## 1、负责模块中有什么技术亮点？ ##

### 1.表单数据重复提交，是通过接口幂等性的思路来解决的，首先是: ###

1.  从数据库方面考虑，数据设计的时候，如果有唯一性，考虑建立唯一索引。
2.  从应用层面考虑，首先判断是单机服务还是分布式服务？
    
    #### 1.单体服务项目-防止重复提交 ####
    
    采用【AOP解析自定义注解】来解决表单/请求重复的提交问题。
    
    思路：
    
    1.建立自定义注解 @NoRepeatSubmit 标记所有Controller中的提交请求。  
    2.通过AOP机制对所有标记了@NoRepeatSubmit 的方法拦截。
    
    3.使用**DCL**（Double Checked Locking，**双重检测锁**）来防止重复提交，里面有一个非常好用的数据结构 LRUMap 可以保存指定数量的固定的数据，
    
    当我们每次不同接口提交不同数据的时候，判断Map里面有没有请求接口的 **ID**的key，如果有进行一个拦截，没有就将这个**ID**存放到map中
    
    #### 2.(刚好我做的这个项目是一个微服务) ####
    
    ##### **利用token机制+redis的分布式锁（jedis）来防止表单/请求重复提交。** #####

思路如下：

1.自定义注解 @NoRepeatSubmit 标记所有Controller中的提交请求。  
2.通过AOP 对所有标记了 @NoRepeatSubmit 的方法拦截。  
3.在业务方法执行前，获取当前用户的 token（或JSessionId）+ 当前请求地址，形成一个唯一Key，然后去获取 Redis 分布式锁（如果此时并发获取，只有一个线程会成功获取锁）。  
4.最后业务方法执行完毕，释放锁。

## 2.API接口防刷,项目中关于短信验证登录 ##

### 拦截器+自定义注解+Redis ###

### AOP+自定义注解+Redis： ###

1.自定义注解 @NoRepeatSubmit 标记所有要访问的方法

2.判断请求是否属于方法的请求

3.获取方法中的注解,看是否有该注解

4.如果没有放行，否则将 访问的方法的标记的**注解 + ip + “:” + uri**形成唯一key存放到Redis中

5.当第一次访问时，给key设置一个时间,过期时间为注解确定的访问周期

6.在限定访问时间内每次访问方法时+1，当超出访问次数限制，不进行任何操作，返回true，否则抛出异常给用户进行一个友好提示

## 2、redis在你模块中有什么应用场景？为什么用redis？为什么选择用redis呢？ ##

速度快，完全基于内存，使用C语言实现，网络层使用epoll解决高并发问题，单线程模型避免了不必要的上下文切换及竞争条件；

## 3、RabbitMQ用过吗？什么场景用的？用来解决什么问题？有什么方案保证消息不丢失呢？ ##

用过：

*  订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功
 *  库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作

### 三种情况：生产者将消息传送到MQ服务器的过程中丢失，MQ服务器自身丢失，MQ服务器将消息传送到消费者的过程中丢失。 ###

生产者到MQ服务器：事务机制和confirm机制。  
MQ服务器自身：持久化、单机集群、普通集群模式、镜像集群模式。  
MQ服务器到消费者：basicAck机制、死信队列、消息补偿机制。

## 4、如果页面查询慢的话，你有什么解决思路？可能是什么问题，如何解决呢？ ##

首先要搞明白慢的原因是什么：是查询条件没有命中索引？还是 load 了不需要的数据列？还是数据量太大？所以优化也是针对这三个方向来的。

1.  首先用 explain 分析语句的执行计划，查看使用索引的情况，是不是查询没走索引，如果可以加索引解决，优先采用加索引解决。
2.  分析语句，看看是否存在一些导致索引失效的用法，是否 load 了额外的数据，是否加载了许多结 果中并不需要的列，对语句进行分析以及重写。
3.  如果对语句的优化已经无法进行，可以考虑表中的数据量是否太大，如果 是的话可以进行垂直拆分或者水平拆分。