餐掌柜之——Redis高级笔记

个人总结

Redis事务机制

Redis支持事务吗？

答案：支持，但没完全支持。因为Redis的事务是基于队列实现的，最后依次执行，如果遇到编译期异常，那么会进行事务回滚；如果遇到运行时异常，事务就失效了，执行成功的命令不会回滚，只会回滚执行出异常的命令。

Redis持久化机制

RDB持久化机制

它基于快照思想隔一段时间将内存中的数据存放在磁盘中。

redis.conf默认触发条件：

注意: 6.0之后才是3600 1

6.0之前是900 1

save ""  # 不使用RDB存储  不能实现主从

# 记忆
save 3600 1     #表示1小时内至少1个键被更改则进行快照。
save 300 100    #表示5分钟（300秒）内至少100个键被更改则进行快照。
save 60 10000  #表示1分钟内至少10000个键被更改则进行快照。

保存快照是否可以手动执行?

答: 可以, 分别为save与bgsave命令

save: 同步处理, 此时redis不能对外提供服务

bgsave: 会创建一个和主线程一致的子线程来保存RDB文件

备注: Redis默认持久化采用的是bgsave

执行流程

增量复制: 新增的数据复制

全量复制: 全部复制

Redis关闭/保存快照: 从内存中增量复制进磁盘中

Redis启动: 从磁盘中全量复制进内存

优缺点

优点：

• 基于二进制文件完成数据备份，占用空间少，便于文件传输。
• 能够自定义规则，根据Redis繁忙状态进行数据备份。(不建议修改, 默认配置是官方经过大量数据测试得出的结果)

缺点：

• 无法保证数据完整性，会丢失最后一次快照之后新增的所有数据。
• bgsave执行每次执行都会阻塞Redis服务进程创建子线程，频繁执行影响系统吞吐率。

AOF持久化机制

服务端接收到的所有增删改命令都会记录到磁盘中的AOF文件中, 当Reedis重启后就可以根据命令的先后顺序进行数据恢复.

不建议使用, 因为Redis本来就是要它的性能, 如果要保证数据的安全直接用Mysql就行了.

执行流程

1. 命令追加: Redis收到增删改命令, 把正确的命令保存在内存中的缓冲区, 有问题的命令移除
2. AOF文件写入: 把缓冲区的数据写入到AOF文件中
3. 文件同步: 把AOF文件同步到磁盘中

配置中开启AOF持久化机制:

# 是否开启AOF，默认为no
appendonly yes

#设置AOF文件名称
appendfilename  appendonly.aof

对于AOF的触发方式有三种：always、everysec、no。 默认使用everysec。可以通过redis.conf中appendfsync属性进行配置。

• always: 每次执行增删改命令都会把缓冲区全部内容都写入到AOF文件中, 并且同步到磁盘, 安全高效率低
• everysec: 每隔1秒把缓冲区中的数据保存到AOF文件中并保存置磁盘
• no: 会保存到缓冲区并且写入AOF文件中, 但不会持久化到磁盘, 同步磁盘由操作系统完成, 默认30秒一次

AOF持久化文件重写优化

我们使用AOF持久化模式时, 每条增删改命令都会保存到AOF文件中, 时间长了这个文件自然而然的会变得非常大, 这时就会重写当前AOF文件替换旧的AOF文件, 重写的文件没有任何冗余命令, 相当于做了个压缩.

配置:

#当前aof文件大小超过上一次aof文件大小的百分之多少时进行重写。如果之前没有重写过，以启动时aof文件大小为准
auto-aof-rewrite-percentage 100

#AOF文件大于多少mb进行优化
auto-aof-rewrite-min-size 64mb

手动执行命令: bgrewriteaof

RDB与AOF对比

如果RDB和AOF都开启, 会以谁为准?

答: 数据持久化他们两个同时进行, 但是恢复数据会以AOF为准, 因为AOF持久化频率更高, 数据更完整.

