redis学习

1. 简介

redis是一个速度极快的非关系数据库,也就是我们所说的NoSQL数据库,采用单线程处理,它可以存储键(key)与5种不同类型的值(value)之间的映射(mapping),可以将存储在内存的键值对数据持久化到硬盘,可以使用复制特性来扩展读性能,还可以使用客户端分片来扩展性能,并且它还提供了多种语言的API。

2. 特性

一个产品的使用场景肯定是需要根据产品的特性,先列举一下redis的特点:

• 读写性能优异
• 持久化
• 数据类型丰富
• 单线程
• 数据自动过期
• 发布订阅
• 分布式

3. 使用场景

3.1 高性能适合当做缓存

缓存是redis最常见的应用场景,之所有这么使用,主要是因为redis读写性能优异。而且逐渐有取代memcached,成为首选服务端缓存的组件。而且,redis内部是支持事务的,在使用时候能有效保证数据的一致性。作为缓存使用时,一般有两种方式保存数据:

1. 读取前,先去读redis,如果没有数据,读取数据库,将数据拉入redis

2. 插入数据时,同时写入redis

方案一: 实施起来简单,但是有两个需要注意的地方

• 避免缓存击穿。(数据库没有就需要命中的数据,导致redis一直没有数据,而一直命中数据库)
• 数据的实时性相对会差一点。

方案二: 数据实时性强,但是开发时不便于统一处理

当然,两种方式根据实际情况来适用。如: 方案一适用于对于数据实时性要求不是特别高的场景。方案二适用于字典表、数据量不大的数据存储。

3.2 丰富的数据格式性能更高,应用场景丰富

redis相比其他缓存,有一个非常大的优势,就是支持多种数据类型。

数据类型	说明
string	字符串,最简单的k-v存储
hash	hash格式,value为field和value
list	简单的list,顺序列表,支持首位或者末尾插入数据
set	无序,查找速度快,适合交集、并集、差集处理
sorted set	有序的set

其实,通过上面的数据类型的特性,基本就能想到合适的应用场景了。

• string——适合最简单的k-v存储,类似于memcached的存储结构,短信验证码,配置信息等,就用这种类型来存储。
• hash——一般key为ID或者唯一标示,value对应的就是详情了。如商品详情,个人信息详情,新闻详情等。
• list——因为list是有序的,比较适合存储一些有序且数据相对固定的数据。如省市区表、字典表等。因为list是有序的,适合根据写入的时间来排序,如: 最新的***,消息队列等。
• set——可以简单的理解为ID-List的模式,如微博中一个人有哪些好友,set最牛的地方在于,可以对两个set提供交集、并集、差集操作。例如: 查找两个人共同的好友等。
• Sorted Set——是set的增强版本,增加了一个score参数,自动会根据score的值进行排序。比较适合类似于top 10等不根据插入的时间来排序的数据。

如上所述,虽然redis不像关系数据库那么复杂的数据结构,但是,也能适合很多场景,比一般的缓存数据结构要多。了解每种数据结构适合的业务场景,不仅有利于提升开发效率,也能有效利用redis的性能。

3.3 单线程可以作为分布式锁

谈到redis和Memcached 的区别,大家更多的是谈到数据结构和持久化这两个特性,其实还有一个比较大的区别就是:

• redis 是单线程,多路复用方式提高处理效率。
• Memcached 是多线程的,通过CPU线程切换来提高处理效率。

所以redis单线程的这个特性,其实也是很重要的应用场景,最常用的就是分布式锁。

3.4 自动过期能有效提升开发效率

redis针对数据都可以设置过期时间,这个特点也是大家应用比较多的,过期的数据清理无需使用方去关注,所以开发效率也比较高,当然,性能也比较高。最常见的就是: 短信验证码、具有时间性的商品展示等。无需像数据库还要去查时间进行对比。因为使用比较简单,就不赘述了。

3.5 分布式和持久化有效应对海量数据和高并发

redis初期的版本官方只是支持单机或者简单的主从,大多应用则都是自己去开发集群的中间件,但是随着应用越来越广泛,用户关于分布式的呼声越来越高,所以redis 3.0版本时候官方加入了分布式的支持,主要是两个方面:

• redis服务器主从热备,确保系统稳定性
• redis分片应对海量数据和高并发

而且redis虽然是一个内存缓存,数据存在内存,但是redis支持多种方式将数据持久化,写入硬盘,所以,redis数据的稳定性也是非常有保障的,结合redis的集群方案,有的系统已经将redis当做一种NoSql数据存储来适用。

