Redis的相关知识点总结

1 Redis事务

基本事务指令

Redis提供了一定的事务支持，可以保证一组操作原子执行不被打断，但是如果执行中出现错误，事务不能回滚，Redis未提供回滚支持。

• multi 开启事务

• exec 执行事务

  127.0.0.1:6379> multi
  OK
  127.0.0.1:6379> set a 100
  QUEUED
  127.0.0.1:6379> set b 200
  QUEUED
  127.0.0.1:6379> get a
  QUEUED
  127.0.0.1:6379> get b
  QUEUED
  127.0.0.1:6379> exec

  1. OK
  2. OK
  3. “100”
  4. “200”

使用multi开启事务后，操作的指令并未立即执行，而是被redis记录在队列中，等待一起执行。当执行exec命令后，开始执行事务指令，最终得到每条指令的结果。

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set c 300
QUEUED
127.0.0.1:6379> hgetall a
QUEUED
127.0.0.1:6379> set d 400
QUEUED
127.0.0.1:6379> get d
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) OK
4) "400"
127.0.0.1:6379>

如果事务中出现了错误，事务并不会终止执行，而是只会记录下这条错误的信息，并继续执行后面的指令。所以事务中出错不会影响后续指令的执行。

Python客户端操作

在django_redis中，提供了pipeline (称为流水线 或 管道)，该工具的作用是：

• 在客户端统一收集操作指令

• 补充上multi和exec指令，当作一个事务发送到redis服务器执行

  from django_redis import get_redis_connection
  redis_cli = get_redis_connection()
  pl = redis_cli.pipeline()
  pl.set(‘a’, 100)
  pl.set(‘b’, 200)
  pl.get(‘a’)
  pl.get(‘b’)
  ret = pl.execute()
  print(ret) # [True, True, b’100’, b’200’]

watch监视

若在构建的redis事务在执行时依赖某些值，可以使用watch对数据值进行监视。

127.0.0.1:6379> set stock 100
OK
127.0.0.1:6379> watch stock
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incrby stock -1
QUEUED
127.0.0.1:6379> incr sales
QUEUED
127.0.0.1:6379> exec
1) (integer) 99
2) (integer) 1

事务exec执行前被监视的stock值未变化，事务正确执行。

127.0.0.1:6379> set stock 100
OK
127.0.0.1:6379> watch stock
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incrby stock -1
QUEUED
127.0.0.1:6379> incr sales
QUEUED

此时在另一个客户端修改stock的值，执行

127.0.0.1:6379> incrby stock -2
(integer) 98

当第一个客户端再执行exec时

127.0.0.1:6379> exec
(nil)

表明事务需要监视的stock值发生了变化，事务不能执行了。

注意：Redis Cluster 集群不支持事务

2 Redis持久化

redis可以将数据写入到磁盘中，在停机或宕机后，再次启动redis时，将磁盘中的备份数据加载到内存中恢复使用。这是redis的持久化。持久化有如下两种机制。

RDB 快照持久化

redis可以将内存中的数据写入磁盘进行持久化。在进行持久化时，redis会创建子进程来执行。

redis默认开启了快照持久化机制。

进行快照持久化的时机如下

• 定期触发
  redis的配置文件
  # save
  #
  # Will save the DB if both the given number of seconds and the given
  # number of write operations against the DB occurred.
  #
  # In the example below the behaviour will be to save:
  # after 900 sec (15 min) if at least 1 key changed
  # after 300 sec (5 min) if at least 10 keys changed
  # after 60 sec if at least 10000 keys changed
  #
  # Note: you can disable saving completely by commenting out all “save” lines.
  #
  # It is also possible to remove all the previously configured save
  # points by adding a save directive with a single empty string argument
  # like in the following example:
  #
  # save “”

    save 900 1
    save 300 10
    save 60 1000
  

• BGSAVE
  执行BGSAVE命令，手动触发RDB持久化

• SHUTDOWN
  关闭redis时触发

AOF 追加文件持久化

redis可以将执行的所有指令追加记录到文件中持久化存储，这是redis的另一种持久化机制。

redis默认未开启AOF机制。

redis可以通过配置如下项开启AOF机制

appendonly yes  # 是否开启AOF
appendfilename "appendonly.aof"  # AOF文件

AOF机制记录操作的时机

# appendfsync always  # 每个操作都写到磁盘中
appendfsync everysec  # 每秒写一次磁盘，默认
# appendfsync no  # 由操作系统决定写入磁盘的时机

使用AOF机制的缺点是随着时间的流逝，AOF文件会变得很大。但redis可以压缩AOF文件。

结合使用

redis允许我们同时使用两种机制，通常情况下我们会设置AOF机制为everysec 每秒写入，则最坏仅会丢失一秒内的数据。

3 缓存问题

1 缓存穿透

缓存只是为了缓解数据库压力而添加的一层保护层，当从缓存中查询不到我们需要的数据就要去数据库中查询了。如果被黑客利用，频繁去访问缓存中没有的数据，那么缓存就失去了存在的意义，瞬间所有请求的压力都落在了数据库上，这样会导致数据库连接异常。

解决方案：

1. 约定:对于返回为NULL的依然缓存，对于抛出异常的返回不进行缓存,注意不要把抛异常的也给缓存了。采用这种手段的会增加我们缓存的维护成本，需要在插入缓存的时候删除这个空缓存，当然我们可以通过设置较短的超时时间来解决这个问题。
2. 制定一些规则过滤一些不可能存在的数据，比如你的订单ID 明显是在一个范围1-1000，如果不是1-1000之内的数据那其实可以直接给过滤掉。

2 缓存雪崩

缓存雪崩是指缓存不可用或者大量缓存由于超时时间相同在同一时间段失效，大量请求直接访问数据库，数据库压力过大导致系统雪崩。

解决方案：

1、给缓存加上一定区间内的随机生效时间，不同的key设置不同的失效时间，避免同一时间集体失效。比如以前是设置10分钟的超时时间，那每个Key都可以随机8-13分钟过期，尽量让不同Key的过期时间不同。

2、采用分布式，用多个服务器存储redis

4 缓存有效期与淘汰策略

Redis的过期策略

定期过期

每隔一定的时间，默认是每100ms检测一次，遇到过期的key则进行删除，这里的检测并不是顺序检测，而是随机检测。那这样会不会有漏网之鱼？显然Redis也考虑到了这一点，当我们去读/写一个已经过期的key时，会触发Redis的惰性删除策略。

惰性过期

只有当访问一个key时，才会判断该key是否已过期，过期则清除，该策略可以最大化地节省CPU资源。

问题

采用定期删除+惰性删除就没其他问题了么?

不是的，如果定期删除没删除key。然后你也没即时去请求key，也就是说惰性删除也没生效。这样，redis的内存会越来越高。那么就应该采用内存淘汰机制。

缓存淘汰

• noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。
• allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。
• allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。
• volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。（最常使用）
• volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。

LRU

LRU（Least recently used，最近最少使用）

LRU算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”。

基本思路

1. 新数据插入到列表头部；
2. 每当缓存命中（即缓存数据被访问），则将数据移到列表头部；
3. 当列表满的时候，将列表尾部的数据丢弃。

Redis淘汰策略的配置

• maxmemory 最大使用内存数量
• maxmemory-policy noeviction 淘汰策略

5 保持数据库和redis数据的一致性

更新方式的方式

先更新数据库，再更新缓存

先删除缓存，再更新数据库

先更新数据库，再删除缓存