1. RDB默认开启，AOF需手动开启。
2. RDB性能优于AOF。
3. AOF安全性优于RDB。
4. AOF优先级高于RDB (同时开启RDB不会关闭)。
5. RDB存储某个时刻的数据快照，AOF存储写命令。
6. RDB在配置触发状态会丢失最后一次快照以后更改的所有数据，AOF默认使用everysec，每秒保存一次，最多丢失两秒以内的数据。

生产环境下持久化实践

1. 如当前只追求高性能，不关注数据安全性，则关闭RDB和AOF，如redis宕机重启，直接从数据源恢复数据。
2. 如需较高性能且关注数据安全性，则开启RDB，并定制触发规则。当开启RDB后发现，Redis数据量过多，服务线程被频繁阻塞，造成系统性能严重下降，则开启AOF。
3. 如更关注数据安全性，则开启AOF。

高可用 - 主从复制

​

一主二从结构

主从复制 执行流程

1. 从服务启动, 主动连接主服务, 并且发送SYNC建立主从关系
2. 主服务执行bgsave保存RDB文件, 并保存生成时间
3. 主服务向所有从服务发送RDB文件
4. 从服务删除旧的数据, 装载新的数据
5. 主服务向所有从服务发送写命令, 让所有从节点把数据写入内存中

主从复制的作用：

• 读写分离：主写从读，提高服务器的读写负载能力
• 负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数量，通过多个从节点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量
• 故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
• 数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
• 高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案
• 提高了数据的安全性

高可用 - 读写分离

在生产环境下，读请求会远远多于写请求，大概10:1的比率。 当单机无法应对大量读请求时，可以通过主从复制机制实现集群, 但也带来了问题: 主节点压力很大。所以就有了读写分离, 主节点只负责写请求，从节点只负责读请求。

注意: 读写分离并不是主节点只能写, 它也能读, 只是人为的控制只让它负责写入.

主节点:可读可写

从节点: 只能读

高可用 - 持久化优化

主节点和从节点如果都开启持久化那么性能不会特别高, 我们可以让从节点开启持久化, 主节点关闭持久化, 让主节点只负责写入和同步数据. 这样性能就能提升很多, 并且也不会影响数据安全.

因为:

• 主节点宕机, 从节点顶上
• 从节点宕机, 主节点可以继续给其他从节点同步数据

高可用 - 哨兵模式

如果是单纯的主从复制, 从节点宕机了, 其他从节点可以顶上, 实在不行主节点也能顶上. 但是如果主节点宕机了呢???

这时就需要使用哨兵模式了, 它可以解决:

1. 如何判断主服务是否宕机?
2. 主服务宕机了选择哪个从服务顶上 ?
3. 怎么把从服务切换成主服务

什么是哨兵?

哨兵其实也是一个Redis服务, 它不提供任何数据服务, 它只用来检测主从集群中的主服务是否宕机.

如何判断主服务是否宕机?

答: 通过哨兵向主服务发送ping命令判断主服务是否宕机, 如果宕机了, 就告诉其他哨兵服务判断一下主服务是否宕机, 然后哨兵集群进行投票, 如果票数超过半数以上, 那么认为主服务宕机, 也就是说如果有3个哨兵, 其中2个哨兵觉得主服务宕机了(主观下线SDOWN), 那就认为主服务宕机了(客观下线ODOWN), 少数服从多数.

这也是从主观下线转换为客观下线的过程

为什么要采用半数机制 ?

因为一个哨兵可能会误判, 多个哨兵投票可以减少误判的概率

主服务下线需要找一个从服务顶替主服务, 如果误判, 则会导致多余的性能开销~

客观下线会作用于从服务吗?

不会, 从服务只要一个哨兵认为宕机那么直接标记下线, 因为单个从服务下线不会影响到大局

通常, 哨兵服务的数量为单数, 并且最少为三台, 原因:

1. 上述所说的半数机制
2. 哨兵服务也可能宕机

哨兵集群组成通过pub/sub订阅的方式集群

高可扩-Redis Cluster分片集群

