1. Redis的简介Redis支持多种数据结构有广泛的业务应用场景。数据保存在内存读写性能高很适合做缓存。数据可以持久化到硬盘可以做数据库来用。官⽅对Redis的作⽤也已经定位成了三个⽅⾯Cache(缓存) Database(数据库)Vector Search(向量搜索)。2. Redis到底是单线程还是多线程Redis对于客户端是多线程的对于服务端是单线程的。客户端的多线程是基于epoll的IO多路复用。epoll负责监听所有客户端的socket当有数据可读或者可写的时候会并行通知redis的主线程哪些客户端准备就绪。redis的主线程收到epoll的通知后将对应的客户端请求放入事件队列。事件分发器将逐个从队列中取出请求根据请求的时间类型分发到不同的时间处理器执行并将结果放到输出缓冲区。命令执行完后对应的socket会被标记为可写。epoll监听到该状态并行的将数据发回给客户端。IO多路复用解决了线程的创建、销毁和上下文切换开销的问题。事件处理流程结合图中架构图片中间的架构图展示了请求的处理路径多路复用入口client1到client4的请求连接、GET、HSET、HGET首先汇聚到IO多路复用​ 层。这一层负责“监听”并收集所有就绪的客户端事件。事件分发汇聚后的事件被送入事件分发器。事件处理器分发器将不同类型的事件分发给具体的处理器如连接应答处理器处理新连接建立。命令请求处理器读取并解析客户端发送的命令。命令回复处理器将执行结果返回给客户端。关键优势串行化执行与免锁Redis 高性能和易用性的关键串行化执行虽然 Redis 同时接收很多请求但它会将它们排成队一个接一个地顺序执行。免并发烦恼因为操作是单线程串行执行的所以 Redis完全不需要考虑​ 多线程下的脏读、幻读、不可重复读等并发问题。天然线程安全你不需要像操作 MySQL 那样为了并发去加锁、考虑事务隔离级别。Redis 的命令执行本身就是原子性的单个命令内。总结Redis 通过 epoll 实现了高效的 IO 多路复用使得单线程能够并发处理海量连接同时它采用串行化的命令执行方式彻底规避了多线程并发控制的复杂性从而实现了极高的性能和可靠性。3. Redis如何保证指令原⼦性复合指令一个指令干着多个指令的活。Redis事务Redis 的事务保证的是原子性命令要么全都不执行【EXEC命令执行之前出现语法/参数错误】要么按顺序全部执行完不会出现执行了一半的情况但它不提供传统意义上的数据恢复Undo Log功能。如果遇到执行错误【EXEC命令执行之后出现运行时错误】已经成功的部分不会撤销这也是 Redis 强调“快”和“简单”的代价。问题EXEC执行后事务中的指令会追加到AOP中但是事务没有执行完redis进程被kill掉导致数据不一致redis重启失败。解决方式使⽤redis-check-aof⼯具修复AOF⽂件将这些不完整的事务操作记录移除掉。这样下次服务就可以正常启动了。Pipeline将客户端的 多个指令打包⼀起往服务端推送。lua脚本lua语言是单线程模型。配置Lua脚本的最⻓控制时间若超时返回BUSY不会一直阻塞。Redis FunctionRedis Function允许将⼀些功能声明成⼀个统⼀的函数提前加载到Redis服务端客户端直接调用实现Function的复用。4.Redis性能压测Redis提供了压测脚本redis-benchmark可以对Redis进⾏快速的基准测试。5.单机数据持久化有四种持久化策略无持久化关闭持久化把redis当缓存。RDB按照时间间隔的策略缓存Redis的快照。AOF记录Redis的每一次操作。通过重放 的方式恢复数据。RDBAOF同时保存Redis的快照数据和操作重启时优先选AOF。RDB的优点RDB文件是二进制文件适合定期备份和容灾恢复。RDB备份时性能好不影响主进程。主进程启动一个子进程完成备份工作。RDB进行大数据量重启时更快。RDB缺点RDB备份不是实时备份存在数据丢失。数据量太大RDB备份容易造成Redis的短暂服务停止。何时触发RDB备份到达配置文件中配置的策略会自动触发。手动save阻塞主线程bgsave后台子线程运行不会阻塞主线程。主从复制触发RDB备份。AOF优点AOF持久化更安全当设置每秒进行一次AOF写入最多丢失一秒的操作。AOF时追加的操作记录更完整。即使出现写入未完成Redis下线的等特殊情况也能使用redis-check-aof修复。AOF文件太大时会自动切换新的日志文件防止单个文件太大。即时有FLUSHALL误删数据的操作也可以在AOF日志文件中将该指令删掉重启redis来恢复数据。AOF缺点同样的数据库AOF文件通常比RDB文件更大。写操作频繁的情况下AOF备份的性能通常比RDB更慢。持久化的使用建议如果你只是把Redis当做⼀个缓存来⽤可以直接关闭持久化。如果你更关注数据安全性并且可以接受服务异常宕机时的小部分数据损失那么可以简单的使用RDB策略。这样性能是⽐较⾼的。不建议单独使⽤AOF。RDB配合AOF可以让数据恢复的过程更快。因为Redis的持久化策略只保证单机的数据安全为了进一步保证数据的安全考虑集群化方案。分布式优化方案主从复制、哨兵集群、Redis集群。6. 主从复制的工作流程1》 Slave启动后向master发送⼀个sync请求。等待建⽴成功后slave会删除掉⾃⼰的数据⽇志⽂ 件等待主节点同步。2》master接收到slave的sync请求后会触发⼀次RDB全量备份同时收集所有接收到的修改数据 的指令。然后master将RDB和操作指令全量同步给slave。完成第⼀次全量同步。3》主从关系建⽴后master会定期向slave发送⼼跳包确认slave的状态。⼼跳发送的间隔通过参 数repl-ping-replica-period指定。默认10秒。4》只要slave定期向master回复⼼跳请求master就会持续将后续收集到的修改数据的指令传递给 slave。同时master会记录offset即已经同步给slave的消息偏移量。5》如果slave短暂不回复master的⼼跳请求master就会停⽌向slave同步数据。直到slave重新上线 后master从offset开始继续向slave同步数据。7. 哨兵集群的工作原理Sentinel的核⼼⼯作原理分两个步骤⼀是如何发现master服务宕机了。⼆是发现master服务宕机 后如何切换新的master。1》如何发现master服务宕机每一个哨兵节点都会向主节点发送心跳当超时没有收到心跳就主观认为该主节点下线。为了避免网络等原因的误判哨兵集群内部互相沟通当超过quorum个哨兵节点认为主节点宕机则客观认为主节点下线了开始故障切换了。2》发现master服务宕机后如何切换新的masterSentinel会在剩余健康的Slave节点中选举出⼀个节点作为新的Master。 选举的规则如下⾸先检查是否有提前配置的优先节点如果⼤家的配置都⼀样就进⼊下⼀个检查规则。然后检查复制偏移量offset最⼤的从节点。也就是找同步数据最快的slave节点。因为他的数据是最全的。如果⼤家的offset还是⼀样的就进⼊下⼀个规则最后按照slave的RunID字典顺序最⼩的节点。切换新的主节点。 Sentinel Leader给新的mater节点执⾏ slave of no one操作将他提升为master节点。 然后给其他slave发送slave of 指令。让其他slave成为新Master的slave。如果旧的master恢复了Sentinel Leader会让旧的master降级为slave并从新的master上同步数据恢复⼯作。8. Redis集群的选举流程当从节点发现自己的主节点变成fail状态会延迟一会再尝试进⾏Failover以期成为新的master。延迟是为了避免主节点刚挂掉其他主节点还没反应过来。若从节点较多就需要投票选举1 发现故障从节点Slave发现自己负责的主节点Master挂了变为 FAIL 状态。2 发起选举它给自己记一个“年份”Epoch并加 1然后向全集群广播。3获得认可其他主节点收到请求确认这个 Slave 合法且数据较新通过 Rank 判断就给它投一张赞成票ACK。4胜选上位当这个 Slave 收集到的赞成票超过集群中主节点总数的一半时它立刻升级为新的主节点。5 通知全网新主节点广播 Pong 消息通知其他集群节点。