黑马点评面试话术

1.项目介绍

美食项目主要是一个基于SpringBoot的前后端分离项目，集成了redis,tomcat,mysql。类似于大众点评。实现了短信登录，商户查询缓存，优惠券秒杀，附近的商户，UV统计，用户签到，好友关注，达人探店

2. 分布式登录功能

分布式登录功能：基于Redis+双拦截机制解决集群下session共享问题，利用ThrealLocal存储用户信息

2.1 讲讲登录的整个流程

1.验证码生成：用户提交手机号，点击发送验证码，后端生成验证码，存储（phone,code）到redis，返回验证码到前端
2.登录：提交手机号和验证码，redis中获取验证码校验，校验过了查询用户，存在则UUID 生成token,存储(token, user)到redis,不存在就新建用户先，再存储到redis。返回token信息给前端

2.2 集群模式session下存储用户信息会有啥问题？

tomcat并不共享session内存空间，一台tomcat无法获取存储在另一台tomcat的session数据

2.3 为什么采用redis存储用户信息和验证码

redis基于内存，速度快，可以实现集群共享
可以存储key,value数据结构

2.4 redis的存储格式怎么样的？

验证码：(key, value) —> (手机号，随机六位数字) String结构
用户信息：（key, value）–> (token, 用户信息) Hash结构

2.5 为什么采用Hash结构存储用户信息

内存占用少，存取操作方便。针对某个字段可以做增删改操作。
String类型需要全部删除

2.6 为什么采用双拦截器？每个拦截器负责什么功能

第一个拦截器：判断token是否存在，存在找到用户信息，存入threadlocal。并刷新token有效期，然后放行
判断threadlocal是否有值，有则放行，无则拦截

3 商品缓存功能

采用Redis实现商品毫秒级响应，采用延时双删策略保证数据的一致性。

3.1 什么是延时双删？为什么要删两次缓存

延时双删是为了解决数据库数据和缓存数据不一致的问题。先删除缓存，再更新数据库，延迟一会再删除缓存。删两次缓存时因为并发环境下，可能数据库还没更新成功，请求来了读取到了数据库的旧数据，回填到redis。所以需要延时一会，再删一次缓存。

4 优惠券秒杀功能

基于Redis实现全局唯一订单ID，CAS解决库存超卖问题，Redission分布式锁解决一人一单并发安全问题

4.1 全局唯一ID是怎么实现的？

符号位+时间戳+计数器，应用到了String中的incrby功能
其中key采用每天生成不同的key,方便统计每天的订单数量

4.2 秒杀下单的流程是怎么样的？

提交优惠券ID，查询优惠券信息，判断秒杀是否开始，判断库存是否充足，查询订单，校验一人一单，减库存，均满足创建订单，返回订单ID即可

4.3 如何解决超卖问题

使用CAS乐观锁，在扣减库存的时候判断库存是否大于0.但是本质还是用到了数据库中的行锁吧，修改数据加了写锁。这里锁的是库存

4.4 如何实现一人一单

在扣减库存之前，到订单表查询用户ID和优惠券ID是否存在存在，存在就拒绝后续动作。这里要加悲观锁，锁用户ID，注意这里通过userId.toString.intern()获取字符串常量池的规范表示，值相同的地址相同，可以锁住，因为toString方法都会底层是新new了一个对象

注意：这里锁的是用户ID，要保证事务提交了，锁才能释放

4.5 锁在事务内部会存在什么问题

锁释放了，但是事务未提交，其他线程进来，查询认为数据库数据未更新，因此可能出现并发安全问题。一般要保证提交事务之后再释放锁

4.6 分布式锁的误删情况了解吗?

线程1，拿到锁，但是业务执行时间太久了，锁过期自动释放。线程2获得redis锁，执行业务，此时线程1业务执行完了，又执行释放锁动作，错误把线程2的锁释放了。
解决方案，释放锁的时候判断UUID+线程ID是否是自己。因为不同集群下线程ID可能一致
这里还存在什么问题吗？
判断锁和释放锁之间执行Full GC 业务代码阻塞，锁超时释放。GC结束，线程2获取锁成功，然后线程1释放锁，又把线程2的锁释放了
所以需要lua脚本实现判断锁和释放锁的原子性

4.7 如何实现调用lua

使用redistemplate的execute(lua,key,value)

4.8 分布式锁失效问题如何解决

采用多个redis节点作为主节点，称之为联锁。只要所有节点获取锁成功，才算成功

5.秒杀优化

使用lua脚本实现库存和用户下单资格判断，采用Stream消费者组实现消息队列存放下单信息，通过单例线程池实现异步下单入库操作，优化接口平均响应时间从 2500ms 降低到 110ms，QPS 提升显著

5.1 秒杀优化流程解析

把判断秒杀库存和校验一人一单功能放到redis做，输出优惠券ID，用户ID，订单ID到阻塞队列中，开启线程异步读取线程信息，完成下单。

5.2 你使用Jmemter主要是看什么

1.平均值：所有请求响应时间的平均值
2.吞吐量：每秒处理成功的请求，本机达到（1500）

5.3 你的阻塞队列的东西什么时候提交线程任务呢？

类初始化之后就提交任务，使用到了PostConstruct注解（和bean的生命周期可以联动）

5.4 为什么采用redis的消息队列，而不使用jvm的阻塞队列？

jvm内存限制，内存故障，消息丢失
redi实现的消息队列可以实现持久化机制，并且不受jvm内存限制

5.5 聊一下redis有哪些消息队列？

List,PubSub和Stream
本项目采用Stream消息队列的原因：支持消费者组，组内竞争消息，避免重复消费，又消费确认机制，保证消息至少被消费一次。吞吐量达到1600

6.多用户行为管理

SortedSet实现笔记点赞排行榜、Set集合管理用户共同关注、Geo实现附近商铺功能，BitMap实现用户签到

6.1 如何设计点赞排行榜（时间）功能的

redis的sortedset实现，key为笔记ID，value为点赞的用户及时间。可以根据时间排序返回

6.2 如何实现关注和共同关注

使用redis的set数据结构，每个用户存储他关注的所有人信息。
要求两个用户的话，拿出来用SInter求交集就行

6.3 如何实现附近商铺功能的

使用到了GEO功能。GEOADD把商铺根据类型作为key,经纬度作为value存入redis.
GEOSearch按照半径返回附近店铺的坐标信息。

6.4 如何实现用户签到功能

使用BitMap,相对于mysql存储记录，节省了大量的内存空间
主要是他的每一位对应的0和1，只要签到了，就记录为1即可
存储的key为用户+月份。只要4个字节即可