序言
2020年12月05日16:43:04 重新更新
本篇帖子的目的主要是为了记录自己在截止目前的项目开发工作中，redis在项目场景中的应用方法。以及一些踩过的坑。也算是做一次复习和回顾了（话说，这段时间怎么能这么冷啊 - -）。总的来说，我这边用到的Redis的地方，主要是分为了4类，包括常规缓存，统计在线人数，限流，使用排它锁来达到续期令牌的目的等。
redis版本：spring-data-redis:2.1.5.RELEASE
项目构建方式：build.gradle
1.常规缓存
一个项目中，总会存在些低频变动的数据。而这些低频变动的数据，就特别适合放在缓存中。采用的策略即是为它们设置一个较长的过期时间（1h，6h，12h，24h，一周等），然后放在缓存中。当数据过期或者是数据库中的数据有更新的时候，再把重新拉取最新数据，并重置缓存。另一方面，这种缓存数据，也能减少不必要的资源消耗（能省一点儿是一点儿咯，毕竟蚊子肉也是肉嘛）。同时，也能提高相关接口的响应速度。
存入缓存时，需要判断当前缓存对应的key是否存在
以账户信息为例
2.在线人数统计
项目中有一个需求是要统计某个直播视频的在线观看人数。我们采用的策略即是，当一个用户进到直播页面的时候，就存入当前用户的登入的时间戳。存时间戳有一个好处是，它们的值会自动递增。相当于每一个人都能有自己的时间标识。然后为其设置过期时间（依据实际情况进行设定，我们设置的是1min）。在统计人数的时候，只要统计1min之内的key值有多少，就能得到具体的人数了。
方法图示 存入key
存入规则
获取统计结果
3.流量限制
这个是通过Redis自身的Increment锁去实现的。原理就是，存入一个key，并为其设定过期时间。在过期时间内，再有其它请求进入时，通过redis的方法判断当前的数量是否超过了限定值。如果没有，则让请求正常的进入到相应的业务处理环节中。反之，如果超过了，则抛出相应的提示说明，阻止当前的请求进入到正常的业务处理逻辑中。
并发场景下，使用Redis的Increment方法来限制请求数
4.生成排它锁，解决线程安全的问题
虽然可以反复地从redis中获取到对象，用来做为是否要继续执行业务逻辑的操作依据。但这样做的一个弊端就是反复的序列化操作，会造成redis资源的无端消耗。所以我们采取了标识过期的思路。即为多个请求要竞争的资源指定一个标识，放入缓存中，同时设定好相应的过期时间。这样，在非过期时间中，只会有一个请求拥有操作资源的资格。从而旧达到了排它的目的。只有等特征标识过期后，下一个请求才能继续进入获取到竞争资源，跟着再去处理别的事项。这就是一种简单的排它锁思路，能有效地解决并发场景下的线程安全的问题。
利用排它锁，实现固定时间内的令牌刷新
