数据为什么会出现不一致的情况？

本期是 Redis 第二期，至此 Redis 部分就全部更新完毕了，下一弹就是常见智力题与面试剖析了，估计还有两三期，整个逆袭进大厂系列就全部完结啦。

完结的时间，也会更新 PDF 的第四版，大家可以放心，第四版绝对值得期待！

17、假如MySQL有1000万数据，采用Redis作为中间缓存，取其中的10万，如何保证Redis中的数据都是热点数据？

可以使用Redis的数据淘汰策略，Redis 内存数据集大小上升到一定大小的时候，就会施行这种策略。具体说来，主要有 6种内存淘汰策略：

voltile－lru：从已设置过期时间的数据集（server．db［i］．expires）中挑选最近最少使用的数据淘汰

volatile－ttl：从已设置过期时间的数据集（server．db［i］．expires）中挑选将要过期的数据淘汰

volatile－random：从已设置过期时间的数据集（server．db［i］．expires）中任意选择数据淘汰

allkeys－lru：从数据集（server．db［i］．dict）中挑选最近最少使用的数据淘汰

allkeys－random：从数据集（server．db［i］．dict）中任意选择数据淘汰

no－enviction（驱逐）：禁止驱逐数据

18、Redis持久化机制可以说一说吗？

Redis是一个支持持久化的内存数据库，通过持久化机制把内存中的数据同步到硬盘文件来保证数据持久化。当Redis重启后通过把硬盘文件重新加载到内存，就能达到恢复数据的目的。

很多时候我们需要持久化数据也就是将内存中的数据写入到硬盘里面，大部分原因是为了之后重用数据（比如重启机 器、机器故障之后回复数据），或者是为了防止系统故障而将数据备份到一个远程位置。

实现：单独创建fork（）一个子进程，将当前父进程的数据库数据复制到子进程的内存中，然后由子进程写入到临时文件中，持久化的过程结束了，再用这个临时文件替换上次的快照文件，然后子进程退出，内存释放。

以下有两种持久化机制快照（snapshotting）持久化（RDB持久化）

Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis创建快照之后，可以对快照进行 备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis主从结构，主要用来提高Redis性 能），还可以将快照留在原地以便重启服务器的时候使用。

快照持久化是Redis默认采用的持久化方式，在Redis．conf配置文件中默认有此下配置：

save 900 1 ＃在900秒（15分钟）之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令

创建快照。

save 300 10 ＃在300秒（5分钟）之后，如果至少有10个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

save 60 10000 ＃在60秒（1分钟）之后，如果至少有10000个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

AOF（append－only file）持久化

与快照持久化相比，AOF持久化的实时性更好，因此已成为主流的持久化方案。默认情况下Redis没有开启 AOF（append only ?le）方式的持久化，可以通过appendonly参数开启：appendonly yes

开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的 保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly．aof。

在Redis的配置文件中存在三种不同的 AOF 持久化方式，它们分别是：

appendfsync always ＃每次有数据修改发生时都会写入AOF文件，这样会严重降低Redis的速度
appendfsync everysec  ＃每秒钟同步一次，显示地将多个写命令同步到硬盘
appendfsync no  ＃让操作系统决定何时进行同步

为了兼顾数据和写入性能，用户可以考虑 appendfsync everysec选项 ，让Redis每秒同步一次AOF文件，Redis性能 几乎没受到任何影响。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。

Redis 4．0 对于持久化机制的优化

Redis 4．0 开始支持 RDB 和 AOF 的混合持久化（默认关闭，可以通过配置项 aof－use－rdb－preamble 开启）。

如果把混合持久化打开，AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头。这样做的好处是可以结合 RDB 和 AOF 的优点， 快速加载同时避免丢失过多的数据。当然缺点也是有的， AOF 里面的 RDB 部分是压缩格式不再是 AOF 格式，可读性较差。

19、AOF重写了解吗？可以简单说说吗？

AOF重写可以产生一个新的AOF文件，这个新的AOF文件和原有的AOF文件所保存的数据库状态一样，但体积更小。

AOF重写是一个有歧义的名字，该功能是通过读取数据库中的键值对来实现的，程序无须对现有AOF文件进行任伺读 入、分析或者写入操作。

在执行 BGREWRITEAOF 命令时，Redis 服务器会维护一个 AOF 重写缓冲区，该缓冲区会在子进程创建新AOF文件期间，记录服务器执行的所有写命令。当子进程完成创建新AOF文件的工作之后，服务器会将重写缓冲区中的所有内容 追加到新AOF文件的末尾，使得新旧两个AOF文件所保存的数据库状态一致。最后，服务器用新的AOF文件替换旧的 AOF文件，以此来完成AOF文件重写操作。

20、是否使用Redis集群，集群的原理是什么

Redis Sentinel（哨兵）着眼于高可用，在master宕机时会自动将slave提升为master，继续提供服务。

Sentinel（哨兵）可以监听集群中的服务器，并在主服务器进入下线状态时，自动从服务器中选举出新的主服务器。

Redis Cluster（集群）着眼于扩展性，在单个Redis内存不足时，使用Cluster进行分片存储。