为什么数据量小的时候用压缩列表 ?
为了省内存。
Redis 主从同步是怎么实现的？
全量同步
master 服务器会开启一个后台进程用于将 redis 中的数据生成一个 rdb 文件，与此同时，
服务器会缓存所有接收到的来自客户端的写命令（包含增、删、改），当后台保存进程处理完
毕后，会将该 rdb 文件传递给 slave 服务器，而 slave 服务器会将 rdb 文件保存在磁盘并
通过读取该文件将数据加载到内存，在此之后 master 服务器会将在此期间缓存的
命令通过 redis 传输协议发送给 slave 服务器，然后 slave 服务器将这些命令依次作用于
自己本地的数据集上最终达到数据的一致性。
增量同步
从 redis 2.8 版本以前，并不支持部分同步，当主从服务器之间的连接断掉之后，master 服
务器和 slave 服务器之间都是进行全量数据同步。
从 redis 2.8 开始，即使主从连接中途断掉，也不需要进行全量同步，因为从这个版本开始
融入了部分同步的概念。部分同步的实现依赖于在 master 服务器内存中给每个 slave 服务
器维护了一份同步日志和同步标识，每个 slave 服务器在跟 master 服务器进行同步时都会
携带自己的同步标识和上次同步的最后位置。当主从连接断掉之后，slave 服务器隔断时间
（默认 1s）主动尝试和 master 服务器进行连接，如果从服务器携带的偏移量标识还在
master 服务器上的同步备份日志中，那么就从 slave 发送的偏移量开始继续上次的同步操
作，如果 slave 发送的偏移量已经不再 master 的同步备份日志中（可能由于主从之间断掉
的时间比较长或者在断掉的短暂时间内 master 服务器接收到大量的写操作），则必须进行
一次全量更新。在部分同步过程中，master 会将本地记录的同步备份日志中记录的指令依次
发送给 slave 服务器从而达到数据一致。
Redis 主从同步策略
主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，
slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，
如不成功，要求从机进行全量同步。
Redis 持久化 RDB 和 AOF 优缺点
RDBRDB 持久化方式，是将 Redis 某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。
RDB 优点：
RDB 是一个非常紧凑（有压缩）的文件,它保存了某个时间点的数据,非常适用于数据的备份。
RDB 作为一个非常紧凑（有压缩）的文件，可以很方便传送到另一个远端数据中心 ，非常适用于灾难恢复。
RDB 在保存 RDB 文件时父进程唯一需要做的就是 fork 出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他 IO 操作，所以 RDB 持久化方式可以最大化redis 的性能。
与 AOF 相比，在恢复大的数据集的时候，RDB 方式会更快一些。
RDB 缺点：
Redis 意外宕机时，会丢失部分数据。
当 Redis 数据量比较大时，fork 的过程是非常耗时的，fork 子进程时是会阻塞的，在这
期间 Redis 是不能响应客户端的请求的。
AOF
AOF 方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行
一遍。
AOF 优点：
使用 AOF 会让你的 Redis 更加持久化。
AOF 文件是一个只进行追加的日志文件，不需要在写入时读取文件。
Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写 。
AOF 文件可读性高，分析容易。
AOF 缺点：
对于相同的数据来说，AOF 文件大小通常要大于 RDB 文件。
根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB。
学习之路贵在坚持，关注我！
浩说编程陪你每天三道高频面试题，日积月累一定会有所收获！
