Redis知识点整理

引言：

redis高并发：主从架构，一主多从，一般来说，很多项目其实就足够了，单主用来写入数据，单机几万QPS，多从用来查询数据，多个从实例可以提供每秒10万的QPS。

redis高并发的同时，还需要容纳大量的数据：一主多从，每个实例都容纳了完整的数据，比如redis主就10G的内存量，其实你就最对只能容纳10g的数据量。如果缓存要容纳的数据量很大，达到了几十g，甚至几百g，或者是几t，那就需要redis集群，而且用redis集群之后，可以提供可能每秒几十万的读写并发。

redis高可用：如果做主从架构部署，其实就是加上哨兵就可以了，就可以实现，任何一个实例宕机，自动会进行主备切换。

---

redis和memcached的区别

1. Redis相比Memcached来说，拥有更多的数据结构和并支持，更丰富的数据操作
2. 由于Redis只使用单核，而Memcached可以使用多核
3. memcached没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；但是redis目前是原生支持cluster模式的，redis官方就是支持redis cluster集群模式的，比memcached来说要更好

redis的线程模型

参考：https://www.cnblogs.com/barrywxx/p/8570821.html

关键词：

1. 文件事件处理器 ： 套接字、 I/O 多路复用程序、 文件事件分派器（dispatcher）、 以及事件处理器
2. 文件事件的处理器 ： 连接应答处理器、命令请求处理器、命令回复处理器…
3. 基于 NIO多路复用

为啥redis单线程模型也能效率这么高？

1. 纯内存操作
2. 核心是基于非阻塞的IO多路复用机制
3. 单线程反而避免了多线程的频繁上下文切换问题

redis都有哪些数据类型？分别在哪些场景下使用比较合适？

1. String : 普通的set和get，做简单的kv缓存
2. hash : 类似map，主要是用来存放一些对象，把一些简单的对象给缓存起来，后续操作的时候，你可以直接仅仅修改这个对象中的某个字段的值

key=150

value={
  “id”: 150,
  “name”: “zhangsan”,
  “age”: 20
}

3. list ：存储一些列表型的数据结构；lrange命令实现分页查询；简单的消息队列，从list头放进去，从list尾巴取出来
4. set ：无序集合，自动去重(分布式) -> 共同好友
5. sorted set ：去重+排序，写进去的时候给一个分数，自动根据分数排序(可自定义排序规则)

redis的过期策略都有哪些？

1. set时设置过期时间(TTL)
2. 定期删除(随机抽取) ： redis默认是每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。
3. 惰性删除 ： 获取key时，redis会检查key，如果设置了过期时间，判断key是否过期？如果过期就会删除，不会返回值。
4. 内存淘汰机制(allkeys-lru) ： redis的内存占用过多的时候，此时会进行内存淘汰

内存淘汰机制都有哪些？

1. noeviction ： 当内存不足以容纳新写入数据时，新写入操作会报错
2. allkeys-lru ： 当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）
3. allkeys-random ： 当内存不足以容纳新写入数据时，在键空间中，随机移除某个key
4. volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key
5. volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key
6. volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除

手写一个LRU算法？

使用LinkedHashMap：

1. LinkedHashMap 构造函数，linkedhashmap按照访问顺序来进行排序，最近访问的放在头，最老访问的就在尾
2. removeEldestEntry

public class LRUCache<K, V> extends LinkedHashMap<K, V> {
    
	private final int CACHE_SIZE;

    // 这里就是传递进来最多能缓存多少数据
    public LRUCache(int cacheSize) {
        super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true); // 这块就是设置一个hashmap的初始大小，同时最后一个true指的是让linkedhashmap按照访问顺序来进行排序，最近访问的放在头，最老访问的就在尾
        CACHE_SIZE = cacheSize;
    }

    @Override
    protected boolean removeEldestEntry(Map.Entry eldest) {
        return size() > CACHE_SIZE; // 这个意思就是说当map中的数据量大于指定的缓存个数的时候，就自动删除最老的数据
    }

}

如果redis要支撑超过10万+（或更多）的并发，那应该怎么做？

前置： 单机redis一般在几万QPS

redis主从架构 -> 读写分离架构 -> 可支持水平扩展的读高并发架构

参考：https://juejin.im/post/5cb04d03e51d456e2b15f5da

redis replication的核心机制

（1）redis采用异步方式复制数据到slave节点，不过redis 2.8开始，slave node会周期性地确认自己每次复制的数据量
（2）一个master node是可以配置多个slave node的
（3）slave node也可以连接其他的slave node
（4）slave node做复制的时候，是不会block master node的正常工作的
（5）slave node在做复制的时候，也不会block对自己的查询操作，它会用旧的数据集来提供服务; 但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了
（6）slave node主要用来进行横向扩容，做读写分离，扩容的slave node可以提高读的吞吐量

slave和高可用性，有很大的关系

master持久化对于主从架构的安全保障的意义

