Redis

一、Redis简介

Memcache和Redis的区别

Memcache跟hash非常类似：

• 支持简单数据类型；
• 不支持数据持久化存储；
• 不支持主从同步；
• 不支持分片；

Redis:

• 数据类型丰富，set、list等；
• 支持数据持久化存储；
• 支持主从同步；
• 支持分片；

为什么Redis这么快

• 完全基于内存，绝大的部分请求是内存操作，执行效率高；

• 数据结构简单，对数据操作也简单；

•  采用单线程，处理高并发请求，想多核也可以启动多实例；

• 使用多路I/O复用模型，非阻塞I/O;

多路I/O复用模型

FD:File Descriptor,文件描述符

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

传统I/O阻塞模型：使用read或write时，如果当前FD不可读或不可写，整个Redis服务不会对其他的操作造成相应，整个服务不可用。

Select系统调用： 

Redis采用得到I/O多路复用函数：epoll/kqueue/evport/select

• 优先选择时间复杂度为O（1） 的I/O多路复用函数作为底层实现；
• 以时间复杂度为O（n）的select作为保底；
• 基于react设计模式监听I/O事件；

常用数据类型

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

hash：String元素组成的字典，适用于存储对象；

List：列表，按照String元素插入顺序排序，后进先出；

Set：String元素组成得到无序集合，通过哈希表实现，不允许重复；

Sorted Set：通过分数来为集合中成员进行从小到大对的排序；

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

海量数据查询

KEYS pattern：查找所有符合给定模式pattern的key；

1. 一次性返回所有key；

2. 键的数量过大会使服务卡顿；

SCAN cursor [MATCH pattern] [COUNT count]：每次执行返回少量数据

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

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

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

4. 一次返回数量不可控，大概率符合count参数；

二、通过Redis实现分布式锁

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

    互斥行、安全性、死锁、容错；

SETNX key value ：如果key不存在，则创建并赋值；

EXPIRE key seconds：设置key的生存时间，当key过期时（生存时间为0），会被自动删除；

SET key value [EX seconds] [PX milliseconds] [NX|XX]：设置过期时间为seconds秒，设置过期时间为milliseconds毫秒，NX在键不存在的时候操作，XX在键存在是进行操作，set完成时，返回OK，否则返回nil。

三、异步队列

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

缺点：队列里没有值就直接消费；

弥补：再应用层引入sleep机制 调用LPOP重试。

2. BLPOP key [key ...] timeout：阻塞直到队列有消息或超时；

缺点：只能让一个消费者消费；

3. pub/sub：主题订阅者模式

发送者（pub）发送消息，订阅者（sub）接收消息；

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

缺点：消息的发布是无状态的，无法保证到达；可以用消息队列如kafka；

四、持久化

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

SAVE：阻塞redis服务器进程，直到RDB文件创建完毕；

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

自动触发RDB持久化方式：

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

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

3. 执行Debug Reload；

4. 执行shutdown时，没有开启AOF持久化；

BGSAVE原理：

系统调用fork()：创建进程，实现Copy-On-write；

Copy-On-write：

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

RDB缺点：

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

2. 可能会因为redis挂掉丢失当前至最近一次快照之间的数据；

AOF（append-only-file）持久化

保存写状态：

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

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

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

调用Fork()，创建一个子进程；子进程把新的AOF文件写到一个临时文件里,不依赖原来的AOF文件；主进程持续将新的变动同时写到内存和原来的AOF文件中；主进程获取子进程重写AOF完成的信号，往新的AOF中同步增量变动；使用新的AOF替换旧的AOF文件。

Redis数据恢复

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

RDB和AOF优缺点：

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

RDB缺点：无法保证最近一次快照之后的数据；

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

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

混合模式：

RDB-AOF混合持久化方式（默认方式）：子进程在做AOF重写时，会通过管道从父进程读取增量数据并缓存，在以RDB保存全量数据时，也会从管道读取数据，同时不会造成管道阻塞。

用BGSAVE做镜像全量持久化，AOF做增量持久化。

五、Pipeline和主从同步

Pipeline和Linux管道相类似 ，批量执行命令，节省多次I/O往返时间，但是有顺序依赖的指令建议分批发送。

全量同步过程：

1. Salve发送sync命令到master‘

2. master启动一个后台进程，将Redis中对的数据快照保存到文件中；

3. master将保存数据快照期间接收到的写命令缓存起来；

4. master完成写文件操作后，将该文件发送给Salve；

5. 使用心动的AOF文件替换掉旧的AOF文件；

6. master将这期间收集的增量写命令发送给Salve端；

增量同步过程：

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

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

3. 将操作传播到其他Salve：对对齐主从库，往响应缓存写入指令；

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

哨兵

Redis Sentinel：解决主从同步master宕机后的主从切换问题：

监控：检查主动从服务器是否运作正常；

提醒：通过API向管理员过其他应用程序发送故障通知；

自动故障迁移：主从切换；

流言协议Gossip

反熵，在杂乱无章中寻求一致：

每个节点都随机与对方通信，最终所有节点的状态达成一致；

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

不保证信息一定会传递给所有节点，但是最终会趋于一致；

 

六、集群

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

采用一致性哈希算法：对2^32取模，将哈希值空间组织成虚拟的圆环；将数据key使用相同的函数Hsah计算出哈希值；