Redis适合的场景
Redis适合的场景
一、【进程内】缓存和【进程外】缓存
- 【进程内】缓存：就是把数据缓存在服务的进程内，就是进程内缓存，通常进程内缓存的实现载体，简单的可以是一个map，list。
- 【进程外】缓存：进程外缓存，最常见的，redis/memcache
二、二者的区别
7-进程内-外缓存.jpg
如图所示，
- 进程外缓存，整个访问流程要经过1，2，3，4四个步骤。
- 进程内缓存，整个访问流程只需要1，2两个步骤即可。
两者相比
- 进程内缓存省去了网络开销，所以依赖节省了内网带宽，二来响应时延会更低。
- 进程内缓存，虽然节省了网络开销，但是数据存了多份，一致性比较难保障。
- 进程外缓存，虽然多一次网络交互，但是统一存储。
所以选用Redis，也不能乱用，需要分析具体的情况，具体分析。
下面介绍一下 redis 适合场景。
三、场景分析
A、进程内缓存：
==场景一==：<font color="red">只读数据</font>，在启动服务的时候，初始化加载到内存。（当然使用redis，也可以）
==场景二==：<font color="red">极其高并发</font>的，如果透传后端压力极大的场景。例如：高并发的交易，秒杀，需要服务层控制流量的。
==场景三==：一定程度上，允许<font color="red">数据不一致</font>业务。
B、进程外缓存：
==场景一==：缓存<font color="red">热数据</font>，进程会被反复使用。
==场景二==：<font color="red">计数器</font>，诸如统计点击等应用，由于单线程，可以避免并发问题，保证不会出错，而且100%毫秒级别性能，命令：INCRBY。
==场景三==：<font color="red">队列</font>，相当于消息系统，XNETD、MQ类似的使用方式，但是简单的使用可以，如果数据一致性要求较高的系统，还是使用XNETD、MQ等专业的系统。
==场景四==：<font color="red">位操作</font>（大数据处理）用于数据量上亿的场景下，例如几亿用户系统的签到，去重复登陆次数统计，某用户是否在线状态等。
举例，想一下， 腾讯10亿用户，要几个毫秒内，查询到某个用户是否在线，你怎么做？千万别说给每一个用户，创建一个key，然后挨个记，这是一个非常可怕的事情，这里要用到位操作【setbit，getbit，bitcount】
原理：redis内构建一个足够长的数组，每个数组元素只能是0和1两个值，然后这个数组的下标index用来表示用户的id（qq号，必须是数字），那么很显然，这个记忆长的大数组，就能通过下标和元素值（0和1）来构建一个记忆系统。
ITS中，委托和估值系统，想要快速横向扩展，可以考虑这个模式。
==场景五==：<font color="red">幂等</font>将请求唯一流水号，参数、接口等hash作为key存储到redis，然后每次请求，去查询，是否有一致的情况，如果有更具业务要求，返回，如弹出“交易已成交，请刷新”，弹出之前的返回结果等。
==场景六==：<font color="red">秒杀系统</font>，基于
redis是单线程特征，防止出现数据库压爆的场景。
==场景七==：<font color="red">优化查询列表</font>，将需要返回的list，都放入redis，下一次用户查询，无需去数据库 分页，直接从redis获取list即可。
==场景八==：<font color="red">全页面缓存</font>，如果你想使用的是服务器端内容渲染，你又不想为每个请求重新渲染每个页面，可以使用Redis把常被请求的内容缓存起来，能够大大的降低页面请求的延迟，已经有很多框架缓存页面，这就是页面静态化的一种方式。
// Set the page that will last 1 minute SET key "<html>...</html>" EX 60 // Get the page GET key
==场景九==：<font color="red">排行榜</font>，Redis基于内存，可以快速高效的处理增加和减少的操作，相比于使用SQL请求的处理方式，性能的提升是非常巨大的。Redis的有序集合可以轻松实现“从一个大型列表中取得排名最高的N个元素”，毫秒级，而且非常简单。
==场景十==：<font color="red">Session 存储</font>，这可能是应用的最广的点了，相比较于类似memcache 的session存储，redis具有缓存数据持久化的功能，当缓存因为出现问题而重启后，之前的缓存数据还在那里，这个就比较实用，避免因为session突然消失带来的用户体验问题。
四、注意点
==A、千万不要吧redis当作数据库用：==
- redis的定期快照，不能保证数据不丢失。
- redis的AOF回降低效率，并且不能支持太大的数据量。
不要期望redis做固化存储比mysql做的好，不同的工具做各自擅长的事情，把redis当作数据用，这样的设计八成是错误的。
==B、做好“雪崩”的预防措施==
- “雪崩”的意思：程序逻辑，查询redis，如果没有，查询DB，当在高并发的情况下，出现redis宕机的情况，导致所有都去数据库，虽然redis自动恢复了，但是数据库已经被压垮了。
- 解决方案推荐：redis高可用的架构模式。
