12个问题搞懂Redis

作者：UStarGao 日期：2021-09-22 13:17:10 人气：栏目：Redis

1、什么是Redis？

（1）Redis 是一个高性能的 key-value 数据库；
（2）作者来自意大利西西里岛的 Salvatore Sanfilippo ；
（3）Redis 使用 ANSI C 语言编写、并遵守 BSD 开源协议；
（4）Redis 支持网络、可基于内存、分布式、也可以用来实现简易的消息队列；
（5）提供丰富的数据结构：字符串(String)、哈希(Hash)、列表(list)、集合(sets)和有序集合(sorted sets) 。

2、都说 Redis 是单线程模型，是什么意思？

（1）单线程并不是说在 Redis 中所有的操作都是由一个线程来完成；
（2）核心功能，比如：网络 IO 和数据的读写是由一个线程来进行处理的；
（3）其他的一些辅助功能，比如：持久化、集群间的数据同步是由单独的线程进行处理；
（4）所以说 Redis 的单线程不是“真正”的单线程。

3、为什么在数据读写处理上不使用多线程？

（1）多线程虽然可以增加系统的吞吐率，但线程的切换会有开销；
（2）多个线程对共享资源的并发处理问题，必然会用到各种锁，有锁就会存在等待锁的释放，反而吞吐率降低了；
（3）处理各种多线程带来的问题，会使系统变得复杂，复杂的系统就容易出现问题。

4、为什么使用单线程，速度却很快？

（1）Redis 的操作是基于内存的，相比较于磁盘，速度上有先天的优势；
（2）Redis 有高效的数据结构，比如：哈希表、跳表；
（3）采用了多路复用机制，可以并发处理大量的请求，实现高吞吐率。

5、单线程处理的瓶颈是什么？

（1）如果有耗时长的操作，后面的请求都需要进行等待；
    ◆ 单个 value 的内容过大，在添加、获取、删除时都会比较耗时；
    ◆ 使用复杂的命令，比如：SORT/SUNION/ZUNIONSTORE；
    ◆ 集合的数据非常大，而又进行了全量查询。
（2）并发量非常大时，虽然 IO 有多路复用机制，从内核缓冲区中拷贝数据的操作仍然是同步操作，会带来性能瓶颈。

6、Redis 6.0 调整为多线程的原因？

（1）上面提到过 6.0 之前的版本是网络 IO 和数据读写是在一个线程中完成的；
（2）随着硬件性能的提升，Redis 的性能瓶颈有时会出现在网络 IO 的处理上，也就是说，单个主线程处理网络请求的速度跟不上底层网络硬件的速度，而读写的操作和网络 IO 是在一个主线程中，势必会有所影响；
（3）所以在 Redis 6.0 中，网络 IO 是由多个 IO 线程并行处理，可以充分利用服务器的多核资源，提高网络读写操作；
（4）Redis 数据的读写处理仍然在单个主线程中完成。

7、在 Redis 中怎样做持久化？

（1）在 Redis 实现持久化有两种方式：AOF 日志 和 RDB 快照；
（2）AOF 日志
    ◆ 命令执行成功后，才记录日志；
    ◆ 命令执行后进行日志记录，不会堵塞当前的写操作。
    ◆ 命令执行完，日志记录前宕机，数据会丢失；
    ◆ AOF 日志在主线程中执行，有 IO 瓶颈时会对后面的操作有堵塞风险；
    ◆ 数据量比较大的时候，恢复很慢。
    ◆ 配置项（appendfsync）
             ◆ Always，同步写回磁盘：每个写命令执行完，立即同步将日志写回磁盘；
             ◆ Everysec，每秒写回磁盘：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
             ◆ No，操作系统控制的写回磁盘：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。
（3）RDB 快照
    ◆ 和 AOF 相比较，RDB 快照记录的是某一个时刻的数据，数据恢复是直接将 RDB 文件读入内存，速度很快；
    ◆ 生成 RDB 文件的两种方式：
             ◆ save：在主线程中执行，会导致阻塞；
             ◆ bgsave：创建一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞，这也是 Redis RDB 文件生成的默认配置。子进程是由主线程 fork 生成的，可以共享主线程的所有内存数据。
    ◆ RDB 快照的间隔时间不宜设置过短，因为频繁进行 Redis 的全量快照，会带来性能问题：
             ◆ 前一个快照还没做完，后面一个开始了，会给磁盘带来压力；
             ◆ bgsave 的子进程虽然不会阻塞主线程，但创建的过程会阻塞，频繁创建也会带来性能问题。
    ◆ 解决上面问题的一种办法就是使用增量快照；
    ◆ 在 Redis 4.0 中提出了一种混合 AOF 日志和 RDB 快照的方式：
             ◆ RDB 快照的间隔时间可以设置比较大，就不会影响到主线程的操作；
             ◆ 在快照的间隔期间可以使用 AOF 日志记录所有的操作，当下一次做全量 RDB 快照的时候，清空 AOF 日志；
             ◆ 通过 aof-use-rdb-preamble yes 来进行设置。

8、常说的缓存雪崩、击穿、穿透是什么？

