Redis从入门到放弃

程序员文章站 2024-03-16 11:55:04

...

一、Redis概述
　　
　　Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。它通常被称为数据结构服务器，因为值（value）可以是字符串(String), 哈希(Hash), 列表(list), 集合(sets) 和有序集合(sorted sets)等类型。

二、Redis与Memcached比较

Redis拥有更多的数据结构和并支持更丰富的数据操作
memcached没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；最新版本redis官方就是支持redis cluster集群模式的，比memcached来说要更好
Redis支持数据的持久化，宕机重启后可以恢复,而Memecache把数据全部存在内存之中
.Memcached是多线程，非阻塞IO复用的网络模型；Redis使用单线程的IO复用模型。

三、为啥使用Redis

性能，频繁访问，并且不会经常变动的数据放在Redis 中可以减少执行SQL的时间，而且纯内存操作，可以快速响应，提高性能。
并发，在高并发的情况下，如果所有的请求直接访问数据库，数据库会扛不住的。这个时候，就需要使用redis做一个缓冲操作，让请求先访问到redis，redis中没有查询的数据才去访问数据库，而不是直接访问数据库。

四、使用redis会可能带来的问题

缓存和数据库双写一致性问题
缓存雪崩问题
缓存击穿问题
缓存的并发竞争问题

五、Redis单线程模型

到这里肯定会有个疑问，为啥单线程的Redis能抗住数万级并发？性能如此好？通常情况下多线程的工作效率会比单线程的高，举个例子，20人团队出去旅游，每辆车载5个，一辆车需要来回4次才能载完，如果搞4辆车，一次就能载到目的地，这样效率肯定更高。那为啥Redis的单线程模型有如此高的性能，主要原因有以下：

纯内存操作
核心是基于非阻塞的IO多路复用机制，使用epoll作为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多的时间
单线程反而避免了多线程的频繁上下文切换问题

下面来看Redis的单线程模型示意图
Redis从入门到放弃
　1）文件事件处理器
　　　redis基于reactor模式开发了网络事件处理器，这个处理器叫做文件事件处理器，这个文件事件处理器，是单线程的，redis才叫做单线程的模型，采用IO多路复用机制同时监听多个socket，根据socket上的事件来选择对应的事件处理器来处理这个事件。
　　　如果被监听的socket准备好执行accept、read、write、close等操作的时候，跟操作对应的文件事件就会产生，这个时候文件事件处理器就会调用之前关联好的事件处理器来处理这个事件。
　　　文件事件处理器是单线程模式运行的，但是通过IO多路复用机制监听多个socket，可以实现高性能的网络通信模型，又可以跟内部其他单线程的模块进行对接，保证了redis内部的线程模型的简单性。
　　　文件事件处理器的结构包含4个部分：多个socket，IO多路复用程序，文件事件分派器，事件处理器（命令请求处理器、命令回复处理器、连接应答处理器，等等）。
　　　多个socket可能并发的产生不同的操作，每个操作对应不同的文件事件，但是IO多路复用程序会监听多个socket，但是会将socket放入一个队列中排队，每次从队列中取出一个socket给事件分派器，事件分派器把socket给对应的事件处理器。
　　　然后一个socket的事件处理完之后，IO多路复用程序才会将队列中的下一个socket给事件分派器。文件事件分派器会根据每个socket当前产生的事件，来选择对应的事件处理器来处理。
　2）文件事件
　　　当socket变得可读时（比如客户端对redis执行write操作，或者close操作），或者有新的可以应答的sccket出现时（客户端对redis执行connect操作），socket就会产生一个AE_READABLE事件。当socket变得可写的时候（客户端对redis执行read操作），socket会产生一个AE_WRITABLE事件。
　　　IO多路复用程序可以同时监听AE_REABLE和AE_WRITABLE两种事件，要是一个socket同时产生了AE_READABLE和AE_WRITABLE两种事件，那么文件事件分派器优先处理AE_REABLE事件，然后才是AE_WRITABLE事件。
　3）文件事件分派器
　　　针对客户端的操作转化为事件，通过文件事件分派器派发到响应的处理器，完成相关操作。
　　　如果是客户端要连接redis，那么会为socket关联连接应答处理器
　　　如果是客户端要写数据到redis，那么会为socket关联命令请求处理器
　　　如果是客户端要从redis读数据，那么会为socket关联命令回复处理器
　4）客户端与redis通信的一次流程
　　　在redis启动初始化的时候，redis会将连接应答处理器跟AE_READABLE事件关联起来，接着如果一个客户端跟redis发起连接，此时会产生一个AE_READABLE事件，然后由连接应答处理器来处理跟客户端建立连接，创建客户端对应的socket，同时将这个socket的AE_READABLE事件跟命令请求处理器关联起来。
　　　当客户端向redis发起请求的时候（不管是读请求还是写请求，都一样），首先就会在socket产生一个AE_READABLE事件，然后由对应的命令请求处理器来处理。这个命令请求处理器就会从socket中读取请求相关数据，然后进行执行和处理。
　　　接着redis这边准备好了给客户端的响应数据之后，就会将socket的AE_WRITABLE事件跟命令回复处理器关联起来，当客户端这边准备好读取响应数据时，就会在socket上产生一个AE_WRITABLE事件，会由对应的命令回复处理器来处理，就是将准备好的响应数据写入socket，供客户端来读取。
　　　命令回复处理器写完之后，就会删除这个socket的AE_WRITABLE事件和命令回复处理器的关联关系。

