达人探店&好友关注
发布探店笔记
数据表准备
接口准备：上传接口、发布接口
黑马点评的各种图片存储在nginx（本地服务器）目录下，指定好本地路径地址，上传图片的操作就是创建一个新文件
发布笔记
查看探店笔记
在blog类里新增两个字段Name、Icon，用于点击进笔记后，页面也会显示发布笔记的用户
查询成功后返回blog对象，前端根据blog对象渲染即可
点赞探店笔记
需求：
使用Set集合标识该blog点赞过的用户，由于set集合元素不重复，所以如果判断该集合中没有当前用户，点赞数加一即可，如果有当前用户，点赞数减一
修改了点赞功能，在首页查询Blog时就需要每次刷新后确保点赞功能（当前用户点赞了，每次查询都是已点赞），因此需要修改查询功能
点赞接口：
首先需要获取当前用户，然后通过opsForSet来判断当前用户是否在集合中，如果集合不存在，会自动创建该集合，同时由于集合不存在，所以判断结果都为false，进入点赞分支，进行点赞并将当前用户存入set里
修改首页查询接口：实现每次刷新（查询）都是正确的点赞信息
点赞排行榜
接口
选择数据类型：由于排行榜是唯一且有序的，使用SortedSet最为合适
修改点赞接口：之前点赞的实现需要先判断用户是否点赞（即用户是否在set中），但使用sortedset本身并没有sismember这个方法，如何判断用户是否存在sortedset中呢，取score，如果能取到，说明存在，取不到则不存在
修改首页查询接口：首页查询点赞时使用的集合也改为sortedset
正式实现点赞排行榜的功能：
controller
service
首先定义一些常量（代码优雅）
将之前的字符串等换成对应的常量
service实现类
改善：由于查询数据库（listByIds）本质使用的是in查询，会打乱顺序，所以指定排序ORDER BY FIELD ( 5 , 1 )
关注和取关
关注取关接口和查询是否关注接口
需求
controller
service
service实现类
共同关注
查看用户信息接口和查看用户笔记接口
查看用户信息接口
查看用户笔记接口
共同关注接口
修改关注接口：共同关注实际上就是求两个用户关注列表的交集，所以在关注操作时需要把被关注的用户存入集合set里，取消关注则移出集合
具体实现共同关注接口
controller
service
service实现类：先导入userService
关注推送
Feed流概念
用户主动读取：如果关注了超多个博主，主动读取会耗时
用户被动接收别人推送过来的消息：如果粉丝数超多，推送会耗时
推拉结合：对于普通用户的粉丝，采取推模式，对于大V的粉丝，如果是活跃用户则采用推模式，如果是普通用户则采用拉模式
比较
基于推模式实现关注推送
如何选择数据类型：List or SortedSet
传统分页模式按照角标来进行查询，如果新插入数据，每次重新执行分页查询逻辑时会出现重复读取的问题
滚动分页模式，每次根据上次查询接下来的id来分页查询
由于List只支持按角标查询、SortedSet支持按顺序（Sorted）查询（其实也是按角标查询），但也可以按Score值（时间戳）查询（每次根据上次查询接下来的时间戳查询）
修改发布探店笔记接口：在将发布笔记存入数据库的同时把笔记推送到SortedSet集合里，之后用户可以读取集合的内容，由于业务复杂，最好在service层里实现
注入followService
实现滚动分页查询前置知识
前置知识：ZREVANGEBYSCORE 时间最大值（上一次查询的时间最小值） 0（时间最小值） WITHSCORE LIMIMT 从时间最大值接下来的第几个元素开始（0表示第一个） 每页记录条数
第一次的时间最大值取很大的值即可
问题：如果有相同时间值的，则会出现重复，因此从时间最大值接下来的第几个元素开始，这里的第几个应该是重复时间值的元素个数
接口信息
具体实现
封装滚动分页查询返回结果，之所以返回offset，是因为第一次查询之后，以后每一次查询的偏移量都需要根据上次查询到的结果来决定
controller
service
service实现类
先提取成常量
这里min、max按java里的参数列表来，获取到分页查询数据
其中TypedTuple的结构如下
TypedTuple不为空，可以查出blogId（getValue）、minTime（getScore），要返回的offset为在上一次结果中，与最小值一样的元素个数，没有一样的就返回1
最后在推送列表，同样需要查询到blog的发布者、是否点赞等信息
