-
点赞功能
-
数据库
- 这里是针对每一个点赞部分设置key，由于点赞有针对帖子和评论两种，所以加上一个type，然后组合在一起：::type:id。但是这只是redis中的key，我除了知道总共赞有多少个外，我还得知道这个赞有谁点了，因此设置set，存储用户id
- 还需要得到每个用户的点赞总和，那么这个存储的是Value，因此可以自增和自减
-
处理逻辑
- 用户点击一次点赞，再点一次表示取消。也就是读取redis，如果存在对应的key则移除对应的id，反之则添加、
-
-
关注功能
-
数据库
-
用户关注的可能不止是用户，还有文章之类的。因此需要标注，type,entityid,userid。其次对于关注者还得知道它关注了什么，数量多少，被关注实体还得知道谁关注了它
- 举例：type=2代表用户，用户201如何知道它有多少个关注者，redis的key为followers:2:201，存的值为301,时间（使用有序集合，为什么不用hashmap，因为不可以按照时间排序）
- 举例：想要知道用户101关注了谁，数量多少，redis的key：followees:201:2，存的值也是id+时间（followers和followees很重要，避免重合分不清是关注者还是被关注者）
-
-
处理逻辑
- 显示关注列表：需要按页显示，关键用到.opsForZSet().reverseRange(followerKey, offset, offset + limit - 1)
-
-
优化登录模块
-
设置redis存储验证码
-
最简单的验证码设置
-
准备工作
- 配置类
- 不用session，因为存储在服务器中，如果session的key是固定的，那么不适合支持多个用户。存储在cookie中，则是存储在客户端浏览器中。那为什么要用redis呢？因为cookie存储的仅仅是验证码的一个标识id，真正是要value值，四个字母存储在redis中
-
-
-
redis登录凭证+用户信息
- 厉害在于，它这里仅仅是修改了service层的信息，没有动controller
- 凭证是为了防止用户每次都要重新登录，比如100天保存，这样还可以用于记录用户第一次登录的时间，用于累计登录签到（前提是凭证不能删除，而是要用status=0）。这里同时存储在cookie中，也有对应的key
- redis中存储的String类型，可以存储Java对象，过程是转为json，json还可以转为Java对象
- 针对所有的对于用户信息的修改，都是要删除redis对应的值，因为会简便，但是在访问时如果没有会自动添加
