Redis除了简单的存储key-value还能用来干什么?
先从一张思维导图开始
1.登陆鉴权
用户登录鉴权，以及对应的登录验证码或token到期失效，是系统最为常见的功能之一。而Redis key的超时失效功能，则非常适合于这种业务场景。
具体实现场景：
- 系统登录场景，用户输入手机号后，点击发送短信验证码，通过Redis存储前缀 + 手机号作为key，验证码作为value，并设置60秒过期时间。
- 用户在60秒内进行登录验证，则可以从Redis中获取到验证码，验证相同则登录成功，超过60秒则获取不到验证码值，登录失败。
- 用户登录后生成token，Redis存储前缀 + token作为key，用户信息作为value，并设置过期时间。
- 接下来可以通过token进行鉴权，并获取对应的用户信息。
2.分布式锁
主流的分布式锁解决方案是通过Redisson来实现的，相比于上述方案，Redisson解决了锁的可重入和续期问题。
3.用户签到统计
用户签到、用户出勤场景，虽然我们用Redis Set数据结构也可以实现，但用户量级庞大的情况下，会极大占用内存空间。
这种情况下，非常适合Redis BitMap数据结构，通过其bit位来进行状态存储。
我们可以把 年和月 作为BitMap的key ，然后保存到一个BitMap中 ，每次签到就到对应的位上把数字从0 变为1，只要是1，就代表是这一天签到了，反之就是没有签到。
-
还可以统计连续签到天数
从最后一次签到开始向前统计，直到遇到第一次未签到为止，计算总的签到次数，就是连续签到天数。
-
如何从后向前遍历每个Bit位
注意：bitMap返回的数据是10进制，哪假如说返回一个数字8，那么我哪儿知道到底哪些是0，哪些是1呢？
我们只需要让得到的10进制数字和1做与运算就可以了，因为1只有遇见1 才是1，其他数字都是0 ，我们把签到结果和1进行与操作，每与一次，就把签到结果向右移动一位，依次内推，我们就能完成逐个遍历的效果了。
-
统计本月到今天为止的所有签到数据
假设今天是7号，那么我们就可以从当前月的第一天开始，获得到当前这一天的位数，是7号，那么就是7位，去拿这段时间的数据，就能拿到所有的数据了，那么这7天里边签到了多少次呢？统计有多少个1即可。
iniBITCOUNT key [start end)注意左闭右开，如果你有一个名为user_activity的bitmap，它记录了用户在某段时间内的活跃状态，并且你想统计第100到200个比特位（包含第100和第200位）中有多少个位是1，你可以这样操作
iniBITCOUNT user_activity 99 200
4.排行榜
Zset（SortedSet），是Set的可排序版，是通过增加一个排序属性score来实现的，适用于排行榜和时间线之类的业务场景，且在高并发场景下具备非常优秀的性能。
5.网站UV统计
假设如下场景，某大型网站需要统计每个网页每天的UV（Unique Visitor）数据，与PV（Page View）的不同点在于，UV需要进行去重操作，同一个用户一天内的多次访问一个网页，只能计数一次。
你可以通过 set 集合、bitmap 这类常用工具，但有个最大的缺点是，如果数据量巨大，比如 1 亿，甚至 10 亿将耗费巨大内存消耗。
Redis HyperLogLog 的数据结构是一种用来进行基数统计（即估算唯一元素数量）的高效算法。它能够在占用极小内存空间的情况下（通常几百字节），精确地估算出一个集合中不重复元素的数量，误差率在0.81%左右。但仅仅占用12k的内存空间，非常适用于大型网站UV统计这种空间消耗巨大，但数据不需要特别精确的业务场景。
-
不要将HyperLogLog和set集合弄混
set集合是将去重的元素放到value里面，HyperLogLog是通过散列哈希等算法判断一个元素是否已经添加过，如果添加过了就将这个HyperLogLog的key的值+1，HyperLogLog是不会保存到底是哪个元素的，只保存数字
为什么会有误差呢？可以参考一下布隆过滤器，布隆有Redis不一定有，布隆没有Redis一定没有，此处不再赘述
6.计数器(点赞数...)
计数器是一种非常常见的业务场景，类似于掘金的文章点赞、收藏等。
7.文章收藏 粉丝关注
都是通过Redis的Set集合实现的，文章收藏等不再赘述了，主要讲讲粉丝关注这类涉及到社交的
为什么使用Redis的Set集合实现粉丝关注？因为Set提供了求交集、求并集等一系列直接操作集合的方法，非常适合于求共同或单方好友、粉丝、爱好之类的业务场景，实现起来特别方便。
8.接口幂等(防止订单重复提交)
接口幂等 : 用户在极短时间内，频繁发起请求去调用系统中的某个接口，该情况下我们需要对其进行限制
举例如下：我们限制用户每秒钟只能下单一次，若用户在一秒钟内连续三次下单，这时只有第一个下单是成功的，其他两个我们会通过Redis的过期时间机制，对其进行限制。
