Redis单线程与多线程机制首先要搞懂Redis是单线程还是多线程核心命令处理 单线程Redis 处理客户端的读写命令get/set/delete… 全程只用一个主线程。所有命令排队执行不存在多线程竞争、锁、线程切换开销这是 Redis 极快的核心原因之一网络 IO / 持久化 多线程Redis 不是全程单线程后台任务用多线程网络 IO 读写6.0 引入多线程 IORDB 快照、AOF 重写异步删除、lazy free主从复制一、单线程机制基于内存所有操作在内存完成纳秒级响应单线程无锁竞争不用加锁、解锁没有线程上下文切换代码简单、稳定、不易出 bug关键使用了 IO 多路复用技术一个线程就能同时监听成千上万个连接这是 Redis 高性能的底层基石。IO多路复用单个线程通过一个系统调用同时监听多个 socket 的读写事件。当某个 socket 就绪可读 / 可写就去处理不阻塞、不浪费 CPU。分步流程1.注册监听主线程把所有客户端 Socket 连接全部注册到 IO 多路复用器 中。多路复用器统一托管所有连接。2.阻塞等待事件多路复用器进入阻塞状态不占用 CPU静静等待任意客户端发请求读 / 写事件。3. 事件触发某一个 / 多个客户端发送数据对应 Socket 变为就绪状态。4.唤醒主线程多路复用器立刻返回就绪的连接列表唤醒主线程。5.串行处理任务主线程遍历就绪连接逐个执行 Redis 命令单线程串行无锁竞争。6.结果返回命令处理完成把响应数据写回对应客户端之后主线程再次回到阻塞等待状态继续等待新事件。Redis的主从复制简介Redis 主从复制指一台主节点Master 将自身的数据自动同步到一台或多台从节点Slave 的机制。架构上遵循一主多从模式主节点承担写操作接收新增、修改、删除请求从节点默认只读只处理查询请求不对外提供写服务流程图示核心特点读写分离如图其中master节点专门负责写操作set k1 v1follower节点专门负责读操作get k1注意:1.数据必须一致一致性问题不是强一致而是最终一致同步数据有延时允许在一段时间内数据不一致言下之意master有新数据那么follower也必须要有这个新数据2.master如果一旦宕机那将如何follower一直等待master活过来依然作为master的小弟从机 不会篡位。此时会产生问题在这段时间内redis主从架构不能提供写服务哨兵模式1.核心作用解决主从复制中主节点宕机后无法自动故障转移的问题实现主节点的自动选举与切换2. 工作原理与流程健康监控哨兵通过定时任务类似 setInterval()定期向 master 节点发送远程调用做健康检查。如果返回 status “unavailable”判定 master 节点宕机。故障通知哨兵检测到 master 宕机后会向所有 follower 节点发送通知告知 master 已宕机让它们准备进行新主选举。故障转移与主从切换从 follower 中选举一台作为新的 master 节点。原 master 节点恢复后会自动降级为新 master 的从节点继续同步数据master-follower 关系反转。3.流程图示哨兵一旦监听到Master节点宕机此时就会给follower节点发送通知告知master已经宕机做好选举准备随机选择一台机器上位那么当原来的master恢复后那么这个master节点就会自动成为新的master节点的从机RDB与AOF一、核心概念Redis 是内存数据库数据默认存储在内存中服务重启会丢失数据。持久化就是把内存数据写入磁盘实现数据的灾备与恢复主要分为 RDB 和 AOF 两种方案也支持两者结合的混合持久化。二、RDBRedis Database持久化1. 原理将 Redis 内存中的数据做快照snapshot保存为一个 .rdb 二进制文件用于灾备与恢复。2. 优缺点优点缺点性能好直接序列化内存数据文件体积小恢复速度快会丢失数据两次快照之间的数据无法保存故障时会丢失最近一次快照后的所有数据不占用磁盘额外开销相比 AOF 日志快照过程中如果数据量极大fork 子进程可能短暂影响性能3. 两种实现方式1save同步阻塞特点主线程直接执行快照会阻塞所有客户端请求生产环境不推荐。配置方式redis.conf格式save 秒数 修改次数表示指定秒数内修改次数达到阈值则触发RDBsave 3600 1 # 3600秒1小时内至少1次修改save 300 100 # 300秒5分钟内至少100次修改save 60 10000 # 60秒内至少10000次修改2bgsave非阻塞主流方式特点主线程调用 fork() 创建子进程由子进程完成快照写入磁盘主线程继续处理客户端请求不阻塞业务。关键技术写时复制Copy-On-Write, COW子进程 fork 时和父进程共享同一份内存数据副本主线程后续修改数据时会先复制一份副本给子进程保证子进程快照的是 fork 瞬间的数据互不干扰。三、AOFAppend Only File持久化1. 原理记录客户端发送的每一条写命令追加到.aof日志文件末尾重启时重放日志恢复数据。2. 优缺点优点缺点数据安全支持每秒 / 每次写操作同步几乎不丢数据性能开销大文件会持续膨胀重放恢复速度慢日志可读可手动修改如误删数据时写命令追加 重写会占用额外磁盘 IO高并发场景性能不如 RDB3. 配置与刷盘策略redis.confappendonly yes # 开启AOF持久化刷盘策略三选一appendfsync always 每次写操作都同步刷盘数据零丢失性能最差appendfsync everysec # 每秒刷盘一次默认配置平衡性能与数据安全appendfsync no 不主动刷盘由操作系统决定性能好但可能丢数据4. AOF 重写机制AOF 文件会随写操作持续变大Redis 会自动触发重写压缩日志体积auto-aof-rewrite-percentage 100 # 文件大小比上一次重写后增长100%即翻倍时触发auto-aof-rewrite-min-size 64mb # 触发重写的最小文件大小低于64MB不触发四、RDB vs AOF 对比与建议维度RDBAOF数据安全丢数据取决于快照间隔几乎不丢数据取决于刷盘策略性能高快照写入恢复快低日志追加 重放恢复慢文件体积小二进制快照大命令日志重写后会压缩故障恢复快慢
Redis的单多线程、主从复制、RDB与AOF原理学习心得
Redis单线程与多线程机制首先要搞懂Redis是单线程还是多线程核心命令处理 单线程Redis 处理客户端的读写命令get/set/delete… 全程只用一个主线程。所有命令排队执行不存在多线程竞争、锁、线程切换开销这是 Redis 极快的核心原因之一网络 IO / 持久化 多线程Redis 不是全程单线程后台任务用多线程网络 IO 读写6.0 引入多线程 IORDB 快照、AOF 重写异步删除、lazy free主从复制一、单线程机制基于内存所有操作在内存完成纳秒级响应单线程无锁竞争不用加锁、解锁没有线程上下文切换代码简单、稳定、不易出 bug关键使用了 IO 多路复用技术一个线程就能同时监听成千上万个连接这是 Redis 高性能的底层基石。IO多路复用单个线程通过一个系统调用同时监听多个 socket 的读写事件。当某个 socket 就绪可读 / 可写就去处理不阻塞、不浪费 CPU。分步流程1.注册监听主线程把所有客户端 Socket 连接全部注册到 IO 多路复用器 中。多路复用器统一托管所有连接。2.阻塞等待事件多路复用器进入阻塞状态不占用 CPU静静等待任意客户端发请求读 / 写事件。3. 事件触发某一个 / 多个客户端发送数据对应 Socket 变为就绪状态。4.唤醒主线程多路复用器立刻返回就绪的连接列表唤醒主线程。5.串行处理任务主线程遍历就绪连接逐个执行 Redis 命令单线程串行无锁竞争。6.结果返回命令处理完成把响应数据写回对应客户端之后主线程再次回到阻塞等待状态继续等待新事件。Redis的主从复制简介Redis 主从复制指一台主节点Master 将自身的数据自动同步到一台或多台从节点Slave 的机制。架构上遵循一主多从模式主节点承担写操作接收新增、修改、删除请求从节点默认只读只处理查询请求不对外提供写服务流程图示核心特点读写分离如图其中master节点专门负责写操作set k1 v1follower节点专门负责读操作get k1注意:1.数据必须一致一致性问题不是强一致而是最终一致同步数据有延时允许在一段时间内数据不一致言下之意master有新数据那么follower也必须要有这个新数据2.master如果一旦宕机那将如何follower一直等待master活过来依然作为master的小弟从机 不会篡位。此时会产生问题在这段时间内redis主从架构不能提供写服务哨兵模式1.核心作用解决主从复制中主节点宕机后无法自动故障转移的问题实现主节点的自动选举与切换2. 工作原理与流程健康监控哨兵通过定时任务类似 setInterval()定期向 master 节点发送远程调用做健康检查。如果返回 status “unavailable”判定 master 节点宕机。故障通知哨兵检测到 master 宕机后会向所有 follower 节点发送通知告知 master 已宕机让它们准备进行新主选举。故障转移与主从切换从 follower 中选举一台作为新的 master 节点。原 master 节点恢复后会自动降级为新 master 的从节点继续同步数据master-follower 关系反转。3.流程图示哨兵一旦监听到Master节点宕机此时就会给follower节点发送通知告知master已经宕机做好选举准备随机选择一台机器上位那么当原来的master恢复后那么这个master节点就会自动成为新的master节点的从机RDB与AOF一、核心概念Redis 是内存数据库数据默认存储在内存中服务重启会丢失数据。持久化就是把内存数据写入磁盘实现数据的灾备与恢复主要分为 RDB 和 AOF 两种方案也支持两者结合的混合持久化。二、RDBRedis Database持久化1. 原理将 Redis 内存中的数据做快照snapshot保存为一个 .rdb 二进制文件用于灾备与恢复。2. 优缺点优点缺点性能好直接序列化内存数据文件体积小恢复速度快会丢失数据两次快照之间的数据无法保存故障时会丢失最近一次快照后的所有数据不占用磁盘额外开销相比 AOF 日志快照过程中如果数据量极大fork 子进程可能短暂影响性能3. 两种实现方式1save同步阻塞特点主线程直接执行快照会阻塞所有客户端请求生产环境不推荐。配置方式redis.conf格式save 秒数 修改次数表示指定秒数内修改次数达到阈值则触发RDBsave 3600 1 # 3600秒1小时内至少1次修改save 300 100 # 300秒5分钟内至少100次修改save 60 10000 # 60秒内至少10000次修改2bgsave非阻塞主流方式特点主线程调用 fork() 创建子进程由子进程完成快照写入磁盘主线程继续处理客户端请求不阻塞业务。关键技术写时复制Copy-On-Write, COW子进程 fork 时和父进程共享同一份内存数据副本主线程后续修改数据时会先复制一份副本给子进程保证子进程快照的是 fork 瞬间的数据互不干扰。三、AOFAppend Only File持久化1. 原理记录客户端发送的每一条写命令追加到.aof日志文件末尾重启时重放日志恢复数据。2. 优缺点优点缺点数据安全支持每秒 / 每次写操作同步几乎不丢数据性能开销大文件会持续膨胀重放恢复速度慢日志可读可手动修改如误删数据时写命令追加 重写会占用额外磁盘 IO高并发场景性能不如 RDB3. 配置与刷盘策略redis.confappendonly yes # 开启AOF持久化刷盘策略三选一appendfsync always 每次写操作都同步刷盘数据零丢失性能最差appendfsync everysec # 每秒刷盘一次默认配置平衡性能与数据安全appendfsync no 不主动刷盘由操作系统决定性能好但可能丢数据4. AOF 重写机制AOF 文件会随写操作持续变大Redis 会自动触发重写压缩日志体积auto-aof-rewrite-percentage 100 # 文件大小比上一次重写后增长100%即翻倍时触发auto-aof-rewrite-min-size 64mb # 触发重写的最小文件大小低于64MB不触发四、RDB vs AOF 对比与建议维度RDBAOF数据安全丢数据取决于快照间隔几乎不丢数据取决于刷盘策略性能高快照写入恢复快低日志追加 重放恢复慢文件体积小二进制快照大命令日志重写后会压缩故障恢复快慢
