Redis 6 新手入门基础篇

Redis 6 新手入门基础篇

Redis 6 新手入门基础篇

文章目录

​​Redis 6 新手入门基础篇​​

​​前言​​

​​Redis持久化​​

​​`RDB`​​

​​RDB的优缺点​​​​RDB的相关配置​​

​​`AOF`​​

​​AOF的工作流程：​​​​AOF重写​​

​​重写条件​​

​​后台重写​​

​​RDB和AOF比较​​

​​主从复制​​

​​单机有什么问题？​​

​​读写分离​​

​​主从复制的配置​​

​​runid和复制偏移量​​​​全量复制​​

​​`全量复制过程`​​

​​部分复制​​

​​`部分复制过程`​​

​​Redis Sentinel​​

​​简介​​​​三个定时任务​​​​主观/客观下线​​

​​`主观下线`​​​​`客观下线`​​

​​conf文件配置​​​​领导者选举​​​​故障转移处理​​

​​Redis Cluster​​

​​总结​​

前言

今天来讲讲redis以下知识点，如有不当请多指教！

​​Redis持久化​​​​主从复制​​​​Sentinel机制​​​​Redis Cluster​​

Redis持久化

redis是基于​​内存​​的，如果不想办法将数据保存在硬盘上，一旦redis重启(退出/故障)，内存的数据将会全部丢失。

Redis提供了两种持久化方法：

​​RDB​​​(基于快照)，将某一时刻的所有数据保存到一个RDB文件中。​​​AOF​​(append-only-file)，当Redis服务器执行写命令的时候，将执行的写命令保存到AOF文件中。

RDB

保存某个时间点的全量数据快照

手动触发​​​SAVE​​​：阻塞Redis的服务器进程，知道RDB文件被创建完毕​​BGSAVE​​：Fork出一个子进程来创建RDB文件，不阻塞服务器进程，使用​​lastsave​​指令可以查看最近的备份时间自动触发根据redis.conf配置里的save m n定时触发（用的是BGSAVE） 主从复制时，主节点自动触发 执行Debug Relaod 执行Shutdown且没有开启AOF持久化

注意：Redis服务器在启动的时候，如果发现有RDB文件，就会自动载入RDB文件(不需要人工干预)

RDB的优缺点

优点： RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照，适合备份，全量复制等场景。 且加载RDB恢复数据远远快于AOF的方式。

缺点： 没办法做到实时持久化/秒级持久化，因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。

RDB的相关配置

//在n秒内修改m条数据时创建RDB文件save 900 1save 300 10save 60 10000stop-writes-on-bgsave-error yes //bgsave出错时停止写入rdbcompression yes //压缩RDB文件rdbchecksum yes //校验文件是否损坏

AOF

与RDB不一样的是，​​AOF​​记录的是命令，而不是数据。

如何开启AOF? 只需在配置文件中将​​​appendonly​​设置为yes即可。

AOF的工作流程：

1、所有的写入命令追加到​​aof_buf​​​缓冲区中。 2、AOF会根据对应的策略向磁盘做同步操作。刷盘策略由​​​appendfsync​​​参数决定。 3、定期对AOF文件进行重写。重写策略由​​​auto-aof-rewrite-percentage​​​，​​auto-aof-rewrite-min-size​​两个参数决定。

appendfsync参数有如下取值：

appendfsync always # 每次有数据修改发生时都会写入AOF文件。appendfsync everysec # 每秒钟同步一次，该策略为AOF的默认策略。appendfsync no # 从不同步。高效但是数据不会被持久化。

AOF重写

为什么要重写？ 重写后可以加快节点启动时的加载时间

重写后的文件为什么可以变小？ 进程内超时的数据不用再写入到AOF文件中 多条写命令可以合并为一个

重写条件

1、手动触发 直接调用​​​bgrewriteaof​​命令

2、自动触发

先来看看有关参数：​​​auto-aof-rewrite-min-size​​​：执行AOF重写时，文件的最小体积，默认值为64MB。​​​auto-aof-rewrite-percentage​​：执行AOF重写时，当前AOF大小(即aof_current_size)和上一次重写时AOF大小(aof_base_size)的比值。

只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个参数同时满足时，才会自动触发AOF重写。

后台重写

Redis将AOF重写程序放到​​子进程​​​里执行(​​BGREWRITEAOF​​​命令)，像​​BGSAVE​​命令一样fork出一个子进程来完成重写AOF的操作，从而不会影响到主进程。

AOF后台重写是不会阻塞主进程接收请求的，新的写命令请求可能会导致当前数据库和重写后的AOF文件的数据不一致！ 为了解决数据不一致的问题，Redis服务器设置了一个​​​AOF重写缓冲区​​，当子进程完成重写后会发送信号让父进程将AOF重写缓冲区的数据写到新的AOF文件。

