本文主要是介绍redis学习笔记，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

一、缓存过期后没释放内存

定期删除+惰性删除

定期删除

指的是Redis默认是每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。

为什么是随机抽取？
假设Redis里放了10万个key，都设置了过期时间，你每隔几百毫秒，就检查10万个key，那redis基本上就死了，因为这样cpu负载会很高的，全都消耗在你的检查过期key上了。

所以这里可不是每隔100ms就遍历所有的设置过期时间的key，Redis如果设置成检查所有Key那将是一场性能上的灾难。所以实际上redis是每隔100ms随机抽取一些key来检查和删除的。

但是问题是，随机抽取检测key是否过去会导致定期删除策略可能会导致很多过期key到了时间并没有被删除掉，那咋整呢？所以Redis还有另一个策略就是惰性删除。

惰性删除

就是说，在你获取某个key的时候，Redis会检查一下 ，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除，不会给你返回任何东西。

所以并不是key到时间就被删除掉，而是你查询这个key的时候，Redis再懒惰的检查一下。

通过上述两种手段，保证过期的key一定会被干掉。

那么刚才的问题就不难理解了，就是说，你的过期key，靠定期删除没有被删除掉，还停留在内存里，占用着你的内存呢，除非你的系统去查一下那个key，才会被redis给删除掉。如果都过期了，定期删除才删了一点点，而你又没有去查，没有触发惰性删除，那么短时间内你的redis内存占用率还是会下不来。

但是实际上这还是有问题的，如果定期删除漏掉了很多过期key，然后你也没及时去查，也就没走惰性删除，会导致redis内存块耗尽了。

内存淘汰策略

如果Redis的内存占用过多的时候，此时会进行内存淘汰，Redis提供如下丰富的可选策略：

• 1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。
  （这个一般没人用吧，实在是太恶心了）

• 2）allkeys-lru：当内存不足以容纳新写入数据时，在所有键空间中，移除最近最少使用的key
  （这个是最常用的）

• 3）allkeys-random：当内存不足以容纳新写入数据时，在所有键空间中，随机移除某个key。
  （这个一般没人用吧，为啥要随机，把我重要的key干掉了咋整，肯定是把最近最少使用的干掉）

• 4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。
  （这个一般不太合适）

• 5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。

• 6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。

例如：Redis 里有10个key，现在内存已经满了，设置的淘汰策略是allkeys-lru，此时Redis需要删除掉一些key来保证你可以继续写入。在这10个key中，其中1个key，最近1分钟被查询了100次，1个key，最近10分钟被查询了50次，1个key，最近1个小时被查询了1次。肯定那些最近最少使用的被干掉了。

为啥存redis的数据有时候会丢失？
很简单，你写的数据太多了，内存占满了，或者触发了什么条件，如redis使用了allkeys-lru内存淘汰策略，自动给你清理掉了一些最近很少使用的数据

二、雪崩和穿透

对于缓存雪崩主要分为事前事中事后，

事前： 如果缓存不可用是因为缓存中的大部分数据集中失效，我们可以对缓存的失效时间加上一个随机值，使失效时间分散一点，尽量避免集中失效。另外如果是因为别的原因redis宕机导致缓存不可用，这时候我们就需要提前做好Redis高可用的架构，如主从+哨兵或redis cluster，来避免Redis出现故障时整个缓存不可用，全盘崩溃。

事中： 可以将一小部分数据同样缓存到本地ehcache（本地缓存组件）缓存，另外加上hystrix限流&降级组件，避免MySQL被打死。

事后： 如果真的发生雪崩，我们还可以用redis的RDB或AOF重启redis快速从磁盘加载缓存数据。这就需要我们提前打开Redis持久化机制，在雪崩发生的事后快速恢复缓存数据，一旦重启从磁盘中恢复数据到内存。

另外一个问题，缓存穿透，一般是黑客恶意攻击，或是自己系统出bug。例如黑客恶意伪造请求，这些请求都是数据库根本查不到的，所以缓存中也没用，那这些大量的恶意请求都会落到数据库去查询，数据库不就挂了吗？

解决办法
1、只要从数据库没查到，就写入一个空值到缓存里去。
2、使用布隆过滤器对请求的key进行一层过滤，过滤掉系统认为不存在不合法的key。

三、数据库+缓存双写不一致

先修改数据库，再删除缓存

会有问题，试想，如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据，出现数据不一致的情况。

先删除缓存，再修改数据库

读缓存读不到，查数据库更新缓存的时候就拿到了最新的库存数据。如果删除缓存成功了，而修改数据库失败了，那么数据库中依旧是旧数据，缓存中是空的，那么数据不会不一致。因为读的时候缓存没有，则读数据库中旧数据，然后更新到缓存中。

并发问题

删完缓存修改数据库的时候，其他线程请求到数据库，此时缓存更新为老数据。

解决办法

1. 串行化
   使读写互斥
2. 二次删除
   删缓存->更新数据库->删缓存
   这种方法不会阻塞，但是会有先修改数据库，再删除缓存 同样的问题

