【小众点评项目】 开发日记 DAY 05 点赞、关注好友和Feed流的实现

1.用户点赞功能

1.1问题分析

在我们数据表tb_blog表中，有一个like字段，用来记录笔记的点赞次数，用户每一次点赞，只需要将like字段的值+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.2 存在的问题

上述方法存在着问题，比如一个用户可以给笔记多次点赞，这肯定不符合逻辑。因此我们需要判断用户是否已经点过赞了，如果点过赞了，那么我们应该不允许再次点赞。

为了判断用户是否已经点过赞了，我们相当了redis中的set数据结构。key是前缀+笔记id，值就是所有点赞用户id组成的set集合。这样一旦用户点赞，我们就可以利用ismember去判断用户是否点过赞了。

具体需求

• 用户点击点赞，如果用户没有点赞，则点赞+1
• 如果用户已经点赞，再次点赞为取消点赞
• 在展示笔记时同时需要展示点赞数和当前用户是否点赞信息

1.3 实现步骤

• 给Blog类添加一个isLiked字段用来记录是否被当前用户点赞。
• 修改点赞功能，利用redis判断用户是否已经点赞
• 根据redis返回的结果来修改数据库like字段。
• 此外还需要在查询blog的同时查询isLike字段。

1.4 代码实现

在Blog 添加一个字段

@TableField(exist = false)
private Boolean isLike;

修改业务代码