通过主从哨兵模式可以解决高可用问题, 但是随着时间的过去, 数据量会越来越大, 单台服务器的存储容量总是有限度的, 这时就需要进行扩容了.

分片集群原理

例如: 分给三个主从集群

1. RdiesCluster将整个集群采用哈希槽进行分片, 从0 到 16383一共有16384个槽, 把这些槽均匀地分给三个主从集群的master服务
2. 在写数据时, 根据CRC16算法计算key的值, 然后把这个值与16384求余数, 这时这个数就一定会在0 - 16384之间
3. 判断计算出来的槽值, 存储到槽值对应的主从集群中

**注意: **

• 需要整个哈希槽分配完, 这个分片集群才提供服务
• 哈希槽只会分配给master主节点

特点： 去中心化， 访问每个分片节点都能拿到想要的数据

查询数据时如何定位

1. 访问服务端查询数据
2. 通过CRC16算法以及取余计算出哈希槽的值
3. 根据哈希值跳转到存放数据的主从集群

主从分别宕机的处理结果

主节点:

• 宕机: 从节点顶上
• 恢复: 添加到新的主节点上, 变成从节点工作

从节点:

• 宕机以及恢复都是以从节点的身份工作

RedisCluster分片集群其中一个主从复制集群挂掉:

• 整个分片集群不提供服务, 因为哈希槽没有分配完

总结

分片集群集群解决了什么问题:

• 海量数据存储
• 高可用
• 高可扩

三种架构总结

• 主从复制: 读写分离, 均衡复制, 提升高可用
• sentinel哨兵: 解决主节点可能宕机问题, 再次提升高可用
• 分片集群: 解决单机redis容量有限的问题

Key过期删除策略

在Redis中, 设置了过期时间的key过期后并不是到期就删除的

Redis有三种删除策略

• 定时删除:
  • 原理: 设置过期时间的同时创建定时器, 过期立马删除
  • 优点: 立即删除, 可以提高空间容量的使用率
  • 缺点: 需要创建大量定时器, 这对CPU不友好, 会占用大量CPU资源
• 惰性删除
  • 原理： 过期后不管， 等再次访问时发现过期了再删除
  • 优点： 不需要创建定时器， 不会占用大量CPU资源
  • 缺点： 大量空间被浪费
• 定期删除：
  • 原理： 默认每秒运行10次设置了过期时间的key， 每次随机扫描20个key， 删除其中过期的key， 如果过期key超过25%则继续扫描， 否则等待下次扫描
  • 总结： 综合了上面两种方法的优缺点
  • 注意： 每秒扫描的周期可以自定义， 但建议不要超过100， 否则会对CPU带来很大压力

总结： 可以结合 惰性删除 与 定期删除的策略来删除key

内存淘汰机制

惰性删除与定期删除并不能100%避免过期key没有被删除， 久而久之内存空间就不足了

这时就要用内存淘汰机制来解决了

内存淘汰分为：

• volatile（设置了过期时间key的内存淘汰）
  • volatile-lru：最久未被使用的删除
  • volatile-lfu：最少被使用的删除
  • volatile-ttl：即将过期的删除
  • volatile-redom：随机删除
• allkeys（所有数据内存淘汰）
  • allkeys-lru：最久未被使用的删除
  • allkeys-lfu：最少被使用的删除
  • allkeys-redom：随机删除
• noevction（不淘汰）

不同策略的使用场景

1、Redis只做缓存，不做DB持久化，使用allkeys。如状态性信息，经常被访问，但数据库不会修改。

2、同时用于缓存和DB持久化，使用volatile。如商品详情页。

3、存在冷热数据区分，则选择LRU或LFU。如热点新闻，热搜话题等。

4、每个key被访问概率基本相同，选择使用random。如企业内部系统，访问量不大，删除谁对数据库也造成太大压力。

5、根据超时时间长久淘汰数据，选择选用ttl。如微信过期好友请求。

Redis6新特性

