Redis笔记_redis appendonly.aof 目录

Redis执行命令执行过程

执行过程：发送指令-> 执行指令->返回结果集
执行命令：单线程执行，所有的命令都存储到队列中按顺序执行
单线程块的原因：纯内存访问，单线程避免了多线程上下文切换和资源竞争产生的消耗
RESP 协议简单：Redis底层协议RESP详解
存在的问题:一旦某个执行执行时间过长，后面的命令就会进入阻塞状态

Redis 慢查询日志

1. Redis的慢查询阈值默认为10毫秒 动态设置慢查询日志的毫秒数指令：
   6379:>config set slowlog-log-slower-than 10000 # 单位是微秒 1毫秒 = 1000微秒
   使用config set 后，若是想永久生效，将修改保存到redis.conf 需要执行 config rewrite 命令
2. 修改redis.conf 配置文件。找到 slowlog-log-slower-than 10000 修改保存即可
   注意：slowlog-log-slower-than 0 代表记录所有的命令 -1 代表什么命令都不记录

慢查询日志原理

慢查询日志也是存在队列中的，slow-max-len 参数代表存放的最大记录条数。比如设置 slow-max-len =10，
当有第11条慢查询日志插入时， 队列的第一条命令就会出列，
第十一条慢查询日志加入队列中，可以通过config set 动态设置也可以通过redis.conf完成配置

慢查询命令

获取队列里慢查询命令 slowlog get
获取慢查询日志的队列长度 slowlog len

1 、对慢查询队列进行清理 slowlog reset //再次查询slowlog len 返回0
2 、对于线上慢查询日志的建议：线上可加大slowlog-max-len的值。记录慢查询存长命令时redis会做截断，不会占用大量内存，线上可以设置1000以上。
3、 对于线上slowlog-log-slower-than配置的建议：默认为10毫秒，根据redis的并发量来进行调整，对于高并发比建议为1毫秒
4 、慢查询是先进先出的队列，访问日志记录出列丢失，需要定期执行slowlog get 讲结果导入到其他设备中 （比如mysql）

redis-cli命令

./redis-cli -h 127.0.0.1 -a 123456 ping //返回pong表示127.0.01:6379能够ping通
./redis-cli -和127.0.0.1 -a 123456 -r 100 -i 1 info|grep used_memory_human //每秒输出内存使用量，输出100次 -r 代表执行N次命令，-i 代表每隔多少秒执行一次
./redis-cli --help 打开帮助

redis-serve 命令

./redis-serve ./redis.conf $ //指定配置文件启动 & 代表在后台启动
./redis-serve --test-memory 1024 //测试操作系统能否提供1GB的内存来给redsi使用，常用于测试，想快速占满机器内存下的极端条件测试可以使用这个命令

redis的事务

pipeline是多条命令的组合，为了保证他的原子性，redis提供了简单的事务。
redis的简单事务，需要将要执行的命令放到multi和exce两个命令之间，其中multi代表事务开始，exce代表事务结束
watch命令，使用watch命令后，multi命令失效，事务失效
redis的事务属于弱事务，有时不会回滚数据。比如在一组事务中出现类型错误，例如 执行 sadd a 1 后，在执行 get a，这种情况下事务不会回滚、

使用lua脚本的好处

1. 减少网络开销
2. 原子性操作
3. 增加复用性

RDB持久化方式

RDB持久化会将当前进程的数据生成一份快照(.rdb)文件保存在磁盘中，有手动触发和自动触发两种方式

手动触发

手动触发有两个命令 save 和 bgsave 命令

• save命令：阻塞当前的redis进程,直到RDB执行完毕若内存中数据量比较大会造成较长时间的阻塞，线上环境不建议使用
• bgsave命令：redis进程执行fork操作创建一个子线程，由子线程完成持久化操作，阻塞时间很短(微妙级)，是save的优化版本，在执行redis-cli shutdown关闭redis服务时，如果没有开启AOF持久化，会自动执行bgsave

bgsave的执行流程

RDB的文件操作

命令：config set dir /usr/local //设置RDB 文件的存放目录
备份：bgsave //将dump.rdb文件保存到 /usr/local 文件目录下
恢复：将dump.rdb文件放在redis安装目录与redis.conf的同级目录下，重启redis即可
优点：1.压缩后的二进制文件，适用于备份，全量复制用于容灾恢复
2.加载RDB数据远快于AOF
缺点: 1.无法做到实时持久化，每次都要创建子进程，频繁操作成本过高
2.保存后的二进制文件 存在老版本不兼容新版本rdb文件的情况

AOF持久化流程

1. 所有的写入命令都会以append的方式写入到aof_buf缓冲区中
2. AOF缓冲区执行sync同步到磁盘中
3. 随着AOF文件越来越大，需要定期对AOF文件rewrite重写达到压缩文件的目的
4. 当redis服务重启，会去读取AOF文件中的指令进行数据恢复
   

AOF配置详解

