本文主要是介绍09 微服务技术—— Redis集群，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

---

目录

前言

一、rides持久化

1、RDB持久化

1.1执行时机：

 1.2、RDB执行原理

2、AOF持久化

 2.1、配置AOF频率

 2.2、AOF文件重写

 3、RDB对比AOF

二、Redis主从集群

1、搭建主从集群

 2、主从数据同步原理

2.1、全量同步

2.2、增量同步

3、Redis主从同步优化

三、Redis哨兵

1、哨兵到的作用

1.1、服务状态监控

​ 1.2、选举新master

四、Redis分片机群

1、分片集群结构

2 、散列插槽

3、集群伸缩

4、故障转

---

前言

与Redis集群相对应的，就是单点Redis，Redis搭建集群出现的原因，也是解决单点Redis所存在的问题。主要存在以下四种问题，也有相对应的解决办法，本文也将从四个方面介绍~

一、rides持久化

持久化就是将数据记录到磁盘当中，当Redis宕机时，可以通过磁盘恢复数据。对Redis数据进行持久化，有RDB和AOF两种策略，两者根本区别在就是在存储方式上，一种是基于快照方式，一种命令日志方式。

1、RDB持久化

概念 : RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。

快照文件称为RDB文件，默认是保存在当前运行目录。

1.1执行时机：

RDB持久化在四种情况下会执行:

- 手动执行save命令时

- 手动执行bgsave命令时

- Redis停机时

- 触发RDB执行条件时

1) save命令

执行下面的命令，可以立即执行一次RDB：

save命令会导致主进程执行RDB，这个过程中其它所有命令都会被阻塞。

所以平时禁止使用,只有在数据迁移时可能用到。

 2）bgsave命令

这个命令可以异步执行RDB：因为这个命令执行后会开启独立进程完成RDB，主进程可以持续处理用户请求，不受影响。

 3）停机时

Redis停机时会执行一次save命令，实现RDB持久化。

4）触发RDB条件

 1.2、RDB执行原理

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。

fork采用的是copy-on-write技术：

• 当主进程执行读操作时，访问共享内存；

• 当主进程执行写操作时，则会拷贝一份数据，执行写操作。

RDB方式bgsave的基本流程：

• fork主进程得到一个子进程，共享内存空间

• 子进程读取内存数据并写入新的RDB文件

• 用新RDB文件替换旧的RDB文件

RDB的缺点：

• RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险

• fork子进程、压缩、写出RDB文件都比较耗时

RDB附加作用：

数据分析,根据解析RDB快照文件,获取redis中的数据,分析问题。

2、AOF持久化

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

 2.1、配置AOF频率

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"

AOF的命令记录的频率也可以通过redis.conf文件来配：有三种策略

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always 
# 表示写命令执行完先放入AOF缓冲区，每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

三种策略对比:

 2.2、AOF文件重写

         AOF文件记录的是操作命令,有时对同一个key多次操作,而对我们有意义的就是最后一次操作,之前的操作命令都是无用的,所以可以通过重写AOF文件,抛去瓤余的操作记录.

 3、RDB对比AOF

二、Redis主从集群

搭建Redis集群实现读写分类，可以提高并发能力

1、搭建主从集群

        单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。

 2、主从数据同步原理

实现主节点与从节点的数据同步，分为第一次全部数据的同步和更新性部分数据的同步，又叫全量同步和增量同步。

2.1、全量同步

master判断salve是否是第一次连接的依据:

• Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid

• offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

  因此slave做数据同步，必须向master声明自己的replication id 和offset，master才可以根据replid是否一致, 判断到底需要同步哪些数据。

2.2、增量同步

repl_backlog原理

这个文件是一个固定大小的数组，只不过数组是环形，也就是说角标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被覆盖。

3、Redis主从同步优化

主从同步可以保证主从数据的一致性，非常重要。

可以从以下几个方面来优化Redis主从就集群：

什么时候执行全量同步？

什么时候执行增量同步？

• 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO。

• Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO

• 适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步

• 限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

  总结

• 简述全量同步和增量同步区别？

• 全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_baklog，逐个发送给slave。

• 增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave

• slave节点第一次连接master节点时

• slave节点断开时间太久，repl_baklog中的offset已经被覆盖时

• slave节点断开又恢复，并且在repl_baklog中能找到offset时

三、Redis哨兵

        Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复。实现了高可用

1、哨兵到的作用

1.1、服务状态监控

 1.2、选举新master

选举依据 :

• 首先会判断slave节点与master节点断开时间长短，如果超过指定值（down-after-milliseconds * 10）则会排除该slave节点

• 然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举

• 如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高

• 最后是判断slave节点的运行id大小，越小优先级越高。

master切换流程 :

• sentinel给备选的slave1节点发送slaveof no one命令，让该节点成为master

• sentinel给所有其它slave发送slaveof 192.168.200.130 7002 命令，让这些slave成为新master的从节点，开始从新的master上同步数据。

• 最后，sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新的master的slave节点

总结

Sentinel的三个作用是什么？

• 监控; 故障转移; 通知

Sentinel如何判断一个redis实例是否健康？

• 每隔1秒发送一次ping命令，如果超过一定时间没有相向则认为是主观下线

• 如果大多数sentinel都认为实例主观下线，则判定服务下线

故障转移步骤有哪些？

• 首先选定一个slave作为新的master，执行slaveof no one

• 然后让所有节点都执行slaveof 新master

• 修改故障节点配置，添加slaveof 新master

四、Redis分片机群

        实现了海量数据存储和高并发写的问题.

1、分片集群结构

2 、散列插槽

概念 :

数据key不是与节点绑定，而是与插槽绑定。redis会根据key的有效部分计算插槽值，分两种情况：

• key中包含"{}"，且“{}”中至少包含1个字符，“{}”中的部分是有效部分

• key中不包含“{}”，整个key都是有效部分

分片插槽设计 :

• 每一个实例都知道其他master实例上有哪些茶巢

• 可以使用{key}将相同key数据放到同样的master上

• 为什么设计插槽? 相当于把数据平摊成16384份,就方便将来做数据迁移. 只需要把其中一部分插槽和数据迁移.

总结 :

Redis如何判断某个key应该在哪个实例？

• 将16384个插槽分配到不同的实例

• 根据key的有效部分计算哈希值，对16384取余

• 余数作为插槽，寻找插槽所在实例即可

如何将同一类数据固定的保存在同一个Redis实例？

• 这一类数据使用相同的有效部分，例如key都以{typeId}为前缀

3、集群伸缩

概念: 就是添加或者移除节点;

• 添加节点时,先创建节点再添加节点到分片集群,最后分配插槽

• 删除节点时,先将节点上的插槽和数据转移到其他节点,再删除节点.

添加节点

1.建立连接：

 1.1得到下面的反馈：询问要移动多少个插槽，我们计划是3000个：

1.2新的问题来了：那个node来接收这些插槽？？

1.3显然是我们要添加的节点，将要添加的节点的id复制上去

1.4这里询问插槽是从哪里移动过来的？

• all：代表全部，也就是三个节点各转移一部分

• 具体的id：目标节点的id

• done：没有了

这里我们要从7001获取，因此填写7001的id：填完后，点击done，这样插槽转移就准备好了,

1.5询问确认要转移吗？输入yes：

 1.6然后，通过命令查看结果：

 1.7可以看到： 目的达成。

4、故障转移

自动故障转移

手动故障转移：

这篇关于09 微服务技术—— Redis集群的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！