1 Redis的持久化机制：RDB和AOF
RDB就是快照方式，AOF是记录操作日志的方式。目前Redis持久化的方式不是具体使用某一种，而是两种方式想结合的方式。
同样，我所开发的项目中，涉及到将关系型数据库的数据同步到大数据，实现方式也是类似这两种方式的结合。在启动或初始化的时候，会进行全量同步，类似快照方式，之后会通过监控操作日志的方式进行异步增量同步，之所以要采取异步的方式是要保证不影响上游关系型数据库的正常使用。
下面再回过头来具体介绍一下，两种持久化的方式：
1.1 RDB机制（快照方式）
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。这是默认的持久化方式。
既然RDB机制是通过把某个时刻的所有数据生成一个快照来保存，那么就应该有一种触发机制来实现这个过程。对于RDB来说，提供了三种机制：save、bgsave、自动化。
save触发方式会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。这种方式显然不可取。
bgsave命令执行时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。
自动触发时由配置文件来完成的，就是指定什么时候将内存中的数据保存到硬盘，比如m秒内数据集存在n次修改时，自动触发。
RDB的优势：文件紧凑，全量备份，在恢复大数据集时的速度比 AOF 的恢复速度要快。
RDB的劣势：当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。
1.2 AOF机制（记录操作日志）：
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。
详细介绍如下：AOF持久化是指将每一个收到的写命令都通过write函数追加到文件中，通俗的理解就是日志记录。
AOF的方式也同时带来了另一个问题，持久化文件会变的越来越大。为了压缩AOF的持久化文件，redis提供了bgrewriteaof命令，将内存中的数据以命令的方式保存到临时文件中，同时会fork出一条新进程来将文件重写。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
AOF也有三种触发机制：（1）always：每修改一次就同步一次，性能较差，但完整性比较好；（2）everysec：每秒同步，异步操作，如果一秒内宕机，有数据丢失；（3）no：不同步。
AOF的优势：数据能够更好地得到保护，通过everysec机制，最多丢失1秒钟的数据；没有任何磁盘寻址开销，写入性能高；不会对客户端产生影响；比较适合做灾难性的误删除的紧急恢复。
AOF的缺点：比RDB数据快照文件更大；AOF开启后，支持写的QPS会比RDB支持写的QPS低。
2 Redis的数据淘汰策略：
2.1 最大参数设置
Redis在参数设置中有一个内存使用上限设置maxmemory，也就是说当redis使用内存达到最大值时，redis会根据配置文件中的策略选取要删除的key，并删除这些key-value的值。若根据配置的策略，没有符合策略的key，也就是说内存已经容不下新的key-value了，但此时又不能删除key，那么这时写的话，将会出现写错误。
若maxmemory参数设置为0，则分两种情况：
（1）在64位系统上，表示没有限制。
（2）在32为系统上，是3G，redis官方文档的说法是，32位系统最大内存是4G，预留1G给系统。而且策略会自动设置为noeviction。也就是说在32位系统上，若maxmemory设置为0，则默认是3G，当到达3G，再往reidis中写入时，则会报错。
2.2 淘汰策略介绍：
Redis在已使用内存达到设定的上限时，提供了6种数据淘汰策略（也就是maxmemory-policy可能的值）：
（1）volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
（2）volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
（3）volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
（4）allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
（5）allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
（6）no-enviction（驱逐）：禁止驱逐数据
2.3 需要注意以下几点：
（1）maxmemory-policy同样可以在运行时设置，用户可以根据内存的使用情况动态的修改淘汰策略。
（2）当redis中的数据有一部分访问频率比较高，另外一部分访问频率较低时，设置allkeys-lru比较合适。或者无法预测数据的使用频率时，allkeys-lru也是不错的选择。
（3）如果你需要循环或者扫描连续数据时，换种说法就是数据的访问概率大致相等时，allkeys-random是不错的选择。
（4）当你想通过设置不同的ttl来控制数据过期的先后顺序时，你可以设置为volatile-ttl。
（5）当你希望一些数据常驻内存，另外一些数据可以被替换掉时，就请用volatile-lru或volatile-random吧。
（6）另外，数据的过期时间是存储在另外一个哈希表中的，因此要耗费更多的内存空间，而allkeys-lru并不需要数据设置过期时间，因此对内存的利用率更高。
（7）volatile-lru, volatile-random 和 volatile-ttl 在没有数据满足被淘汰的条件时，会和noeviction一样返回错误。
2.4 何时触发淘汰数据的动作：
（1）一个客户端执行指令，导致数据的增加时。
（2）Redis检测到内存的使用已经达到上限。
（3）Redis自身执行指令时，等等
