redis — 持久化机制与内存淘汰策略（二）

1. 存储数据结构

Redis 总的以 HashTable 存储，内部存储 5 种数据结构。

• Key-String 字符串存储；
• Key-List 列表存储；
• Key-Hash 哈希存储；
• Key-Set 集合存储；
• Key-Zset 有序集合存储。

其他高级命令:
keys 全量遍历键（谨慎使用） scan 渐进式遍历键 >scan 0 match * count 1000 从游标位置，匹配 1000 条记录，返回游标加集合 >scan p1 match p2 count p3 其中，3 个参数，p1：游标，p2：匹配内容，p3：查询数量。

2.特点、实现&部分配置

2.1 特点

• 连接请求使用单线程，无线程间切换损耗 此处注意，单线程只是接收命令的入口使用单线程。还有其他线程用于处理持久化，AOF 重写以及其他操作。
• I/O多路复用
• 内存数据，基本操作在纳秒级别。缓存数据被存在内存中，访问速度非常迅速。但需要注意的是，避免使用消耗资源较大的命令，如 keys ，若数据量小时没问题，如果数据量非常庞大时，将会影响 Redis 的性能，比如数据的传输变慢，占用内存飙高，CPU 上升等问题。

2.2 Redis持久化机制与内存淘汰策略

• 快照持久化：
  默认开启，配置快照持久化后，会生成一个快照文件（相当于将数据打包并且压缩备份好，默认：dump.rdb），并可以配置生成快照文件的频率。启动加载 RDB 文件。 配置文件名与文件保存地址。
• AOF 持久化：
  默认关闭，开启此配置后，将会生成一个 AOF 文件，内部记录的 Redis 启动后执行的所有命令。启动执行 AOF 文件内的命令。
  1.首先开启配置：appendonly yes
  2.配置文件名： appendfilename “appendonly.aof” 生成文件目录与 RDB 路径相同

AOF 文件的生成规则：

这样的配置，涉及持久化文件的重写，配置：

1. 文件扩大 100% 的时候重写；
2. 文件大于 64M 的时候才能触发重写动作。
   这里所说的重写是指，Redis 启动后，除了生成快照的持久化，还有 AOF 记录命令的持久化，当 AOF 文件过大，且达到重写的条件后，将 AOF 内的命令与 RDB 文件结合，重新生成 RDB，而 AOF 内的命令将会清除，开始记录新的命令。

• 持久化文件有了，并且理论上大小不限，那么 Redis 的数据就要收到内存的限制了，那么是否会将内存撑爆呢？
  
  查看内存管理模块，可以看到一大部分注释，最后一行，默认是注释掉的，就相当于不限制 Redis 的内存使用，那么如果数据了持久增加的情况下，内存会爆掉。可以适当设置内存的大小，比如设置 8GB，在集群的情况下，不需要设置太高，保持良好性能。

• 设置好了内存大小限制，那么当内存满了之后，Redis 将会如何处理呢？
  此时，需要提供缓存淘汰策略了，配置当内存达到最大时，按照一定规则去删除内存中旧的值。
  
  Redis 提供了多种缓存淘汰策略。LRU：表示最近最少使用； LFU：表示最不常用的。
  区别在于：LFU 是一定时间内访问最少的，比如 10 分钟内访问最少的，而 LRU 则是指服务启动后，访问量最少的内容。 下面按顺序说明下淘汰策略：

  1. 筛选出设置了有效期的，最近最少使用的 key；
  2. 所有 key 中，筛选出最近最少使用的 key；
  3. 筛选出设置了有效期的，最不常用的 key；
  4. 所有 key 中，筛选出最不常用的 key ；
  5. 随机筛选出设置了有效期的 key；
  6. 所有 key 中，随机筛选出 key进行删除；
  7. 筛选出所有设置有效期的 key 中，有效期最短的 key；
  8. 拒绝策略，当内存满了之后，服务不做任何处理，直接返回一个错误 Redis 默认是拒绝策略，可根据实际情况做出设置。

• 这样做的目的是什么呢？
  在 Redis 服务重启时，快照数据恢复的时间，比 AOF 一行行执行命令快；
  AOF 是实时记录 Redis 执行的命令的，不会造成命令丢失，而快照是要满足一定条件才能出发（如，记录变动了 1 次，不满足更新快照的条件，此时服务宕机了，那么重启时，这次变动的数据就丢失了，而 AOF 记录下了执行的命令）。这样就防止了数据的丢失；
  快速恢复快照的内容，之后再执行剩余的 AOF 内的命令，完整恢复数据。