• 支持多线程： 底层数据还是单线程， 多线程只是用于网络数据读写和协议解析
• 引入了ACL机制： 可以给每个用户设置不同权限， 可以提高安全性
• 客户端缓存：类似浏览器缓存

Redis面试题

Redis常见面试题

Redis中如何找一个想要的Key?

scan方法迭代查询, 千万别用key *, 因为在redis中查询所有是一个很危险的行为, 数据很多会导致卡顿, 而scan方法是一个异步的方法, 可以有效解决卡顿问题, 提升效率.

Redis 持久化机制

Redis是一个支持持久化的内存数据库，通过持久化机制把内存中的数据同步到硬盘文件来保证数据持久化。当Redis重启后通过把硬盘文件重新加载到内存，就能达到恢复数据的目的。

实现：单独创建fork()一个子进程，将当前父进程的数据库数据复制到子进程的内存中，然后由子进程写入到临时文件中，持久化的过程结束了，再用这个临时文件替换上次的快照文件，然后子进程退出，内存释放。

RDB是Redis默认的持久化方式。按照一定的时间周期策略把内存的数据以快照的形式保存到硬盘的二进制文件。即Snapshot快照存储，对应产生的数据文件为dump.rdb，通过配置文件中的save参数来定义快照的周期。（ 快照可以是其所表示的数据的一个副本，也可以是数据的一个复制品。）
AOF：Redis会将每一个收到的写命令都通过Write函数追加到文件最后，类似于MySQL的binlog。当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复。

缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级等问题

缓存雪崩

缓存雪崩我们可以简单的理解为：由于原有缓存失效，新缓存未到期间

(例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。

解决办法：

大多数系统设计者考虑用加锁（ 最多的解决方案）或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。还有一个简单方案就是讲缓存失效时间分散开。

缓存穿透

缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。

解决办法：

最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

另外也有一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。通过这个直接设置的默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴。

5TB的硬盘上放满了数据，请写一个算法将这些数据进行排重。如果这些数据是一些32bit大小的数据该如何解决？如果是64bit的呢？

对于空间的利用到达了一种极致，那就是Bitmap和布隆过滤器(Bloom Filter)。

Bitmap：典型的就是哈希表

缺点是，Bitmap对于每个元素只能记录1bit信息，如果还想完成额外的功能，恐怕只能靠牺牲更多的空间、时间来完成了。

布隆过滤器（推荐）

就是引入了k(k>1)k(k>1)个相互独立的哈希函数，保证在给定的空间、误判率下，完成元素判重的过程。

它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。

Bloom-Filter算法的核心思想就是利用多个不同的Hash函数来解决“冲突”。

Hash存在一个冲突（碰撞）的问题，用同一个Hash得到的两个URL的值有可能相同。为了减少冲突，我们可以多引入几个Hash，如果通过其中的一个Hash值我们得出某元素不在集合中，那么该元素肯定不在集合中。只有在所有的Hash函数告诉我们该元素在集合中时，才能确定该元素存在于集合中。这便是Bloom-Filter的基本思想。

Bloom-Filter一般用于在大数据量的集合中判定某元素是否存在。

缓存穿透与缓存击穿的区别

缓存击穿：是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据。

解决方案：在访问key之前，采用SETNX（set if not exists）来设置另一个短期key来锁住当前key的访问，访问结束再删除该短期key。

给一个我公司处理的案例：背景双机拿token，token在存一份到redis，保证系统在token过期时都只有一个线程去获取token;线上环境有两台机器，故使用分布式锁实现。

三、缓存预热

缓存预热这个应该是一个比较常见的概念，相信很多小伙伴都应该可以很容易的理解，缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

解决思路：

• 直接写个缓存刷新页面，上线时手工操作下；
• 数据量不大，可以在项目启动的时候自动进行加载；
• 定时刷新缓存；

四、缓存更新

除了缓存服务器自带的缓存失效策略之外（Redis默认的有6种策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：

• 定时去清理过期的缓存；
• 当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。

两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。

五、缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

以参考日志级别设置预案：

• 一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
• 警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
• 错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
• 严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

服务降级的目的，是为了防止Redis服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是，Redis出现问题，不去数据库查询，而是直接返回默认值给用户。

热点数据和冷数据是什么

热点数据，缓存才有价值

对于冷数据而言，大部分数据可能还没有再次访问到就已经被挤出内存，不仅占用内存，而且价值不大。频繁修改的数据，看情况考虑使用缓存

对于上面两个例子，寿星列表、导航信息都存在一个特点，就是信息修改频率不高，读取通常非常高的场景。

对于热点数据，比如我们的某IM产品，生日祝福模块，当天的寿星列表，缓存以后可能读取数十万次。再举个例子，某导航产品，我们将导航信息，缓存以后可能读取数百万次。

数据更新前至少读取两次， 缓存才有意义。这个是最基本的策略，如果缓存还没有起作用就失效了，那就没有太大价值了。

那存不存在，修改频率很高，但是又不得不考虑缓存的场景呢？有！比如，这个读取接口对数据库的压力很大，但是又是热点数据，这个时候就需要考虑通过缓存手段，减少数据库的压力，比如我们的某助手产品的，点赞数，收藏数，分享数等是非常典型的热点数据，但是又不断变化，此时就需要将数据同步保存到Redis缓存，减少数据库压力。

Memcache与Redis的区别都有哪些？

1)、存储方式 Memecache把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。Redis有部分存在硬盘上，redis可以持久化其数据