4. redis高可用方案

包含三种高可用方案: 主从复制,哨兵,集群

4.1 主从复制

通过持久化功能,redis保证了即使在服务器重启的情况下也不会损失（或少量损失）数据,因为持久化会把内存中数据保存到硬盘上,重启会从硬盘上加载数据。
但是由于数据是存储在一台服务器上的,如果这台服务器出现硬盘故障等问题,也会导致数据丢失。为了避免单点故障,通常的做法是将数据库复制多个副本以部署在不同的服务器上,这样即使有一台服务器出现故障,其他服务器依然可以继续提供服务。为此, redis 提供了复制（replication）功能,可以实现当一台数据库中的数据更新后,自动将更新的数据同步到其他数据库上。
在复制的概念中,数据库分为两类,一类是主数据库（master）,另一类是从数据库（slave）。主数据库可以进行读写操作,当写操作导致数据变化时会自动将数据同步给从数据库。而从数据库一般是只读的,并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库,而一个从数据库只能拥有一个主数据库。

原理:

当从数据库启动时,会向主数据库发送sync命令,主数据库接收到sync后开始在后台报错快照rdb,在保存快照期间受到的命名缓存起来,当快照完成时,主数据库会将快照和缓存的命令一块发送给从。复制初始化结束。之后,主每受到1个命令就同步发送给从。 
当出现断开重连后,2.8之后的版本会将断线期间的命令传给重数据库。

主从复制是乐观复制,当客户端发送写执行给主,主执行完立即将结果返回客户端,并异步的把命令发送给从,从而不影响性能。也可以设置至少同步给多少个从主才可写。 

无硬盘复制:如果硬盘效率低将会影响复制性能,2.8之后可以设置无硬盘复制

优点:

• 高可靠性: 一方面,采用双机主备架构,能够在主库出现故障时自动进行主备切换,从库提升为主库提供服务,保证服务平稳运行;另一方面,开启数据持久化功能和配置合理的备份策略,能有效的解决数据误操作和数据异常丢失的问题。
• 读写分离策略: 从节点可以扩展主库节点的读能力,有效应对大并发量的读操作。

缺点:

• 故障恢复复杂,如果没有 redis HA 系统(需要开发),当主库节点出现故障时,需要手动将一个从节点晋升为主节点,同时需要通知业务方变更配置,并且需要让其他从库节点去复制新主库节点,整个过程需要人为干预,比较繁琐。
• 主库的写能力受到单机的限制,可以考虑分片。
• 主库的存储能力受到单机的限制,可以考虑 Pika。（一款类redis存储系统,主要解决的是用户使用 redis 的内存大小超过 50G、80G 等等这样的情况,会遇到启动恢复时间长,一主多从代价大,硬件成本贵,缓冲区容易写满等问题。）

4.2 哨兵

当主数据库遇到异常中断服务后,开发者可以通过手动的方式选择一个从数据库来升格为主数据库,以使得系统能够继续提供服务。然而整个过程相对麻烦且需要人工介入,难以实现自动化。 为此,redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。
哨兵的作用就是监控redis主、从数据库是否正常运行,主出现故障自动将从数据库转换为主数据库。

顾名思义,哨兵的作用就是监控redis系统的运行状况。他的功能如下:

• 监控主从数据库是否正常运行
• master出现故障时,自动将slave转化为master
• 多哨兵配置的时候,哨兵之间也会自动监控
• 多个哨兵可以监控同一个redis

其中 redis Sentinel 集群是由若干 Sentinel 节点组成的分布式集群,可以实现故障发现、故障自动转移、配置中心和客户端通知。redis Sentinel 的节点数量要满足 2n+1(n>=1)的奇数个。

优点:

• redis Sentinel 集群部署简单;
• 能够解决 redis 主从模式下的高可用切换问题;
• 很方便实现 redis 数据节点的线形扩展,轻松突破 redis 自身单线程瓶颈,可极大满足 redis 大容量或高性能的业务需求;
• 可以实现一套 Sentinel 监控一组 redis 数据节点或多组数据节点。

缺点:

• 部署相对 redis 主从模式要复杂一些,原理理解更繁琐;
• 资源浪费,redis 数据节点中 slave 节点作为备份节点不提供服务;
• redis Sentinel 主要是针对 redis 数据节点中的主节点的高可用切换,对 redis 的数据节点做失败判定分为主观下线和客观下线两种,对于 redis 的从节点有对节点做主观下线操作,并不执行故障转移。
• 不能解决读写分离问题,实现起来相对复杂。

