深圳专业网站企业为什么要做手机网站

深圳专业网站,企业为什么要做手机网站,服务器用来做网站和数据库,如何建设一个手机网站在上一篇中#xff0c;我们探讨了 Redis 的分布式锁。今天#xff0c;我们回归 Redis 的本质——内存数据库。既然是“内存”数据库#xff0c;大家最担心的就是一个问题#xff1a;断电了怎么办#xff1f; 如果服务器宕机#xff0c;内存里的数据就会瞬间蒸发#xff…在上一篇中我们探讨了 Redis 的分布式锁。今天我们回归 Redis 的本质——内存数据库。既然是“内存”数据库大家最担心的就是一个问题断电了怎么办如果服务器宕机内存里的数据就会瞬间蒸发这对业务来说是灾难性的。为了解决这个问题Redis 提供了强大的持久化机制将内存数据写入磁盘。本文将深入扒开 RDB、AOF 以及 Redis 4.0 引入的混合持久化的底层细节。一、 RDB给内存拍张“照片”RDB (Redis Database Backup file)又被称为数据快照。它的原理非常直观在指定的时间间隔内将内存中的所有数据集快照写入磁盘。 恢复时直接将快照文件读入内存。1. 触发机制在redis.conf中我们可以配置触发规则Bashsave 900 1 # 900秒内至少1个key被修改则触发 save 300 10 # 300秒内至少10个key被修改则触发 save 60 10000 # 60秒内至少10000个key被修改则触发除了自动触发我们还可以手动执行命令save由主进程执行。注意因为 Redis 是单线程的主进程去写磁盘会直接阻塞所有客户端请求生产环境绝对禁止使用。bgsaveBackground Save。Redis 会在后台异步进行快照操作不阻塞主进程。2. 原理深度剖析bgsave 与 它的底层实现Copy-On-Write (写时复制)写时复制的意思其实就是主线程在进行写操作的时候先复制备份一份在备份的这个文件上去进行写操作这样子进程读操作就可以保证一直读的是之前的那个旧版本。问题场景Redis 一边在“拍照”持久化一边还在“干活”处理用户写请求。如果数据一直在变照片怎么拍比如拍照要 1 分钟这 1 分钟内数据变了怎么办为了解决这个问题Redis 引入了 Fork 和 COW (Copy-On-Write) 机制。第一步Fork 子进程当执行bgsave时主进程会调用操作系统的fork()系统调用创建一个子进程。关键点fork不会复制原本的 10GB 内存数据否则内存瞬间爆炸且耗时极长。它只复制主进程的页表Page Table。页表可以理解为内存数据的“目录”。结果子进程诞生的一瞬间它手里的“目录”和主进程一模一样指向同一块物理内存。这个过程极快只阻塞主进程几毫秒。第二步写时复制 (Copy-On-Write)fork 结束后主进程继续响应客户端请求子进程负责写文件。此时主子进程共享同一份物理内存。如果主进程是读数据大家相安无事。如果主进程要写数据比如修改 Key A操作系统发现这块内存被共享且标记为“只读”触发中断。操作系统将 Key A 所在的**那一页内存4KB**复制一份副本。主进程在副本上修改 Key A。子进程继续读取原件。结论通过 COW 机制子进程拿到的永远是 fork 那一瞬间的“时间冻结”数据。无论主进程怎么改生成的 RDB 文件都是绝对纯净、一致的快照。3. RDB 优缺点优点恢复速度极快解压二进制文件即可文件体积小。缺点数据安全性低。RDB 是间隔执行的如果每 5 分钟拍一次Redis 在第 4 分钟宕机你就会丢失这 4 分钟的所有数据。二、 AOF记账员的“流水账”简单来说RDB是拍照AOF就是记录所有的命令。AOF (Append Only File)意思是追加文件。它的逻辑与 RDB 完全不同Redis 每执行一条写命令就把它以文本协议的格式追加到日志文件的末尾。恢复时Redis 就像重播电影一样把日志里的命令从头到尾执行一遍。1. 刷盘策略 (fsync)AOF 解决了 RDB 丢数据的问题但“写文件”也是有磁盘 IO 开销的。Redis 提供了三种策略Always同步刷盘。每执行一条写命令立马强制写入磁盘。优点数据绝对安全。缺点性能极差吞吐量低。Everysec (默认)每秒刷盘。先把命令写到缓冲区每隔 1 秒将缓冲区写入磁盘。优点性能与安全的平衡点最多丢失 1 秒数据。No操作系统看着办。性能最好但不可控。2. AOF 重写 (Rewrite)随着时间推移AOF 文件会越来越大。比如你对 count 执行了 100 次 INCR最终 count100。AOF 文件里存了 100 条命令但恢复数据时其实只需要一条 SET count 100 就够了。为了给日志“瘦身”Redis 提供了bgrewriteaof命令Redis 会创建一个子进程。子进程读取当前的内存状态。用最少的命令构建一个新的 AOF 文件替换掉旧的大文件。3. AOF 优缺点优点数据安全。使用everysec策略顶多丢失 1 秒数据。缺点恢复速度慢要重新执行所有命令文件体积通常比 RDB 大。三、 混合持久化升级版”的 AOF 重写瘦身方式简单来说就是先把当前现有的存为RDB格式然后新增的用AOF格式追加在后面。在 Redis 4.0 之前我们经常陷入纠结用 RDB 怕丢数据用 AOF 怕恢复太慢。Redis 4.0 推出了 RDB-AOF 混合持久化作为默认配置完美解决了这个问题。1. 核心原理混合持久化发生在 AOF 重写 的过程中。当 Redis 重写 AOF 文件时它不再只是单纯地把内存转成 AOF 命令而是前半部分将当前的内存数据以RDB (二进制快照)的格式写入 AOF 文件开头。后半部分在重写期间产生的新增量数据依然以AOF (文本命令)的格式追加在后面。2. 最终的文件结构打开一个开启了混合持久化的.aof文件你会发现开头是乱码一样的二进制数据RDB 快照。末尾是可读的文本命令AOF 增量日志。3. 压倒性的优势启动超快Redis 启动时先加载开头的 RDB 部分速度飞快。数据不丢加载完 RDB 后再执行末尾少量的 AOF 命令补全最后时刻的数据。四、 总结与选型建议特性RDB (快照)AOF (日志)混合持久化底层原理Fork Copy-On-Write追加写 重写RDB AOF恢复速度快慢快数据安全性低 (可能丢几分钟)高 (丢1秒)高文件大小小大中等给开发者的建议生产环境强烈建议开启混合持久化Redis 4.0 默认开启。这是目前的最佳实践。纯缓存模式如果你完全不在乎数据丢失比如只是做数据库的缓存丢了可以回源查 MySQL可以关闭所有持久化获得极致的性能。永远不要只开启 RDB除非你这台 Redis 是用来做纯粹的离线备份否则数据丢失的风险在生产环境中是不可接受的。