Redis适合的场景-CSDN博客

Redis适合的场景

一、【进程内】缓存和【进程外】缓存

【进程内】缓存：就是把数据缓存在服务的进程内，就是进程内缓存，通常进程内缓存的实现载体，简单的可以是一个map，list。
【进程外】缓存：进程外缓存，最常见的，redis/memcache

二、二者的区别

img_3d872d9ad85597846c0f1442b329af76.jpe

7-进程内-外缓存.jpg

如图所示，

进程外缓存，整个访问流程要经过1，2，3，4四个步骤。
进程内缓存，整个访问流程只需要1，2两个步骤即可。

两者相比

进程内缓存省去了网络开销，所以依赖节省了内网带宽，二来响应时延会更低。
进程内缓存，虽然节省了网络开销，但是数据存了多份，一致性比较难保障。
进程外缓存，虽然多一次网络交互，但是统一存储。

所以选用Redis，也不能乱用，需要分析具体的情况，具体分析。

下面介绍一下 redis 适合场景。

三、场景分析

A、进程内缓存：

==场景一==：只读数据，在启动服务的时候，初始化加载到内存。（当然使用redis，也可以）

==场景二==：极其高并发的，如果透传后端压力极大的场景。例如：高并发的交易，秒杀，需要服务层控制流量的。

==场景三==：一定程度上，允许数据不一致业务。

B、进程外缓存：

==场景一==：缓存热数据，进程会被反复使用。

==场景二==：计数器，诸如统计点击等应用，由于单线程，可以避免并发问题，保证不会出错，而且100%毫秒级别性能，命令：INCRBY。

==场景三==：队列，相当于消息系统，XNETD、MQ类似的使用方式，但是简单的使用可以，如果数据一致性要求较高的系统，还是使用XNETD、MQ等专业的系统。

==场景四==：位操作（大数据处理）用于数据量上亿的场景下，例如几亿用户系统的签到，去重复登陆次数统计，某用户是否在线状态等。
举例，想一下，腾讯10亿用户，要几个毫秒内，查询到某个用户是否在线，你怎么做？千万别说给每一个用户，创建一个key，然后挨个记，这是一个非常可怕的事情，这里要用到位操作【setbit，getbit，bitcount】
原理：redis内构建一个足够长的数组，每个数组元素只能是0和1两个值，然后这个数组的下标index用来表示用户的id（qq号，必须是数字），那么很显然，这个记忆长的大数组，就能通过下标和元素值（0和1）来构建一个记忆系统。
ITS中，委托和估值系统，想要快速横向扩展，可以考虑这个模式。

==场景五==：幂等将请求唯一流水号，参数、接口等hash作为key存储到redis，然后每次请求，去查询，是否有一致的情况，如果有更具业务要求，返回，如弹出“交易已成交，请刷新”，弹出之前的返回结果等。

==场景六==：秒杀系统，基于
redis是单线程特征，防止出现数据库压爆的场景。

==场景七==：优化查询列表，将需要返回的list，都放入redis，下一次用户查询，无需去数据库分页，直接从redis获取list即可。

==场景八==：全页面缓存，如果你想使用的是服务器端内容渲染，你又不想为每个请求重新渲染每个页面，可以使用Redis把常被请求的内容缓存起来，能够大大的降低页面请求的延迟，已经有很多框架缓存页面，这就是页面静态化的一种方式。
// Set the page that will last 1 minute SET key "<html>...</html>" EX 60 // Get the page GET key

==场景九==：排行榜，Redis基于内存，可以快速高效的处理增加和减少的操作，相比于使用SQL请求的处理方式，性能的提升是非常巨大的。Redis的有序集合可以轻松实现“从一个大型列表中取得排名最高的N个元素”，毫秒级，而且非常简单。

==场景十==：Session 存储，这可能是应用的最广的点了，相比较于类似memcache 的session存储，redis具有缓存数据持久化的功能，当缓存因为出现问题而重启后，之前的缓存数据还在那里，这个就比较实用，避免因为session突然消失带来的用户体验问题。