4.3 集群

redis Cluster 是 3.0 版后推出的 redis 分布式集群解决方案,主要解决 redis 分布式方面的需求,比如,当遇到单机内存,并发和流量等瓶颈的时候,redis Cluster 能起到很好的负载均衡的目的。redis Cluster 集群节点最小配置 6 个节点以上(3 主 3 从),其中主节点提供读写操作,从节点作为备用节点,不提供请求,只作为故障转移使用。redis Cluster 采用虚拟槽分区,所有的键根据哈希函数映射到 0～16383 个整数槽内,每个节点负责维护一部分槽以及槽所印映射的键值数据。

优点:

1. 无中心架构。
2. 数据按照 slot 存储分布在多个节点,节点间数据共享,可动态调整数据分布。
3. 可扩展性: 可线性扩展到 1000 多个节点,节点可动态添加或删除。
4. 高可用性: 部分节点不可用时,集群仍可用。通过增加 Slave 做 standby 数据副本,能够实现故障自动 failover,节点之间通过 gossip 协议交换状态信息,用投票机制完成 Slave 到 Master 的角色提升。
5. 降低运维成本,提高系统的扩展性和可用性。

缺点:

1. Client 实现复杂,驱动要求实现 Smart Client,缓存 slots mapping 信息并及时更新,提高了开发难度,客户端的不成熟影响业务的稳定性。目前仅 JedisCluster 相对成熟,异常处理部分还不完善,比如常见的“max redirect exception”。
2. 节点会因为某些原因发生阻塞(阻塞时间大于 clutser-node-timeout),被判断下线,这种 failover 是没有必要的。
3. 数据通过异步复制,不保证数据的强一致性。
4. 多个业务使用同一套集群时,无法根据统计区分冷热数据,资源隔离性较差,容易出现相互影响的情况。
5. Slave 在集群中充当“冷备”,不能缓解读压力,当然可以通过 SDK 的合理设计来提高 Slave 资源的利用率。
6. …

5. 持久化策略

两种: RDB 和 AOF；

RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照

AOF 持久化记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 redis 协议的格式来保存,新命令会被追加到文件的末尾。 redis 还可以在后台对 AOF 文件进行重写（rewrite）,使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。

redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下, 当 redis 重启时, 它会优先使用 AOF 文件来还原数据集, 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。你甚至可以关闭持久化功能,让数据只在服务器运行时存在。

5.1 RDB

优点:

RDB 是一个非常紧凑的文件,它保存了 redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份: 比如说,你可以在最近的 24 小时内,每小时备份一次 RDB 文件,并且在每个月的每一天,也备份一个 RDB 文件。 这样的话,即使遇上问题,也可以随时将数据集还原到不同的版本。

RDB 非常适用于灾难恢复（disaster recovery）: 它只有一个文件,并且内容都非常紧凑,可以（在加密后）将它传送到别的数据中心,或者亚马逊 S3 中。 RDB 可以最大化 redis 的性能: 父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程,然后这个子进程就会处理接下来的所有保存工作,父进程无须执行任何磁盘 I/O 操作。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

缺点:

如果你需要尽量避免在服务器故障时丢失数据,那么 RDB 不适合你。 虽然 redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率, 但是, 因为RDB 文件需要保存整个数据集的状态, 所以它并不是一个轻松的操作
因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下, 一旦发生故障停机, 你就可能会丢失好几分钟的数据。每次保存 RDB 的时候,redis 都要 fork() 出一个子进程,并由子进程来进行实际的持久化工作。 在数据集比较庞大时, fork() 可能会非常耗时,造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大,并且 CPU 时间非常紧张的话,那么这种停止时间甚至可能会长达整整一秒
虽然 AOF 重写也需要进行 fork() ,但无论 AOF 重写的执行间隔有多长,数据的耐久性都不会有任何损失。

5.2 AOF

优点:

对于相同的数据集来说,AOF 文件的体积通常要大于 RDB 文件的体积。根据所使用的 fsync 策略,AOF 的速度可能会慢于 RDB 。 在一般情况下, 每秒 fsync 的性能依然非常高, 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快, 即使在高负荷之下也是如此。
不过在处理巨大的写入载入时,RDB 可以提供更有保证的最大延迟时间（latency）。

缺点:

