Redis常见问题

1.为什么使用Redis

分析：在项目汇总使用redis，主要是从两个角度去考虑：性能和并发，这是当前互联网发展过程中首要考虑的两个重难题。当然除去这两个要点之外，redis还具备可以做分布式锁等其他功能，但是只是为了分布式锁这些其他功能，完全还有其他中间件（如zookeeper等）代替，并不是非要使用redis。Redis还易于扩展、支持丰富的数据类型存储。
（1）性能
如下图所示，我们在碰到需要执行耗时特别久，且结果不频繁变动的SQL，就特别适合将运行结果放入缓存。这样，后面的请求就去缓存中读取，因为Redis是基于内存级别的缓存，这样使得请求能够迅速从缓存中得到响应。相比传统请求数据库，响应速度大幅度提高。

题外话：忽然想聊一下这个迅速响应的标准。其实根据交互效果的不同，这个响应时间没有固定标准。不过曾经有人这么告诉我:"在理想状态下，我们的页面跳转需要在瞬间解决，对于页内操作则需要在刹那间解决。另外，超过一弹指的耗时操作要有进度提示，并且可以随时中止或取消，这样才能给用户最好的体验。"那么瞬间、刹那、一弹指具体是多少时间呢？
根据《摩诃僧祗律》记载
一刹那者为一念，二十念为一瞬，二十瞬为一弹指，二十弹指为一罗预，二十罗预为一须臾，一日一夜有三十须臾。
那么，经过周密的计算，一瞬间为0.36 秒,一刹那有 0.018 秒.一弹指长达 7.2 秒。

（2）并发
如下图所示，在大并发的情况下，所有的请求直接访问数据库，数据库会出现连接异常。这个时候，就需要使用redis做一个缓冲操作，并且Redis支持高性能的主从复制的集群策略，这样大大提高满足高并发访问及快速响应。请求优先访问到redis请求数据，从而避免高并发情况下直接访问数据库。

2.Redis 都有哪些应用场景

缓存：Redis最主要的功能，也是大型网站必备机制，合理地使用缓存不仅可以加快数据的访问速度，而且能够有效的降低后端数据源的压力

共享session：对于一些依赖session功能的服务来说，如果需要从单机变成集群的话，可以选择redis来统一管理session

消息队列系统：消息队列系统可以说是一个大型网站的必备基础组件，因为其具有业务 解耦、非实时业务削峰等特性。Redis提供了发布订阅功能和阻塞队列的功能，虽然和专业的消息队列对比还不够足够强大，但是对于一般的消息队列功能基本可以满足。比如在分布式爬虫系统中，使用redis来统一管理url队列

分布式锁：在分布式服务中。可以利用redis的setnx功能来编写分布式的锁，虽然这个可能不是太常用

当然还有诸如排行榜、点赞功能都可以使用Redis来实现，但是Redis也不是什么都可以做，比如数据量特别大时，不适合Redis，我们知道Redis是基于内存的，虽然内存很便宜，但是如果每天的数据量特别大，比如几亿条的用户行为日志数据，用redis来存储的话，成本相当的高。

3.单线程的Redis为什么这么快

Redis有多快？官方给出的答案是读写速度10万/秒，这个数字不让人意外，但是Redis是单线程的。为什么单线程的Redis速度这么快？原因有以下三点：
纯内存操作：Redis是安全基于内存的，所以读写效率非常的高，当然Redis存在持久化操作，但持久化操作都是fork子进程和利用Linux系统的页缓存技术来完成，并不会影响Redis的性能

单线程操作：单线程并不是坏事，单线程可以避免了频繁的上下文切换，频繁的上下文切换也会影响性能

合理高效的数据结构
采用了非阻塞I/O多路复用机制：多路I/O复用模型是利用select、poll、epoll可以同时监察多个流的I/O事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有I/O事件时，就从阻塞态中唤醒，于是只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。

4.说说Redis的数据结构及使用场景

Redis提供了5种数据结构，每一种数据结构有各种的使用场景
1.String 字符串
字符串类型是Redis最基础的数据结构，首先键都是字符串类型，而且其他几种数据结构都是字符串类型基础上构建的，我们常使用的set/get key value命令就是字符串。常用在缓存、计数、共享session、限速等。

2.Hash 哈希
在Redis中，哈希类型是指键值本身又是一个键值对结构，形如value={{field1, value1},…{fieldN, valueN}}，这里value存放的是结构化的对象，比较方便的就是操作其中某个字段，添加命令：hset key field value。哈希可以用来存放用户信息，比如实现购物车，还可以做单点登录，就是用这种数据结构存储用户信息，以cookieId作为key，设置30分钟为缓存过期时间，能很好的模拟出类似session的效果。

3.List列表
列表（list）类型是用来存储多个有序的字符串。可以做简单的消息队列的功能，例如限时抢购、秒杀等记录商品数量变化。另外，可以利用lrange命令，做基于redis的分页功能，性能极佳，用户体验好。

4.set集合
集合（set）类型也是用来保存多个的字符串元素，但和列表类型不一样的是，集合不允许有重复的元素，并且集合中的元素是无序的，不能通过索引下标获取元素。利用Set的交集、并集、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好等功能。