四、Redis各种数据类型及其使用场景

1. string

Redis中最基本的类型，也最常用，没啥可说的，就是普通的set和get，做简单的kv缓存

2. hash

这个是类似map的一种结构，一般可以将结构化的数据，比如一个对象（前提是这个对象没嵌套其他的对象）给缓存在redis里，然后每次读写缓存的时候，可以就操作hash里的某个字段，而不是把整个对象都拿出来，这样节省了IO操作，效率更高。

使用HSET key field value命令存储一个对象，如我们有一个用户，

bashkey=user:id:1

value={
  "id": 1,
  "name": "walking",
  "age": 24
}

hash类的数据结构，主要是用来存放一些对象，把一些简单的对象给缓存起来，后续操作的时候，你可以直接仅仅修改这个对象中的某个字段的值。

value={
  "id": 1,
  "name": "walking",
  "age": 18
}

HGET user:id:1 age获取用户ID为1的age值。

3. list

有序列表，这个是可以玩儿出很多花样的。

比如在微博里，有个大v的粉丝，就可以以list的格式放在Redis里去缓存。

key=某大v

value=[zhangsan, lisi, wangwu]

比如可以通过list存储一些列表型的数据结构，类似粉丝列表了、文章的评论列表了之类的东西。

4. set

set无序集合，可以自动去重。

直接基于set将系统里需要去重的数据扔进去，自动就给去重了，如果你需要对一些数据进行快速的全局去重，你当然也可以基于jvm内存里的HashSet进行去重。但是如果你的某个系统部署在多台机器上呢？就得基于Redis进行全局的set去重了。

当然还可以基于set玩儿交集、并集、差集的操作，比如交集吧，可以把两个人的粉丝列表整一个交集，看看俩人的共同好友是谁？对吧。

把两个大v的粉丝都放在两个set中，对两个set做交集，看到共同关注的人。

5. sorted set

排序的set，去重但是可以排序，写进去的时候给一个分数，自动根据分数排序，这个可以玩儿很多的花样。这个数据类型的最大的特点是有个分数的概念，可以自定义排序规则。

比如说你要是想根据时间对数据排序，那么可以写入进去的时候用某个时间作为分数，人家自动给你按照时间排序了。

另外，这个数据类型很适合最排行榜这类的功能。

排行榜： 将每个用户以及其对应的分数写入进去
命令zadd board score username
如

zadd board 85 Jobs
zadd board 72 Jerry
zadd board 96 Walking
zadd board 62 Tom
...

接着使用命令zrevrange board start stop，就可以获取排名从start到stop的用户。

使用命令zrank board username，可以看到用户在排行榜里的排名。

如：
zrevrange board 0 3获取排名前3的用户

96 Walking
85 Jobs
72 Jerry

查看排名zrank board Tom
返回4

五、 Redis的线程模型（单线程）

1. 基本原理

采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗）

1. 为什么不采用多进程或多线程处理？
   • 多线程处理可能涉及到锁
   • 多线程处理会涉及到线程切换而消耗CPU
2. 单线程处理的缺点？
   无法发挥多核CPU性能，不过可以通过在单机开多个Redis实例来完善

2. Redis不存在线程安全问题

Redis采用了线程封闭的方式，把任务封闭在一个线程，自然避免了线程安全问题，不过对于需要依赖多个redis操作的复合操作来说，依然需要锁，而且有可能是分布式锁

3. 多路I/O复用（Epoll）

（1）非阻塞【忙轮询】：采用死循环方式轮询每一个流，如果有IO事件就处理，这样可以使得一个线程可以处理多个流，但是效率不高，容易导致CPU空转

（2）Select代理（无差别轮询）：可以观察多个流的IO事件，如果所有流都没有IO事件，则将线程进入阻塞状态，如果有一个或多个发生了IO事件，则唤醒线程去处理。但是还是得遍历所有的流，才能找出哪些流需要处理。如果流个数为N，则时间复杂度为O（N）

（3）Epoll代理：Select代理有一个缺点，线程在被唤醒后轮询所有的Stream，还是存在无效操作。 Epoll会哪个流发生了怎样的I/O事件通知处理线程，因此对这些流的操作都是有意义的，复杂度降低到了O(1)

六、 Redis高并发，高可用

高并发： redis的单机吞吐量可以达到几万不是问题，如果想提高redis的读写能力，可以用redis的主从架构，redis天然支持一主多从的准备模式，单主负责写请求多从负责读请求，主从之间异步复制，把主的数据同步到从。

高可用： 首先利用redis的主从架构解决redis的单点故障导致的不可用，然后如果使用的是主从架构，那么只需要增加哨兵机制即可，就可以实现，redis主实例宕机，自动会进行主备切换。以此来达到redis的高可用。

1. 主从复制的原理

在redis主从架构中，master负责接收写请求，写操作成功后返回客户端OK，然后后将数据异步的方式发送给多个slaver进行数据同步，不过从redis 2.8开始，slave node会周期性地确认自己每次复制的数据量。

