目录
Redis 基础详解
一、Redis 是什么
Redis 是一个使用 C 语言写成的，开源的、key-value 结构的、非关系型数据库。它支持存储的 value 类型相对更多，包括 String(字符串)、List(列表)、Set(集合)、Sorted Set(有序集合) 和 Hash(哈希)，而且这些操作都是原子性的。在此基础上，Redis 支持各种不同方式的排序。为了保证效率，数据都是缓存在内存中。Redis 可以周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。
使用 Redis 有哪些好处？
· 速度快，因为数据存在内存中；
· 支持丰富数据类型，支持 string，list，set，sorted set，hash等；
· 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行；
· 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除；
二、单线程？
为什么 Redis 是单线程的？
Redis 的数据存储在内存中，如果数据全都在内存里，单线程的去操作就是效率最高的。
为什么呢？因为多线程的本质就是 CPU 模拟出来多个线程的情况，这种模拟出来的情况就有一个代价，就是上下文的切换，对于一个内存的系统来说，它没有上下文的切换就是效率最高的。因为上下文切换所花费的时间远大于直接从内存中读取数据所花费的时间。
Redis 用单个 CPU 绑定一块内存的数据，然后针对这块内存的数据进行多次读写的时候，都是在一个CPU上完成的，所以它是单线程处理这个事。在内存的情况下，这个方案就是最佳方案。
这里我们一直在强调的单线程，只是在处理我们的网络请求的时候只有一个线程来处理，一个正式的 Redis Server 运行的时候肯定是不止一个线程的，例如 Redis 进行持久化的时候会以子进程或者子线程的方式执行。
Redis 单线程如何处理那么多的并发客户端连接？
Redis的IO多路复用：redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，依次放到文件事件分派器，事件分派器将事件分发给事件处理器。
三、Redis 数据类型
1、String
String 数据结构是简单的 key-value 类型，value 其实不仅可以是 String，也可以是数字。需要注意是一个键值最大存储 512MB。
2、Hash（哈希）
Hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。 比如我们可以 Hash 数据结构来存储用户信息，商品信息等等。
3、List（列表）
是 Redis 的简单的字符串列表。list 的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销。
4、Set
Set 对外提供的功能与 list 类似是一个列表的功能，特殊之处在于 set 不允许重复元素，可以自动排重的，并且 set 提供了判断某个成员是否在一个 set 集合内的重要接口，这个也是 list 所不能提供的。
在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis 可以非常方便的实现如共同关注、共同喜好、二度好友等功能。
5、Sorted Set
与 set 相比，Sorted set 增加了一个权重参数 score，使得集合中的元素能够按 score 进行有序排列。
举例： 在直播系统中，实时排行信息包含直播间在线用户列表，各种礼物排行榜，弹幕消息（可以理解为按消息维度的消息排行榜）等信息，适合使用 Sorted set 结构进行存储。
四、Redis 数据持久化存储
上面说了 Redis 是基于内存的数据库，一旦进程退出，数据就会丢失，所以我们需要它也可以把数据写到磁盘上，当 Redis 重启后，可以从磁盘中恢复数据。
Redis 提供了两种解决方案将内存中的数据保存到磁盘上。一种是 RDB 持久化，原理是将 Reids 在内存中的全部数据库记录定时 dump 到磁盘上的 RDB 持久化；另外一种是 AOF 持久化，原理是将 Reids 的操作日志以追加的方式写入文件。
1、RDB快照（snapshot）
RDB 是 Redis 用来进行持久化的一种方式，是把当前内存中的数据集快照写入磁盘，也就是 Snapshot 快照所有数据。恢复时是将快照文件直接读到内存里。
在默认情况下， Redis 将内存数据库快照保存在名字为dump.rdb的二进制文件中。
你可以对 Redis 进行设置， 让它在N秒内数据集至少有M个改动这一条件被满足时， 自动保存一次数据集。
save 60 1000
redis.conf文件里面有默认的3种情况，3种是或的关系
RDB 存储的劣势：
- RDB 方式数据没办法做到实时持久化，该方式是每间隔一段时间做一次备份。因为 bgsave 每次运行都要执行 fork 操作创建子进程，属于重量级操作，频繁执行成本过高。所以如果 Redis 意外挂掉，就会丢失最后一次快照后的所有修改；
- RDB 是内存数据的全量同步，数据量大会由于 I/O 而严重影响性能；
RDB 文件使用特定二进制格式保存，Redis 版本演进过程中有多个格式的 RDB 版本，旧版本无法兼容新版的格式。
2、AOF(Append Only File)
AOF 持久化：记录除了查询以外，所有变更数据库状态的指令，以 append 的形式追加保存到 AOF 文件中。AOF 文件通常会比 RDF 文件体积更大。
快照功能并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化，将修改的每一条指令记录进文件
你可以通过修改配置文件来打开 AOF 功能：
appendonly yes
开启后，每当 Redis 执行一个改变数据集的命令时（比如SET）， 这个命令就会被追加到 AOF 文件的末尾。
这样的话， 当 Redis 重新启时， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。
你可以配置 Redis 多久才将数据fsync到磁盘一次。
有三个选项：
每次有新命令追加到 AOF 文件时就执行一次fsync：非常慢，也非常安全。
每秒fsync一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。
从不fsync：将数据交给操作系统来处理。更快，也更不安全的选择。
推荐（并且也是默认）的措施为每秒fsync一次， 这种fsync策略可以兼顾速度和安全性。
RDB 和 AOF ，我应该用哪一个？
如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。
有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。
3、RDB-AOF 混合模式
混合模式是先使用 bgsave 以 RDB 形式将内存中的全部数据写入磁盘，之后当有新的数据时，再使用 AOF 的形式追加到文件中。
aof-use-rdb-preamble yes
五、Redis 应用
1、模糊查询
Redis 中有 1 亿个 key，其中有 10 万个 key 是已知的某个固定前缀，如何将找出这些 key。
当问题是：如何找出某一前缀的 key。这里需要注意数据规模是多大，再结合实际场景去解决。
如果数据量小，可以使用 keys 命令来查询。
但是，如果数据量大，而 Redis 正在线上运行，使用 keys 命令很可能会阻塞 Redis，使其不能提供服务。
这时可以使用 SCAN cursor [MATCH pattern] [COUNT count] 命令。需要注意的是条命令返回的数量是不可控的，只能大概符合 count。
cursor 从 0 开始，这里第一个返回值为 cursor 用于下一次迭代，当 cursor 再次为 0 时，说明迭代完成。
2、如何通过 Redis 实现分布式锁
首先想到的方法是使用 SETNX key value，如果 key 不存在，则创建并赋值，返回 1；若 key 已存在，则创建失败，返回 0。
当某一个线程通过 SETNX key value 设置成功后占用该资源，其他线程执行该命令就会设置失败，说明已经有线程占用该资源，通过这种方式来实现分布式锁。
同时，为了防止死锁，还需要设置 key 的过期时间 EXPIRE key second，设置 key 的过期时间，经过 second 秒后 key 会被删除。
虽然 Redis 中每个命令都满足原子性，但两个命令组合起来不满足了，例如若设置锁后，程序挂了，来不及设置过期时间，那么这个锁就无法释放了。
所以我们需要把上面两个命令结合起来的命令 SET key value [EX seconds] [PX milliseconds] [NX|XX]，其中 NX 是 key 不存在时设置成功，XX 是 key 存在时设置成功。例如：
这里还需要注意，不要让大量的 key 在同一时间过期，因为删除大量的 key 很耗时，会出现卡顿现象。所以我们可以在设置 key 的过期时间时，加上一个随机值来避免。
3、使用 Redis 实现消息队列
使用 List 作为队列，RPUSH 生产消息，LPOP 消费消息。
但是这样有个缺点，就是只能一对一的消息通信，所以还可以使用 pub/sub 主题订阅者模式，发送者(pub)使用 PUBLISH channel message 发送消息，订阅者(sub)使用 SUBSCRIBE channel 接受消息，并且订阅者可以接收任意数量的 channel。
但是消息的发布是无状态的，无法保证可达性。
4、redis string与hash的数据差别
网路传输时候，必须要进行进行序列化，才可以进行网路传输，那么在使用string类型的类型的时候需要进行相关序列化，hash也是要进行相关的系列化，所以会存在很多序列化，在存储的时候hash是可以存储的更加丰富，但是在反序列化的时候，string的反序列化相对较低，而hash的序列化和返序列化是相对hash类更加复杂，所以看业务场景，如果是数据经常修改的那种，为了性能可以使用string，如果是数据不是经常改的那种就可以使用hash，由于hash，存储数据时比较丰富，可以存储多种数据类型
5、Redis主挂了怎么操作
redis提供了哨兵模式，当主挂了，可以选举其他的进行代替，哨兵模式的实现原理，就是三个定时任务监控，
1 每隔10s，每个S节点（哨兵节点）会向主节点和从节点发送info命令获取最新的拓扑结构
2 每隔2s，每个S节点会向某频道上发送该S节点对于主节点的判断以及当前Sl节点的信息，
同时每个Sentinel节点也会订阅该频道，来了解其他S节点以及它们对主节点的判断（做客观下线依据）
3 每隔1s，每个S节点会向主节点、从节点、其余S节点发送一条ping命令做一次心跳检测(心跳检测机制)，来确认这些节点当前是否可达
当三次心跳检测之后，就会进行投票，当超过半数以上的时候就会将该节点当做主
6、Redis集群
redis集群在3.0以后提供了ruby脚本进行搭建，引入了糙的概念，
Redis集群内节点通过ping/pong消息实现节点通信，消息不但可以传播节点槽信息，还可以传播其他状态如：主从状态、节点故障等。因此故障发现也是通过消息传播机制实现的，主要环节包括：主观下线（pfail）和客观下线（fail）
主观下线：集群中每个节点都会定期向其他节点发送ping消息，接收节点回复pong消息作为响应。如果通信一直失败，则发 送节点会把接收节点标记为主观下线（pfail）状态。
客观下线：超过半数，对该主节点做客观下线
主节点选举出某一主节点作为领导者，来进行故障转移。
故障转移（选举从节点作为新主节点）
7、内存淘汰策略
Redis的内存淘汰策略是指在Redis的用于缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据。
noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。
allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。
allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。
volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。
volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。
volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。
8、缓存穿透（DB的key为空）
业务系统要查询的数据根本就不存在！当业务系统发起查询时，按照上述流程，首先会前往缓存中查询，由于缓存中不存在，然后再前往数据库中查询。由于该数据压根就不存在，因此数据库也返回空。这就是缓存穿透。
综上所述：业务系统访问压根就不存在的数据，就称为缓存穿透。
危害：如果存在海量请求查询压根就不存在的数据，那么这些海量请求都会落到数据库中，数据库压力剧增，可能会导致系统崩溃
解决方案：
空值缓存
将数据库查询结果为空的key也存储在缓存中。当后续又出现该key的查询请求时，缓存直接返回null，而无需查询数据库，针对这类数据设置一个较短的过期时间，让其自动剔除。
缺点：空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 ( 如果是攻击，问题更严重 )
BloomFilter（布隆过滤器）
它需要在缓存之前再加一道屏障，里面存储目前数据库中存在的所有key。当业务系统有查询请求的时候，首先去BloomFilter中查询该key是否存在。若不存在，则说明数据库中也不存在该数据，因此缓存都不要查了，直接返回null。若存在，则继续执行后续的流程，先前往缓存中查询，缓存中没有的话再前往数据库中的查询。
缺点：这种方法适用于数据命中不高，数据相对固定实时性低（通常是数据集较大）的应用场景，代码维护较为复杂，但是缓存空间占用少。
9、缓存雪崩（服务宕机）
如果缓存因某种原因发生了宕机，那么原本被缓存抵挡的海量查询请求就会像疯狗一样涌向数据库。此时数据库如果抵挡不了这巨大的压力，它就会崩溃。
解决方法：
1 使用缓存集群，保证缓存高可用，redis集群，通过集群方式将数据放置
2 后端服务降级和限流，专业工具使用Hystrix，Hystrix是一款开源的“防雪崩工具”，它通过 熔断、降级、限流三个手段来降低雪崩发生后的损失。
Hystrix就是一个Java类库，它采用命令模式，每一项服务处理请求都有各自的处理器。所有的请求都要经过各自的处理器。处理器会记录当前服务的请求失败率。一旦发现当前服务的请求失败率达到预设的值，Hystrix将会拒绝随后该服务的所有请求，直接返回一个预设的结果。这就是所谓的“熔断”。当经过一段时间后，Hystrix会放行该服务的一部分请求，再次统计它的请求失败率。如果此时请求失败率符合预设值，则完全打开限流开关；如果请求失败率仍然很高，那么继续拒绝该服务的所有请求。这就是所谓的“限流”。而Hystrix向那些被拒绝的请求直接返回一个预设结果，被称为“降级”。
后端服务降级和限流：当一个接口请求次数过多，那么就会添加过多数据，可以对服务进行限流，限制访问的数量，这样就可以减少问题的出现
10、缓存击穿（热点数据集中失效）
热点数据集中失效，我们一般都会给缓存设定一个失效时间，过了失效时间后，该数据库会被缓存直接删除，从而一定程度上保证数据的实时性。
但是，对于一些请求量极高的热点数据而言，一旦过了有效时间，此刻将会有大量请求落在数据库上，从而可能会导致数据库崩溃。
解决方案：
互斥锁：此方法只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可。
永远不过期：
此方法有效杜绝了热点 key 产生的问题，但唯一不足的就是重构缓存期间，会出现数据不一致的情况，这取决于应用方是否容忍这种不一致。
11、ZSET跳跃表
跳跃表是一种有序数据结构，它实现了同二分查找一样的平均 O(logN)、最坏 O(N) 复杂度的节点查找。由于它的效率可以和平衡树相媲美，而实现又比平衡树简单，因此很多情况下可以用来代替平衡树。
跳跃表在 Redis 中不如链表和字典等数据结构的应用广泛，只有两个地方用到。一是实现有序集合键，另一个是在集群节点中用作内部数据结构。
12、Redis跳表为何不用树
跳表是一种随机化的数据结构，目前开源软件 Redis 和 LevelDB 都有用到它，它的效率和红黑树以及 AVL 树不相上下，但跳表的原理相当简单
redis使用跳表不用B+数的原因是：redis是内存数据库，而B+树纯粹是为了mysql这种IO数据库准备的。B+树的每个节点的数量都是一个mysql分区页的大小
因为B+树的原理是 叶子节点存储数据，非叶子节点存储索引，B+树的每个节点可以存储多个关键字，它将节点大小设置为磁盘页的大小，充分利用了磁盘预读的功能。每次读取磁盘页时就会读取一整个节点,每个叶子节点还有指向前后节点的指针，为的是最大限度的降低磁盘的IO;因为数据在内存中读取耗费的时间是从磁盘的IO读取的百万分之一
而Redis是 内存中读取数据，不涉及IO，因此使用了跳表
下面的结构是就是跳表：
其中 -1 表示 INT_MIN， 链表的最小值，1 表示 INT_MAX，链表的最大值。
跳表具有如下性质：
(1) 由很多层结构组成
(2) 每一层都是一个有序的链表
(3) 最底层(Level 1)的链表包含所有元素
(4) 如果一个元素出现在 Level i 的链表中，则它在 Level i 之下的链表也都会出现。
(5) 每个节点包含两个指针，一个指向同一链表中的下一个元素，一个指向下面一层的元素。
跳表的搜索
例子：查找元素 117
(1) 比较 21， 比 21 大，往后面找
(2) 比较 37, 比 37大，比链表最大值小，从 37 的下面一层开始找
(3) 比较 71, 比 71 大，比链表最大值小，从 71 的下面一层开始找
(4) 比较 85， 比 85 大，从后面找
(5) 比较 117， 等于 117， 找到了节点。
跳表的插入
先确定该元素要占据的层数 K（采用丢硬币的方式，这完全是随机的）
然后在 Level 1 … Level K 各个层的链表都插入元素。
例子：插入 119， K = 2
如果 K 大于链表的层数，则要添加新的层。
例子：插入 119， K = 4
丢硬币决定 K
插入元素的时候，元素所占有的层数完全是随机的，通过一下随机算法产生：
相当与做一次丢硬币的实验，如果遇到正面，继续丢，遇到反面，则停止，
用实验中丢硬币的次数 K 作为元素占有的层数。显然随机变量 K 满足参数为 p = 1/2 的几何分布，
K 的期望值 E[K] = 1/p = 2. 就是说，各个元素的层数，期望值是 2 层。
跳表的删除
在各个层中找到包含 x 的节点，使用标准的 delete from list 方法删除该节点。
例子：删除 71
跳表的高度
n 个元素的跳表，每个元素插入的时候都要做一次实验，用来决定元素占据的层数 K，
跳表的高度等于这 n 次实验中产生的最大 K
跳表的空间复杂度分析
根据上面的分析，每个元素的期望高度为 2， 一个大小为 n 的跳表，其节点数目的
期望值是 2n
13、Redis的哨兵机制
什么是哨兵机制?
Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:
监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。
哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议
来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。
每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).
若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"
哨兵(sentinel) 的一些设计思路和zookeeper非常类似。
Sentinel的工作方式:
1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令。
2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。
3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 。
5)：在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 。
6)：当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 。
7)：若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。
若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。
971
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