5. appendonly yes //开启AOF持久化机制
6. #appendfsync always //每当有写命令执行时强制将命令写入磁盘，效率很慢，但是能保证完全持久化，不推荐使用
7. appendfsync everysec 每秒强制写入磁盘一次 //属于折中方案，在性能和持久化之间平衡，推荐使用
8. #appendfsync no //完全依赖系统自身的同步，性能最好，持久化没有保证
9. no-appendfsync-rewrite yes //正在执行RDB同步时要不要暂停同步AOF
10. auto-aof-rewrite-percentage 100 //aof文件大小比起上次重写增长的大小，增长率达到100%时重写
11. auto-aof-rewrite-min-size 64 //aof文件至少超过64MB大小时重写

AOF数据恢复

1. 设置appendonly 为yes
2. 将appendonly.aof文件放入redis.conf的dir指定目录
3. 启动redis,redis将会自动加载aof文件进行数据恢复

Redis数据恢复时加载AOF与RDB的顺序

Redis主从复制

配置redis主从复制

方式一：新增配置文件redis6380.conf 加入 slaveof 127.0.0.1:6379 在6379启动完成之后在启动6380完成配置
方式二：redis-serve -slaveof 127.0.0.1:6379
查看状态：info repilction
断开主从复制：在slave节点(从节点)执行slaveof no one
断开后在变成主从复制：slaveof 127.0.0.1:6379
数据较为重要的节点，使用密码 验证：requirepass 密码
从节点建议设置为只读模式 slave-read-only=tyes，若从节点修改数据会造成主从不一致

注意

Redis主从拓补

一主一从

用于主节点故障时，转移到从节点，当主节点写命令高并发需要持久化时，可以只在从节点开启AOF

一主多从

适用于读请求比较高的场景，，读由多个从节点进行分担，但是节点越多，主节点同步到从节点的次数也就越多，影响宽带也影响主节点的稳定性，一般情况下一个主节点带两个从节点

多级主从

一主多从的缺点可以用多级主从来解决，主节点下面设置两个从节点，主节点只需要向这两个从节点同步数据，同时，从节点也相当于一个主节点，下面设置两个从节点，再由这个节点将数据向下同步，这样就能减轻主节点的压力

主从复制原理

当执行 slave master prot 后
与主节点链接，同步主节点的数据 6379:>info repliction:查看主从同步信息

配置完从节点配置后，启动从节点6380

1. 保存主节点信息
2. 与主节点建立socket链接
3. 发送ping命令
4. 权限验证
5. 同步数据集
6. 持续复制数据
   

数据同步

redis2.8以后的版本使用psync命令完成同步，同步分为全量同步和部分同步

全量同步

一般用于初次复制的场景（第一次建立slave之后）

部分同步

当网络出现问题，从节点再次链接到主节点以后，由于从节点已经有了部分数据，所以主节点会补发缺少的数据，以后每次复制都会部分同步

心跳

主从之间有长连接心跳，主节点默认每10s向从节点发送ping命令。repl-ping-slave-period 命令控制发送的频率

Redis哨兵

什么是高可用

• 解释一：它被认为是不间断操作的容错技术，是目前企业防止核心系统因为故障而无法工作的最有效保护手段

• 解释二：高可用一般指服务的冗余，一个服务挂了，可以自动切换到另一个服务上，不影响用户体验

哨兵机制(sentintl)的高可用

当主节点发生故障时，由Redis sentintl 自动完成故障的发现和转移，并通知应用方实现高可用

哨兵的数量需要为奇数个 – 选举机制
哨兵可以监控各个redis的健康状况，当主节点宕机后，哨兵会选举出一个健康状况比较好的节点，当作主节点

哨兵有三个定时监控任务，来对各个节点进行发现和监控

• 每隔十秒发送一次info
• 每隔两秒发送一次 publish/subscribe(发布/订阅)
• 每隔一秒发送一次ping

主观下线

当一个哨兵发送ping 超过 down-after-milliseconds 无回复
就会判断这个节点是不可用的，但是这种方式比较粗暴，可信度不高
主观下线后，不准确，不会做故障转移

客观下线

至少有quorum个以上哨兵认为当前节点有问题才会将节点下线

领导者哨兵

当主节点宕机以后，会有哨兵推举出一个从节点来代替原来的主节点，同时，会将新主节点的数据，向其他从节点同步，同步这个操作是由哨兵来完成的，那么被推举出来完成新节点的数据同步的哨兵就是领导者哨兵

领导者哨兵选举流程

假如哨兵三发现了主观下线，哨兵三会发送 is-masterdown-by-addr（主节点挂了）征求其他哨兵的判断，如果其他哨兵返回同意，那么哨兵三就会成为领导者哨兵，来处理这次的故障

哨兵故障转移机制

• A 、由Sentinel节点定期监控发现主节点是否存在故障
  Sentinel会定期向主节点发送心跳Ping来确定主节点是否存活，如果master在一段时间内不回应ping或者回复了一个错误的消息，那么这个Sentinel会主观的(单方面的)认为这个节点已经不可用了
  
