Redis问题汇总

朱雀 2020-10-25 11:04 795阅读 0赞

一、Redis为何这么快

1.官方提供的数据表示Redis可以达到10w+的QPS（每秒查询次数）

2.Redis是单线程单进程的模型，Redis完全基于内存操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章的采用单线程方案了。

3.使用多路复用IO模型，非阻塞IO。

二、Redis和Memached的区别

1.存储方式上：Memached会把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。Redis有部分数据存在硬盘上，这样保证了数据的持久性。

2.数据支持类型上：Memached对数据类型的支持简单，只支持简单的key-value，而Redis支持五种数据类型。

3.使用底层模型不同：它们之间底层实现方式以及与客户端之间通信的应用协议不一样。Redis直接自己构建了VM机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。

4.value的大小：Redis可以达到1GB,而Memached只有1MB。

三、Redis的淘汰策略

1.volatile-Iru： 从已设置过期时间的KV集中优先对最近最少使用(less recently used)的数据淘汰。

2.volatile-ttl：从已设置过期时间的KV集中优先对剩余时间短(time to live)的数据淘汰。

3.volatile-random：从已设置过期时间的KV集中随机选择数据淘汰。

4.allkeys-Iru：从所有KV集中优先对最近最少使用(less recently used)的数据淘汰。

5.allkeys-random：从所有KV集中随机选择数据淘汰。

6.noeviction：不淘汰策略，若超过最大内存，返回错误信息。

7.volatile-lfu：从已设置过期时间的KV集中，统计访问频率，将访问频率最少，即最不经常使用的KV淘汰。

8.allkeys-lfu：从所有KV集中，统计访问频率，将访问频率最少，即最不经常使用的KV淘汰。

四、Redis的持久化

Redis为了保证效率，数据缓存在了内存中，但是会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件中，以保证数据的持久化。

Redis的持久化策略有两种：

1、RDB:快照形式是直接把内存中的数据保存到一个dump文件中，定时保存，保存策略。

2、AOF:把所有的对Redis的服务器进行修改的命令都存到一个文件里，命令的集合。

Redis默认是快照RDB的持久化方式。当Redis重启的时候，它会优先使用AOF文件来还原数据集，因为AOF文件保存的数据集通常比RDB文件所保存的数据集更完整。你甚至可以关闭持久化功能，让数据只在服务器运行时存。

RDB的工作原理：

当Redis需要做持久化时，Redis会fork一个子进程，子进程将数据写到磁盘上一个临时RDB文件中，当子进程完成写临时文件后，将原来的RDB替换掉，这样的好处是可以copy-on-write.

RDB的优点：

这种文件非常适用于备份，比如，你可以在最近的24小时内，每小时备份一次，并且在每个月的每一天也备份一个RDB文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。RDB非常适合灾难恢复。

RDB的缺点：

如果需要尽量避免在服务器故障时丢失数据，那么RDB不适合。

AOF的工作原理：

AOF可以做到全程持久化，只需要再配置中开启appendonly yes。 这样Redis每执行一个修改数据的命令，都会把它添加到AOF文件中，当Redis重启时，将会读取AOF文件进行重放，恢复Redis关闭前的最后时刻。

AOF的优点：

使用AOF的优点是会让Redis变得非常耐久，可以设置不同的fsync策略，aof的默认策略是每秒钟fsync一次，在这种配置下，就算发生故障停机，也最多丢失一秒钟的数据。

AOF的缺点：

对于相同的数据集来说，AOF的文件体积通常要大于RDB文件的体积。根据所使用的fsync策略，AOF的速度可能会慢于RDB。

RDB和AOF如何选择：

如果非常关系新数据，但是仍然可以承受数分钟内的数据丢，那么可以只是用RDB持久。因为AOF会将Redis执行的每一条命令追加到磁盘中，处理巨大的写入会降低Redis的性能。定时生成RDB快照非常便于进行数据库备份，并且RDB恢复数据集的速度也要比AOF恢复的速度快。当然了，Redis支持同时开启RDB和AOF，系统重启后，Redis会优先使用AOF来恢复数据，这样丢失的数据会最少。

五、Redis的主从复制

主从配置结合哨兵模式能解决单点故障问题，提高Redis可用性。从节点仅提供读操作，主节点提供写操作。对于读多写少的状况，可给主节点配置多个从节点，从而提高响应效率。

1）复制的过程：

1.从节点执行slaveof\[masterIP\]\[masterPort\]，保存主节点信息。

2.从节点中的定时任务发现主节点信息，建立和主节点对的socket连接

3.从节点发送Ping信号，主节点返回Pong，两边能互相通信

4.连接建立后，主节点将所有数据发送给从节点（数据同步）

5.主节点把当前的数据同步给从节点后，便完成了复制的建立过程。接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。

2）Redis主从节点数据同步的过程：

Redis2.8之前使用sync\[runId\]\[offset\]同步命令，Redis2.8之后使用psync\[ronId\]\[offset\]命令。两者不同在于，sync命令仅支持全量复制过程，psync支持全量和部分复制。介绍同步之前，先介绍几个概念：

1.runId:每个Redis节点启动都会生成唯一的uuid,每次Redis重启后，runId都会发生变化。

2.offset:主节点和从节点都各自维护自己的主从复制偏移量offset,当主节点有写入命令时，offset=offset+命令的字节长度。从节点在收到主节点发送的命令后，也会增加自己的offset，并把自己的offset发送给主节点。这样，主节点同时保存自己的offset和从节点的offset，通过对比offset来判断主从节点的数据是否一致。

3.repl\_backlog\_size:保存在主节点上的一个固定长度的先进先出队列，默认大小是1MB。

1）主节点发送数据给从节点过程中，主节点还会进行一些写操作，这时候的数据存储在复制缓冲区中。从节点同步主节点数据完成后，主节点将缓冲区的数据继续发送给从节点，用于部分复制。

2）主节点响应写命令时，不但会把命名发送给从节点，还会写入复制挤压缓冲区，用于复制命令丢失的数据补救。

从节点发出psync\[runId\]\[offset\]命令，主节点有三种响应：

1.FULLRESYNC:第一次连接，进行全量复制。

2.CONTINUE:进行部分复制。

3.ERR:不支持psync命令，进行全量复制。

六、哨兵

主从复制会存在以下问题：

1.主节点宕机，从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。

2.主节点的写能力收到单机的限制。

3.主节点的存储能力收到单机的限制。