交流空间：当一些内存 page 被存储在交流空间文件上，而 Redis 又要央求那些数据，那么操作系统会阻塞 Redis 进程，然后把想要的 page，从交流空间中拿出来，放进内存。这其中触及整个进程的阻塞，所以能够会形成延时成绩，一个处置办法是制止运用交流空间（Redis Essentials 中如是建议，假设内存空间不足，请用别的办法处置）。
思索耐久化带来的开支Redis 的一项重要功用就是耐久化，也就是把数据复制到硬盘上。基于耐久化，才有了 Redis 的数据恢复等功用。
但维护这个耐久化的功用，也是有功用开支的。
首先说，RDB 全量耐久化。
这种耐久化方式把 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作者和散布式大神打架，最大的赢家居然是吃瓜网友
全球散布式算力共享鼻祖寻觅外星人近 21 年，一切都是白费？
Nginx在高并发下的功用优化点！有这篇就够了！
超过8000不安全Redis暴露在云端
我司用了 6 年的 Redis 散布式限流器，可以说是十分凶猛了
(责任编辑：admin)