场景题
# 解决了什么技术难题/你负责项目的时候遇到了哪些比较棘手的问题
（1）设计模式
- 工厂模式+策略
- 责任链模式
回答思路
什么背景（技术问题）
过程（解决问题的过程）
最终落地方案
举例：
①：介绍登录业务（一开始没有用设计模式，所有的登录方式都柔和在一个业务类中，不过，发现需求经常改）
②：登录方式经常会增加或更换，每次都要修改业务层代码，所以，经过我的设计，使用了工厂设计模式和策略模式，解决了，经常修改业务层代码的问题
③：详细介绍一下工厂模式和策略模式（参考前面设计模式的课程）
（2）线上BUG
- CPU飙高
- 内存泄漏
- 线程死锁
- ....
回答方式参考上面的回答思路，具体问题可以参考前面的课程（JVM和多线程相关的面试题）
（3）调优
- 慢接口
- 慢SQL
- 缓存方案
（4）组件封装
- 分布式锁
- 接口幂等
- 分布式事务
- 支付通用
# 你们项目中日志怎么采集的
- 我们搭建了ELK日志采集系统
- 介绍ELK的三个组件：
- Elasticsearch是全文搜索分析引擎，可以对数据存储、搜索、分析
- Logstash是一个数据收集引擎，可以动态收集数据，可以对数据进行过滤、分析，将数据存储到指定的位置
- Kibana是一个数据分析和可视化平台，配合Elasticsearch对数据进行搜索，分析，图表化展示
# 查看日志的命令
需要掌握的Linux中的日志：
- 实时监控日志的变化
- 实时监控某一个日志文件的变化：tail -f xx.log；实时监控日志最后100行日志： tail –n 100 -f xx.log
- 按照行号查询
- 查询日志尾部最后100行日志：tail – n 100 xx.log
- 查询日志头部开始100行日志：head –n 100 xx.log
- 查询某一个日志行号区间：cat -n xx.log | tail -n +100 | head -n 100 (查询100行至200行的日志)
- 按照关键字找日志的信息
- 查询日志文件中包含debug的日志行号：cat -n xx.log | grep "debug"
- 按照日期查询
- sed -n '/2023-05-18 14:22:31.070/,/ 2023-05-18 14:27:14.158/p’xx.log
- 日志太多，处理方式
- 分页查询日志信息：cat -n xx.log |grep "debug" | more
- 筛选过滤以后，输出到一个文件：cat -n xx.log | grep "debug" >debug.txt
# 生产问题怎么排查
已经上线的bug排查的思路：
先分析日志，通常在业务中都会有日志的记录，或者查看系统日志，或者查看日志文件，然后定位问题
远程debug(通常公司的正式环境（生产环境）是不允许远程debug的，因为可以访问到生产环境的数据。一般远程debug都是公司的测试环境，方便调试代码)
远程代码需要配置启动参数，把项目打包放到服务器后启动项目的参数：
java -jar -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 project-1.0-SNAPSHOT.jar
-agentlib:jdwp 是通知JVM使用(java debug wire protocol)来运行调试环境
transport=dt_socket 调试数据的传送方式
server=y 参数是指是否支持在server模式
suspend=n 是否在调试客户端建立起来后，再执行JVM。
address=5005 调试端口设置为5005，其它端口也可以
- idea中设置远程debug，找到idea中的 Edit Configurations...
idea中启动远程debug
访问远程服务器，在本地代码中打断点即可调试远程
# 场景题
# 单点登录这块怎么实现的
1，先解释什么是单点登录
单点登录的英文名叫做：Single Sign On（简称SSO）
2，介绍自己项目中涉及到的单点登录（即使没涉及过，也可以说实现的思路）
3，介绍单点登录的解决方案，以JWT为例
I. 用户访问其他系统，会在网关判断token是否有效
II. 如果token无效则会返回401（认证失败）前端跳转到登录页面
III. 用户发送登录请求，返回浏览器一个token，浏览器把token保存到cookie
IV. 再去访问其他服务的时候，都需要携带token，由网关统一验证后路由到目标服务
# 权限认证是如何实现的
- 后台管理系统的开发经验
- 介绍RBAC权限模型5张表的关系（用户、角色、权限）
- 权限框架：Spring security
# 上传数据的安全性你们怎么控制？
- 使用非对称加密（或对称加密），给前端一个公钥让他把数据加密后传到后台，后台解密后处理数据
- 传输的数据很大建议使用对称加密，不过不能保存敏感信息
- 传输的数据较小，要求安全性高，建议采用非对称加密
# 如何判断几十亿个数 是否存在某个数？
对于几十亿个数的查找问题
- “对于几十亿个数的查找问题，首先可以考虑直接查找，但时间复杂度是O(n)，效率较低。
- 如果数据允许排序，可以先排序再使用二分查找，排序的时间复杂度是O(n log n)，而查找的时间复杂度是O(log n)，但整体性能仍然可能不够理想。
- 为了提高查找效率，可以考虑使用哈希表或布隆过滤器，哈希表的查找时间复杂度是O(1)，但需要较大的内存空间；而布隆过滤器则是一种空间效率更高的数据结构，不过布隆过滤器会有误判，只能用于快速判断某个数不存在或可能存在。
- 如果数据量太大，无法一次性加载到内存中，可以采用分片处理方法，将数据分成多个小文件进行处理。如果数据存储在分布式系统中，可以使用分布式计算框架（如Hadoop或Spark）来并行处理查找请求。
- 此外，如果数据范围有限且密集，可以使用位图法来节省空间，因为每个数只需要一个bit来表示。但位图法需要预先将数据加载到位图中，适合数据范围较小的场景。
- 对于频繁查找的场景，可以考虑使用缓存或预处理（如建立索引）来优化查找效率。
# 如何防止超卖
最简单的方式是直接通过SQL语句判断库存大于0，通过数据库行锁，完成查询扣库存的原子性操作，实现防止超卖，适用于用户、并发量小的情况。 并发大的，可以将库存预热到redis中，通过Lua脚本查询库存、通过用户ID作为Key来避免重复下单、扣库存、生成订单号，再通过消息队列异步操作数据库和具体订单的生成
# 设计30分钟未支付自动取消功能(考察延时队列实现)
有多种方式可以实现
- 对数据库轮询，通过定时任务扫描数据库，取消超时订单，但是对数据库压力大，而且有延迟性
- 使用时间轮算法，可以使用Netty 的HashedWheelTimer，按时间槽调度任务，这种方式实现代码简单，但是缺点是重启后消息会丢失。
- 使用RabbitMQ的延迟队列，可以设置消息的存活时间，如果超时未消费就会变成死信，进入死信队列，再通过从死信队列中拿消息进行处理。由RabbitMQ保证消息的不丢失和不重复消费
# 高并发下如何保证Redis和MySQL库存数据一致性?
若允许短暂不一致，采用 Canal 异步监听数据库binlog日志 并延迟删除缓存 + 如果删除失败，MQ异步重试 实现最终一致。 若要求强一致，使用 Redisson 实现的读写锁，在读的时候添加共享锁，当我们更新数据的时候，添加排他锁。
# 用户连续点击支付按钮，如何保证只扣款一次?
首先前端肯定是要设置按钮只允许点击一次，后端可以通过Redis，使用setnx，将当前用户和商品id为key来保证生成订单业务只执行一次。
如果是用户重复支付，可以在订单支付成功回调时先判断订单是否已经支付，支付过执行退款业务。
# 千万级数据表如何优化深分页?(ES scroll vs游标方案对比)
Elasticsearch Scroll：适合离线大批量拉取，牺牲实时性换取吞吐量。
数据库游标分页：适合用户实时操作，需业务侧配合传递游标参数。
避免深分页
# MySQL到ES的数据一致性如何保障?(Binlog+CDC方案)
# 如何防止恶意用户批量调用注册接口
# AQ
公司对这个岗位的期待是什么，您认为我和这个期待还有哪些差距
个人优势和未来规划