标签：磁盘 内存不足 导致 val 邮箱 额外 修改 volatile 数据集
内存数据库，用于做缓存。可做分布式锁，提供多种数据类型支持不同业务场景。支持事务、持久化、LUA脚本、LRU驱动事件。
高性能：第一次访问数据库中的数据会比较慢，因为是从磁盘上读取。将用户第一次访问的数据放入缓存，第二次或以后的多次访问直接查缓存，没有再去磁盘，提高查询效率，缩短查询时间。如果数据库中的数据改变，那么就同步改变缓存中的数据。
高并发：直接操作缓存能够承受的请求远远超过直接访问数据的请求。可以考虑将部分数据库中的数据移到缓存中，从而实现一部分请求不经过数据库，而直接进入缓存。
缓存分为两种：分布式缓存和本地缓存，redis是分布式缓存，map是本地缓存。
本次缓存容量小，有上限。分布式缓存容量大。
map缓存不具有一致性，redis缓存具有一致性。
支持多种数据类型（list set zset hash等等）而传统memcache仅支持String类型
redis支持数据持久化，可以将内存中的数据保存在磁盘中。重启redis可直接使用。
redis使用单线程的多路IO复用模型，数据安全。
String：String数据结构为简单的Key-Value类型，value不仅可以是字符串，也可以是数字。
使用场景：统计数量，粉丝数量，用户数量。
List：支持反向查找和遍历，但有额外开销。可实现分页查询。
使用场景：分页查询
Set：相比较List，Set中不允许存储重复的元素。
使用场景：统计共同关注好友等
Redis有设置过期的功能，就是对存储在redis缓存中的数据设置有效时间。短信验证码或者邮箱验证码是一个很好的实例。
定期删除：默认每隔100ms随机抽取那些设置过期数据的key，检查是否过期，过去就删除，是随机抽取的。
惰性删除： 定期删除可能导致许多过期的key过了有效时间却没有被删除，当过期key没有靠定期删除机制删除时，就停留在内存中，除非系统去查看那些key，才会被redis删除。这就是惰性删除。
解决策略：仅仅通过设置过期时间还不够，还需要内存淘汰策略。关于内存淘汰机制，请继续往下看。
volatile-ru：从已设置过期时间的数据集（server.db[i].expires）中挑选出最近最少使用的数据，然后淘汰。
volatile-til：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据，然后淘汰。
volatile-random：从已设置过期时间的数据（server.db[i].expires）中选择任意数据，然后淘汰。
allkeys-lru：当内存不足以容纳新的写入数据操作时，在键空间中，移除最近最少使用的key（常用）
alleys-random：从数据集（server.db[i].dict）中选择任意数据淘汰。
no-eviction：禁止驱逐数据。就是不允许删除数据，没人使用这个。
为什么要有持久化机制？
多数是为了“数据重用”，比如我们重启机制、机制故障之后进行恢复数据。
RDB持久化
| save | 900 1 | 900秒后，至少有1个key发生变化，redis自动触发BGSAVE命令 |
| save | 300 10 | 300秒后，至少有10个key发生变化，redis自动触发BGSAVE命令 |
| save | 60 10000 | 60秒后，至少有10000个key发生变化，redis自动触发BGSAVE命令 |
AOF持久化
AOF相比较RDB，AOF的实时性更好，redis默认情况下没有开启AOF（append only file）方式的持久化，可以通过设置appendonly参数开启：appendonly：yes
AOF开启后，每执行一条更改操作，redis就会将该命令写入磁盘中的AOF文件。
在redis的配置文件中存在三种不同的AOF持久化方式：
appendfsync always # 每次有数据修改时会写入AOF文件，会降低redis的速度
appendfsync everysec # 每秒钟同步一次，显式地将多个写命令同步到磁盘。
appendfsync no # 让操作系统决定何时进行同步操作
为了兼顾数据存储和写入性能，用户可以考虑appendfsync everysec一项，让redis每秒同步一次，这样用户最多丢失1秒的数据，当磁盘IO繁忙时，redis会放慢自己的速度以使用磁盘的最大写入速度。
标签：磁盘 内存不足 导致 val 邮箱 额外 修改 volatile 数据集
原文地址：https://www.cnblogs.com/bytAya/p/11172216.html
