Hello Redis，我有7个问题想请教你( 四 ) _Redis

②分裂
这个过程也成为分裂的过程，本来父子进程都指向很多相同的内存块，但是如果父进程对其中某个内存块进行该修改，就会将其复制出来，进行分裂再在新的内存块上面进行修改。
因为子进程在 Fork 的时候就可以固定内存，这个时间点的数据将不会产生变化。
所以我们可以安心的产生快照不用担心快照的内容受到父进程业务请求的影响。
另外可以想象，如果在 Bgsave 的过程中，Redis 没有任何操作，父进程没有接收到任何业务请求也没有任何的背后例如过期移除等操作，父进程和子进程将会使用相同的内存块。
AOF
AOF 是 Redis 操作指令的日志存储，类同于 MySQL 的 Binlog，假设 AOF 从 Redis 创建以来就一直执行，那么 AOF 就记录了所有的 Redis 指令的记录。
如果要恢复 Redis，可以对 AOF 进行指令重放，便可修复整个 Redis 实例。
不过 AOF 日志也有两个比较大的问题：

一个是 AOF 的日志会随着时间递增，如果一个数据量大运行的时间久，AOF 日志量将变得异常庞大。
另一个问题是 AOF 在做数据恢复时，由于重放的量非常庞大，恢复的时间将会非常的长。

AOF 写操作是在 Redis 处理完业务逻辑之后，按照一定的策略才会进行些 AOF 日志存盘，这点跟 MySQL 的 Redolog 和 Binlog 有很大的不同。
也因为此原因，Redis 因为处理逻辑在前而记录操作日志在后，也是导致 Redis 无法进行回滚的一个原因。
bgrewriteaof：针对上述的问题，Redis 在 2.4 之后也使用了 bgrewriteaof 对 AOF 日志进行瘦身。
bgrewriteaof 命令用于异步执行一个 AOF 文件重写操作。重写会创建一个当前 AOF 文件的体积优化版本。
RDB 和 AOF 混合搭配模式
在对 Redis 进行恢复的时候，如果我们采用了 RDB 的方式，因为 Bgsave 的策略，可能会导致我们丢失大量的数据。
如果我们采用了 AOF 的模式，通过 AOF 操作日志重放恢复，重放 AOF 日志比 RDB 要长久很多。

文章插图

Redis 4.0 之后，为了解决这个问题，引入了新的持久化模式，混合持久化，将 RDB 的文件和局部增量的 AOF 文件相结合。
RDB 可以使用相隔较长的时间保存策略，AOF 不需要是全量日志，只需要保存前一次 RDB 存储开始到这段时间增量 AOF 日志即可，一般来说，这个日志量是非常小的。
Redis 在内存使用上是如何开源节流

文章插图

Redis 跟其他传统数据库不同，Redis 是一个纯内存的数据库，并且存储了都是一些数据结构的数据，如果不对内存加以控制的话，Redis 很可能会因为数据量过大导致系统的奔溃。
Ziplist
127.0.0.1:6379> hset hash_test abc 1 (integer) 1 127.0.0.1:6379> object encoding hash_test "ziplist" 127.0.0.1:6379> zadd z_test 10 key (integer) 1 127.0.0.1:6379> object encoding z_test "ziplist" 当最开始尝试开启一个小数据量的 Hash 结构和一个 Zset 结构时，发现他们在 Redis 里面的真正结构类型是一个 Ziplist 。
Ziplist 是一个紧凑的数据结构，每一个元素之间都是连续的内存，如果在 Redis 中，Redis 启用的数据结构数据量很小时，Redis 就会切换到使用紧凑存储的形式来进行压缩存储。

文章插图

例如，上面的例子，我们采用了 Hash 结构进行存储，Hash 结构是一个二维的结构，是一个典型的用空间换取时间的结构。
但是如果使用的数据量很小，使用二维结构反而浪费了空间，在时间的性能上也并没有得到太大的提升，还不如直接使用一维结构进行存储。
在查找的时候，虽然复杂度是 O(n)，但是因为数据量少遍历也非常快，增至比 Hash 结构本身的查询更快。
如果当集合对象的元素不断的增加，或者某个 Value 的值过大，这种小对象存储也会升级生成标准的结构。
Redis 也可以在配置中进行定义紧凑结构和标准结构的转换参数：
hash-max-ziplist-entries 512 # hash的元素个数超过512就必须用标准结构存储 hash-max-ziplist-value 64 # hash的任意元素的key/value的长度超过 64 就必须用标准结构存储 list-max-ziplist-entries 512 list-max-ziplist-value 64 zset-max-ziplist-entries 128 zset-max-ziplist-value 64 set-max-intset-entries 512 Quicklist
127.0.0.1:6379> rpush key v1 (integer) 1 127.0.0.1:6379> object encoding key "quicklist"