Java面试题———热门篇①
目录
1、分布式服务的接口幂等性如何设计？
概述
需要幂等的场景
网络波动
MQ消息重复
用户重复点击
应用使用失败或超时重试机制
后端解决方案
方案一：数据库唯一索引
方案二：token+redis
方案三：分布式锁
2、单点登录这块怎么实现的
3、权限认证是如何实现的
4、上传数据的安全性你们怎么控制？
对称加密
非对称加密
5、你负责项目的时候遇到了哪些比较棘手的问题？怎么解决的？
6、你们项目中日志怎么采集的？
7、你们的app用户量有多少？你们项目的的qps是多少、有多少台服务器？
8、说说你们系统生产部署情况
1、分布式服务的接口幂等性如何设计？
概述
所谓幂等: 多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致。
基于RESTful API的角度对部分常见类型请求的幂等性特点进行分析
| 请求方式 | 说明 |
|---|---|
| GET | 查询操作，天然幂等 |
| POST | 新增操作，请求一次与请求多次造成的结果不同，不是幂等的 |
| PUT | 更新操作，如果是以绝对值更新，则是幂等的。如果是通过增量的方式更新，则不是幂等的 |
| DELETE | 删除操作，根据唯一值删除，则是幂等的；如果是根据条件删除，则不一定的幂等。例如每次删除某字段最大的记录 |
需要幂等的场景
网络波动
因网络波动，可能会引起重复请求
MQ消息重复
生产者已把消息发送给MQ，在MQ给生产者返回ack的时候网络中断，故生产者未收到确定消息，生产者认为消息未发送成功。但实际情况是，MQ已成功接收到了消息，在网络重连后，生产者会重新发送刚才的消息，造成MQ接收了重复的消息。
用户重复点击
用户在使用产品时，可能会误操作而触发多笔交易，或因为长时间没有响应，而有意触发多笔交易。
应用使用失败或超时重试机制
为了考虑系统业务稳定性，开发人员一般设计系统时，会考虑失败了如何进行下一步操作或等待一定时间继续前端的动作的。
后端解决方案
方案一：数据库唯一索引
使用数据库提供的唯一索引来保证数据重复插入，避免脏数据产生
解决场景：新增
方案二：token+redis
-
第一次请求
-
在后端生成一个唯一的token(比如：key:userid,value:UUID)
-
将token存储到redis中
-
将token返回前端
-
-
第二次请求
-
在真正处理业务的时候需要携带过来之前的token
-
到redis中查询token是否存在
-
如果存在，则正常处理业务，同时删除redis中的token
-
如果不存在，则操作失败
-
解决场景：新增、删除、修改
方案三：分布式锁
在分布式锁使用的时候，要注意粒度
在操作数据时，先添加一个分布式锁，当操作完成后再释放掉这把锁，同时在操作过程中，如果有人来抢锁，应当抛出异常，即：
if (!lock) {log.info("操作作者信息获取锁失败，operator:{}",request.getOperator());throw new BaseBizException("新增/修改失败");}
操作完成后，释放掉锁，因为幂等问题，通常是一个请求快速过来两次或者多次，所以在释放锁之前让后来的同一个用户的请求，直接失败即可，保证当前方法在短时间之内只能被执行一次，切记控制锁的粒度。
2、单点登录这块怎么实现的
单点登录的英文名叫做：Single Sign On（简称SSO）。
在以前的时候，一般我们就单系统，所有的功能都在同一个系统上。
单体系统的session共享
-
登录：将用户信息保存在Session对象中
-
-
如果在Session对象中能查到，说明已经登录
-
如果在Session对象中查不到，说明没登录（或者已经退出了登录）
-
-
注销（退出登录）：从Session中删除用户的信息
后来，我们为了合理利用资源和降低耦合性，于是把单系统拆分成多个子系统。
多系统即可能有多个Tomcat，而Session是依赖当前系统的Tomcat，所以系统A的Session和系统B的Session是不共享的。
解决系统之间Session不共享问题有一下几种方案：
-
Tomcat集群Session全局复制（集群内每个tomcat的session完全同步）
-
把Session数据放在Redis中（使用Redis模拟Session）自己实现
-
CAS实现单点登录
SSO 单点登录访问流程主要有以下步骤：
-
访问服务：SSO 客户端发送请求访问应用系统提供的服务资源。
-
定向认证：SSO 客户端会重定向用户请求到 SSO 服务器。
-
用户认证：用户身份认证。
-
发放票据：SSO 服务器会产生一个随机的 Service Ticket。
-
验证票据：SSO 服务器验证票据 Service Ticket 的合法性，验证通过后，允许客户端访问 服务。
-
传输用户信息：SSO 服务器验证票据通过后，传输用户认证结果信息给客户端。
-
3、权限认证是如何实现的
五张表：用户、角色、权限
框架：shiro 、 spring security
你是谁？
你要做什么？
4、上传数据的安全性你们怎么控制？
对称加密
文件加密和解密使用相同的密钥，即加密密钥也可以用作解密密钥
解释: 在对称加密算法中，数据发信方将明文和加密密钥一起经过特殊的加密算法处理后，使其变成复杂的加密密文发送出去，收信方收到密文后，若想解读出原文，则需要使用加密时用的密钥以及相同加密算法的逆算法对密文进行解密，才能使其回复成可读明文。在对称加密算法中，使用的密钥只有一个，收发双方都使用这个密钥，这就需要解密方事先知道加密密钥。
优点: 对称加密算法的优点是算法公开、计算量小、加密速度快、加密效率高。
缺点: 没有非对称加密安全.
用途： 一般用于保存用户手机号、身份证等敏感但能解密的信息。
常见的对称加密算法有:
AES、DES、3DES、Blowfish、IDEA、RC4、RC5、RC6、HS256
非对称加密
两个密钥：公开密钥（publickey）和私有密钥，公有密钥加密，私有密钥解密
解释: 同时生成两把密钥：私钥和公钥，私钥隐秘保存，公钥可以下发给信任客户端.
加密与解密:
私钥加密，持有公钥才可以解密
公钥加密，持有私钥才可解密
签名:
私钥签名, 持有公钥进行验证是否被篡改过.
优点: 非对称加密与对称加密相比，其安全性更好；
缺点: 非对称加密的缺点是加密和解密花费时间长、速度慢，只适合对少量数据进行加密。 用途： 一般用于签名和认证。私钥服务器保存, 用来加密, 公钥客户拿着用于对于令牌或者签名的解密或者校验使用.
常见的非对称加密算法有： RSA、DSA（数字签名用）、ECC（移动设备用）、RS256 (采用SHA-256 的 RSA 签名)
面试题：上传数据的安全性你们怎么控制？
使用非对称加密（或对称加密），给前端一个公钥让他把数据加密后传到后台，后台负责解密后处理数据
5、你负责项目的时候遇到了哪些比较棘手的问题？怎么解决的？
这个问题考察的点是想看下你是否真的做过开发,如果你的简历中写了2-3年的工作经验那么你肯定是遇到过一些事情的,如果你一个都没遇到过那么可能你的简历就存在水分了或者你开发的全部是没有技术含量的功能,同时如果你遇到过看下你遇到的事情深度怎么样然后如何去解决的,从侧面看下你在公司开发的功能水平怎么样从而推测你的个人能力以及在上一家公司的地位水平。
要像解决这个问题大家可以准备一个jvm的或者mysql优化的或者用设计模式去优化复杂系统的场景去回答。
内存溢出
CPU飙高
mysql调优
使用策略模式+工厂模式优化代码
6、你们项目中日志怎么采集的？
ELK：即Elasticsearch、Logstash和Kibana三个开源软件的缩写
1、Elasticsearch Elasticsearch 全文搜索和分析引擎，对大容量的数据进行接近实时的存储、搜索和分析操作。
2、Logstash Logstash是一个数据收集引擎，它可以动态的从各种数据源搜集数据，并对数据进行过滤、分析和统一格式等操作，并将输出结果存储到指定位置上
3、Kibana Kibana是一个数据分析和可视化平台，通常与Elasticsearch配合使用，用于对其中的数据进行搜索、分析，并且以统计图标的形式展示。
7、你们的app用户量有多少？你们项目的的qps是多少、有多少台服务器？
我们app端用户量，目前是10万，经过测试，最高的并发集中在晚上7点至9点，其中有的查询接口最高有几次达到了接近2000的qps。
目前生产的服务器使用的tomcat9，使用jmeter压测后，处理的并发数极限为400左右，所以高频访问的微服务通常都是6、7台服务器做了集群。其他访问量较少的集群数量更低一些。
8、说说你们系统生产部署情况
要结合的访问项目的QPS，压测后的结果来计算部署多少台服务器