六、Redis常用的数据类型和场景

string
常规的get/set操作，key value形式,一般用来做一些简单的k，v缓存
hash
这个是类似map的一种结构，一般就是可以将结构化的数据放入value，比如用来存储用户登录成功返回的信息，以cookieId作为key，设置30分钟为缓存过期时间，过期后就要求重新登录
list
使用List的数据结构，可以做简单的消息队列的功能。另外还有一个就是，可以利用lrange命令，做基于redis的分页功能，性能极佳，用户体验好，还可以用来存储粉丝，好友列表等。
set
无序集合，自动去重，可以基于set做交集、并集、差集的操作，比如交集吧，可以把两个人的好友列表做交集就知道他们共同的好友
sorted set
排序的set，去重但是可以排序，写进去的时候给一个分数，自动根据分数排序，比如排行榜，zrevrange 0 100 获取排名前100名，zrank 可以看到在排行榜里的排名

七、Redis数据过期策略和内存淘汰机制

Redis数据过期策略：定期删除+惰性删除
　　定期删除：指的是redis默认是每隔100ms（或者说每秒10次）就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。假设redis里放了10万个key，都设置了过期时间，每隔几百毫秒，就检查10万个key，那redis基本上就死了，cpu负载会很高的，消耗在检查过期key上了，这样就是一场性能上的灾难，所以每隔100ms检查不是遍历所有的设置过期时间的key，而是redis每隔100ms随机抽取一些key来检查和删除的。
定期删除存在的问题：定期删除可能会导致很多过期key到了时间并没有被删除掉，因为他是一个随机抽取的过程。
　　惰性删除：获取某个key的时候，redis会检查一下这个key ，如果设置了过期时间并且过期了就会删除，不会返回该key的值
通过上述两种手段结合起来，保证过期的key一定会被干掉。但是也存在一些问题，定期删除漏掉了很多过期key，也没及时去查（就是去调用key），也就没走惰性删除，这样就有可能大量过期key堆积在内存里，导致redis内存块耗尽了。

Redis内存淘汰机制可以解决上述问题，内存淘汰机制有以下几种策略：

noeviction 当内存不足以容纳新写入数据时，新写入操作会报错，这种一般不会使用，太不友好了
allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）
allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key，这个一般也不会使用，随机偶然性太大了，会产生问题
volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key，这个一般也不会
volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key，这个一般也不会
volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除

