详细代码在我的Github上,地址:
https://github.com/CodeTeng/RedisCase
感兴趣的朋友可以去我的语雀平台进行查看更多的知识。
https://www.yuque.com/ambition-bcpii/muziteng
8. 达人探店
8.1 点赞功能
初始代码
@GetMapping("/likes/{id}")
public Result queryBlogLikes(@PathVariable("id") Long id) {
//修改点赞数量
blogService.update().setSql("liked = liked +1 ").eq("id",id).update();
return Result.ok();
}
问题分析:这种方式会导致一个用户无限点赞,明显是不合理的
造成这个问题的原因是,我们现在的逻辑,发起请求只是给数据库+1,所以才会出现这个问题
完善点赞功能
需求:
- 同一个用户只能点赞一次,再次点击则取消点赞
- 如果当前用户已经点赞,则点赞按钮高亮显示(前端已实现,判断字段Blog类的isLike属性)
实现步骤:
- 给Blog类中添加一个isLike字段,标示是否被当前用户点赞
- 修改点赞功能,利用Redis的set集合判断是否点赞过,未点赞过则点赞数+1,已点赞过则点赞数-1
- 修改根据id查询Blog的业务,判断当前登录用户是否点赞过,赋值给isLike字段
- 修改分页查询Blog业务,判断当前登录用户是否点赞过,赋值给isLike字段
核心代码:
public Result likeBlog(Long id) {
// 1. 获取当前用户
Long userId = UserHolder.getUser().getId();
// 2. 判断该用户是否已经点赞
String key = RedisConstants.CACHE_BLOG_LIKED + id;
Double score = stringRedisTemplate.opsForZSet().score(key, userId.toString());
if (score == null) {
// 3. 如果未点赞,可以点赞
// 3.1 数据库点赞
boolean isSuccess = this.update().setSql("liked = liked + 1").eq("id", id).update();
if (isSuccess) {
// 3.2 保存用户到redis的set中--->保存到SortedSet
stringRedisTemplate.opsForZSet().add(key, userId.toString(), System.currentTimeMillis());
}
} else {
// 4. 已点赞,取消点赞
// 4.1 数据库点赞-1
boolean isSuccess = this.update().setSql("liked = liked - 1").eq("id", id).update();
if (isSuccess) {
// 4.2 用户从redis中移除
stringRedisTemplate.opsForZSet().remove(key, userId.toString());
}
}
return Result.ok();
}
8.2 点赞排行榜
核心代码:
public Result queryBlogLikes(Long id) {
String key = RedisConstants.CACHE_BLOG_LIKED + id;
// 1. 查询top5的点赞用户
Set<String> top = stringRedisTemplate.opsForZSet().range(key, 0, 4);
if (top == null || top.isEmpty()) {
return Result.ok(Collections.emptyList());
}
// 2. 解析出其中的用户id
List<Long> userIdList = top.stream().map(Long::valueOf).collect(Collectors.toList());
String userIdStr = StrUtil.join(",", userIdList);
// 3. 根据用户id查询用户 where id in (6, 1) order by filed(id, 6, 1)
QueryWrapper<User> queryWrapper = new QueryWrapper<>();
queryWrapper.in("id", userIdList).last("order by field(id," + userIdStr + ")");
List<UserDTO> userDTOList = userMapper.selectList(queryWrapper)
.stream().map(user -> BeanUtil.copyProperties(user, UserDTO.class)).collect(Collectors.toList());
// 4. 返回
return Result.ok(userDTOList);
}
注意:为什么SQL语句里面要用filed…这是因为MySQL在查询时会进行优化,会将in(6,1)优化为in(1,6),所以我们需要自定义field
9. 好友关注
9.1 关注和取关
涉及到的数据库表
create table tb_follow
(
id bigint auto_increment comment '主键'
primary key,
user_id bigint unsigned not null comment '用户id',
follow_user_id bigint unsigned not null comment '关联的用户id',
create_time timestamp default CURRENT_TIMESTAMP not null comment '创建时间'
)
collate = utf8mb4_general_ci;
9.2 共同关注
实现共同关注,我们需要首先查看其他人的首页,能查看他人的个人信息和探店笔记。
共同关注功能
当然是使用我们之前学习过的set集合咯,在set集合中,有交集并集补集的api,我们可以把两人的关注的人分别放入到一个set集合中,
然后再通过api去查看这两个set集合中的交集数据。
我们先来改造当前的关注列表,改造原因是因为我们需要在用户关注了某位用户后,需要将数据放入到set集合中,方便后续进行共同关
注,同时当取消关注时,也需要从set集合中进行删除。
核心代码:
public Result followCommons(Long targetUserId) {
// 1. 获取登录用户
Long userId = UserHolder.getUser().getId();
String myUserKey = RedisConstants.FOLLOW_USER_KEY + userId;
String targetUserKey = RedisConstants.FOLLOW_USER_KEY + targetUserId;
// 2. 求交集
Set<String> intersect = stringRedisTemplate.opsForSet().intersect(myUserKey, targetUserKey);
if (intersect == null || intersect.isEmpty()) {
// 无共同关注
return Result.ok(Collections.emptyList());
}
// 3. 解析id集合
List<Long> ids = intersect.stream().map(Long::valueOf).toList();
// 4. 查询用户
List<UserDTO> userDTOList = userMapper.selectBatchIds(ids).stream()
.map(user -> BeanUtil.copyProperties(user, UserDTO.class)).toList();
return Result.ok(userDTOList);
}
9.3 关注推送
9.3.1 Feed流实现方案
当我们关注了用户后,这个用户发了动态,那么我们应该把这些数据推送给用户,这个需求,其实我们又把他叫做Feed流,关注推送也
叫做Feed流,直译为投喂。为用户持续的提供“沉浸式”的体验,通过无限下拉刷新获取新的信息。例如抖音。
对于传统的模式的内容解锁:我们是需要用户去通过搜索引擎或者是其他的方式去解锁想要看的内容
对于新型的Feed流的的效果:不需要我们用户再去推送信息,而是系统分析用户到底想要什么,然后直接把内容推送给用户,从而使用
户能够更加的节约时间,不用主动去寻找。
Feed流产品有两种常见模式:
Timeline:不做内容筛选,简单的按照内容发布时间排序,常用于好友或关注。例如朋友圈。
- 优点:信息全面,不会有缺失。并且实现也相对简单
- 缺点:信息噪音较多,用户不一定感兴趣,内容获取效率低
智能排序:利用智能算法屏蔽掉违规的、用户不感兴趣的内容。推送用户感兴趣信息来吸引用户
- 优点:投喂用户感兴趣信息,用户粘度很高,容易沉迷
- 缺点:如果算法不精准,可能起到反作用
我们本次针对好友的操作,采用的就是Timeline的方式,只需要拿到我们关注用户的信息,然后按照时间排序即可,因此采用Timeline的
模式。该模式的实现方案有三种:
- 拉模式
- 推模式
- 推拉结合
拉模式:也叫做读扩散
该模式的核心含义就是:当张三和李四和王五发了消息后,都会保存在自己的邮箱中,假设赵六要读取信息,那么他会从读取他自己的收
件箱,此时系统会从他关注的人群中,把他关注人的信息全部都进行拉取,然后在进行排序。
优点:比较节约空间,因为赵六在读信息时,并没有重复读取,而且读取完之后可以把他的收件箱进行清楚。
缺点:比较延迟,当用户读取数据时才去关注的人里边去读取数据,假设用户关注了大量的用户,那么此时就会拉取海量的内容,对服务器压力巨大。
推模式:也叫做写扩散。
推模式是没有写邮箱的,当张三写了一个内容,此时会主动的把张三写的内容发送到他的粉丝收件箱中去,假设此时李四再来读取,就不用再去临时拉取了。
优点:时效快,不用临时拉取
缺点:内存压力大,假设一个大V写信息,很多人关注他, 就会写很多分数据到粉丝那边去
推拉结合模式:也叫做读写混合,兼具推和拉两种模式的优点。
推拉模式是一个折中的方案,站在发件人这一段,如果是个普通的人,那么我们采用写扩散的方式,直接把数据写入到他的粉丝中去,因
为普通的人他的粉丝关注量比较小,所以这样做没有压力;如果是大V,那么他是直接将数据先写入到一份到发件箱里边去,然后再直接
写一份到活跃粉丝收件箱里边去。现在站在收件人这端来看,如果是活跃粉丝,那么大V和普通的人发的都会直接写入到自己收件箱里边
来,而如果是普通的粉丝,由于他们上线不是很频繁,所以等他们上线时,再从发件箱里边去拉信息。
三者对比
9.3.2 基于推模式-推送到粉丝收件箱
需求:
- 修改新增探店笔记的业务,在保存blog到数据库的同时,推送到粉丝的收件箱
- 收件箱满足可以根据时间戳排序,必须用Redis的数据结构实现
- 查询收件箱数据时,可以实现分页查询
Feed流中的数据会不断更新,所以数据的角标也在变化,因此不能采用传统的分页模式。
传统了分页在feed流是不适用的,因为我们的数据会随时发生变化
假设在t1 时刻,我们去读取第一页,此时page = 1 ,size = 5 ,那么我们拿到的就是10~6 这几条记录,假设现在t2时候又发布了一条记录,此时t3 时刻,我们来读取第二页,读取第二页传入的参数是page=2 ,size=5 ,那么此时读取到的第二页实际上是从6 开始,然后是6~2 ,那么我们就读取到了重复的数据,所以feed流的分页,不能采用原始方案来做。
Feed流的滚动分页
我们需要记录每次操作的最后一条,然后从这个位置开始去读取数据
举个例子:我们从t1时刻开始,拿第一页数据,拿到了10~6,然后记录下当前最后一次拿取的记录,就是6,t2时刻发布了新的记录,此时这个11放到最顶上,但是不会影响我们之前记录的6,此时t3时刻来拿第二页,第二页这个时候拿数据,还是从6后一点的5去拿,就拿到了5-1的记录。我们这个地方可以采用sortedSet来做,可以进行范围查询,并且还可以记录当前获取数据时间戳最小值,就可以实现滚动分页了。
推送粉丝到redis核心代码:
public Result saveBlog(Blog blog) {
// 1. 获取登录用户
UserDTO user = UserHolder.getUser();
blog.setUserId(user.getId());
// 2. 保存探店博文
boolean isSuccess = this.save(blog);
if (!isSuccess) {
return Result.fail("新增笔记失败!");
}
// 3. 查询作者所有的粉丝 select user_id from tb_follow where follow_user_id = ?
List<Follow> follows = followMapper.selectList(new QueryWrapper<Follow>().eq("follow_user_id", user.getId()).select("user_id"));
// 4. 发送给粉丝
follows.forEach(follow -> {
String key = RedisConstants.FEED_FOLLOW_KEY + follow.getUserId();
stringRedisTemplate.opsForZSet().add(key, blog.getId().toString(), System.currentTimeMillis());
});
// 5. 返回id
return Result.ok(blog.getId());
}
9.3.3 实现分页查询收邮箱
需求:在个人主页的“关注”卡片中,查询并展示推送的Blog信息:
具体操作如下:
1、每次查询完成后,我们要分析出查询出数据的最小时间戳,这个值会作为下一次查询的条件
2、我们需要找到与上一次查询相同的查询个数作为偏移量,下次查询时,跳过这些查询过的数据,拿到我们需要的数据
综上:我们的请求参数中就需要携带 lastId:上一次查询的最小时间戳 和偏移量这两个参数。
这两个参数第一次会由前端来指定,以后的查询就根据后台结果作为条件,再次传递到后台。
核心代码:
public Result queryBlogOfFollow(Long max, Integer offset) {
// 1. 获取当前用户
Long userId = UserHolder.getUser().getId();
// 2. 查询收件箱 ZREVRANGEBYSCORE key Max Min LIMIT offset count
String key = RedisConstants.FEED_FOLLOW_KEY + userId;
Set<ZSetOperations.TypedTuple<String>> typedTuples = stringRedisTemplate.opsForZSet()
.reverseRangeByScoreWithScores(key, 0, max, offset, 2);
if (typedTuples == null || typedTuples.isEmpty()) {
return Result.ok();
}
// 3. 解析数据:blogId、score---minTime(时间戳)、offset
List<Long> ids = new ArrayList<>(typedTuples.size());
long minTime = 0;
int finalOffset = 1;
for (ZSetOperations.TypedTuple<String> typedTuple : typedTuples) {
// 3.1 获取blogId集合
ids.add(Long.valueOf(typedTuple.getValue()));
// 3.2 获取时间戳(分数)
long time = typedTuple.getScore().longValue();
if (minTime == time) {
finalOffset++;
} else {
// 不是最小的 重置
minTime = time;
finalOffset = 1;
}
}
// 4. 根据id查询blog
String idStr = StrUtil.join(",", ids);
// 不能直接in,因为MySQL会进行优化
List<Blog> blogs = this.query().in("id", ids).last("order by field(id," + idStr + ")").list();
blogs.forEach(blog -> {
// 4.1 查询blog有关的用户
this.queryBlogUser(blog);
// 4.2 查询blog是否被点赞
this.isBlogLiked(blog);
});
// 5. 封装并返回
ScrollResult scrollResult = new ScrollResult();
scrollResult.setList(blogs);
scrollResult.setOffset(finalOffset);
scrollResult.setMinTime(minTime);
return Result.ok(scrollResult);
}