Redis提升——高级部分笔记

Posted 2022-11-27 小王子jvm

Redis配置文件

默认的配置文件名：redis.conf，我们也可以在启动服务的时候指定加载配置文件。

网络相关的配置

• bind：默认情况bind=127.0.0.1只能接受本机的访问请求，不写的情况下，无限制接受任何ip地址的访问

  生产环境肯定要写你应用服务器的地址；服务器是需要远程访问的，所以需要将其注释掉

  如果开启了protected-mode，那么在没有设定bind ip且没有设密码的情况下，Redis只允许接受本机的响应

• protected-mode：本机访问保护模式设置。

• tcp-backlog：设置tcp的backlog。

  backlog其实是一个连接队列，backlog队列总和=未完成三次握手队列 + 已经完成三次握手队列。

  在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。

  注意Linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值（128），所以需要确认增大/proc/sys/net/core/somaxconn和/proc/sys/net/ipv4/tcp_max_syn_backlog（128）两个值来达到想要的效果

• timeout：一个空闲的客户端维持多少秒会关闭，0表示关闭该功能。即永不关闭。

• tcp-keepalive：对访问客户端的一种心跳检测，每个n秒检测一次。单位为秒，如果设置为0，则不会进行Keepalive检测，建议设置成60，表示这个时间内没有操作就给你断开连接。

GENERAL通用配置

• daemonize：是否为后台进程，设置为yes，守护进程，后台启动。
• pidfile：存放pid文件的位置，每个实例会产生一个不同的pid文件
• loglevel：指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为notice，四个级别根据使用阶段来选择，生产环境选择notice 或者warning
• logfile：日志文件名称
• databases 16：设定库的数量 默认16，默认使用的数据库为0，可以使用SELECT 命令在连接上指定数据库id

LIMITS限制

• maxclients：设置redis同时可以与多少个客户端进行连接，默认情况下为10000个客户端，如果达到了此限制，redis则会拒绝新的连接请求，并且向这些连接请求方发出“max number of clients reached”以作回应

• maxmemory：设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定，如果redis无法根据移除规则来移除内存中的数据，或者设置了“不允许移除”，那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。但是对于无内存申请的指令，仍然会正常响应，比如GET等。

• maxmemory-policy：设置移除数据规则。选项很多：

  volatile-lru	使用LRU算法移除key，只对设置了过期时间的键；（最近最少使用）
  allkeys-lru	在所有集合key中，使用LRU算法移除key
  volatile-random	在过期集合中移除随机的key，只对设置了过期时间的键
  allkeys-random	在所有集合key中，移除随机的key
  volatile-ttl	移除那些TTL值最小的key，即那些最近要过期的key
  noeviction	不进行移除。针对写操作，只是返回错误信息

• maxmemory-samples：设置样本数量，LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小，redis默认会检查这么多个key并选择其中LRU的那个。一般设置3到7的数字，数值越小样本越不准确，但性能消耗越小。

Redis 发布和订阅

Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。

Redis 客户端可以订阅任意数量的频道。

这个很好理解，相当于你关注了某个人，这个人发动态你就可以 收到这个通知，查看到信息。

实现

打开一个客户端订阅channel1，命令：subscribe channel1。

打开另一个客户端，给channel1发布消息hello，命令：publish channel1 hello

注：发布的消息没有持久化，如果在订阅的客户端收不到hello，只能收到订阅后发布的消息

Redis事务

定义

Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

Redis事务的主要作用就是串联多个命令防止别的命令插队。

Multi、Exec、discard（三个命令）

从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入Exec后，Redis会将之前的命令队列中的命令依次执行。

组队的过程中可以通过discard来放弃组队。

• 组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消。
• 如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。

事务冲突问题

一个请求想给金额减8000

一个请求想给金额减5000

一个请求想给金额减1000

悲观锁解决：

顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

乐观锁解决：

顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

• WATCH key [key …]

  在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

• unwatch

  取消 WATCH 命令对所有 key 的监视。如果在执行 WATCH 命令之后，EXEC 命令或DISCARD 命令先被执行了的话，那么就不需要再执行UNWATCH 了

Redis 事务三特性

• 单独的隔离操作

  事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

• 没有隔离级别的概念

  队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行