RDB和AOF比较

RDB和AOF并不互斥，它俩可以同时使用。

RDB的优点：载入时恢复数据快、文件体积小。 RDB的缺点：会一定程度上丢失数据(因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。)

AOF的优点：丢失数据少(默认配置只丢失1秒的数据)。 AOF的缺点：恢复数据相对较慢，文件体积大

如果Redis服务器同时开启了RDB和AOF持久化，服务器会​​优先使用AOF文件来还原数据​​(因为AOF更新频率比RDB更新频率要高，还原的数据更完善)

主从复制

单机有什么问题？

单机即在一台机器上部署一个redis节点，主要会存在以下问题： 1、如果发生机器故障，例如磁盘损坏，主板损坏等，未能在短时间内修复好，客户端将无法连接redis 2、Redis的内存是有限的，可能放不下那么多的数据 3、单台Redis支持的并发量也是有限的

如图上面是​​master节点​​​，下面是​​slave​​节点，即主节点和从节点。从节点也是可以对外提供服务的，主节点是有数据的，从节点可以通过复制操作将主节点的数据同步过来，并且随着主节点数据不断写入，从节点数据也会做同步的更新。

整体起到的就是数据备份的效果

除了一主一从模型之外，redis还提供了一主多从的模型，也就是一个master可以有多个slave，也就相当于有了多份的数据副本。

读写分离

除了作为数据备份，主从模型还能做另外一个功能，就是读写分离。 让master节点负责提供写服务，slave节点提供读服务，而将数据读取的压力进行分流和负载，分摊给所 有的从节点。

主从复制的配置

slaveof命令

slaveof 198.162.88.66 6379

执行该命令使当前redis节点成为指定redis节点的从节点，此复制命令是​​异步​​进行的，redis会自动进行后续数据复制的操作

如果想取消从节点可以执行 ​​slave of on one​​ 命令

2、修改配置

# 配置主节点的IP和端口号slaveof ip port# 从节点只做读的操作，保证主从数据的一致性slave-read-only yes

runid和复制偏移量

redis每次启动的时候都会有一个随机的ID，作为一个标识，这个ID就是runid，当然重启之后值就改变了。 假如端口为6380的redis去复制6379，知道​​​runid​​​后，在6380上做一个标识，如果​​runid​​​改变了，说明主可能重启了或者发生了其它变化，这时候就可以做一个全量复制把数据同步过来。或者第一次启动时根本不知道6379的​​runid​​，也会进行全量复制

偏移量：数据写入量的字节 比如主执行set hello world，就会有一个偏移量，然后从同步数据，也会记录一个偏移量 当两个偏移量达到一致时候，实际上数据就是完全同步的状态。

全量复制

全量复制主节点会将RDB文件也就是当前状态去同步给slave，在此期间主节点新写入的命令会单独记录起来，然后当RDB文件加载完毕之后，会通过偏移量对比将这个期间产生的写入值同步给slave，这样就能达到数据完全同步的效果

全量复制过程

在其内部有一条命令​​psync​​​，是做同步的命令，它可以完成全量复制和部分复制的功能，当启动slave节点时，它会发送​​psync​​​命令给主节点，需要传递两个参数，​​runid​​​和​​offset​​(偏移量)，也就是从节点向主节点传递主节点的runid以及自己的偏移量，对于第一次复制而言，就直接传递？和 -1，当然这个参数是由slave内部传的。master接收到命令后知道从希望做全量复制，主就会将自己的runid和offset传递给从节点slave节点保存master的基本信息master执行​​bgsave​​​生成RDB文件，并且在此期间新产生的写入命令会被记录到​​repl_back_buffer​​(复制缓冲区)主节点向从节点传输RDB文件主节点向从节点发送复制缓冲区内容清空从节点旧的数据从节点加载RDB文件到内存中，同时加载缓冲区数据

执行全量复制除了开销大之外，还会有个问题： 假如master和slave网络发生了抖动，那一段时间内这些数据就会丢失，对于slave来说这段时间master更新的数据是不知道的。最简单的方式就是再做一次全量复制，从而获取到最新的数据，在redis2.8之前是这么做的。

部分复制

redis2.8之后提供部分复制，如果发生类似网络抖动，可以有这样一种机制将这种损失降低到最低，如何实现的？

部分复制过程