八、Redis持久化　
　　数据持久化的必要性，持久化主要是做灾难恢复，数据恢复，如果Redis宕机了，重启redis，如果没做数据备份，数据没了，这时候来了大量请求，缓存全部无法命中，所有请求都会涌入数据库，然后数据库扛不住压力挂掉了，整个系统就无法使用，这就引起了缓存雪崩问题。因此Redis持久化也是高可用的一部分。

Redis持久化机制：RDB和AOF
RDB持久化：够在指定的时间间隔能对你的数据进行快照存储
1）工作方式：

Redis 调用forks。同时拥有父进程和子进程。
子进程将数据集写入到一个临时 RDB 文件中。当子进程完成对新 RDB
文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件

2）触发条件

1 配置文件中设置在指定的时间间隔内，执行指定次数的写操作
2 执行save（阻塞，只管保存快照，其他的等待）或者是bgsave （异步）命令
3 执行flushall 命令，清空数据库所有数据。
4 执行shutdown命令，保证服务器正常关闭且不丢失任何数据。

3）RDB持久化机制的优点

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

4）RDB持久化机制的缺点

如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据
RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒

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

5)AOF持久化机制的优点

AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据
AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复
AOF日志文件即使过大的时候，出现后台重写(rewrite)操作，也不会影响客户端的读写。rewrite会像replication一样，fork出一个子进程，创建一个临时文件，遍历数据库，将每个key、value对输出到临时文件。输出格式就是Redis的命令，但是为了减小文件大小，会将多个key、value对集合起来用一条命令表达。在rewrite期间的写操作会保存在内存的rewrite buffer中，rewrite成功后这些操作也会复制到临时文件中，在最后临时文件会代替AOF文件。
AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

6)AOF持久化机制的缺点

对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的

7）生成环境如何选择持久化方式

不要仅仅使用RDB，因为那样会导致你丢失很多数据。
也不要仅仅使用AOF，因为那样有两个问题，第一，你通过AOF做冷备，没有RDB做冷备，来的恢复速度更快; 第二，RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug。
综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择;用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复。

八、redis高可用架构-----主从架构+哨兵集群
Redis从入门到放弃
1、主从架构的核心原理
　　当启动一个slave node的时候，它会发送一个PSYNC命令给master node，如果是slave node第一次连接master node，那么会触发一次full resynchronization，如果是slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据; 开始full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。

2、主从复制的断点续传
　从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份，master node会在内存中常见一个backlog，master和slave都会保存一个replica offset还有一个master id，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制，但是如果没有找到对应的offset，那么就会执行一次resynchronization

3、无磁盘化复制
　　master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了
　　repl-diskless-sync
　　repl-diskless-sync-delay，等待一定时长再开始复制，因为要等更多slave重新连接过来

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

九、哨兵集群

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

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

哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作

故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题
即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了

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

2、哨兵的核心知识

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

3、为什么redis哨兵集群只有2个节点无法正常工作？

哨兵集群必须部署2个以上节点

如果哨兵集群仅仅部署了个2个哨兵实例，quorum=1

   +----+      	 +----+     
   | M1 |--------| R1 |
   | S1 |        | S2 |
   +----+        +----+

Configuration: quorum = 1

master宕机，s1和s2中只要有1个哨兵认为master宕机就可以还行切换，同时s1和s2中会选举出一个哨兵来执行故障转移

同时这个时候，需要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），2个哨兵都运行着，就可以允许执行故障转移

但是如果整个M1和S1运行的机器宕机了，那么哨兵只有1个了，此时就没有majority来允许执行故障转移，虽然另外一台机器还有一个R1，但是故障转移不会执行

4、经典的3节点哨兵集群

          +----+
          | M1 |
          | S1 |
          +----+
             |
   +----+    |    +----+
   | R2 |----+----| R3 |
   | S2 |         | S3 |
   +----+         +----+