2)、数据支持类型 memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型 ，提供list，set，zset，hash等数据结构的存储

3)、使用底层模型不同 它们之间底层实现方式 以及与客户端之间通信的应用协议不一样。Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。

4). value 值大小不同：Redis 最大可以达到 512M；memcache 只有 1mb。

5）redis的速度比memcached快很多

6）Redis支持数据的备份，即master-slave模式的数据备份。

单线程的redis为什么这么快

(一)纯内存操作

(二)单线程操作，避免了频繁的上下文切换

(三)采用了非阻塞I/O多路复用机制

redis的数据类型，以及每种数据类型的使用场景

回答：一共五种

(一)String

这个其实没啥好说的，最常规的set/get操作，value可以是String也可以是数字。一般做一些复杂的计数功能的缓存。

(二)hash

这里value存放的是结构化的对象，比较方便的就是操作其中的某个字段。博主在做单点登录的时候，就是用这种数据结构存储用户信息，以cookieId作为key，设置30分钟为缓存过期时间，能很好的模拟出类似session的效果。

(三)list

使用List的数据结构，可以做简单的消息队列的功能。另外还有一个就是，可以利用lrange命令，做基于redis的分页功能，性能极佳，用户体验好。本人还用一个场景，很合适取行情信息。就也是个生产者和消费者的场景。LIST可以很好的完成排队，先进先出的原则。

(四)set

因为set堆放的是一堆不重复值的集合。所以可以做全局去重的功能。为什么不用JVM自带的Set进行去重？因为我们的系统一般都是集群部署，使用JVM自带的Set，比较麻烦，难道为了一个做一个全局去重，再起一个公共服务，太麻烦了。

另外，就是利用交集、并集、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好等功能。

(五)sorted set

sorted set多了一个权重参数score,集合中的元素能够按score进行排列。可以做排行榜应用，取TOP N操作。

Redis 内部结构

• dict 本质上是为了解决算法中的查找问题（Searching）是一个用于维护key和value映射关系的数据结构，与很多语言中的Map或dictionary类似。本质上是为了解决算法中的查找问题（Searching）
• sds sds就等同于char * 它可以存储任意二进制数据，不能像C语言字符串那样以字符’\0’来标识字符串的结 束，因此它必然有个长度字段。
• skiplist （跳跃表） 跳表是一种实现起来很简单，单层多指针的链表，它查找效率很高，堪比优化过的二叉平衡树，且比平衡树的实现，
• quicklist
• ziplist 压缩表 ziplist是一个编码后的列表，是由一系列特殊编码的连续内存块组成的顺序型数据结构，

