Redis

一、Redis简介

一般为了提升性能，会在存储层和客户端之间添加一个缓存层，当客户端向后端发送请求的时候，会先去缓存层查，看看是否有相应的数据，如果有则直接返回，这样就减轻存储层的压力，如果缓存层没有相关数据，才会去到存储层去查询，这就是我们行业里所说的穿透。如果存储层有数据则会将数据返回给缓存层，以便客户端下次请求同样的数据时，可以直接从缓存层取数据，回写的过程就是回种，回种之后将结果返回给客户端，完成一次请求响应的操作。熔断：当发现存储层挂掉，可以让客户端的请求直接打在缓存层上，不管有没有获取到数据直接返回，因此缓存很重要。

1.1 缓存中间件：Memchache和Redis的区别

• Memchache：代码层次类似hash

  1. 支持简单数据类型

  2. 不支持数据持久化存储

  3. 不支持主从

  4. 不支持分片

• Redis

  1. 数据类型丰富

  2. 支持数据磁盘持久化存储

  3. 支持主从

  4. 支持分片（Redis3.0）

1.2 为什么Redis能这么快？

每秒10万+QPS（QPS即query per second,每秒的响应时间）

1. 完全基于内存，绝大部分请求时纯粹的内存操作，执行效率高

   Redis是支持单进程单线程模型的KV数据库，将数据存储在内存里面，读写数据不会受Io限制

2. 数据结构简单，对数据操作也简单

   Redis不使用表，他 当数据库不会预定义或者强制去要求用户对Redis存储的不同数据进行关联，因此性能相比关系型数据库 要高出不止一个量级，其存储结构类似于键值对HashMap

3. 采用单线程单线程也能处理高并发请求，想多核也可启动多实例

   Redis的单线程结构是指其主线程是单线程的，这里主线程包括IO时间的处理，以及io对象的相关业务请求处理，此外主线程还负责过期键的处理，机器协调等等。对于客户端的所有读写请求，都由一个主线程串行的处理，因此多个客户端对一个键进行读写操作的时候，就不会有并发的问题，避免了频繁的上下文切换和锁竞争，所以Redis执行起来效率更高

4. 使用多路IO复用模型，给堵塞IO

   redis是单线程，所有的操作按照顺序执行，由于读写操作等待用户输入或者输出都是阻塞的，所以IO操作在一般情况下往往不能直接返回，这会导致某一文件IO阻塞，进而导致整个进程无法对客户端进行服务，而IO多路复用就是解决这个问题

1.3 多路I/O复用模型

1.3.1 FD:File Descriptor，文件描述符

• 一个打开的文件通过唯一的描述符进行引用，该描述符是打开文件元数据到文件本身的映射。

1.3.2 传统的阻塞I/O模型

1.3.3 Select系统调用

selector负责监听文件是否可读可写的，监听的任务交给selector之后，程序就可以继续去做其他事情，而不被阻塞

1.3.4 redis采用的多路复用函数：epoll/kqueue/ecport/select 具体采用哪一个？

1. 因地制宜：redis可以在多个平台上运行，为了最大化提高执行效率，会根据平台的不同选用不同的多路复用函数

2. 优先选择时间复杂度为O(1)的I/O多路复用函数作为底层实现

3. 以时间复杂度为O(n)的select作为保底

4. 基于react设计模式监听I/O事件

二、Redis的数据类型

2.1 供用户使用的数据类型：

2.1.1 String：最基本的数据类型，二进制安全

• 就是我们经常使用的KV键值对，他的值最大可以存储512M。

• 二进制安全：redis的String可以包含任何数据，比如jpg图片，或者是序列化的对象，String支持这么多的数据类型，离不开底层的动态字符串sdshdr

2.1.2 Hash：String元素组成的字典，适合存储对象

2.1.3 List：列表，按String元素插入顺序排序

• 可以用于最新消息排行榜

2.1.4 set：String元素组成的集合，同坐hash表实现，不允许重复

2.1.5 sorted set：通过分数来为集合中的成员进行从小到大的排序

不允许重复元素，且元素有顺序.每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序

2.1.6 用于计数的HyperLogLog，用于支持存储地理位置信息的GEO

2.2 从海量数据中查出某一个固定前缀的key

SCAN cursor[MATCH pattern] [COUNT count]

1. 基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程

2. 以0作为游标开始一次新的迭代，直到命令返回游标0完成一次遍历

3. 不保证每次执行都返回某个给定数量的元素，支持模糊查询

4. 一次返回的数量不可控，只能是大概率符合count参数

三、如何提高Redis实现分布式锁

分布式锁是控制分布式系统或不同系统之间共同访问共享资源的一种锁的实现

3.1 分布式锁需要解决的问题

1. 互斥性：任意时刻只有一个客户端获取锁

2. 安全性：锁只有持有该锁的客户端删除，不能由其他客户端删除

3. 死锁：获取锁的客户端因为某些原因而宕机，而未能释放锁，其他客户端再也不能或得到该锁，而导致死锁，此时需要机制来容错

4. 容错：部分节点，如Redis节点宕机的时候，客户端仍然可以获取到锁，和释放锁

3.2 SETNX key value:如果key不存在，则创建并赋值

1. 时间复杂度：O(1)

2. 返回值：设置成功，返回1；失败，返回0

3.3 如何解决SETNX长期有效的问题

1、EXPIRE key seconds

1. 设置key的生存时间，当key过期时（生存时间为0），会被自动删除

2. 缺点：原子性得不到满足

2、SET 可以 value [EX seconds] [PX milliseconds] [NX|XX]