• 不保证原子性

  事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

Redis 持久化

Redis提供了两种不同得持久化方式：RDB和AOF。

RDB方式

基本介绍

指在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是所谓的：Snapshot快照，恢复的时候将快照直接读取到内存中。

持久化流程

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

fork 一个子进程

Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”

一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

流程图如下：

rdb文件

在redis.conf中配置文件名称，默认为dump.rdb，rdb文件的保存路径，也可以修改。默认为Redis启动时命令行所在的目录下。（也就是redis-cli在哪里启动这个数据文件就在哪里生成）

---

触发RDB快照（保持策略）

这几个配置得意思就是：900秒内，有一次更改，就会生成快照，同理，第二项就是300秒内由10次。

命令save VS bgsave

save ：save时只管保存，其它不管，全部阻塞。手动保存。不建议这样使用。

• 格式：save 秒钟 写操作次数。

  RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，

  默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。

bgsave：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。

可以通过lastsave 命令获取最后一次成功执行快照的时间

flushall 命令

执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

配置文件参数

• stop-writes-on-bgsave-error：当Redis无法写入磁盘的话，直接关掉Redis的写操作。推荐yes

• rdbcompression 压缩文件：对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用 LZF 算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。推荐yes.

• rdbchecksum 检查完整性：在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能，推荐yes.

RDB得优劣势

优势

• 适合大规模的数据恢复

• 对数据完整性和一致性要求不高更适合使用

• 节省磁盘空间

• 恢复速度快

劣势

• Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

• 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。

• 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

AOF方式

基本介绍

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作(将所有写入得指令都执行一遍)

持久化流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；

（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

流程图如下：

AOF默认是不开启的，需要在配置文件中配置开启：

这两个同时开启的时候，系统默认取AOF得数据（因为AOF数据几乎不会丢失）

AOF 启动/修复/恢复

AOF的备份机制和性能虽然和RDB不同，但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

正常恢复：只要我们开启了AOF，服务器挂掉，下次启动也会给我们加载数据。

加入生成得appendonly.aof损坏，通过redis-check-aof–fix appendonly.aof进行恢复。如果文件损坏启动redis，会出现：

Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix <filename>

AOF 同步频率设置

• appendfsync always：始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

• appendfsync everysec：每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

• appendfsync no：redis不主动进行同步，把同步时机交给操作系统。

Rewrite压缩

基本介绍

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制， 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof

重写原理

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。

no-appendfsync-on-rewrite：

• 开启，不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）

• 不开启，还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）

auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。

例如：文件达到70MB开始重写，降到50MB，下次100MB得时候又开始重写

系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size，如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

重写得流程

（1）bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。

（2）主进程fork出子进程执行重写操作，保证主进程不会阻塞。

（3）子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。

（4）子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。主进程把aof_rewrite_buf中的数据写入到新的AOF文件。

（5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

AOF得优劣势

优势

备份机制更稳健，丢失数据概率更低。

可读的日志文本，通过操作AOF稳健，可以处理误操作。

劣势

比起RDB占用更多的磁盘空间。

恢复备份速度要慢。

每次读写都同步的话，有一定的性能压力。

存在个别Bug，造成恢复不能。

总结（官方推荐）

官方推荐两个都启用：如果对数据不敏感，可以选单独用RDB。不建议单独用 AOF，因为可能会出现Bug。如果只是做纯内存缓存，可以都不用。

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储

• AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.

• Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大

• 只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.

• 同时开启两种持久化方式

• 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

• RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？

• 建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)， 快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

性能建议

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

如果使用AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。

代价,一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。

只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值

Redis主从复制

什么是主从复制：主机数据更新后根据配置和策略， 自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主

可以做什么：读写分离。（提高性能，便于容灾恢复）

环境搭建

拷贝多个redis.conf文件include(写绝对路径)，开启daemonize yes

复制原来的配置文件更名redis6379.conf

然后更改端口即可，再创建两个向东的配置文件更名为：redis6380和6381，注意如果这几个配置文件在同一个目录下，我们启动redis服务的时候在同一个目录，就需要把对应的rdb文件名更改为一下，否则会冲突。

然后启动加载对应的配置文件：

info replication，打印主从复制的相关信息：

配从(库)不配主(库)

