[大数据]Redis相关

目录

Redis

redis持久化

缓存击穿

缓存穿透

缓存雪崩

过期数据的删除策略

redis内存淘汰机制

Redis

• Redis 就是一个使用 C 语言开发的数据库，Redis 的数据是存在内存中的，读写速度很快，被广泛应用于缓存方向。

• Redis 除了做缓存之外，Redis 也经常用来做分布式锁，甚至是消息队列。

• 分布式缓存主要解决的是单机缓存的容量受服务器限制并且无法保存通用的信息。因为，本地缓存只在当前服务里有效，比如如果你部署了两个相同的服务，他们两者之间的缓存数据是无法共同的。

• 为什么用redis而不是memcached？

  • Redis 支持更丰富的数据类型（支持更复杂的应用场景）。Redis 不仅仅支持简单的 k/v 类型的数据，同时还提供 list，set，zset，hash 等数据结构的存储。

  • Redis 支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用,而 Memecache 把数据全部存在内存之中。

  • 公司有完整的一套redis，如果用memcached还需要重新弄一套memcached

redis持久化

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

• 快照持久化（RDB）----》 redis默认采用的持久化方式

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

• AOF持久化

  • 每执行一条会更改 Redis 中的数据的命令，Redis 就会将该命令写入硬盘中的 AOF 文件。

  • AOF 文件的保存位置和 RDB 文件的位置相同，都是通过 dir 参数设置的，默认的文件名是 appendonly.aof。

  • 实时性比RDB好，redis默认没有开启AOF。

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

• 持久化机制的优化

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

  • AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头。

  • 优点：可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据。

  • 缺点：AOF 里面的 RDB 部分是压缩格式不再是 AOF 格式，可读性较差。

缓存击穿

• 缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。

• 解决方法：

  • 设置热点数据永远不过期。

  • 加互斥锁。

缓存穿透

• 大量请求的 key 根本不存在于缓存中（数据库中也没有），导致请求直接到了数据库上，根本没有经过缓存这一层。如：某个黑客故意制造我们缓存中不存在的 key 发起大量请求，导致大量请求落到数据库。

• 解决办法：

  • 首先做好参数校验，一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。

  • 缓存无效key。

    • 如果缓存和数据库都查不到某个 key 的数据就把这个key写到redis中去，然后设置过期时间， SET key value EX 10086 。这种方式可以解决请求的 key 变化不频繁的情况，如果黑客恶意攻击，每次构建不同的请求 key，会导致 Redis 中缓存大量无效的 key 。所以尽量将无效的 key 的过期时间设置短一点比如 1 分钟。

    • 一般情况下我们是这样设计 key 的： 表名:列名:主键名:主键值 。

  • 布隆过滤器。

    • 是一个数据结构，它可以帮助判断一个给定数据是否存在于海量数据中。

    • 把所有可能存在的请求的值都存放在布隆过滤器中，当用户请求过来，先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程。

    • 布隆过滤器说某个元素存在，小概率会误判。布隆过滤器说某个元素不在，那么这个元素一定不在。

    • 当一个元素加入布隆过滤器中的时候，

      • 使用布隆过滤器中的哈希函数对元素值进行计算，得到哈希值（有几个哈希函数得到几个哈希值）。

      • 根据得到的哈希值，在位数组中把对应下标的值置为 1。

    • 当我们需要判断一个元素是否存在于布隆过滤器的时候，

      • 对给定元素再次进行相同的哈希计算；

      • 得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个值在布隆过滤器中，如果存在一个值不为 1，说明该元素不在布隆过滤器中。

      • 不同的字符串可能哈希出来的位置相同。 （可以适当增加位数组大小或者调整我们的哈希函数来降低概率）

缓存雪崩

• 缓存在同一时间大面积的失效（Redis 服务不可用），或者有一些被大量访问的数据（热点缓存）在某一时刻大面积失效（热点缓存失效），后面的请求都直接落到了数据库上，造成数据库短时间内承受大量请求。

• 解决方法：

  • 针对 Redis 服务不可用的情况：

    1. 采用 Redis 集群，避免单机出现问题整个缓存服务都没办法使用。

    2. 限流，避免同时处理大量的请求。

  • 针对热点缓存失效的情况：

    1. 设置不同的失效时间比如随机设置缓存的失效时间。

    2. 缓存永不失效。

过期数据的删除策略

1. 惰性删除 ：只会在取出key的时候才对数据进行过期检查。这样对CPU最友好，但是可能会造成太多过期 key 没有被删除。

2. 定期删除 ： 每隔一段时间抽取一批 key 执行删除过期key操作。并且，Redis 底层会通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响。

定期删除对内存更加友好，惰性删除对CPU更加友好。两者各有千秋，所以Redis 采用的是 定期删除+惰性/懒汉式删除 。

redis内存淘汰机制

1. volatile-lru（least recently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

2. volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

3. volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

4. allkeys-lru（least recently used）：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）

5. allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

6. no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！

4.0 版本后增加以下两种：

1. volatile-lfu（least frequently used）：从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰

2. allkeys-lfu（least frequently used）：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的 key