1、Redis五大对象：
在Redis中有五大对象，分别是String、List、Hash、Set、Sorted Set。
这五大对象都有自己独特的编码方式，每个编码的实现都不一样，有自己独特的使用场景。
通过命令：object encoding keyName查看键的编码类型。
a、String（字符串类型）：
INT：可以用long型保存的整数。
EMBSTR：除了字符串、long，还可以保存double这种浮点数，但长度需要<=44。
RAW：保存长度大于44的字符串、long、double。
b、List（列表）：
quicklist包含多个ziplist，是对ziplist的优化。
list-max-ziplist-size，若值是整数则表示quicklist上ziplist的节点数量，负数则表示ziplist的大小（公式：KB = -1 * 2 ^ n）。
- -3：quicklist节点的ziplist大小不能超哥16KB。
- -2：quicklist节点的ziplist大小不能超哥8KB（默认值）。
- -1：quicklist节点的ziplist大小不能超哥4KB。
因为list被设计成两端获取效率高，中间数据获取效率低，若满足这个条件可以通过list-compress-depth配置来压缩中间数据，进一步节省内存。
- 0：特殊值，不是不压缩（默认值）。
- 1：quicklist两端各有1个节点不压缩，中间的节点压缩。
- 2：quicklist两端各有2个节点不压缩，中间的节点压缩。
- 以此类推。
c、Hash（字典）：
当哈希对象同时满足一下两个条件时，使用ziplist编码：
- 所有键值元素长度小于64字节，可通过改变hash-max-ziplist-value修改默认值。
- 键值对数量小于512个，可通过改变hash-max-ziplst-entries修改默认值
d、Set（集合）：
当集合对象同时满足以下两个条件时，集合对象使用intset编码
- 集合对象保存的所有元素都是整数值。
- 键值对数量不超过512个，可通过修改配置文件中的set-max-inset-entries属性改变默认值。
e、ZSet（有序集合）：
当有序集合对象同时满足以下两个条件时，有序集合对象使用ziplist编码：
有序集合对象保存的所有成员长度小于64字节，可通过修改配置文件中的zset-max-ziplist-value属性改变默认值。
有序集合对象保存的所有元素数量小于128个，可通过修改配置文件中的zset-max-ziplist-entries属性改变默认值。
2、Redis持久化
a、RDB持久化：
RDB持久化方式就是把当前进程中的数据以快照形式保存到磁盘的过程，其分为手动和自动触发。
手动：
- save命令：save命令会阻塞主进程，若数据量较大则会影响正常的服务请求。
- bgsave命令：bgsave会fork一个子进程，则会阻塞fork子进程的时间且阻塞时间很短。
自动触发条件：
- 根据单位时间（秒）内数据修改次数来触发，默认配置如下：
- save 900 1
- save 300 10
- save 60 10000
- 从节点进行全量复制时。
- 执行debug reload命令时。
- 执行shutdown命令时若没有开启aof时执行bgsave。
RDB持久化步骤：
- 执行bgsave命令，此时父进程会判断是否有正在执行的子进程（如RDB/AOP），如有直接返回。
- 父进程执行fork操作创建子进程，此时父进程会阻塞（可通过info stats命令查看latest_fork_usec选项查看最近一个fork操作耗时，单位微妙）。
- 父进程fork完后，bgsave会返回"Background saving started"，并不再阻塞父进程。
- 子进程创建RDB文件。
RDB优缺点：
优点：
- RDB持久化的文件非常紧凑（有压缩），它会保存某个时间点的数据，可以方便的把数据传送远端数据中心，适用于灾难恢复。
- bgsave存储时用子进程执行操作，最大化的优化redis的性能。
- 与AOF相比，在恢复大量数据时会快些。
缺点：
- 因为不是实时存储数据，所以宕机时会丢失一部分数据。
- 数据量大时，fork的过程会非常耗时，如果fork阻塞，那么主线程也会受到影响。
- RDB方式的持久化的文件是特定的格式，可读性、兼容性差（不同版本的RDB格式都不一样）。
b、AOF持久化：
RDB与AOF两种持久化方式只能二选一，若需要使用AOF需要通过配置文件开启，因为默认是不开启的。
配置：
- 是否开启APO（默认false）：appendonly yes。
- AOF文件名（默认appendonly.aof）：appendfilename xxx.aof。
- 保存路径：通过dir配置指定。
AOF持久化是通过保存Redis服务器所执行的命令来记录数据库的状态，每执行一个命令就会往AOF文件后追加一个命令。
AOF采用RESP协议写入数据：
单行字符，+开头。
多行字符，$开头，后跟字符串长度。
整数值，:开头，后跟整数字符串形式。
错误消息，-开头。
数组，*开头，后跟数组长度。
AOF持久化流程：
- 首先每次追加直接操作磁盘的话，性能上肯定不高，所以Redis会先将命令追加到aof_buf中。
- 然后缓冲区再根据相应的策略将缓冲区的内容同步到磁盘。
- 并且Redis还会定期的对AOF文件进行重写，以达到压缩的目的。
- 服务器重启时可以通过AOF文件恢复数据。
为什么AOF文件能够重写：
- 过期的数据可以不写入。
- 无效的数据可以不写入。
- 多条命令可以合并成一个写入。
AOF持久化的优缺点：
优点：
- 支持秒级持久化。
- 可用于不同版本的Redis服务器，兼容性强。
- 可读性高。
缺点：
- 文件大，恢复数据慢。
3、Redis主从复制
a、主从复制是什么：
在绝大多数中间件中都会具有主动复制这一功能，而多数也就是为了服务的高可用罢了；Redis也不例外，它提供了复制功能，实现了相同数据的多个副本。
b、搭建复制三种方式：
- 从节点配置文件中加入slaveof <masterIp> <masterPort>
- 启动命令后加入--slaveof <masterIp> <masterPort>
- 通过命令laveof <masterIp> <masterPort>
注意：
- slaveof是异步命令，节点保存主节点信息后便返回，后续复制就从在节点异步进行。
- 由于复制模式是单向的，从节点接收写命令的话无法让主节点感知，这样会造成数据不一致的情况，所以从节点需要配置成只读模式（slave-read-only=yes）。
c、主动复制原理：
流程：
- 保存主节点信息：从节点保存主节点信息（ip、port）。
- job网络连接主节点：从节点内部通过job来维护复制相关逻辑，当job发现新的主节点后会尝试与该节点建立网络连接；若无法连接job会无限重试直到连接成功，或执行slaveof no one命令取消复制。
- 发送ping给主节点：从节点会发送ping命令，检测主动之间套接字是否可用，和主节点当前是否可接受处理命令。
- 权限验证：如果主节点设置了requirepass则需要密码验证，且从节点需要有相同的配置才能通过验证；如果验证失败复制终止，从节点断开连接。
- 连接成功：发送从节点的ip、port给主节点。
- 数据同步：依据情况主从之间进行全量或部分复制。
- 命令传播：当上述步骤完成后，也算是完成了复制的建立流程，接下来主节点会持续地把命令发送给从节点来保证主从数据的一致性。
全量复制于部分复制：
）全量：psync ? -1
一般用于初次复制的场景（虽然早期的Redis也仅支持全量复制），它会一次性的打包所有的数据给从节点，当数据量较大时会主从节点和网络造成很大的开销。
）部分：psync <runid> <offset>
用于复制过程中宕机或网络闪断的场景，主节点会补发数据给从节点。因补发数据远小于全量数据，所以可以有效的避免全量复制的开销。
部分复制的三要素：
- 复制偏移量：参与复制的主从节点都会维护自身的偏移量，主节点在处理完写命令后会累加这个偏移量，从节点会每秒的上报偏移量，因此主节点就拥有了主从的偏移量。
- 温馨提示：可以通过主节点master_repl_offset信息判断主动节点相差的数据量，从而得知复制的健康度。
- 复制积压缓冲区：主节点执行写命令时不但会将数据同步给从节点，还会写入到复制积压缓冲区。部分复制时会根据缓冲区的偏移量来判断从哪开始复制。
- 运行ID：若主从runid相同，则表示此主从之前同步过，进行部分复制即可；若不同则表示从节点之前同步的主节点并非此主节点，所以要进行全量复制。
psync命令流程图：