@Override
public Result likeBlog(Long id){
// 1.获取登录用户
Long userId = UserHolder.getUser().getId();
// 2.判断当前登录用户是否已经点赞
String key = BLOG_LIKED_KEY + id;
Boolean isMember = stringRedisTemplate.opsForSet().isMember(key, userId.toString());
if(BooleanUtil.isFalse(isMember)){
     //3.如果未点赞，可以点赞
    //3.1 数据库点赞数+1
    boolean isSuccess = update().setSql("liked = liked + 1").eq("id", id).update();
    //3.2 保存用户到Redis的set集合
    if(isSuccess){
        stringRedisTemplate.opsForSet().add(key,userId.toString());
    }
}else{
     //4.如果已点赞，取消点赞
    //4.1 数据库点赞数-1
    boolean isSuccess = update().setSql("liked = liked - 1").eq("id", id).update();
    //4.2 把用户从Redis的set集合移除
    if(isSuccess){
        stringRedisTemplate.opsForSet().remove(key,userId.toString());
    }
}

2.点赞排行榜功能

2.1 问题分析

在笔记的详情页面应该将前5个点赞人的头像显示出来供用户查看，显示的顺序按照用户点赞的时间顺序递增排列。

2.2 解决思路

这里我们有了排序的需求，所以我们应该使用redis中的zset数据结构。因此我们的思路就如下

• 我们需要修改我们之前使用set方式记录用户点赞的方法，将其修改成使用zset实现。同时zset的Score值就是用户点赞时候的时间戳。
• 这样我们就可以根据用户点赞的顺序进行排列。通过zset中的range函数取得前5个点赞的用户id
• 然后根据用户id在数据库中查询用户信息并返回给前端。

2.3 代码实现

将之前的set修改为zset，Score为当前时间戳

stringRedisTemplate.opsForZSet().add(key, userId.toString(), System.currentTimeMi

@Override
public Result queryBlogLikes(Integer id) {
    // TODO 根据笔记ID到Redis中查询前五名的用户id
    Set<String> userSet = stringRedisTemplate.opsForZSet().range(BLOG_LIKE_KEY + id, 0, 4);
    if (userSet == null || userSet.isEmpty()) {
        return Result.ok(Collections.emptyList());
    }
    // TODO 根据用户id查询用户
    List<UserDTO> top5 = new ArrayList<>();
    Long userId = null;
    User user = null;
    UserDTO dto = null;
    for (String s : userSet) {
        userId = Long.valueOf(s);
        user = userService.getById(userId);
        dto = new UserDTO();
        BeanUtil.copyProperties(user, dto);
        top5.add(dto);
    }
    // TODO 封装用户DTO返回
    return Result.ok(top5);
}

3. 关注好友和取消关注好友

3.1 关注和取关好友

一个用户可以关注多个好友，也可以被多个好友关注，显然属于多对多的关系。因此在数据库中建立了一个表用来记录这种关系。tb_follow

3.2 思路

• 前端传递过来要取关或者关注的用户id，取关和关注通过isFollow来判断
• 此外前端还需要判断当前用户是否关注过该用户来判断前端页面上是显示"关注"还是“取消关注”.

3.3 代码实现

FollowController.java

//关注取消关注
@PutMapping("/{id}/{isFollow}") // 这里通过isFollow来判断是关注还是取关 值由前端传递
public Result follow(@PathVariable("id") Long followUserId, @PathVariable("isFollow") Boolean isFollow) {
    return followService.follow(followUserId, isFollow);
}
//判断当前用户是否已经关注该用户
@GetMapping("/or/not/{id}")
public Result isFollow(@PathVariable("id") Long followUserId) {
      return followService.isFollow(followUserId);
}

@Override
public Result isFollow(Long followUserId) {
        // 1.获取登录用户
        Long userId = UserHolder.getUser().getId();
        // 2.查询是否关注 select count(*) from tb_follow where user_id = ? and follow_user_id = ?
        Integer count = query().eq("user_id", userId).eq("follow_user_id", followUserId).count();
        // 3.判断
        return Result.ok(count > 0);
    }


@Override
public Result follow(Long followUserId, Boolean isFollow) {
    // 1.获取登录用户
    Long userId = UserHolder.getUser().getId();
    String key = "follows:" + userId;
    // 1.判断到底是关注还是取关
    if (isFollow) {
        // 2.关注，新增数据
        Follow follow = new Follow();
        follow.setUserId(userId);
        follow.setFollowUserId(followUserId);
        boolean isSuccess = save(follow);

    } else {
        // 3.取关，删除 delete from tb_follow where user_id = ? and follow_user_id = ?
        remove(new QueryWrapper<Follow>()
                .eq("user_id", userId).eq("follow_user_id", followUserId));

    }
    return Result.ok();
}

4. 共同好友功能

4.1 问题分析

查找共同好友的功能的本质是找当前用户和她关注用户的好友列表的交集。有两种实现方式，一种是通过redis，另一种是通过map。当前也可以通过多层遍历的方式，不过那样效率就太低了。

4.2 思路

4.2.1 使用Map的方式

• 首先从数据库中查询出当前用户和目标用户的关注列表，得到两个集合。
• 然后创建一个Map，利用循环遍历方式将集合1中所有的元素作为key存入到map中。
• 然后循环遍历集合2，以集合2中保存的用户id作为key从map中取数据，如果能取到，则为共同好友。

4.2.2 使用redis方式

Redis的set数据类型中已经给我们提供好了求两个set集合交集的函数，可以直接利用。

• 我们在redis中创建set集合，以前缀+用户id为key，值为该用户关注的所有用户的id。
• 在用户点击关注某一个好友的时候，就将这个数据写入到redis中。
• 那么我们在获取共同关注的时候只需要拿到当前用户id和好友id，然后查询交集就可以了。

4.3 代码实现

修改之前关注和取关的业务代码

@Override
public Result follow(Long followUserId, Boolean isFollow) {
    // 1.获取登录用户
    Long userId = UserHolder.getUser().getId();
    String key = "follows:" + userId;
    // 1.判断到底是关注还是取关
    if (isFollow) {
        // 2.关注，新增数据
        Follow follow = new Follow();
        follow.setUserId(userId);
        follow.setFollowUserId(followUserId);
        boolean isSuccess = save(follow);
        if (isSuccess) {
            // 把关注用户的id，放入redis的set集合 sadd userId followerUserId
            stringRedisTemplate.opsForSet().add(key, followUserId.toString());
        }
    } else {
        // 3.取关，删除 delete from tb_follow where user_id = ? and follow_user_id = ?
        boolean isSuccess = remove(new QueryWrapper<Follow>()
                .eq("user_id", userId).eq("follow_user_id", followUserId));
        if (isSuccess) {
            // 把关注用户的id从Redis集合中移除
            stringRedisTemplate.opsForSet().remove(key, followUserId.toString());
        }
    }
    return Result.ok();
}

求共同好友的业务代码

@Override
public Result followCommons(Long id) {
    // 1.获取当前用户
    Long userId = UserHolder.getUser().getId();
    String key = "follows:" + userId;
    // 2.求交集
    String key2 = "follows:" + id;
    Set<String> intersect = stringRedisTemplate.opsForSet().intersect(key, key2);
    if (intersect == null || intersect.isEmpty()) {
        // 无交集
        return Result.ok(Collections.emptyList());
    }
    // 3.解析id集合
    List<Long> ids = intersect.stream().map(Long::valueOf).collect(Collectors.toList());
    // 4.查询用户
    List<UserDTO> users = userService.listByIds(ids)
            .stream()
            .map(user -> BeanUtil.copyProperties(user, UserDTO.class))
            .collect(Collectors.toList());
    return Result.ok(users);
}

5.使用Feed流实现好友动态的推送

5.1 什么是feed流

当我们关注了用户后，这个用户发了动态，那么我们应该把这些数据推送给用户，这个需求，其实我们又把他叫做Feed流，关注推送也叫做Feed流，直译为投喂。为用户持续的提供“沉浸式”的体验，通过无限下拉刷新获取新的信息。
对于传统的模式的内容解锁：我们是需要用户去通过搜索引擎或者是其他的方式去解锁想要看的内容

对于新型的Feed流的的效果：不需要我们用户再去推送信息，而是系统分析用户到底想要什么，然后直接把内容推送给用户，从而使用户能够更加的节约时间，不用主动去寻找。

Feed流的实现有两种模式：
Feed流产品有两种常见模式：Timeline：不做内容筛选，简单的按照内容发布时间排序，常用于好友或关注。例如朋友圈

• 优点：信息全面，不会有缺失。并且实现也相对简单
• 缺点：信息噪音较多，用户不一定感兴趣，内容获取效率低

智能排序：利用智能算法屏蔽掉违规的、用户不感兴趣的内容。推送用户感兴趣信息来吸引用户

• 优点：投喂用户感兴趣信息，用户粘度很高，容易沉迷
• 缺点：如果算法不精准，可能起到反作用

本项目中我们采用的方式是Timeline方式。

5.2 实现Timeline的三种方式

实现Timeline的方式有三种

• 拉模式，也叫做读扩散。当张三和李四和王五发了消息后，都会保存在自己的邮箱中，假设赵六要读取信息，那么他会从读取他自己的收件箱，此时系统会从他关注的人群中，把他关注人的信息全部都进行拉取，然后在进行排序

优点：比较节约空间，因为赵六在读信息时，并没有重复读取，而且读取完之后可以把他的收件箱进行清楚。
缺点：比较延迟，当用户读取数据时才去关注的人里边去读取数据，假设用户关注了大量的用户，那么此时就会拉取海量的内容，对服务器压力巨大。

• 推模式，也叫做写扩散。推模式是没有写邮箱的，当张三写了一个内容，此时会主动的把张三写的内容发送到他的粉丝收件箱中去，假设此时李四再来读取，就不用再去临时拉取了。

优点：时效快，不用临时拉取
缺点：内存压力大，假设一个大V写信息，很多人关注他， 就会写很多分数据到粉丝那边去

• 推拉结合模式：也叫做读写混合，兼具推和拉两种模式的优点。推拉模式是一个折中的方案。
  • 站在发件人这一段，如果是个普通的人，那么我们采用写扩散的方式，直接把数据写入到他的粉丝中去，因为普通的人他的粉丝关注量比较小，所以这样做没有压力
  • 如果是大V，那么他是直接将数据先写入到一份到发件箱里边去，然后再直接写一份到活跃粉丝收件箱里边去
  • 现在站在收件人这端来看，如果是活跃粉丝，那么大V和普通的人发的都会直接写入到自己收件箱里边来，而如果是普通的粉丝，由于他们上线不是很频繁，所以等他们上线时，再从发件箱里边去拉信息。
    
    本项目中采取的方式是推模式

5.3 实现将用户动态推送到粉丝收件箱

5.3.1 需求分析

在用户发布动态的时候需要同步的将博文的id推送到他的粉丝的收件箱中。删除，修改博文时不需要推送，因为修改的话博文ID不会发生变化，而删除的话如果我们查不到就直接返回一个空。
因为需要排序，因此我们借助redis中的zset实现。博文id应该按照其发布顺序排列，因此我们将score设置为时间戳。

5.3.2 代码实现

在saveBlog方法中新增发送博文ID到分析信箱代码

@Override
@Transactional
public Result saveBlog(Blog blog) {
    // 获取登录用户
    UserDTO user = UserHolder.getUser();
    blog.setUserId(user.getId());
    // 保存探店博文
    boolean isSuccess = this.save(blog);
    if (isSuccess) {
        // 如果成功 则将博文ID推送到当前用户粉丝的收件箱中
        // 获取当前用户的所有粉丝
        List<Follow> follows = followService.query().eq("user_id", user.getId()).list();
        long time = System.currentTimeMillis();
        // 将消息推送到粉丝收件箱
        for (Follow follow : follows) {
            stringRedisTemplate.opsForZSet().add(FEED_MESSAGEBOX_KEY + follow.getFollowUserId(), blog.getId().toString(), time);
        }
    }
    // 返回id
    return Result.ok(blog.getId());
}

5.4 实现粉丝查看信箱并分页显示的功能

5.4.1.需求分析

当用户在个人主页页面点击关注的时候，应该显示该用户关注的博主发送的博文信息，并分页展示出来

5.4.2 分页查询的难点

传统的分页查询一般通过下标即可实现。但是在feed流中，使用下标会产生问题。原因是因为feed流中的数据是不断变化的，这就会导致消息的下标也是变化的，使用传统的分页方式就会造成数据的重读。下面通过一个例子说明

• 假设在t1 时刻，我们去读取第一页，此时page = 1 ，size = 5 ，那么我们拿到的就是10~6 这几条记录
• 假设现在t2时候又发布了一条记录
• 此时t3 时刻，我们来读取第二页，读取第二页传入的参数是page=2 ，size=5 ，那么此时读取到的第二页实际上是从6 开始，然后是6~2 ，那么我们就读取到了重复的数据，所以feed流的分页，不能采用原始方案来做。

为了解决这一问题，我们在用滚动分页的方式。我们需要记录每次操作的最后一条，然后从这个位置开始去读取数据

我们始终从lastId的下一个元素作为下次分页的开始坐标，查询size条消息。

举个例子：我们从t1时刻开始，拿第一页数据，拿到了10~6，然后记录下当前最后一次拿取的记录，就是6，t2时刻发布了新的记录，此时这个11放到最顶上，但是不会影响我们之前记录的6，此时t3时刻来拿第二页，第二页这个时候拿数据，还是从6后一点的5去拿，就拿到了5-1的记录。我们这个地方可以采用sortedSet来做，可以进行范围查询，并且还可以记录当前获取数据时间戳最小值，就可以实现滚动分页了。

此外，我们还需要考虑时间戳相同的情况。虽然概率很小。
举个例子：假设现在有5条数据，时间戳分别是 5 5 5 5 4 3 3 2 ，pageSize是2

• 第一次查询 5 5 lastId = 5 size = 2
• 第二次查询 4 3 lastId = 4 size = 2

显然发生了漏读，因此针对这种情况，我们还需要设置一个偏移量，它的值就是本次查询中最小的时间戳出现的次数。

• 第一次查询 5 5 lastId = 5 size = 2 offset = 2 因为查询结果 5 5 里面最小的时间戳就是5 出现了2次
• 第二次查询，从第1个5开始(包含第一个5)往后走offset个位置的下一个位置就是本次分页的起始位置。
  引入了offset以后，就解决了滚动分页查询中时间戳相同导致出漏读问题。

5.4.3 代码实现

分析完流程以后，代码实现相对简单。
因为本次返回的对象不止是blog对象，还有lastId和offset，因此我们定义了一个类来封装返回结果。

@Data
public class ScrollResult {
    private List<?> list;
    private Long minTime;
    private Integer offset;
}

@Override
public Result queryBlogOfFollow(Long max, Integer offset) {
    // TODO 获取当前用户 只有登录才能进入到个人主页查看关注博文 所以这里一定登陆了
    Long userId = UserHolder.getUser().getId();
    String key = FEED_MESSAGEBOX_KEY + userId;
    // TODO 获取当前用户的信箱    ZREVRANGEBYSCORE key名称 最大分数 最小分数 偏移量 取元素的个数
    Set<ZSetOperations.TypedTuple<String>> typedTuples = stringRedisTemplate.opsForZSet().reverseRangeByScoreWithScores(key, 0, max, offset, 3);
    // TODO 判断是否信箱为空
    if (typedTuples == null || typedTuples.isEmpty()) {
        return Result.ok();
    }
    // TODO 如果不为空 则解析信箱数据 并计算出下一次的max和offset
    List<Long> blogIdList = new ArrayList<>(typedTuples.size());
    Long minTimeStamp = 0L;
    int os = 1; // 记录offset
    for (ZSetOperations.TypedTuple<String> typedTuple : typedTuples) {
        blogIdList.add(Long.valueOf(typedTuple.getValue()));
        // 循环结束记录的正好是最后一条博文的时间戳，最后一条博文的时间戳就是最小的时间戳
        // 5 5 4 3
        long timeStamp = typedTuple.getScore().longValue();
        if (minTimeStamp == timeStamp) {
            os++;
        } else {
            minTimeStamp = timeStamp;
            os = 1;
        }
    }
    // TODO 根据博文ID查询博文 和相关的用户信息和点赞信息
    String idsStr = StrUtil.join(",", blogIdList);
    List<Blog> blogList = super.query().in("id", blogIdList).last("order by field(id, " + idsStr + ")").list();
    // 查询作者和点赞信息
    for (Blog blog : blogList) {
        this.queryBlogUser(blog);
        this.isBlogLiked(blog);
    }

    // TODO 封装返回对象
    ScrollResult r = new ScrollResult();
    r.setList(blogList);
    r.setOffset(os);
    r.setMinTime(minTimeStamp);

    return Result.ok(r);
}

关于这个滚动分页中的reverseRangeByScoreWithScores(key, 0, max, offset, 3);代码的解释

• ZREVRANGEBYSCORE key名称 最大分数 最小分数 偏移量 取元素的个数
• 0是最小值，也就是发布最早的动态，max记录的是上一次分页查询时查询到的最后的一条动态
• 因此下面的redis命令实际上的意思就是，从max开始往后查(查询比max时间戳更早的博文)，查询范围是(0, max)
• (0, max) 表示的就是还没有查询到的博文,
• offset 是在max的基础上向后再跳过几条记录，主要的目的是防止有多个时间戳一样的记录，假设有3个时间戳为1的，而上一次查询到第一个时间戳为1的
• 那么如果不加offset的话，那么这几条就露了，
• 最后一个参数3就是pageSize，一次取三条记录