如果采用了主从架构，建议必须开启master node的持久化！

原因一：

不建议用slave node作为master node的数据热备，因为那样的话，如果你关掉master的持久化，可能在master宕机重启的时候数据是空的，然后可能一经过复制，salve node数据也丢了

master -> RDB和AOF都关闭了 -> 全部在内存中

master宕机，重启，是没有本地数据可以恢复的，然后就会直接认为自己IDE数据是空的

master就会将空的数据集同步到slave上去，所有slave的数据全部清空

100%的数据丢失

原因二：

即使采用了哨兵架构（sentinal），slave node可以自动接管master node，但是也可能sentinal还没有检测到master failure，master node就自动重启了，还是可能导致上面的所有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如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。

主从复制的断点续传

从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份

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

但是如果没有找到对应的offset，那么就会执行一次full resynchronization

无磁盘化复制

master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了

repl-diskless-sync
repl-diskless-sync-delay：等待一定时长再开始复制，因为要等更多slave重新连接过来

过期key处理

slave不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。

主从复制的完整流程

1. slave node启动，仅仅保存master node的信息，包括master node的host和ip(redis.conf里面的slaveof配置)
2. slave node内部有个定时任务，每秒检查是否有新的master node要连接和复制，如果发现，就跟master node建立socket网络连接
3. slave node发送ping命令给master node
4. 口令认证，如果master设置了requirepass，那么salve node必须发送masterauth的口令过去进行认证
5. master node第一次执行全量复制，将所有数据发给slave node
6. master node后续持续将写命令，异步复制给slave node

数据同步相关的核心机制

指的就是第一次slave连接msater的时候，执行的全量复制

（1）master和slave都会维护一个offset

	master会在自身不断累加offset，slave也会在自身不断累加offset

	slave每秒都会上报自己的offset给master，同时master也会保存每个slave的offset

	这个倒不是说特定就用在全量复制的，主要是master和slave都要知道各自的数据的offset，才能知道互相之间的数据不一致的情况

（2）backlog

	master node有一个backlog，默认是1MB大小

	master node给slave node复制数据时，也会将数据在backlog中同步写一份

	backlog主要是用来做全量复制中断后的增量复制的

（3）master run id

	info server，可以看到master run id

	如果根据host+ip定位master node，是不靠谱的，如果master node重启或者数据出现了变化，那么slave node应该根据不同的run id区分，run id不同就做全量复制

	如果需要不更改run id重启redis，可以使用redis-cli debug reload命令

（4）psync

	从节点使用psync从master node进行复制，psync runid offset

	master node会根据自身的情况返回响应信息，可能是FULLRESYNC runid offset触发全量复制，可能是CONTINUE触发增量复制

全量复制

1. master执行bgsave，在本地生成一份rdb快照文件
2. master node将rdb快照文件发送给salve node，如果rdb复制时间超过60秒（repl-timeout），那么slave node就会认为复制失败，可以适当调节大这个参数
3. 对于千兆网卡的机器，一般每秒传输100MB，6G文件，很可能超过60s
4. master node在生成rdb时，会将所有新的写命令缓存在内存中，在salve node保存了rdb之后，再将新的写命令复制给salve node
5. client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么停止复制，复制失败
6. slave node接收到rdb之后，清空自己的旧数据，然后重新加载rdb到自己的内存中，同时基于旧的数据版本对外提供服务
7. 如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF

rdb生成、rdb通过网络拷贝、slave旧数据的清理、slave aof rewrite，很耗费时间

如果复制的数据量在4G~6G之间，那么很可能全量复制时间消耗到1分半到2分钟

增量复制

1. 如果全量复制过程中，master-slave网络连接断掉，那么salve重新连接master时，会触发增量复制
2. master直接从自己的backlog中获取部分丢失的数据，发送给slave node，默认backlog就是1MB
3. msater就是根据slave发送的psync中的offset来从backlog中获取数据的

heartbeat

主从节点互相都会发送heartbeat信息

master默认每隔10秒发送一次heartbeat，salve node每隔1秒发送一个heartbeat

异步复制

master每次接收到写命令之后，现在内部写入数据，然后异步发送给slave node

哨兵（sentinal）的介绍

哨兵是redis集群架构中非常重要的一个组件，主要功能如下：

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

故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题

即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了

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

哨兵（sentinal）的相关知识

1. 哨兵至少需要3个实例，来保证自己的健壮性
2. 哨兵 + redis主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性
3. 对于哨兵 + redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练

---

两种数据丢失的情况

主备切换的过程，可能会导致数据丢失

1. 异步复制导致的数据丢失

   因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了

2. 脑裂导致的数据丢失

   脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着

   此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master

   这个时候，集群里就会有两个master，也就是所谓的脑裂

   此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了

   因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据

解决异步复制和脑裂导致的数据丢失

min-slaves-to-write 1
min-slaves-max-lag 10

要求至少有1个slave，数据复制和同步的延迟不能超过10秒

如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了

