redis知识总结

Redis

---

主从复制

1. 全量同步

slave服务器重启 或者 刚刚开始同步的时候进行的操作

MacDown logo

2. 增量同步

slave服务器初始化以后 进行的操作
主服务器发送命令到从服务器

持久化

1. RDB

手动执行持久化

手动进行一次数据快照，区分SAVE 和 BGSAVE

SAVE操作在Redis主线程中工作，因此会阻塞其他请求操作，应该避免使用。

BGSAVE命令会fork一个子进程，子进程在后台生成RDB文件，主进程进行处理客户端命令请求。
Fork发生时，父子进程内存共享，所以为了不影响子进程做数据快照，在这期间修改的数据，将会被复制一份，而不进共享内存。所以说，RDB所持久化的数据，是Fork发生时的数据。在这样的条件下进行持久化数据，如果因为某些情况宕机，则会丢失一段时间的数据。

自动执行持久化

通过配置文件的方式自动进行

通过在配置文件里设置save选项，让服务器每隔一段时间自 动执行一次BGSAVE命令， 如：save 900 1 指在900秒内对数据库至少修改一次就会执行BGSAVE命令。

配置如下：

MacDown logo

2. AOF

RDB持久化通过保存数据库中键值对来记录数据库状态，

AOF持久化通过保存redis服务器执行的写命令保存数据库状态,所有写命令以命令请求协议格式保存，即纯文本格式。

AOF 开启：

appendonly yes

开启后，你所执行的每一条指令，都会被记录到appendonly.aof文件中

AOF 将硬盘缓存刷入硬盘文件的频率控制：

MacDown logo

redis默认使用everysec，就是说每秒持久化一次。no默认30s 一次。

3. AOF vs RDB

1. RDB每次进行快照方式会重新记录整个数据集的所有信息,RDB在恢复数据时更快（由于是纯数据）

2. AOF有序的记录了redis的命令操作。意外情况下数据丢失甚少

3. AOF 文件变大 优化策略

   比如你对一个key1键的操作，

   set key1 001,

   set key1 002,

   set key1 003

   那优化的结果就是将前两条去掉，具体配置：

MacDown logo

前者是指超过上一次aof重写aof文件大小的百分之多少，会再次优化，如果没有重写过，则以启动时为主。后者是限制了允许重写的最小aof文件大小。bgrewriteaof命令是手动重写命令，会fork子进程，在临时文件中重建数据库状态

Redis 中的事件驱动模型

Redis 内存优化

共享内存池

redis 内部维护的一个[0-9999]的整数对象池