【Redis篇】【常用应用场景】

一.缓存

热点数据（经常会被查询，但是不经常被修改或者删除的数据），首选是使用redis缓存.
热点数据如果没次都需要查询一次数据库, 当访问量比较大会对数据库造成具大压力,故经常被访问的数据可以查询一次存放入缓存, 每次查询时先查询缓存,如果缓存中存在直接返回.减轻数据库压力

注意事项: 结合具体应用需要注意一下：

Select 数据库前查询redis，有的话使用redis数据，放弃select 数据库，没有的话，select 数据库，然后将数据插入redis
update或者delete数据库钱，查询redis是否存在该数据，存在的话先删除redis中数据，然后再update或者delete数据库中的数据
上面这种操作，如果并发量很小的情况下基本没问题，但是高并发的情况请注意下面场景：

为了update先删掉了redis中的该数据，这时候另一个线程执行查询，发现redis中没有，瞬间执行了查询SQL，并且插入到redis中一条数据，回到刚才那个update语句，这个悲催的线程压根不知道刚才那个该死的select线程犯了一个弥天大错！于是这个redis中的错误数据就永远的存在了下去，直到下一个update或者delete。

建议: 对Redis的数据进行在进行更新时, 更新前与更新后都执行一次删除操作

二. 计数器

利用Redis是原子性操作, 可实现多服务共享某一个数据.

例如: 分布式ID生成、点赞、阅读量统计等场景

三.分布式锁

在分布式架构中, 一个业务ID请求进入服务,我们只需要其中一个服务为期服务时, 或者秒杀系统,只需要一个ID能够获取的商品时. 这个时候可以采用Redis做到仅切只有一个人获得服务权.

String 类型setnx方法，只有不存在时才能添加成功，返回true(抢到锁)

四.限流

当一个用户大量访问页面时候,需要控制访问次数时.
以访问者的ip和其他信息作为key，访问一次增加一次计数，超过次数则返回false

五.分布式跨域session共享

集群模式下，在应用不多的情况下一般使用容器自带的session复制功能就能满足，当应用增多相对复杂的系统中，一般都会搭建以Redis等内存数据库为中心的session服务，session不再由容器管理，而是由session服务及内存数据库管理。

六.最新列表

Redis列表结构，LPUSH可以在列表头部插入一个内容ID作为关键字，LTRIM可用来限制列表的数量，这样列表永远为N个ID，无需查询最新的列表，直接根据ID去到对应的内容页即可。

以上是个人理解常用的场景, 当然Redis还可以做的事情特别多, 在这里就不一一列举了.