5.Sorted set 有序集合
Sorted set多了一个权重参数Score，集合中的元素能够按Score进行排序。可以做排行榜应用，取TOP N操作。另外sorted set可以用来做延时任务、范围查找。

5. Redis的数据过期策略

Redis中数据过期策略采用定期删除+惰性删除策略
1.定期删除、惰性删除策略是什么？
定期删除策略：Redis启用一个定时器定时器定时监视所有的key，判断key是否过期，过期的话就删除。这种策略可以保证过期的key最终都会被删除，但是也存在严重的缺点：每次都遍历内存中所有的数据，非常消耗CPU资源，并且当key已过期，但是定时器还处于未唤起状态，这段时间内key仍然可用
惰性删除策略：在获取key时，先判断key是否过期，如果过期则删除。这种方式存在一个缺点：如果这个key一直未被使用，那么它一直在内存中，其实它已经过期了，会浪费大量的空间。

2.定期删除+惰性删除策略是如何工作的
这两张策略天然的互补，结合起来之后，定时删除策略就发生了一些改变，不在是每次扫描全部的key了，而是随机抽取一部分key进行检查，这样就降低了对CPU资源的消耗，惰性删除策略互补了未检查到的key基本上满足了所有要求。但是有时候就是这么的巧，既没有被定时器抽取到，有没有被使用，这些数据如何从内存中消失？没关系，还有内存淘汰机制，当内存不够用时，内存淘汰机制就会上场。Redis内存淘汰机制有以下几种策略：
noeviction（没有驱逐）：当内存不足以容纳新写入数据时，新写入操作会报错（Redis默认策略）
allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（推荐）
allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key
volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。这种情况一般是把Redis即当缓存，又做持久化的时候才用
volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key
volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除

配置内存淘汰机制只需要在redis.conf配置文件中配置maxmemory-polucy参数即可。

6.使用redis有什么缺点

（1）缓存和数据库双写一致性问题
分析：一致性问题是分布式常见的问题，还可以再分为最终一致性和强一致性。数据库和缓存双写，就必然会存在不一致的问题。答这个问题，先明白一个前提。就是如果对数据有强一致性要求，不能放缓存。我们所做的一切，只能保证最终一致性。另外，我们所做的方案其实从根本上来说，只能说降低不一致发生的概率，无法完全避免。因此，有强一致性要求的数据，不能放缓存。
首先，采取正确更新策略，先更新数据库，再删缓存。其次，因为可能存在删除缓存失败的问题，提供一个补偿措施即可，例如利用消息队列。

（2）缓存雪崩问题
缓存雪崩：由于缓存层承载着大量请求，有效地保护了存储层，但是如果缓冲层由于某些原因不能提供服务，比如Redis节点挂掉了，热点key全部失效了，在这些情况下，所有的请求都会直接请求到数据库，可能会造成数据库宕机的情况。
一般中小型传统软件企业，很难碰到这个问题。如果有大并发的项目，流量有几百万左右。这两个问题一定要深刻考虑。
缓存雪崩，即缓存同一时间大面积失效，这个时候又来了一波请求，结果请求都怼到数据库上，从而导致数据库连接异常。
预防和解决缓存雪崩的问题，可以从以下几个方面进行着手：
1.使用Redis高可用架构：使用Redis集群来保证Redis服务不会挂掉
2.缓存时间不一致：给缓存的失效时间，加上一个随机值，避免集体失效
3.限流降低策略：有一定的备案，比如个性推荐服务不可用了换成热点数据推荐服务
4.使用互斥锁，但是该方案吞吐量明显下降了
5.双缓存。我们有两个缓存，缓存A和缓存B。缓存A的失效时间为20分钟，缓存B不设失效时间。自己做缓存预热操作。然后细分以下几个小点
a.从缓存A读数据库，有则直接返回
b.A没有数据，直接从B读取数据，直接返回，并且异步启动一个更新线程
c.更新线程同时更新缓存A和缓存B

（3）缓存击穿问题
缓存穿透：缓存穿透是指查询一个根本不存在的数据，这样的数据肯定不在缓存中，这会导致请求全部落到数据库上，有可能出现数据库宕机的情况。（即黑客故意去请求缓存中不存在的数据，导致所有的请求都怼到数据库上，从而数据库连接异常。）

预防和解决缓存穿透问题，可以考虑以下几种方法：
1.缓存空对象：将空值缓存起来，但是这样就有一个问题，大量无效的空值将占用空间，非常浪费
2.布隆过滤器拦截：将所有可能的查询key 先映射到布隆过滤器中，查询时先判断key是否存在布隆过滤器中，存在才继续向下执行，如果不存在，则直接返回。布隆过滤器有一定的误判，所以需要你的业务允许一定的容错性。（提供一个能迅速判断请求是否有效的拦截机制，比如，利用布隆过滤器，内部维护一系列合法有效的key。迅速判断出，请求所携带的key是否合法有效。如果不合法，则直接返回。）
3.利用互斥锁，缓存失效的时候，先去获得锁，得到锁了，再去请求数据库。没得到锁，则休眠一段时间重试
4.采用异步更新策略，无论key是否取到值，都直接返回。value值中维护一个缓存失效时间，缓存如果过期，异步起一个线程去读数据库，更新缓存。需要做缓存预热（项目启动前，先加载缓存）操作。