一、登录模块
1.Session存在共享问题
2. redis
因此选择用redis，数据结构：
手机号:验证码code
随机码为token:用户信息(保存为一个Map<String,Object>对象,具体为key与value)
3.整体流程
(1) 发送验证码
(2) 短信验证码登录、注册
(3) 校验登录状态 token
(4) 拦截器优化
二、实现商品信息缓存
1. 查询流程
2. 缓存与数据库一致性问题
- redis缓存更新策略有几种？选择哪种？
内存淘汰和过期淘汰 主动更新 - 操作缓存和数据库
(1) 删除缓存还是更新缓存 删除
(2)如何保证缓存与数据库的操作同时成功或失败 事务
(3)先操作缓存还是数据库 写数据库比较慢
3. 三大问题及解决方案
- 缓存穿透
定义、有哪两种方式解决
- 缓存雪崩
定义(2种情况)、解决方案 - 缓存击穿
定义
两种解决方案: 一致性、可用性
- 互斥锁 setnx
利用redis的setnx命令,通过获取锁和释放锁的方式来完成。锁的过期时间设置10s,能够保证一致性，但是无法保证可用性(线程会一直查询)
- 设置逻辑过期时间
给缓存设置一个逻辑过期时间
还是需要互斥锁，不同的就是:不是每一个线程都需要取重写数据库,如果发现获取不到锁会直接返回旧的数据，获取不到锁不会说一直重试,而且拿到锁也是开启一个新线程取写数据库。保证了可用性，但失去了一致性(此时拿到的数据不是新的数据)
- 结果对比
三、优惠券秒杀
1. Redis自增实现全局唯一id
- 常见的生成全局唯一id生成策略
(各自特点,自己搜资料补充) - 具体实现方式及原因
符号位+时间戳+序列号 保证了递增性、安全性、唯一性
2. 秒杀下单，并利用乐观锁解决超卖问题
- 超卖是什么
库存小于0 - 下单必须满足的条件
秒杀是否开始或结束，如果尚未开始或已经结束则无法下单
库存是否充足，不足则无法下单 - 能不能直接采用版本号？存在什么问题
只要我扣减库存时的库存和之前我查询到的库存是一样的，就意味着没有人在中间修改过库存，那么此时就是安全的，但是以上这种方式通过测试发现会有很多失败的情况，失败的原因在于：在使用乐观锁过程中假设100个线程同时都拿到了100的库存，然后大家一起去进行扣减，但是100个人中只有1个人能扣减成功，其他的人在处理时，他们在扣减时，库存已经被修改过了，所以此时其他线程都会失败 - 项目中的乐观锁如何实现
在扣减库存之前 判断库存大于0就好
3. 优惠券秒杀：一人一单
- 一人一单
- 解决方案
根据用户id加一个synchronized锁
控制锁的粒度
代理模式解决事务失效,并且保证提交事务后再释放锁(不建议自己说出来,坑太多，不好讲) - 存在的问题：集群模式下锁失效
4.分布锁解决集群下锁失效的问题（基于Setnx）
4.1 基于setnex（setIfAbsent) 实现分布式锁
防止死锁？添加过期时间
4.2 分布式锁的误删问题
什么是误删？ 线程1发生了业务阻塞，锁超时释放了自己的锁，后面正常执行业务后，线程1又执行锁释放把线程2的锁给释放了
如何解决？：在释放锁的时候判断锁是否属于自己
4.3 分布式锁的原子性问题
判断锁和释放锁是两个不同的动作！需要让判断和释放锁变成一个原子操作
利用lua脚本
4.4 存在的问题
不可重入
不可重试
超时释放
主从一致性
5. 基于Redission的分布式锁（对setnex的优化）
5.1 不可重入
5.2 锁重试和watchdog机制
5.3 MultiLock解决主从不一致问题
redission提出来了MutiLock锁，使用这把锁咱们就不使用主从了，每个节点的地位都是一样的， 这把锁加锁的逻辑需要写入到每一个主丛节点上，只有所有的服务器都写入成功，此时才是加锁成功，假设现在某个节点挂了，那么他去获得锁的时候，只要有一个节点拿不到，都不能算是加锁成功，就保证了加锁的可靠性
6. 异步秒杀优化
- 基于阻塞队列的思路
- 先利用Redis完成库存余量、一人一单判断，完成抢单业务
- 再将下单业务放入阻塞队列，利用独立线程异步下单
- 基于阻塞队列的异步秒杀存在哪些问题？
内存限制问题
数据安全问题 - 基于Redis的Stream结构作为消息队列,实现异步秒杀下单
- 创建一个Stream类型的消息队列，名为stream.orders
- 修改之前的秒杀下单Lua脚本，在认定有抢购资格后，直接向stream.orders中添加消息，内容包含voucherId、userId、orderId
- 项目启动时，开启一个线程任务，尝试获取stream.orders中的消息，完成下单 (用Java代码消息队列中的信息)，出现异常需要读取Pending List的
- Stream类型消息队列的消费者组的特点
四. 点赞排行榜
SortedSet数据结构 根据时间进行排行的
- 问题一：代码细节
List<UserDTO> userDTOS = userService.query()
.in("id", ids).last("ORDER BY FIELD(id," + idStr + ")").list()
.stream()
.map(user -> BeanUtil.copyProperties(user, UserDTO.class))
.collect(Collectors.toList());
- 问题二：SortedSet底层
hash结构：关联元素和权重
跳跃表：空间换时间，提高查找效率
五. 附近商户
- 设计思路
- 选择geo数据结构
- 分组
根据type来对数据进行筛选，所以我们可以按照商户类型做分组，类型相同的商户作为同一组，以typeId为key存入同一个GEO集合中即可 - 导入数据
数据库表中的数据导入到redis中去，redis中的GEO，GEO在redis中就一个menber和一个经纬度，我们把x和y轴传入到redis做的经纬度位置去，但我们不能把所有的数据都放入到menber中去，毕竟作为redis是一个内存级数据库，如果存海量数据，redis还是力不从心，所以我们在这个地方存储他的id即可。
六. 用户签到
0. 数据结构
Bitmap
bitMap返回的数据是10进制
1. 签到功能
@Override
public Result sign() {
// 1.获取当前登录用户
Long userId = UserHolder.getUser().getId();
// 2.获取日期
LocalDateTime now = LocalDateTime.now();
// 3.拼接key
String keySuffix = now.format(DateTimeFormatter.ofPattern(":yyyyMM"));
String key = USER_SIGN_KEY + userId + keySuffix; //user:sign:5:202302
// 4.获取今天是本月的第几天
int dayOfMonth = now.getDayOfMonth();
// 5.写入Redis SETBIT key offset 1
stringRedisTemplate.opsForValue().setBit(key, dayOfMonth - 1, true);
return Result.ok();
}
2. 统计签到天数
思路：
bitMap返回的数据是10进制，哪假如说返回一个数字8，那么我哪儿知道到底哪些是0，哪些是1呢？我们只需要让得到的10进制数字和1做与运算就可以了，因为1只有遇见1 才是1，其他数字都是0 ，我们把签到结果和1进行与操作，每与一次，就把签到结果向右移动一位，依次内推，我们就能完成逐个遍历的效果了。
七. UV统计
数据结构的选择HyperLogLog
八. 共同关注
选择的数据结构是set，比如用户1关注了A B C，那么就是 1：A B C
同理对用户2有同样的操作，求共同关注就是求两个set的交集
//设置key：当前登录用户，关注的对象
stringRedisTemplate.opsForSet().add(key, followUserId.toString());
//求交集
Set<String> intersect = stringRedisTemplate.opsForSet().intersect(key, key2);
九. 推模式Feed流
1. Feed流理论
- feed流：内容推送给用户
- feed流两种模式：Timeline和智能排序
- Timeline三种实现方式：推、拉、推拉结合
拉模式:
当张三和李四和王五发了消息后，都会保存在自己的邮箱中，假设赵六要读取信息，那么他会从读取他自己的收件箱，此时系统会从他关注的人群中，把他关注人的信息全部都进行拉取，然后在进行排序
推模式：
推模式是没有写邮箱的，当张三写了一个内容，此时会主动的把张三写的内容发送到他的粉丝收件箱中去，假设此时李四再来读取，就不用再去临时拉取了
优点：时效快，不用临时拉取
缺点：内存压力大，假设一个大V写信息，很多人关注他， 就会写很多分数据到粉丝那边去
推拉结合模式：也叫做读写混合，兼具推和拉两种模式的优点。
推拉模式是一个折中的方案，站在发件人这一段，如果是个普通的人，那么我们采用写扩散的方式，直接把数据写入到他的粉丝中去，因为普通的人他的粉丝关注量比较小，所以这样做没有压力，如果是大V，那么他是直接将数据先写入到一份到发件箱里边去，然后再直接写一份到活跃粉丝收件箱里边去，现在站在收件人这端来看，如果是活跃粉丝，那么大V和普通的人发的都会直接写入到自己收件箱里边来，而如果是普通的粉丝，由于他们上线不是很频繁，所以等他们上线时，再从发件箱里边去拉信息。
2. 实现方案
在保存完探店笔记后，获得到当前笔记的粉丝，然后把数据推送到粉丝的redis中去。按照时间顺序feed,数据结构
@Override
public Result saveBlog(Blog blog) {
// 1.获取登录用户
UserDTO user = UserHolder.getUser();
blog.setUserId(user.getId());
// 2.保存探店笔记
boolean isSuccess = save(blog);
if(!isSuccess){
return Result.fail("新增笔记失败!");
}
// 3.查询笔记作者的所有粉丝 select * from tb_follow where follow_user_id = ?
List<Follow> follows = followService.query().eq("follow_user_id", user.getId()).list();
// 4.推送笔记id给所有粉丝
for (Follow follow : follows) {
// 4.1.获取粉丝id
Long userId = follow.getUserId();
// 4.2.推送
String key = FEED_KEY + userId;
stringRedisTemplate.opsForZSet().add(key, blog.getId().toString(), System.currentTimeMillis());
}
// 5.返回id
return Result.ok(blog.getId());
}
功能二：实现分页查询
思路分析
1、每次查询完成后，我们要分析出查询出数据的最小时间戳，这个值会作为下一次查询的条件
2、我们需要找到与上一次查询相同的查询个数作为偏移量，下次查询时，跳过这些查询过的数据，拿到我们需要的数据
综上：我们的请求参数中就需要携带 lastId：上一次查询的最小时间戳 和偏移量这两个参数。
这两个参数第一次会由前端来指定，以后的查询就根据后台结果作为条件，再次传递到后台。
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