redis的过期策略以及内存淘汰机制

redis采用的是定期删除+惰性删除策略。

为什么不用定时删除策略?

定时删除,用一个定时器来负责监视key,过期则自动删除。虽然内存及时释放，但是十分消耗CPU资源。在大并发请求下，CPU要将时间应用在处理请求，而不是删除key,因此没有采用这一策略.

定期删除+惰性删除是如何工作的呢?

定期删除，redis默认每个100ms检查，是否有过期的key,有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。

于是，惰性删除派上用场。也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除。

采用定期删除+惰性删除就没其他问题了么?

不是的，如果定期删除没删除key。然后你也没即时去请求key，也就是说惰性删除也没生效。这样，redis的内存会越来越高。那么就应该采用内存淘汰机制。

在redis.conf中有一行配置

maxmemory-policy volatile-lru1

该配置就是配内存淘汰策略的(什么，你没配过？好好反省一下自己)

• volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
• volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
• volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
• allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
• allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
• no-enviction（驱逐）：禁止驱逐数据，新写入操作会报错

ps：如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。

Redis 为什么是单线程的

官方FAQ表示，因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。

既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了（毕竟采用多线程会有很多麻烦！）Redis利用队列技术将并发访问变为串行访问

1）绝大部分请求是纯粹的内存操作（非常快速）

2）采用单线程,避免了不必要的上下文切换和竞争条件

3）非阻塞IO优点：

• 速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)
• 支持丰富数据类型，支持string，list，set，sorted set，hash
• 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行
• 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除如何解决redis的并发竞争key问题

同时有多个子系统去set一个key。这个时候要注意什么呢？

不推荐使用redis的事务机制。因为我们的生产环境，基本都是redis集群环境，做了数据分片操作。你一个事务中有涉及到多个key操作的时候，这多个key不一定都存储在同一个redis-server上。因此，redis的事务机制，十分鸡肋。

• 如果对这个key操作，不要求顺序：准备一个分布式锁，大家去抢锁，抢到锁就做set操作即可
• 如果对这个key操作，要求顺序：分布式锁+时间戳。假设这会儿系统B先抢到锁，将key1设置为{valueB 3:05}。接下来系统A抢到锁，发现自己的valueA的时间戳早于缓存中的时间戳，那就不做set操作了。以此类推。
• 利用队列，将set方法变成串行访问也可以redis遇到高并发，如果保证读写key的一致性

对redis的操作都是具有原子性的,是线程安全的操作,你不用考虑并发问题,redis内部已经帮你处理好并发的问题了。

Redis 集群方案应该怎么做？都有哪些方案？

1.twemproxy，大概概念是，它类似于一个代理方式， 使用时在本需要连接 redis 的地方改为连接 twemproxy， 它会以一个代理的身份接收请求并使用一致性 hash 算法，将请求转接到具体 redis，将结果再返回 twemproxy。

缺点：twemproxy 自身单端口实例的压力，使用一致性 hash 后，对 redis 节点数量改变时候的计算值的改变，数据无法自动移动到新的节点。

2.codis，目前用的最多的集群方案，基本和 twemproxy 一致的效果，但它支持在 节点数量改变情况下，旧节点数据可恢复到新 hash 节点

3.redis cluster3.0 自带的集群，特点在于他的分布式算法不是一致性 hash，而是 hash 槽的概念，以及自身支持节点设置从节点。具体看官方文档介绍。

有没有尝试进行多机redis 的部署？如何保证数据一致的？

主从复制，读写分离

一类是主数据库（master）一类是从数据库（slave），主数据库可以进行读写操作，当发生写操作的时候自动将数据同步到从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据，一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。

对于大量的请求怎么样处理

redis是一个单线程程序，也就说同一时刻它只能处理一个客户端请求；

redis是通过IO多路复用（select，epoll, kqueue，依据不同的平台，采取不同的实现）来处理多个客户端请求的

Redis 常见性能问题和解决方案？