AOF 在过去曾经发生过这样的 bug : 因为个别命令的原因,导致 AOF 文件在重新载入时,无法将数据集恢复成保存时的原样。 （举个例子,阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。） 测试套件里为这种情况添加了测试: 它们会自动生成随机的、复杂的数据集, 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见, 但是对比来说, RDB 几乎是不可能出现这种 bug 的。

5.3 如何选？

一般来说,如果想达到足以媲美 PostgreSQL 的数据安全性, 你应该同时使用两种持久化功能。如果你非常关心你的数据,但仍然可以承受数分钟以内的数据丢失, 那么你可以只使用 RDB 持久化。有很多用户都只使用 AOF 持久化, 但我们并不推荐这种方式: 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份, 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快, 除此之外, 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。

6. 三大问题及解决方案

6.1 缓存穿透

在大多数互联网应用中,缓存的使用流程如下

1. 当业务系统发起某一个查询请求时,首先判断缓存中是否有该数据；
2. 如果缓存中存在,则直接返回数据；
3. 如果缓存中不存在,则再查询数据库,然后返回数据。

6.1.1 简介

业务系统要查询的数据根本就不存在！当业务系统发起查询时,按照上述流程,首先会前往缓存中查询,由于缓存中不存在,然后再前往数据库中查询。由于该数据压根就不存在,因此数据库也返回空。这就是缓存穿透。

6.1.2 危害

如果存在海量请求查询压根就不存在的数据,那么这些海量请求都会落到数据库中,数据库压力剧增,可能会导致系统崩溃（你要知道,目前业务系统中最脆弱的就是IO,稍微来点压力它就会崩溃,所以我们要想种种办法保护它）。

6.1.3 原因

发生缓存穿透的原因有很多,一般为如下两种:

1.恶意攻击,故意营造大量不存在的数据请求我们的服务,由于缓存中并不存在这些数据,因此海量请求均落在数据库中,从而可能会导致数据库崩溃。

2.代码逻辑错误。

6.1.4 解决方案

6.1.4.1 缓存空数据

之所以发生缓存穿透,是因为缓存中没有存储这些空数据的key,导致这些请求全都打到数据库上。

那么,我们可以稍微修改一下业务系统的代码,将数据库查询结果为空的key也存储在缓存中。当后续又出现该key的查询请求时,缓存直接返回null,而无需查询数据库。

**缓存空对象会有两个问题: **
第一,空值做了缓存,意味着缓存层中存了更多的键,需要更多的内存空间 ( 如果是攻击,问题更严重 ),比较有效的方法是针对这类数据设置一个较短的过期时间,让其自动剔除。
第二,缓存层和存储层的数据会有一段时间窗口的不一致,可能会对业务有一定影响。例如过期时间设置为 5 分钟,如果此时存储层添加了这个数据,那此段时间就会出现缓存层和存储层数据的不一致,此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。

6.1.4.2 BloomFilter

它需要在缓存之前再加一道屏障,里面存储目前数据库中存在的所有key,如下:

当业务系统有查询请求的时候,首先去BloomFilter中查询该key是否存在。若不存在,则说明数据库中也不存在该数据,因此缓存都不要查了,直接返回null。若存在,则继续执行后续的流程,先前往缓存中查询,缓存中没有的话再前往数据库中的查询。

这种方法适用于数据命中不高,数据相对固定实时性低（通常是数据集较大）的应用场景,代码维护较为复杂,但是缓存空间占用少。

6.1.4.3 两种方案的比较

这两种方案都能解决缓存穿透的问题,但使用场景却各不相同。

对于一些恶意攻击,查询的key往往各不相同,而且数据贼多。此时,第一种方案就显得提襟见肘了。因为它需要存储所有空数据的key,而这些恶意攻击的key往往各不相同,而且同一个key往往只请求一次。因此即使缓存了这些空数据的key,由于不再使用第二次,因此也起不了保护数据库的作用。

因此,对于空数据的key各不相同、key重复请求概率低的场景而言,应该选择第二种方案。而对于空数据的key数量有限、key重复请求概率较高的场景而言,应该选择第一种方案。

6.2 缓存雪崩

6.2.1 简介

通过上文可知,缓存其实扮演了一个保护数据库的角色。它帮数据库抵挡大量的查询请求,从而避免脆弱的数据库受到伤害。
如果缓存因某种原因发生了宕机,那么原本被缓存抵挡的海量查询请求就会像疯狗一样涌向数据库。此时数据库如果抵挡不了这巨大的压力,它就会崩溃。
这就是缓存雪崩。