slaveof ：成为某个实例的从服务器

在6380和6381上执行: slaveof 127.0.0.1 6379

此时可以在主机上写入数据，从机上读取数据，如果从机上写就会报错。

主机此时挂掉，从机也不会成为主机，等主机恢复即可。也可以将slaveof <ip> <port>配置增加到文件中。永久生效。

两个问题

服务器挂掉

假设主服务器挂了，此时的从服务器（相当于小弟）是不会主动篡位的，需要自己手动输入命令在可以将从服务器改为主服务器：slaveof no one。如果主服务器重启成功，一切恢复原来的样子。

假设从服务器挂掉，主服务器会失去这个从服务器，此时的从服务器重启，如果配置文件写入了主服务器配置，就自动连接主服务器并进行数据同步恢复。没有则手动输入命令。

薪火相传

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。

用 slaveof 中途变更转向，会清除之前的数据，重新建立拷贝最新的

风险是一旦某个slave宕机，后面的slave都没法备份，主机挂了，从机还是从机，无法写数据了

复制原理

1、当从服务器连接上主服务器之后，从服务器向主服务器发送数据同步消息

2、主服务器接收到从服务器发送过来的同步消息，把主服务器的数据进行持久化成rdb文件，把rdb文件发送到从服务器，然后从服务器读取这个数据文件恢复数据

3、每次主服务器写入数据之后，会把这个写入操作发送给从服务器，从服务器后台自动更新。

哨兵模式

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

搭建步骤

新建sentinel.conf文件，名字绝不能错，配置内容如下：

# 其中mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量。
sentinel monitor mymaster 127.0.0.1 6379 1

启动哨兵

redis做压测可以用自带的redis-benchmark工具，执行redis-sentinel /sentinel.conf

主机挂掉，从机选举中产生新的主机（大概10秒左右可以看到哨兵窗口日志，切换了新的主机）根据优先级别：slave-priority 原主机重启后会变为从机。

复制延时

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

故障恢复

优先级在redis.conf中默认：slave-priority 100，值越小优先级越高

偏移量是指获得原主机数据最全的

每个redis实例启动后都会随机生成一个40位的runid

Redis安全问题

首先补充一个缓存的处理流程：

缓存穿透

key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会压到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。

为什么会出现这种情况，因为数据库查询要进行磁盘IO，这个消耗资源，又费时间，如果数据不存在，起码是对整个表进行全部表扫描！大量这种请求过来，当然就可能数据库崩溃！

解决方案

一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

• **对空值缓存：**如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟。

  这种办法只能搞定访问请求相同的情况。

• **设置可访问的名单（白名单）：**使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。

• 采用布隆过滤器：(布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量(位图)和一系列随机映射函数（哈希函数）。

  布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。)

  将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被 这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力。

• **进行实时监控：**当发现Redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务

缓存击穿

key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决方案

• 预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长

• 实时调整：现场监控哪些数据热门，实时调整key的过期时长

• 使用锁：

  就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db。

  先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX）去set一个mutex key

  当操作返回成功时，再进行load db的操作，并回设缓存,最后删除mutex key；

  当操作返回失败，证明有线程在load db，当前线程睡眠一段时间再重试整个get缓存的方法。

使用锁的大致意思就是大量请求过来，可能由于并发，都去访问了数据库，但是如果此时对热门数据的key加锁，那么至始至终这个时刻只能由一个用户访问，此时这个用户获得排他锁，进行数据库查询，别的用户由于没有拿到锁先暂停一下，带回来查询，这样等拿到锁的用户加载完数据，自然把数据备份到了redis中，此时暂停的用户再次查询就不会查询数据库，都去查缓存！

缓存雪崩

key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

缓存雪崩与缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key

解决方案

缓存失效时的雪崩效应对底层系统的冲击非常可怕！

• 构建多级缓存架构：nginx缓存 + redis缓存 +其他缓存（ehcache等）

• 使用锁或队列：

  用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况

• 设置过期标志更新缓存：

  记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存。

• 将缓存失效时间分散开：

  比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

为什么这里的锁就不太好使，因为上面的缓存击穿是一个key，或者说少量的key，这样加锁只会让少量的key进行数据库查询，而这里数量多，再加锁，不就更直接访问数据库大差不差了吗。