如果发生了抖动，相当于连接断开了主节点会将写命令记录到缓冲区(repl_back_buffer)当slave再次去连接master时候，就是说网络抖动结束之后，会触发部分复制从节点会执行pysnc命令，将当前自己的offset和主的runid传递给master如果发现传输的offset偏移量是在buffer内的，如果不在内就说明你已经错过了很多数据，buffer也是有限的，默认是1M(建议调为10M)，会将offset开始到队列结束的数据同步给从节点。这样master和slave就达到了一致。

通过部分复制有效的降低了全量复制的开销。

Redis Sentinel

简介

​​Sentinel​​​(哨兵)是用于监控redis集群中master状态的工具，是Redis 的高可用性解决方案，sentinel哨兵模式已经被集成在redis2.4之后的版本中。Sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为新的master服务，替代已下线的master服务继续处理请求，等挂掉的主服务器重连上来，会将它变成从服务器。

三个定时任务

Sentinel在内部有3个定时任务 1）每隔10秒——每个sentinel会对master和slave执行info命令，这个任务主要用来发现slave节点和确认主从关系。 2）每隔2秒——每个sentinel通过master节点的channel交换信息（pub/sub）。master节点上有一个名为​​__sentinel__:hello​​​的发布订阅的频道。sentinel节点通过__sentinel__:hello频道进行信息交换(对节点的"看法"和自身的信息)，达成共识。 3）每隔1秒——每个sentinel对其他sentinel和redis节点执行ping操作（相互监控），这个其实是一个心跳检测，是失败判定的依据。

主观/客观下线

判断主服务器是否下线有两种情况：

主观下线

Sentinel会以每秒一次的频率向与它创建命令连接的实例(包括主从服务器和其他的Sentinel)发送PING命令，通过PING命令返回的信息判断实例是否在线 如果一个主服务器在down-after-milliseconds毫秒内连续向Sentinel发送无效回复，那么当前Sentinel就会主观认为该主服务器已经下线了。

客观下线

当Sentinel将一个主服务器判断为主观下线以后，为了确认该主服务器是否真的下线，它会向同样监视该主服务器的Sentinel询问，看它们是否也认为该主服务器是否下线。 如果足够多的Sentinel认为该主服务器是下线的，那么就判定该主服务为客观下线，并对主服务器执行故障转移操作。

conf文件配置

在redis-sentinel的conf文件里有这么两个配置：

1）sentinel monitor

四个参数含义：​​​masterName​​​这个是对某个master+slave组合的一个区分标识。​​​ip​​​ 和 ​​port​​​ 就是master节点的 ip 和 端口号。​​​quorum​​这个参数是进行客观下线的一个依据，意思是**至少有 quorum 个sentinel主观的认为这个master有故障，才会对这个master进行下线以及故障转移。**因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。

2）sentinel down-after-milliseconds

这个配置其实就是进行主观下线的一个依据，表示：如果这台sentinel超过timeout这个时间都无法连通master包括slave的话，就会主观认为该master已经下线。

领导者选举

当一个主服务器被认为客观下线以后，此时需要一个Sentinel服务器对该服务器进行处理，因此监视这个下线的主服务器的各个Sentinel会进行协商，选举出一个领头的Sentinel，领头的Sentinel会对下线的主服务器执行故障转移操作。

选举领头Sentinel的规则也比较多，总的来说就是先到先得(哪个快，就选哪个)

故障转移处理

多个sentinel发现并确认master有问题选举出一个sentinel作为领导选出一个slave作为master通知其余slave成为新的master的slave通知客户端主从变化等待老的master复活成为新master的slave

注意：挑选某一个从服务器作为主服务器也是有策略的，大概如下：

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

Redis Cluster

Redis3.0版本之前，可以通过Redis Sentinel（哨兵）来实现高可用，从3.0版本之后，官方推出了​​Redis Cluster​​，它的主要用途是实现数据分片，并且实现高可用。

在Redis Sentinel模式中，每个节点需要保存全量数据，冗余比较多，而在Redis Cluster模式中，每个分片只需要保存一部分的数据，

Redis Cluster每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。

Redis Cluster的具体实现细节是采用了​​Hash槽​​​的概念，集群会预先分配​​16384​​​个槽，并将这些槽分配给具体的服务节点，通过对Key进行​​CRC16(key)%16384​​运算得到对应的槽是哪一个，从而将读写操作转发到该槽所对应的服务节点。当有新的节点加入或者移除的时候，再来迁移这些槽以及其对应的数据。在这种设计之下，我们就可以很方便的进行动态扩容或缩容。

Redis Cluster为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉。

有关redis集群的安装配置在这里就不多说了，在这里对先对redis cluster有个了解，日后再来补充。

总结

如果这篇文章对您有所帮助，或者有所启发的话，求一键三连：点赞、转发、收藏，您的支持是我坚持写作最大的动力。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。