6.2.2 如何避免缓存雪崩？

6.2.2.1 使用缓存集群,保证缓存高可用

和飞机都有多个引擎一样,如果缓存层设计成高可用的,即使个别节点、个别机器、甚至是机房宕掉,依然可以提供服务,例如前面介绍过的 redis Sentinel（哨兵） 和 redis Cluster（集群) 都实现了高可用。

6.2.2.2 使用Hystrix

Hystrix是一款开源的“防雪崩工具”,它通过 熔断、降级、限流三个手段来降低雪崩发生后的损失。

Hystrix就是一个Java类库,它采用命令模式,每一项服务处理请求都有各自的处理器。所有的请求都要经过各自的处理器。处理器会记录当前服务的请求失败率。一旦发现当前服务的请求失败率达到预设的值,Hystrix将会拒绝随后该服务的所有请求,直接返回一个预设的结果。这就是所谓的“熔断”。当经过一段时间后,Hystrix会放行该服务的一部分请求,再次统计它的请求失败率。如果此时请求失败率符合预设值,则完全打开限流开关；如果请求失败率仍然很高,那么继续拒绝该服务的所有请求。这就是所谓的“限流”。而Hystrix向那些被拒绝的请求直接返回一个预设结果,被称为“降级”。

6.3 缓存击穿（热点数据集中失效）

6.3.1 什么是热点数据集中失效？

我们一般都会给缓存设定一个失效时间,过了失效时间后,该数据库会被缓存直接删除,从而一定程度上保证数据的实时性。

但是,对于一些请求量极高的热点数据而言,一旦过了有效时间,此刻将会有大量请求落在数据库上,从而可能会导致数据库崩溃。

如果某一个热点数据失效,那么当再次有该数据的查询请求时就会前往数据库查询。但是,从请求发往数据库,到该数据更新到缓存中的这段时间中,由于缓存中仍然没有该数据,因此这段时间内到达的查询请求都会落到数据库上,这将会对数据库造成巨大的压力。此外,当这些请求查询完成后,都会重复更新缓存。

6.3.2 解决方案

6.3.2.1 互斥锁

此方法只允许一个线程重建缓存,其他线程等待重建缓存的线程执行完,重新从缓存获取数据即可。

当第一个数据库查询请求发起后,就将缓存中该数据上锁；此时到达缓存的其他查询请求将无法查询该字段,从而被阻塞等待；当第一个请求完成数据库查询,并将数据更新值缓存后,释放锁；此时其他被阻塞的查询请求将可以直接从缓存中查到该数据。

当某一个热点数据失效后,只有第一个数据库查询请求发往数据库,其余所有的查询请求均被阻塞,从而保护了数据库。但是,由于采用了互斥锁,其他请求将会阻塞等待,此时系统的吞吐量将会下降。这需要结合实际的业务考虑是否允许这么做。

互斥锁可以避免某一个热点数据失效导致数据库崩溃的问题,而在实际业务中,往往会存在一批热点数据同时失效的场景。那么,对于这种场景该如何防止数据库过载呢？

设置不同的失效时间

当我们向缓存中存储这些数据的时候,可以将他们的缓存失效时间错开。这样能够避免同时失效。如: 在一个基础时间上加/减一个随机数,从而将这些缓存的失效时间错开。

6.3.2.2 永远不过期

“永远不过期”包含两层意思:
从缓存层面来看,确实没有设置过期时间,所以不会出现热点 key 过期后产生的问题,也就是“物理”不过期。
从功能层面来看,为每个 value 设置一个逻辑过期时间,当发现超过逻辑过期时间后,会使用单独的线程去构建缓存。

从实战看,此方法有效杜绝了热点 key 产生的问题,但唯一不足的就是重构缓存期间,会出现数据不一致的情况,这取决于应用方是否容忍这种不一致。

6.3.3 两种方案比较

• 互斥锁 (mutex key): 这种方案思路比较简单,但是存在一定的隐患,如果构建缓存过程出现问题或者时间较长,可能会存在死锁和线程池阻塞的风险,但是这种方法能够较好的降低后端存储负载并在一致性上做的比较好。
• ” 永远不过期 “: 这种方案由于没有设置真正的过期时间,实际上已经不存在热点 key 产生的一系列危害,但是会存在数据不一致的情况,同时代码复杂度会增大。