上面两个配置可以减少异步复制和脑裂导致的数据丢失

1. 减少异步复制的数据丢失

有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内

2. 减少脑裂的数据丢失

如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求

这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失

上面的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求

因此在脑裂场景下，最多就丢失10秒的数据

---

Redis持久化机制

RDB和AOF两种持久化机制的介绍

RDB持久化机制，对redis中的数据执行周期性的持久化

AOF机制对每条写入命令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集

如果我们想要redis仅仅作为纯内存的缓存来用，那么可以禁止RDB和AOF所有的持久化机制

通过RDB或AOF，都可以将redis内存中的数据给持久化到磁盘上面来，然后可以将这些数据备份到别的地方去，比如说阿里云，云服务

如果redis挂了，服务器上的内存和磁盘上的数据都丢了，可以从云服务上拷贝回来之前的数据，放到指定的目录中，然后重新启动redis，redis就会自动根据持久化数据文件中的数据，去恢复内存中的数据，继续对外提供服务

如果同时使用RDB和AOF两种持久化机制，那么在redis重启的时候，会使用AOF来重新构建数据，因为AOF中的数据更加完整

RDB持久化机制的优点

1. RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去，比如说Amazon的S3云服务上去，在国内可以是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份redis中的数据
2. RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可
3. 相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速

RDB持久化机制的缺点

1. 如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据

2. RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒

AOF持久化机制的优点

1. AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据

2. AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复

3. AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。

4. AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

AOF持久化机制的缺点

1. 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大

2. AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的

3. 以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。所以说，类似AOF这种较为复杂的基于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF就是为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。

RDB和AOF到底该如何选择

1. 不要仅仅使用RDB，因为那样会导致你丢失很多数据

2. 也不要仅仅使用AOF，因为那样有两个问题，第一，你通过AOF做冷备，没有RDB做冷备，来的恢复速度更快; 第二，RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug

3. 综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复

---

redis cluster集群模式的原理

怎么才能够突破单机瓶颈，让redis支撑海量数据？

redis cluster : 支撑N个redis master node，每个master node都可以挂载多个slave node

1. 自动将数据进行分片，每个master上放一部分数据
2. 提供内置的高可用支持，部分master不可用时，还是可以继续工作的

读写分离的架构，对于每个master来说，写就写到master，然后读就从mater对应的slave去读

高可用，因为每个master都有salve节点，那么如果mater挂掉，redis cluster这套机制，就会自动将某个slave切换成master

redis cluster（多master + 读写分离 + 高可用）

我们只要基于redis cluster去搭建redis集群即可，不需要手工去搭建replication复制+主从架构+读写分离+哨兵集群+高可用

redis cluster vs. replication + sentinal

如果你的数据量很少，主要是承载高并发高性能的场景，比如你的缓存一般就几个G，单机足够了

replication，一个mater，多个slave，要几个slave跟你的要求的读吞吐量有关系，然后自己搭建一个sentinal集群，去保证redis主从架构的高可用性，就可以了

redis cluster，主要是针对海量数据+高并发+高可用的场景，海量数据，如果你的数据量很大，那么建议就用redis cluster

分布式数据存储的核心算法，数据分布的算法

hash算法 -> 一致性hash算法（memcached） -> redis cluster，hash slot算法

1. 最老土的hash算法

   大量缓存重建 ： 某一个 master 宕机 或 新增机器，就会导致之前大部分缓存没发拿到（几乎100%）

2. 一致性hash算法（自动缓存迁移）+ 虚拟节点（自动负载均衡）

   参考 ： https://blog.youkuaiyun.com/maihilton/article/details/81979361

   一致性hash算法（自动缓存迁移）

   问题 ： Master 热点问题，某个Hash区别内的值特别多，会导致大量的数据都涌入一个master内

   虚拟节点（自动负载均衡）

3. redis cluster的hash slot算法

   redis cluster有固定的16384个hash slot，对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot

   redis cluster中每个master都会持有部分slot，比如有3个master，那么可能每个master持有5000多个hash slot

   hash slot让node的增加和移除很简单，增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去

   移动hash slot的成本是非常低的

   客户端的api，可以对指定的数据，让他们走同一个hash slot，通过hash tag来实现

---

总结：

redis高并发：主从架构，一主多从，一般来说，很多项目其实就足够了，单主用来写入数据，单机几万QPS，多从用来查询数据，多个从实例可以提供每秒10万的QPS。

redis高并发的同时，还需要容纳大量的数据：一主多从，每个实例都容纳了完整的数据，比如redis主就10G的内存量，其实你就最对只能容纳10g的数据量。如果缓存要容纳的数据量很大，达到了几十g，甚至几百g，或者是几t，那就需要redis集群，而且用redis集群之后，可以提供可能每秒几十万的读写并发。

redis高可用：如果做主从架构部署，其实就是加上哨兵就可以了，就可以实现，任何一个实例宕机，自动会进行主备切换。

参考：中华石衫资料