Configuration: quorum = 2，majority

如果M1所在机器宕机了，那么三个哨兵还剩下2个，S2和S3可以一致认为master宕机，然后选举出一个来执行故障转移

同时3个哨兵的majority是2，所以还剩下的2个哨兵运行着，就可以允许执行故障转移
5、哨兵的工作原理
1）sdown和odown转换机制
　　sdown和odown两种失败状态
　　sdown是主观宕机，就一个哨兵如果自己觉得一个master宕机了，那么就是主观宕机
　　odown是客观宕机，如果quorum数量的哨兵都觉得一个master宕机了，那么就是客观宕机
　　sdown达成的条件很简单，如果一个哨兵ping一个master，超过了is-master-down-after-milliseconds指定的毫秒数之后，就主观认为master宕机
　　sdown到odown转换的条件很简单，如果一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机

2）哨兵集群的自动发现机制
　　哨兵互相之间的发现，是通过redis的pub/sub系统实现的，每个哨兵都会往__sentinel__:hello这个channel里发送一个消息，这时候所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在
　　每隔两秒钟，每个哨兵都会往自己监控的某个master+slaves对应的__sentinel__:hello channel里发送一个消息，内容是自己的host、ip和runid还有对这个master的监控配置
　　每个哨兵也会去监听自己监控的每个master+slaves对应的__sentinel__:hello channel，然后去感知到同样在监听这个master+slaves的其他哨兵的存在
　　每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步

3）slave配置的自动纠正
　　哨兵会负责自动纠正slave的一些配置，比如slave如果要成为潜在的master候选人，哨兵会确保slave在复制现有master的数据; 如果slave连接到了一个错误的master上，比如故障转移之后，那么哨兵会确保它们连接到正确的master上

4）slave->master选举算法
　　如果一个master被认为odown了，而且majority哨兵都允许了主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个slave来

会考虑slave的一些信息

（1）跟master断开连接的时长
（2）slave优先级
（3）复制offset
（4）run id

如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

接下来会对slave进行排序

（1）按照slave优先级进行排序，slave priority越低，优先级就越高
（2）如果slave priority相同，那么看replica offset，哪个slave复制了越多的数据，offset越靠后，优先级就越高
（3）如果上面两个条件都相同，那么选择一个run id比较小的那个slave

5）quorum和majority
　　每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个哨兵来做切换，这个哨兵还得得到majority哨兵的授权，才能正式执行切换

如果quorum < majority，比如5个哨兵，majority就是3，quorum设置为2，那么就3个哨兵授权就可以执行切换

但是如果quorum >= majority，那么必须quorum数量的哨兵都授权，比如5个哨兵，quorum是5，那么必须5个哨兵都同意授权，才能执行切换

6）configuration epoch
　　哨兵会对一套redis master+slave进行监控，有相应的监控的配置

执行切换的那个哨兵，会从要切换到的新master（salve->master）那里得到一个configuration epoch，这就是一个version号，每次切换的version号都必须是唯一的

如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待failover-timeout时间，然后接替继续执行切换，此时会重新获取一个新的configuration epoch，作为新的version号

7）configuraiton传播
　　哨兵完成切换之后，会在自己本地更新生成最新的master配置，然后同步给其他的哨兵，就是通过之前说的pub/sub消息机制，这里之前的version号就很重要了，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换之后，新的master配置是跟着新的version号的，其他的哨兵都是根据版本号的大小来更新自己的master配置的

十、主备切换+哨兵集群架构数据丢失问题

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

异步复制导致的数据丢失
master -> slave的复制是异步的，可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了
脑裂导致的数据丢失
脑裂，也就是说，某个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就不会再接收任何请求了

有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内，减少异步复制导致数据丢失。
如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求，这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失，上面的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求，因此在脑裂场景下，最多就丢失10秒的数据，这样就减少了脑裂问题造成的数据丢失。

Redis从入门到放弃