这种耐久化方式把 Redis 中的全量数据打包成 rdb 文件放在硬盘上。但是执行 RDB 耐久化进程的是原进程 fork 出来一个子进程，而 fork 这个系统调用是需求时间的，依据Redis Lab 6 年前做的 实验 [12] ，在一台新型的 AWS EC2 m1.small^13 上，fork 一个内存占用 1GB 的 Redis 进程，需求 700+ 毫秒，而这段时间，redis 是无法处置央求的。

虽然如今的机器应该都会比那个时分好，但是 fork 的开支也应该思索吧。为此， 要运用合理的 RDB 耐久化的时间距离，不要太频繁 。

接上去，我们看另外一种耐久化方式：AOF 增量耐久化。

这种耐久化方式会把你发到 redis server 的指令以文本的方式保存上去（格式遵照 redis protocol），这个进程中，会调用两个系统调用，一个是 write(2) ，同步完成，一个是 fsync(2) ，异步完成。

这两部都能够是延时成绩的缘由：

write 能够会由于输入的 buffer 满了，或许 kernal 正在把 buffer 中的数据同步到硬盘，就被阻塞了。

fsync 的作用是确保 write 写入到 aof 文件的数据落到了硬盘上，在一个 7200 转/分的硬盘上能够要延时 20 毫秒左右，消耗还是挺大的。更重要的是，在 fsync 停止的时分，write 能够会被阻塞。

其中，write 的阻塞貌似只能接受，由于没有更好的办法把数据写到一个文件中了。但关于 fsync，Redis 允许三种配置，选用哪种取决于你对备份及时性和功用的平衡：

always：当把 appendfsync 设置为 always，fsync 会和客户端的指令同步执行，因此最能够形成延时成绩，但备份及时性最好。

everysec：每秒钟异步执行一次 fsync，此时 redis 的功用表现会更好，但是 fsync 依然能够阻塞 write，算是一个折中选择。

no：redis 不会自动动身 fsync （并不是永远不 fsync，那是不太能够的），而由 kernel 决议何时 fsync

运用散布式架构 —— 读写别离、数据分片

以上，我们都是基于单台，或许单个 Redis 效劳停止优化。下面，我们思索当网站的规模变大时，应用散布式架构来保障 Redis 功用的成绩。

首先说，哪些状况下不得不（或许最好）运用散布式架构：

数据量很大，单台效劳器内存不能够装得下，比如 1 个 T 这种量级

需求效劳高可用

单台的央求压力过大

处置这些成绩可以采用数据分片或许主从别离，或许两者都用（即，在分片用的 cluster 节点上，也设置主从结构）。

这样的架构，可以为功用提升参加新的切入点：

把慢速的指令发到某些从库中执行

把耐久化功用放在一个很少运用的从库上

把某些大 list 分片

其中前两条都是依据 Redis 单线程的特性，用其他进程（甚至机器）做功用补充的办法。

当然，运用散布式架构，也能够对功用有影响，比如央求需求被转发，数据需求被不断复制分发。（待查）

后话

其实还有很多东西也影响 Redis 的功用，比如 active rehashing（keys 主表的再哈希，每秒 10 次，关掉它可以提升一点点功用），但是这篇博客曾经写的很长了。而且，更重要不是搜集曾经被别人提出的成绩，然后记忆处置方案；而是掌握 Redis 的基本原理，以不变应万变的方式决绝新出现的成绩。

(责任编辑：admin)