当启动一个slave node的时候，它会发送一个PSYNC命令给master node。如果slave node是重新连接master node，那么master node仅仅会复制给slave部分缺少的数据; 否则如果是slave node第一次连接master node，那么会触发一次full resynchronization全量复制。

开始full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存（内存缓冲区）中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。

另外slave node做复制的时候，是不会block master node的正常工作的，也不会block对自己的查询操作，它会用旧的数据集来提供服务; 但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了。slave node主要用来进行横向扩容，做读写分离，扩容的slave node可以提高读的吞吐量。slave与高可用性有很大的关系。

2. 主从复制的过程中如果因为网络原因停止复制了会怎么样？

如果出现网络故障断开连接了，会自动重连的，从redis 2.8开始，就支持主从复制的断点续传，可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份。

master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。

master node会在内存中创建一个backlog，master和slave都会保存一个replica offset，还有一个master id，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制。

但是如果没有找到对应的offset，那么就会执行一次resynchronization全量复制。

3. 哨兵

哨兵是redis集群架构中非常重要的一个组件，主要功能如下
（1）集群监控，负责监控redis master和slave进程是否正常工作
（2）消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
（3）故障转移，如果master node挂掉了，会自动转移到slave node上
（4）配置中心，如果故障转移发生了，通知client客户端新的master地址

哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作
（1）故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题
（2）即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。

目前采用的是sentinal 2版本，sentinal 2相对于sentinal 1来说，重写了很多代码，主要是让故障转移的机制和算法变得更加健壮和简单

4. 主备切换的时候会有数据丢失的可能

1. 异步复制

因为master 到 slave的复制是异步的，所以可能有部分数据还没复制到slave的时候，master就宕机了，此时这些部分数据就丢失了。虽然master会做持久化，但是哨兵将slave提升为master后，如果旧的master这时候好了，会当做slave挂到新的master上，从新的master同步数据，原来的数据还是会丢失。

3. 脑裂导致的数据丢失

某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着，即集群分区现象。此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master.
这个时候，集群里就会有两个master，也就是所谓的脑裂。
此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续向旧master写数据，这部分数据可能就丢失了。因此旧master再次恢复的加入到主从结构中时，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据，原来的写到旧master的数据就丢失了。

七、 Redis哨兵原理

1)每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令。

2)如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被当前 Sentinel 标记为主观下线。

3)如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。

4)当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 。

5)当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 （在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 ）。

6)若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会变成主观下线。若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

7）sentinel节点会与其他sentinel节点进行“沟通”，投票选举一个sentinel节点进行故障处理，在从节点中选取一个主节点，其他从节点挂载到新的主节点上自动复制新主节点的数据。

八、Redis持久化

redis持久化主要是做灾难恢复，数据恢复，也可以归类到高可用的范畴。

比如Redis整个挂了，导致Redis不可用了，这时候首先要做的事情是让Redis尽快变得可用。那么就会去重启Redis，尽快让它对外提供服务。但是如果没做持久化没有数据备份，这个时候Redis启动了，也不可用啊，数据都没了！

这时候很可能，大量的请求过来，在缓存全部无法命中，这个时候就死定了，可能会导致缓存雪崩问题，所有的请求，没有在Redis命中，就会去数据库中去找，数据库一下子承接高并发，然后就挂了。数据库挂掉，你都没法去找数据恢复到redis里面去。

1. AOF

记录每次写请求的命令，以追加的方式在文件尾部追加，直接在尾部追加，效率比较高。
对于操作系统来说，不是每次写都直接写到磁盘，操作系统自己会有一层cache，redis写磁盘的数据会先缓存在os cache里，redis每隔1秒调用一次操作系统的fsync操作，强制将os cache中的数据刷入AOF文件中。

当redis重启的时候，就把AOF中记录的命令重新执行一遍就可以了，但是如果文件很大的话，执行会耗费较多的时间，对于数据恢复来说耗时会多一点。

优点

1. AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
2. AOF持久化性能高，AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。
3. AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指令进行压缩，创建出一份需要恢复数据的最小日志出来。在创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
4. AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。

缺点

1. 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
2. AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的。
3. 唯一的比较大的缺点，其实就是做数据恢复的时候，会比较慢，做冷备不太合适。

2. RDB

是快照文件，每隔一定时间将redis内存中的数据生成一份完整的RDB快照文件，当redis重启的时候直接加载数据即可，同样的数据比AOF恢复的要快。

优点

1. 就是他会生成多个数据文件，每个数据文件都代表了某一时刻redis中的数据，非常适合做冷备。
2. 第二点，RDB持久化机制对redis对外提供的读写服务影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。
3. 相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速。

缺点

1. 故障时可能数据丢失的比AOF要多。一般来说，RDB数据快照文件，都是每隔5分钟或者更长时间生成一次，这个时候一旦redis进程宕机，那么会丢失最近5分钟的数据。
2. RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。

这篇关于redis学习笔记的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！