本文详细介绍了Redis的持久化机制，包括RDB和AOF的优缺点及4.x版本的整合策略，并讨论了Redis实现分布式锁的方法及其可能出现的问题。同时，提到了Kafka的持久化、架构设计和消息丢失场景，以及Zookeeper的数据模型和在分布式协调中的作用。文章还涵盖了面试中常见的Redis、Kafka和Zookeeper的相关知识点和问题解答。
“消费组中的消费者个数如果超过topic的分区，那么就会有消费者消费不到数据”这句话是否正确
ZAB（ZooKeeper Atomic Broadcast）协议
Redis
redis 为什么那么快
Redis 的读写速度快主要归功于以下几个因素：
-
**内存存储：** Redis 是基于内存存储的数据库系统，数据完全存储在内存中，这使得数据的读写速度非常快，因为内存的读写速度通常远远快于磁盘。
-
**单线程模型：** Redis 使用单线程模型来处理客户端请求，这意味着它在任何时候都只有一个线程在处理请求，避免了多线程的上下文切换和锁竞争带来的开销。单线程模型简化了并发控制，降低了系统的复杂度，使得 Redis 在处理大量并发请求时依然能够保持高效率。
-
**非阻塞 I/O：** Redis 使用非阻塞的 I/O 处理方式，可以在一个线程中处理多个并发的网络连接，通过事件轮询机制实现高效的 I/O 处理。这使得 Redis 能够充分利用系统资源，提高了并发处理能力。
-
**优化的数据结构：** Redis 内置了丰富的数据结构，如字符串、列表、哈希表、集合和有序集合等，这些数据结构在设计上都经过了优化，能够高效地支持各种数据操作，从而提高了读写的速度。
-
**持久化策略：** Redis 支持多种持久化策略，如快照和日志追加（AOF），通过将内存中的数据定期或实时地写入到磁盘中，保证数据的持久性，同时尽量减少对性能的影响。
综合以上因素，Redis 能够实现快速的读写操作，使其成为许多应用场景下的首选缓存和数据存储解决方案。
redis持久化机制：RDB和AOF
Redis 持久化
Redis 提供了不同级别的持久化方式:
- RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储.
- AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.
- 如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
- 你也可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
- 最重要的事情是了解RDB和AOF持久化方式的不同,让我们以RDB持久化方式开始:
RDB的优点
- RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集.
- RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心（可能加密），非常适用于灾难恢复.
- RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
- 与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.
RDB的缺点
- 如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你.虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据.
- RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度.
AOF 优点
- 使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.
- AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题.
- Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
- AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。
AOF 缺点
- 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
- 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。
4.X版本的整合策略
在AOF重写策略上做了优化
在重写AOF文件时，4.x版本以前是把内存数据集的操作指令落地，而新版本是把内存的数据集以rdb的形式落地
这样重写后的AOF依然追加的是日志，但是，在恢复的时候是先rdb再增量的日志，性能更优秀
Redis做分布式锁用什么命令？
SETNX 格式：setnx key value 将 key 的值设为 value ，当且仅当 key 不存在。 若给定的 key 已经存在，则 SETNX 不做任何动作,操作失败。
SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。
加锁：set key value nx ex 10s
释放锁：delete key
Redis做分布式锁死锁有哪些情况，如何解决？
情况1：加锁，没有释放锁。需要加释放锁的操作。比如delete key。
情况2：加锁后，程序还没有执行释放锁，程序挂了。需要用的key的过期机制。
Redis如何做分布式锁？
假设有两个服务A、B都希望获得锁，执行过程大致如下:
Step1： 服务A为了获得锁，向Redis发起如下命令: SET productId:lock 0xx9p03001 NX EX 30000 其中，"productId"由自己定义，可以是与本次业务有关的id，"0xx9p03001"是一串随机值，必须保证全局唯一，“NX"指的是当且仅当key(也就是案例中的"productId:lock”)在Redis中不存在时，返回执行成功，否则执行失败。"EX 30000"指的是在30秒后，key将被自动删除。执行命令后返回成功，表明服务成功的获得了锁。
Step2: 服务B为了获得锁，向Redis发起同样的命令: SET productId:lock 0000111 NX EX 30000 由于Redis内已经存在同名key，且并未过期，因此命令执行失败，服务B未能获得锁。服务B进入循环请求状态，比如每隔1秒钟(自行设置)向Redis发送请求，直到执行成功并获得锁。
Step3: 服务A的业务代码执行时长超过了30秒，导致key超时，因此Redis自动删除了key。此时服务B再次发送命令执行成功，假设本次请求中设置的value值为0000222。此时需要在服务A中对
最低0.47元/天 解锁文章
扫一扫
2574
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
