文章目录
Reids 分布式缓存
基于 Reids 集群来解决单机的 Reids 存在的问题。
在单机的 Reids 中存在着一共有 4 大问题。
- 数据丢失问题；要实现的是 Reids 的数据持久化。
- 并发能力问题；搭建主从集群，实现读写分离。
- 故障恢复问题；利用 Reids 哨兵机制，实现健康监测和自动恢复能力。
- 存储能力问题；搭建分片集群，利用插槽机制来实现动态扩容。
Redis 的持久化
在 Redis 中有着两种持久化的方案
- RDB持久化
- AOE持久化
RDB 持久化
RDB 全称 Redis Database Backup file（Redis数据备份文件），也被叫做Redis 数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis 实例故障重启后，从磁盘中读取快照文件，恢复数据。快照文件称为RDB 文件，默认是保存在当前运行目录。
RDB 持久化会在四种情况下会执行：
● 执行 save 命令
● 执行 bgsave 命令
● Redis 停机时
● 触发 RDB 条件时
执行 save 命令的时候，save 会导致 RDB，这个过程中其它所有命令都会被阻塞。只有在数据迁移时可能用到。平常情况下，不建议使用。
执行 bgsave 命令的时候。这个命令执行后会开启一个独立的进程完成 RDB，主进程可以持续处理用户请求，而不受印象。
在 Redis 停机的时候，也会触发一次 RDB 的。
在退出前的时候，就会执行一次 RDB 。
触发 RDB 的条件
在 Redis 内部也是有着触发 RDB 的机制，可以在 redis.conf 文件中找到，格式如下：
# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是 save "" 则表示禁用RDB
save 900 1
save 300 10
save 60 10000
RDB 的也有一些其它配置也可以在 redis.conf 文件中设置：
# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
rdbcompression yes
# RDB文件名称
dbfilename dump.rdb
# 文件保存的路径目录
dir ./
RDB 原理
在 bgsave 开始的时候就会 fork 主进程而得到一个子进程，子进程共享主进程的内存数据，完成 fork 以后读取内存数据并写入 RDB 文件。
以这样的方式，看似在持久化的时候，不会阻塞主进程，但是在 fork 的时候，还是会短暂性的阻塞一下主进程，在 fork 之后，主进程就不会再受打扰了。
完整流程：
当发生 bgsave 的时候，先会短暂性的暂停一下主进程，将主进程里的页表复制到子进程里面，然后将物理内存（就是磁盘）里的 Redis 数据改为 read-only 模式，只能读取模式。然后子进程通过 fork 过来的页表对数据进行操作，形成新的 RDB 文件，在完成之后，用新的 RDB 文件覆盖替换旧的 RDB 文件。当在子进程工作的时候，磁盘文件是只读模式。那么这个时候主进程产生需要对物理内存中数据修改的操作时，物理内存会将需要修改的数据复制出来，形成一个副本数据，对这个副本数据进行操作。这种情况下，以理论角度来思考，是会发生将原 RDB 数据全部进行了修改，那个这个时候，就将内存的大小进行了翻倍。
页表：就是将虚拟地址转换为物理地址 ；管理 cpu 对物理页的访问，如读写执行权限 。它就是一种映射关系。将虚拟内存与物流内存之间连接起来。
fork 采用的是 copy-on-write 技术：
- 当主进程执行读操作时，访问共享内存；
- 当主进程执行写操作时，则会拷贝一份数据，执行写操作。
RDB方式bgsave的基本流程概述：
- fork主进程得到一个子进程，共享内存空间
- 子进程读取内存数据并写入新的RDB文件
- 用新RDB文件替换旧的RDB文件
AOF 原理
AOF全称为Append Only File（追加文件）。Redis 处理的每一个写命令都会记录在 AOF 文件，可以看做是命令日志文件。
比如我们对 redis 里保存一个 SET num 123 命令
在 AOF 保存的文件里就是这样的命令：
AOF 持久化
在 Redis 配置文件里面 AOF 默认是关闭的。
需要修改 redis.conf 的配置文件来开启 AOF：
# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"
AOF 的命令记录的频率也是可以通过 redis.conf 文件来配置的。（也是三种策略）
# 表示每执行一次写命令，立即记录到AOF文件
appendfs
最低0.47元/天 解锁文章
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