（1）雪崩、击穿、穿透最终的结果都是请求压力会转移到数据库，导致系统崩溃，但场景有所区别；
（2）雪崩
    ◆ 大量的不同请求无法在 Redis 中命中，导致请求都流向了数据库，数据库的压力剧增；
    ◆ 发生雪崩的原因可能是，有大量的缓存 Key 在同一时间过期。
（3）击穿
    ◆ 并发很大的情况下，针对某个特定的请求，缓存中数据不存在，导致都请求到了数据库，造成数据库压力过大；
    ◆ 原因通常是某个 Key 过期了;
    ◆ 和雪崩相比较，击穿是针对的单个 Key。
（4）穿透
    ◆ 缓存穿透是指请求的数据不在 Redis 缓存中，也不在数据库中，导致访问缓存时，找不到数据，会去请求数据库，而在数据库中也找不到相应的数据；
    ◆ 并发比较大的时候，数据库会遭受巨大的压力；
    ◆ 发生穿透的原因可能有两个：
             ◆ 误操作导致 Redis 和数据库中的数据都被删除了；
             ◆ 恶意攻击。

9、怎样解决雪崩、击穿、穿透带来的问题？

（1）雪崩
    ◆ 缓存的数据过期时间设置随机，防止同一时间大量数据过期现象发生；
    ◆ 如果缓存数据库是分布式部署，将热数据均匀分布在不同缓存数据库中；
    ◆ 当发生雪崩时，可以通过服务降级来应对。
（2）击穿
    ◆ 设置热数据永远不过期。
（3）穿透
    ◆ 在接口层进行校验，将恶意请求直接过滤掉；
    ◆ 使用布隆过滤器快速判断数据是否存在；
    ◆ 缓存空值或缺省值。

10、怎样设计缓存的淘汰机制？

（1）业务数据在不断地增长，不可能将所有数据全部存储在 Redis 缓存中，内存的价格远远大于磁盘。所以需要做淘汰机制的设计；
（2）缓存的淘汰就是根据一定的策略，将不太重要的数据从缓存中进行删除；
（3）Redis 一共有 8 种淘汰策略，在 Redis 4.0 之前有 6 种，4.0 之后又增加了 2 种，如下图：

12个问题搞懂Redis(图1)

（4）缓存策略的解释：
    ◆ volatile-random：在设置了过期时间的数据中，进行随机删除；
    ◆ volatile-ttl：根据过期时间，越早过期的数据越先删除；
    ◆ volatile-lru：在设置了过期时间的数据中，根据 LRU 算法进行数据删除；
    ◆ volatile-lfu：在设置了过期时间的数据中，根据 LFU 算法进行数据删除；
    ◆ allkeys-lru：在所有数据中，根据 LRU 算法进行数据删除；
    ◆ allkeys-random：在所有数据中，进行随机删除；
    ◆ allkeys-lfu：在所有数据中，根据 LFU 算法进行数据删除；
（5）默认情况下，当 Redis 的使用空间超过 maxmemory 设置的大小时，并不会淘汰数据，也就是执行的 noeviction 策略，如果写满，再有写请求时就会出错；
（6）如果业务中有明显的热数据和冷数据，优先使用 allkeys-lru 策略，让热数据保留在缓存中；
（7）如果业务中没有明显冷热数据，可以使用 volatile-random 或 allkeys-random。

11、怎样保证缓存和数据库的数据一致？

（1）缓存和数据库一致的意思是，当缓存中有数据时，缓存和数据库数据相同，当没有数据时，数据库中是最新的；
（2）在做增删改操作的时候，对缓存的更新有两种方式：
    ◆ 新增直接添加到数据库，删除和修改时先更新缓存，然后同步或异步进行数据库的更新；
    ◆ 新增直接添加到数据库，删除和修改时先更新数据库，再删除对应的缓存。
（3）上面的操作都涉及到两个，操作 Redis 和操作数据库，当其中一个成功一个失败时就会出现数据不一致的情况；
（4）解决不一致的问题：
    ◆ 将操作通过消息队列异步处理，设置重试机制，保证最终的一致性；
    ◆ 使用分布式事务，保证操作 Redis 和数据库的两个操作在一个事务中。

12、Redis 有什么使用规范？

（1）Redis 单实例的内存大小都不要设置太大，建议在 2~6GB ，设置太大，会导致 RDB 快照、从 AOF 日志恢复、主从集群进行数据同步等都会耗时很长，阻塞正常请求的处理；
（2）对集合进行全量数据获取时，时间复杂度是 O(n)，所以这个 n 不宜太大；
（3）单个 key 的值不要太大，即便是最新的 6.0 版本，在读写这部分仍然是单线程，大 value 的读取会耗时，导致堵塞；
（4）根据具体的业务特点设计好淘汰策略；
（5）使用高效的序列化和压缩方法对缓存数据进行处理，来进一步提升性能；
（6）生产环境中禁止使用 KEYS、FLUSHALL、FLUSHDB 等操作，数据量大的时候耗时长，会阻塞主线程；
（7）有时为了排查错误，会使用 MONITOR 命令进行监控，该命令也会对性能造成严重影响；

作者：UStarGao
链接：https://www.starcto.com/redis/241.html
来源：STARCTO
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

UCloud云平台推荐

UCloud新用户专属注册连接

UCloud CDN超值特惠专场

UCloud全球云主机（UHost/VPS）大促页面

UCloud快杰云主机大促页面