自己做网站项目,苏州 规划建设局网站,重庆招标信息网官网,孝感网站建设孝感Redis 持久化
Redis 为了保证效率#xff0c;数据缓存在了内存中#xff0c;但是会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件中#xff0c;以保证数据的持久化。总的目的把数据保存到硬盘#xff0c;有 RDB 和 AOF 两种。
RDB 持久化方案: RDB 是一…Redis 持久化
Redis 为了保证效率数据缓存在了内存中但是会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件中以保证数据的持久化。总的目的把数据保存到硬盘有 RDB 和 AOF 两种。
RDB 持久化方案: RDB 是一次的全量备份快照形式是周期性直接把内存中的数据保存到一个 dump 文件中定时保存。是 redis 默认的存储方式推荐使用。 优点: 性能消耗的比较小速度快 缺点: 容易丢失数据
AOF 持久化方案把所有的对 Redis 的服务器进行修改的命令都存到一个文件里是命令的集合。 优点: 不容易丢失数据 缺点: 性能差给客户的体验度不好
当 Redis 重启时会优先使用 AOF 文件来还原数据集因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。甚至可以关闭持久化功能让数据只在服务器运行时存储。
RDB 持久化
RDB 是默认的持久化方案推荐使用的。Redis 生成二进制压缩的快照文件 xxx.rdb 保存到磁盘。
RDB 工作原理当 Redis 需要做持久化时Redis 会 fork 一个子进程子进程将数据写到磁盘上一个临时 RDB文件中。当子进程完成写临时文件后将原来的 RDB 替换掉这样的好处是可以 copy-on-write。
定时生成 RDB 快照非常便于进行数据库备份并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度快。Redis4.0支持同时开启 RDB 和 AOF系统重启后Redis 会优先使用 AOF 来恢复数据这样丢失的数据会最少。
需要查看配置文件满足三个条件中一个触发生成快照 rdb 文件。可以配置符合快照触发条件默认的是 1 分钟内改动 1 万次或者 5 分钟改动 10 次或者是 15 分钟改动一次
save 900 1
save 300 10
save 60 10000
启动服务器的时候需要通过命令行启动进入 reids 的安装目录 redis-server.exe redis.conf
save 命令save 时只管保存其他不管全部阻塞
bgsave 命令redis 会在后台进行快照操作快照操作的同时还可以响应客户端的请求可以通过 lastsave 命令获取最后一次成功执行快照的时间。
AOF 持久化
AOF 日志存储的是 redis 服务器的顺序指令序列即对内存中数据进行修改的指令记录。当 redis 收到客户端修改指令后先进行参数校验如果校验通过把该指令存储到 AOF 日志文件中也就是先存到磁盘然后再执行该修改指令。当 redis 宕机后重启后可以读取该 AOF 文件中的指令进行数据恢复恢复的过程就是把记录的指令再顺序执行一次这样就可以恢复到宕机之前的状态。
打开 AOF 配置 redis.conf 中的 appendonly yes 就可以打开 AOF 功能例如 appendfsync no 当设置 appendfsync为 no 的时候Redis 不会主动调用 fsync 去将 AOF 日志内容同步到磁盘所以这一切就完全依赖于操作系统的调试了。对大多数 Linux 操作系统是每 30 秒进行一次 fsync将缓冲区中的数据写到磁盘上。
appendfsync everysec 当设置 appendfsync 为 everysec 的时候Redis 会默认每隔一秒进行一次 fsync 调用将缓冲区中的数据写到磁盘。但是当这一次的 fsync 调用时长超过 1 秒时。Redis 会采取延迟 fsync 的策略再等一秒钟。也就是在两秒后再进行 fsync这一次的 fsync 就不管会执行多长时间都会进行。这时候由于在fsync 时文件描述符会被阻塞所以当前的写操作就会阻塞。
在绝大多数情况下Redis 会每隔一秒进行一次 fsync。在最坏的情况下两秒钟会进行一次 fsync 操作。这一操作在大多数数据库系统中被称为 group commit就是组合多次写操作的数据一次性将日志写到磁盘。
appendfsync always 每一次写操作都会调用一次 fsync这时数据是最安全的当然由于每次都会执行 fsync所以其性能也会受到影响
AOF 重写
因为 AOF 持久化是通过保存被执行的写命令来记录数据库状态的那么就会涉及到很多无用的命令如 set a b 和 set a c 以及 set a d其实就最后一条有意义。
Redis 会 fork 一个进程来读取现在 redis 生成的 AOF 文件然后在内存中去除冗余命令在此过程中不会影响原来 AOF 文件的继续写入如果有新的命令会缓存在重写缓冲中当重写完全结束后会替换掉原来的 AOF文件
重写触发条件手动命令 BGREWRITEAOF 和配置自动调用
RDB 与 AOF 的选择
宕机后会优先加载 AOF 文件。RDB 保存的数据AOF 保存的命令RDB 文件比 AOF 小。恢复速度 RDB 小更快。RDB 一次写入的数据较多时间间隔会比 AOF 长出现宕机丢失的数据会更多各有优劣如果能综合就好了所幸的是在 redis4.0 后通过配置 aof-use-rdb-preamble 就可以开启两者混合持久化取长补短。
单机性能建议
因为 RDB 文件只用作后备用途只要 15 分钟备份一次就够了只保留 save 900 1 这条规则。
如果 Enable AOF好处是在最恶劣情况下也只会丢失不超过两秒数据启动脚本较简单只 load 自己的 AOF 文件就可以了。 代价一是带来了持续的 IO二是 AOF rewrite 的最后将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可应该尽量减少 AOF rewrite 的频率AOF 重写的基础大小默认值 64M 太小了可以设到 5G 以上。 默认超过原大小 100%大小时重写可以改到适当的数值。
混合持久化
Redis4.0 后大部分的使用场景都不会单独使用 RDB 或者 AOF 来做持久化机制而是兼顾二者的优势混合使用。
其原因是 RDB 虽然快但是会丢失比较多的数据不能保证数据完整性AOF 虽然能尽可能保证数据完整性但是性能确实是一个诟病比如重放恢复数据。
混合持久化通过 aof-use-rdb-preamble yes 开启Redis 4.0 以上版本默认开启 推荐是 AOF 和 RDB 两者均开启 如果对数据不敏感可以选单独用 RDB 不建议单独用 AOF因为可能会出现 Bug 如果只是做纯内存缓存可以都不用 Redis 事务
事务是指一个完整的动作要么全部执行要么什么也没有做。redis 事务相关的四个 redis 指令即 multi、exec、discard、watch。这四个指令构成了 redis 事务处理的基础。
1、multi 用来组装一个事务
2、exec 用来执行一个事务
3、discard 用来取消一个事务
4、watch 用来监视一些 key一旦这些 key 在事务执行之前被改变则取消事务的执行。 redis multi redis INCR id redis INCR id redis exec 用 multi 组装事务时每一个命令都会进入内存中缓存起来QUEUED 表示缓存成功在 exec 时这些被 QUEUED的命令都会被组装成一个事务来执行。
对于事务的执行来说如果 redis 开启了 AOF 持久化的话那么一旦事务被成功执行事务中的命令就会通过write 命令一次性写到磁盘中去如果在向磁盘中写的过程中恰好出现断电、硬件故障等问题那么就可能出现只有部分命令进行了 AOF 持久化这时 AOF 文件就会出现不完整的情况这时可以使用 redis-check-aof 工具来修复这一问题这个工具会将 AOF 文件中不完整的信息移除确保 AOF 文件完整可用。
遇到的两类错误有调用 EXEC 之前的错误和调用 EXEC 之后的错误。 调用 EXEC 之前的错误是有可能是由于语法有误导致的也可能时由于内存不足导致的。只要出现某个命令无法成功写入缓冲队列的情况redis 都会进行记录在客户端调用 EXEC 时redis2.6.5 版本之后会拒绝执行这一事务。在 2.6.5 之前的版本中 redis 会忽略那些入队失败的命令只执行那些入队成功的命令。 对于调用 EXEC 后的错误 redis 则采取了完全不同的策略即 redis 不会理睬这些错误而是继续向下执行事务中的其他命令。这是因为对于应用层面的错误并不是 redis 自身需要考虑和处理的问题所以一个事务中如果某一条命令执行失败并不会影响接下来的其他命令的执行。 127.0.0.1:6379 set age 23
127.0.0.1:6379 watch age //开始监视 age
127.0.0.1:6379 set age 24 //在 EXEC 之前age 的值被修改了
127.0.0.1:6379 multi
127.0.0.1:6379 set age 25
127.0.0.1:6379 get age
127.0.0.1:6379 exec //触发 EXEC返回 nil
指令 watch 可以实现类似于乐观锁的效果即 CAS。watch 本身的作用是监视 key 是否被改动过而且支持同时监视多个 key只要还没真正触发事务watch 都会尽职尽责的监视一旦发现某个 key 被修改了在执行exec 时就会返回 nil表示事务无法触发。
如果在 WATCH 执行之后EXEC 执行之前有其他客户端修改了 key 值那么当前客户端的事务就会失败。 程序需要做的 就是不断重试这个操作 直到没有发生碰撞为止。这种形式的锁被称作乐观锁 它是一种非常强大的锁机制。 并且因为大多数情况下 不同的客户端会访问不同的键 碰撞的情况一般都很少 所以通常并不需要进行重试。
Redis 集群
Redis 单节点存在单点故障问题为了解决单点问题一般都需要对 Redis 配置从节点然后使用哨兵来监听主节点的存活状态如果主节点挂掉从节点能继续提供缓存功能主从配置结合哨兵模式能解决单点故障问题提高 Redis 可用性。从节点仅提供读操作主节点提供写操作。对于读多写少的状况可给主节点配置多个从节点从而提高响应效率。
redis 主从读写
与 mysql 相同redis 也提供了主从的功能更加非常简单。Mysql 的一主多从不能达到主高可用只能提高并发高可用不能直接依赖于 mysql 主从复制需要依赖于集群redis 的主从通过哨兵机制可以达到高可用 高并发单位时间内可以接收的请求数量 高可用服务器的服务质量 应用场景
1、在生产中难以避免单台 redis 出现故障保证高可用可以用主从
2、单台 redis 官网说能抗住 11w 并发量超过了 10w 高并发就可以主从
3、QPS 瓶颈。其中 QPS 每秒处理的查询次数、TPS 每秒处理的事务数。从请求到获得数据为一个完整事务过程
注意:一个 master 可以有多个 slave一个 slave 只能有一个 master数据流向是单向的 master 到 slave
主从复制的作用
1、读写分离master 写slave 读提高服务器的读写负载能力
2、负载均衡基于主从架构配合读写分离由 slave 分担 master 负载并根据需求的变化改变 slave 的数量通过多个从节点分担数据读取负载大大提高 redis 服务器并发量和数据吞吐量
3、故障恢复当 master 出现问题时由 slave 提供服务实现快速的故障恢复
4、数据冗余实现数据热备份是持久化之外的一种数据冗余方式
5、高可用基石基于主从复制构建哨兵模式与集群实现 redis 的高可用方案。
主从复制实现步骤
1、复制 redis 为 2 个对应的端口号分别为 6379 和 6380通过启动两个进程以模拟两个节点的情形
2、设置主从关系例如 6379 为 master可以通过 info replication 查看节点角色
3、slaveof localhost 6379 将一个节点转换为从节点。打开从节点配置文件 redis.conf 文件找到#slaveofmasterip masterport这个地方添加 slaveof master 的 ip 地址 master 的端口
4、从节点配置文件 slave-read-only 为 yes 则从节点只能读。注意如果配置从节点可以写的化主节点不会获取数据
5、可以在 redis-cli -p 6379 的客户端使用 shutdown 关闭主节点这时候从节点不会自动转换为主节点重启主节点后它仍旧是 master
主从复制实现原理
主从复制过程主要可以分为 3 个阶段连接建立阶段、数据同步阶段、命令传播阶段
1、连接建立阶段在主从节点之间建立连接为数据同步做准备
2、数据同步阶段执行数据的全量或增量复制复制 RDB 文件
3、命令传播阶段主节点将已执行的命令发送给从节点从节点接收命令并执行从而实现主从节点的数据一致性
主从模式中一个主节点可以有多个从节点。为了减少主从复制对主节点的性能影响一个从节点可以作为另外一个从节点的主节点进行主从复制。
不足之处主节点宕机之后需要手动拉起从节点来提供业务不能达到高可用
哨兵模式 Sentinel
Redis Sentinel 是 Redis 的高可用实现方案它可以实现对 redis 的监控、通知和自动故障转移当 redis master挂掉之后可以自动拉起 slave 提供业务从而实现 redis 的高可用。为了避免 Sentinel 本身出现单点故障Sentinel 自己也可采用集群模式
哨兵模式的原理
Sentinel 是一种特殊的 redis 节点每个 sentinel 节点会维护与其他 redis 节点包括 master、slave、sentinel的心跳。
1、当一个 sentinel 节点与 master 节点的心跳丢失时这个 sentinel 节点就会认为 master 节点出现了故障处于不可用的状态这种判定叫作主观下线即 sentinel 节点自己主观认为 master 下线了。
2、之后这个 sentinel 节点会与其他 sentinel 节点交换信息如果发现认为主节点发生故障的 sentinel 节点的个数超过了某个阈值通常为 sentinel 节点总数的 1/21即超过半数则 sentinel 会认为 master 节点已经处于客观下线的状态即大家都认为 master 故障不可用了。
3、之后sentinel 节点中会选举处一个 sentinel leader 来执行 redis 主节点的故障转移。
被选举出的 Sentinel 领导者进行故障转移的具体步骤
1、在从节点列表中选出一个节点作为新的主节点 过滤不健康或者不满足要求的节点 选择 slave-priority 优先级最高的从节点如果存在则返回不存在则继续 选择复制偏移量最大的从节点如果存在则返回不存在则继续 选择 runid 最小的从节点 2、Sentinel 领导者节点会对选出来的从节点执行 slaveof no one 命令让其成为主节点
3、Sentinel 领导者节点会向剩余的从节点发送命令让他们从新的主节点上复制数据
4、Sentinel 领导者会将原来的主节点更新为从节点 并对其进行监控 当其恢复后命令它去复制新的主节点。
集群架构
Redis 集群使用数据分片 sharding 而非一致性哈希 consistency hashing 来实现
1、一个 Redis 集群包含 16384 个哈希槽 hash slot数据库中的每个键都属于这 16384 个哈希槽的其中一个
2、集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽 其中 CRC16(key)语句用于计算键 key的 CRC16 校验和
3、集群中的每个节点负责处理一部分哈希槽
Redis 集群不支持那些需要同时处理多个键的 Redis 命令因为执行这些命令需要在多个 Redis 节点之间移动数据 并且在高负载的情况下 这些命令将降低 Redis 集群的性能 并导致不可预测的错误。Redis 为了兼容 multi-key 操作提供了 hash tags 操作每个 key 可以包含自定义的 tags在存储的时候根据 tags 计算此 key 应该映射到哪个 node 上
1、Redis 集群通过分区 partition 来提供一定程度的可用性 availability即使集群中有一部分节点失效或者无法进行通讯 集群也可以继续处理命令请求
2、Redis 集群尽可能保证数据的强一致性但在特定条件下会丢失数据原因有两点异步 replication 机制以及 network partition
3、Redis Cluster 提供了 replicas migration 机制当 Master 节点发生 failover 后集群会动态重新分配、平衡Slaves 的分布有效地提高了集群的可用性
