业务场景
- 缓存，登录存token等
- 评论点赞
- 排行榜:list，zset
- 好友关系（点赞/共同好友）
- 简单的消息队列（订阅发布/阻塞队列）
- 计数器/限速器（统计播放数据/浏览量/在线人数）
- 分布式锁
1.缓存
验证码处理： 可设计手机号为redis的key,value为验证码的值，并设置过期时间。
登录的设计： 现主流的登录系统用的都是oatuth2协议，比如java的spring security。redis主要就是存个token，前端携带token信息来进行校验是否登录等。token也设置过期时间。
各种缓存： 比如商品缓存，用户信息缓存等。解决缓存穿透，缓存雪崩，缓存击穿。
2.评论点赞设计，阅读数，回复数，收藏数等。
1. hash k1 k2 value
比如对某篇文章点赞，这个文章的id是1 key的设计为article1，article1_group是数据统计key value是一个vo对象包含了各种统计数据。
用户的id是a key的设计为usera。
用户点赞会先进行登录的一波检验。
查询article1:agree这个key中的点赞集合里是否有usera。
存在，点赞数-1，反之+1。（key:article_1_group value:vo）
2. 阅读数，回复数，收藏数等的统计都可以通过这个vo来实现，这时候用的是key value数据结构，也可以拆分成hash形式。
3. 每天可点赞的设计：文章id+用户id设置一个key，并设置0点过期。key的设计：agree_article1_usera。
小结： list结构也可以设计点赞，统计点赞数，看场景是否需要聚合多个数值吧。主要是针对key的设计符合自己的业务需求即可。
3.排行榜、热门推荐
热门是根据浏览量，收藏数，回答数等来综合判断的。更新很频繁用redis较好。
排序效果需要用到zset数据结构，key name score来排序。
key可以设置一个hot_sort固定的key，score为浏览量，点赞数，收藏数的和
name为文章id.
4.好友关系(好友推荐)
假设三个用户的好友关系如下：
user:1:frends [user:2, user:3]
user:2:frends [user:1, user:4, user:5, user:8]
user:3:frends [user:1, user:6, user:7]
向user:1推荐可能认识的人:
- 遍历user:1的好友
- 把user:2 / user:3所有的好友去并集,存储起来 sunionstore tmp user:2 user:3
- 删除自己user:1 srem tmp user:1
- 把user:1已经认识的人删除 sdiffstore tmp tmp user:1:frends
- 随机推荐 srandmember tmp 2
共同好友就是做交集处理，大同小异。
5.简单的消息队列
嗯，没啥用。没mq好用就这么简单。
能做消息队列，但是不好用。list,stream,发布订阅模式等。都有各种问题不好用。（小声哔哔，就是不想写字太多）
6.限流，防止重复提交
限流： key设计用户的ip地址，限制请求数量，时间就好了。
重复提交： 根据前端什么玩意 反正是唯一的一个东西，存到redis中，key就是这个唯一的东西，存在即不可提交。看实际场景，没有这个唯一的东西，协商解决，或者根据用户id啥玩意设置1s内不能重复提交等。
7.分布式锁
这玩意厉害了，只有zookeeper实现的分布式锁可以与之一较高下。
实现方式有多种，简单的如setnx即可实现，稍复杂的用lua脚本，王者级别用redlock实现。也是看公司具体项目是否提供现成的api，没有再看业务场景是否需要，要什么级别即可。(写的话字太多，我比较废)
8.数据初始化
同步mysql数据到redis中。数据初始化字面意思，从头到尾都是新的一个新项目新系统也要做好数据初始化的操作，除非项目开发完，后面再也不维护用不到缓存的功能了，不然数据预热啥的还是要初始化缓存数据的。
9.缓存数据落地(很重要)
写定时方法去实现数据落地，一般定时类，quartz,xxl-job,spring的task都可。 虽然说redis有rdb,aof。甚至实际生产环境还是多主多从的，不怕宕机数据丢失。但是数据落地还是很有必要的，因为内存的资源非常昂贵，不可能无限制的把数据往里面扔，定期的数据落地可以让系统的数据一致性得到保证。其他业务场景需要这些数据的话也方便同步到。