1. EX second:设置键的过期时间为second秒

2. PX millisecond：设置键的过期时间为millisecond毫秒

3. NX：只在键不存在时，才对键继续设置操作

4. XX：只在键已经存在时，才对键进行设置操作

5. SET操作成功时，返回OK，否则返回nil

3.4 大量的可以同时过期的注意事项

集中过期，由于清除大量的key很耗时，会出现短暂的卡顿现象

1. 解决方案：在设置key的过期时间的时候，给每个key加上随机值

3.5 如何使用Redis做异步队列

1、使用list作为队列，RPUSH生产消息，LPOP消费消息

1. 缺点：没有等待队列中有值才会去消费

2. 弥补：可以在应用层引入Sleep机制去调用LPOP重试

2、BLPOP key [key...] timeout:阻塞知道队列有消息或者超时

1. 缺点：只能供一个消费者消费

3、pub/sub:主题订阅者模式

1. 发布者（pub）发送消息，订阅者（sub）接受消息

2. 订阅者可以订阅任意数量的频道

3. pub/sub的缺点

   1. 消息的发布是无状态的，无法保证可达

   

4 Redis持久化

4.1 Redis如何做持久化（RDB）

1、RDB（快照）持久化：保存某个时间点的全量数据快照

1. SAVE：阻塞Redis的服务器进程，知道RDB文件被创建完毕

2. BGSAVE：Fork出一个子进程来创建RDB文件，不阻塞服务器进程

2、自动化触发RDB持久化的方式

1. 根据redis.com配置里的SAVE m n定时触发（用的是BGSAVE）

2. 主从复制时，主节点自动触发

3. 执行Debug Reload

4. 执行SHutdown且没有开启AOF持久化

3、Copy-on-Write

如果有多个调用者同时要求相同资源（如内存或磁盘上的数据存储），他们会共同获取相同指针指向相同的资源，直到某个调用者视图修改资源的内容时，系统才会真正复制一份专用副本给调用者，二其他调用者缩减到的最初的资源仍然保持不变。

4、RDB缺点

1. 内存数据的全量同步，数据量大会由于I/O而严重影响性能

2. 可能会因为Redis挂掉而丢失从当前至最近一次快照器件的数据

4.2 Redis如何做持久化（AOF）

1、AOP（Append-only-File）持久化：保存写状态

1. 记录下除了查询以外的所有变更数据库状态的指令

2. 以append的形式追加保存到AOP文件中（增量）

   AOF的持久化默认是关闭的. vim redis.conf

   appendonlyno. —>修改为 appendonly yes 生效

   appendfilename "append only.aof"

   appendfsync:可以指定AOF写入方式 :

   1.always 2.everysec 3.no

    

2、日志重写解决AOF文件大小不断增大的问题，原理如下

1. 调用fork（），创建一个子进程

2. 子进程把新的AOF写到一个临时文件里，不依赖原来的AOF文件

3. 主进程持续将新的变动同时写到内存和原来的AOF里

4. 主进程获取子进程重写AOF的完成信号，玩新AOF同步增量变动

5. 使用新的AOF文件替换掉旧的AOF文件

4.3 Redis数据的恢复

RDB和AOF文件共存情况下的恢复流程

4.4 总结RDB和AOF的优缺点

1. RDB优点：全量数据快照，文件小，恢复快

2. RDB缺点：无法保存最近一次快照之后的数据

3. AOF优点：可读性高，适合保存增量数据，数据不易丢失

4. AOF缺点：文件体积大，恢复时间长

RDB-AOF混合持久化的方式：

• BGSAVE做镜像全量持久化,AOF做增量持久化

5 Pipeline及主从同步

5.1 使用Pipeline的好处

1. Pipeline和Linux的管道类似

2. Redis基于请求/响应模型，单个请求处理需要——应答

3. Pipeline批量执行指令，节省多次IO往返的时间

4. 有顺序依赖的指令建议分批发送

5.2 Redis的同步机制

1、主从原理

2、全同步过程

1. Slave发送sync命令到master

2. master启动一个后台进程,将redis中的数据快照保存到文件中

3. master将保存快照期间收到的命令缓存起来

4. master完成写文件操作后,将该文件发送给salve

5. 使用新的AOF文件替换掉旧的AOF文件

6. master将这期间收到的写命令发送给salve,进行回放

3、增量同步工程

1. master接受用户的操作指令,判断是否需要传播到salve

2. 将操作记录追加到aof文件

3. 将操作传播到其他slave:1.对齐主从库 2.往响应缓存中写入指令

4. 将缓存中的数据发送给slave

4、Redis Sentinel（哨兵）

主从模式不具备高可用性,当master挂掉以后,slave将无法对外提供写入操作,为解决该问题,引入redis sentinel(哨兵)解决主从同步宕机后的主从切换问题

解决主从同步Master宕机后的主从切换问题：

• 监控：检查主从服务器是否运行正常

• 提醒:通过API向管理员或者其他应用程序发送故障通知

• 自动故障转移:主从切换

5、流言协议 Gossip

在杂乱无章中寻求一致

1. 每个节点都随机与对方通信,最终所有节点的状态达成一致。

2. 种子节点定期随机向其他节点发送节点列表以及需要传播的信息

3. 不保证信息一定会传递给所有的节点,但最终会趋于一致性。

6 Redis集群

6.1 如何从海量数据里快速找到所需？

1. 分片：按照某种规则去划分数据，分赛存储在多个节点上

2. 常规的按照哈希划分无法实现节点的动态增减