(1) Master 最好不要做任何持久化工作，如 RDB 内存快照和 AOF 日志文件

(2) 如果数据比较重要，某个 Slave 开启 AOF 备份数据，策略设置为每秒同步一次

(3) 为了主从复制的速度和连接的稳定性， Master 和 Slave 最好在同一个局域网内

(4) 尽量避免在压力很大的主库上增加从库

(5) 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <-
Slave3…

往期面试题汇总：001期~150期汇总

讲解下Redis线程模型

文件事件处理器包括分别是套接字、 I/O 多路复用程序、 文件事件分派器（dispatcher）、 以及事件处理器。使用 I/O 多路复用程序来同时监听多个套接字， 并根据套接字目前执行的任务来为套接字关联不同的事件处理器。

当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（close）等操作时， 与操作相对应的文件事件就会产生， 这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

I/O 多路复用程序负责监听多个套接字， 并向文件事件分派器传送那些产生了事件的套接字。

工作原理：

I/O 多路复用程序负责监听多个套接字， 并向文件事件分派器传送那些产生了事件的套接字。

尽管多个文件事件可能会并发地出现， 但 I/O 多路复用程序总是会将所有产生事件的套接字都入队到一个队列里面， 然后通过这个队列， 以有序（sequentially）、同步（synchronously）、每次一个套接字的方式向文件事件分派器传送套接字：

当上一个套接字产生的事件被处理完毕之后（该套接字为事件所关联的事件处理器执行完毕）， I/O 多路复用程序才会继续向文件事件分派器传送下一个套接字。如果一个套接字又可读又可写的话， 那么服务器将先读套接字， 后写套接字.

为什么Redis的操作是原子性的，怎么保证原子性的？

对于Redis而言，命令的原子性指的是：一个操作的不可以再分，操作要么执行，要么不执行。

Redis的操作之所以是原子性的，是因为Redis是单线程的。（Redis新版本已经引入多线程，这里基于旧版本的Redis）

Redis本身提供的所有API都是原子操作，Redis中的事务其实是要保证批量操作的原子性。

多个命令在并发中也是原子性的吗？

不一定， 将get和set改成单命令操作，incr 。使用Redis的事务，或者使用Redis+Lua==的方式实现.

Redis事务

Redis事务功能是通过MULTI、EXEC、DISCARD和WATCH 四个原语实现的

Redis会将一个事务中的所有命令序列化，然后按顺序执行。

1. redis 不支持回滚“Redis 在事务失败时不进行回滚，而是继续执行余下的命令”， 所以 Redis 的内部可以保持简单且快速。
2. 如果在一个事务中的命令出现错误，那么所有的命令都不会执行；
3. 如果在一个事务中出现运行错误，那么正确的命令会被执行。

注：redis的discard只是结束本次事务,正确命令造成的影响仍然存在.

1）MULTI命令用于开启一个事务，它总是返回OK。MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。

2）EXEC：执行所有事务块内的命令。返回事务块内所有命令的返回值，按命令执行的先后顺序排列。当操作被打断时，返回空值 nil 。

3）通过调用DISCARD，客户端可以清空事务队列，并放弃执行事务， 并且客户端会从事务状态中退出。

4）WATCH 命令可以为 Redis 事务提供 check-and-set （CAS）行为。可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行，监控一直持续到EXEC命令。

搜索Java大数据修炼之道公众号，回复“PDF”，送你一份Java面试题宝典.pdf

Redis实现分布式锁

Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系Redis中可以使用SETNX命令实现分布式锁。继续项目实战，集成Redis分布式锁（大神勿进）

将 key 的值设为 value ，当且仅当 key 不存在。若给定的 key 已经存在，则 SETNX 不做任何动作

解锁：使用 del key 命令就能释放锁

解决死锁：

• 通过Redis中expire()给锁设定最大持有时间，如果超过，则Redis来帮我们释放锁。
• 使用 setnx key “当前系统时间+锁持有的时间”和getset key “当前系统时间+锁持有的时间”组合的命令就可以实现。