• B、当主节点发生故障，此时假设3个哨兵共同选举出Sentinel3节点作为领导者sentinel，负责处理主节点的故障转移
  
• C、由Sentinel3主导负责主节点的故障转移，过程和主从复制一样，但是是自动执行

• 故障转移后的Redis拓补结构图
  
• 故障转移的详细流程
  

Redis哨兵安装部署

以三个sentinel节点，一个主节点两个从节点为例安装部署

Redis Sentinel 监控两个主节点

sentinel 部署建议

1. sentinel节点应部署在不同的物理机上（线上环境）
2. 至少三个且奇数个sentinel节点（选举时用，少数服从多数原则）
3. 三个sentinel可同时监控一个或者多个redis主节点，当监听N个主节点时，如果sentinel出现异常，会对多个主节点产生影响，同时还会造成sentinel节点产生过多的网络连接，一般线上建议是三个sentinel监控一个主节点

sentilen哨兵的API

Redis集群

• ./redis-cli -h 127.0.0.1 -p 6379 -a 123456 -c // -c 为进入集群模式
• redis最大存储量为物理机的百分之75%

Redis Clusters

是 Redis的分布式解决方案，在3.0版本推出的方案，有效的解决了Redis分布式的需求，当遇到单机内存，并发瓶颈时，可以使用此方案解决这些问题

分布式概念

分布式数据库就是把一组数据按照分区规则映射到多个节点，即把数据划分到多个节点上，每个节点存储整个数据的一个子集。
比如用户有900条数据，有三个redis节点，将900划分成三份，分别存到三个redis中

Redis分区规则

分区规则常见的有HASH分区和顺序分区，Redis集群使用了HASH分区，顺序分区暂时用不到。
RedisCluster 采用了HASH分区的虚拟槽分区方式（HASH分区取余，一致性HASH分区和虚拟槽分区）

虚拟槽分区

槽：slot
RedisCluster 采用此分区，所有的键根据HASH函数（CRC6（KEY）&16383）映射到0-16383个槽内，共有16384个槽位，每个节点维护部分槽以及槽所映射的键值数据。
哈希函数:hash()=CRC6(key)&16383

槽，键，数据的关系

当有一个key添加到redis中时，会对这个key进行HASH运算，最后得到一个槽的位置，然后根据槽与节点的映射关系，判断这条数据到底被存储在哪个节点上

RedisCluster的缺陷

1. 键的批量操作支持有限，类似于mset，mget这类操作，如果多个键映射到不同的槽内就无法支持(因为mset和mget这类命令属于原子操作，如果映射到多个槽内就有可能跨节点获取数据，无法保证数据的完整性)
2. 键的事物支持有限，当多个键处于不同的节点就无法使用事物，同一节点是支持事物的
3. 键是数据分区的最小粒度，不能将一个很大的键值对映射到不同的节点
4. 不支持多数据库，只能使用数据库0也就是 select 0
5. 复制结构只支持单级结构，不支持树形结构。(也就是在主从复制的时候只支持一主多从的模式，不支持多级主从)

Redis集群搭建(这只是PPT)

修改配置

启动服务

Redis集群健康检测

集群的一主多从配置

集群之间节点通信

节点之间采用gossip协议来进行通信，Gossip协议就是指节点之间不间断的交换信息，当主从角色变化或者新增加下线节点的时候，彼此通过ping/pong进行通信，知道所有节点的最新状态以达到集群同步

Gossip通讯协议

Goossip协议的主要职责就是信息交换，信息交换的载体就是节点之间彼此发送的Gossip信息，常用的Gossip消息有ping消息、pong消息、meet消息、fail消息

• meet消息：用于通知新节点的加入，消息发送者通知接收者加入当前集群，meet消息通信完毕后，接收节点会加入到集群当中，并进行周期性的ping/pong交换
• ping消息：节点之间交换最频繁的消息，集群中的每个节点每秒向其他节点发送ping消息，用于检测其他节点是否在线和状态信息，ping消息发送封装自身节点和其他数据节点的状态数据。
• pomg消息：当收到ping消息或者meet消息时，作为响应消息返回给对方，用来确认正常通信，pong消息也封装了自身状态数据。
• fail消息：当节点判定集群内的另一个节点下线时，会向集群广播一个fail消息
  

集群节点的通信流程

• 解析消息
  
• 发送消息
  

节点扩容

新增节点操作

集群下线流程

路由重定向

当我们在 集群的某一个节点查询一个key的时候 get key value ，redis会对kay使用hash函数计算对应槽的节点，然后判断当前的槽节点是否指向自身，如果指向自身，就执行命令将数据返回，如果不是指向自身就回复客户端一个moven指令，由客户端重定向到目标节点去查询

故障转移-主观下线

故障转移-客观下线

故障恢复

如果发生故障的节点恢复运行后，那么这个节点会变成当前主节点的从节点