360网站在系统那里,用英文介绍购物网站,百度竞价排名一年费用,个人门户网站模板文章目录 Redis的持久化RDB模式异步持久化的实现AOF模式总结 Redis的主从架构1.端口以及文件调试测试2.主从配置3.数据同步原理#xff08;第一次同步为全局同步#xff09;4.增量同步5.主从配置优化6.问:master主机怎么判断从机slave是不是第一次同步数据#xff1f; Redis… 文章目录 Redis的持久化RDB模式异步持久化的实现AOF模式总结 Redis的主从架构1.端口以及文件调试测试2.主从配置3.数据同步原理第一次同步为全局同步4.增量同步5.主从配置优化6.问:master主机怎么判断从机slave是不是第一次同步数据 Redis的持久化
Redis服务的前言 数据丢失问题实现Redis持久化用备份 并发能力问题单节并发度较低搭建主从集群实现读写分离 储存能力问题搭建分片集群利用插槽机制实现动态扩容 故障恢复问题redis宕机服务不可用会出现很多状况需要自动故障恢复手段哨兵实现健康监测和自动恢复 RDB模式
RDB被称为Redis数据快照 记录内存数据到磁盘中当Redis实例故障重启后会从磁盘读取快照文件恢复数据
快照文件为RDB文件默认保存在当前运行目录有两种保存方式savebgsaveRedis挂了也会执行一次RDB
bgsave:创建一个子进程——通过fork主进程得到子进程共享主进程内存数据然后将fork完的内存数据写入redis中
save是由Redis主进程来执行save回阻塞所有命令所以一般都使用bgsave 也可以自动触发RDB 在redis.conf下有Redis触发RDB的机制 RDB其他配置 压缩rdb文件到磁盘rdbcompression yes 文件保存路径目录dir ./ rdb文件改了名称后会丢失数据 时间不能太长也不能太短因为太短如果数据量很大比如1g你1s一次来不赢压力很大 时间太长你写入数据比较快然后挂了那么数据就会丢失保存不了 所以一般用默认的RDB触发时间就行了
异步持久化的实现
我们主进程用的是虚拟内存其实也就是本机内存的一部分然后其他物理内存中的数据的调用是由于页表的作用——操作系统会维护页表主进程通过页表中的映射关系得到物理内存中的数据
而我们这里的的异步持久化——作用就是主进程fork了一个子进程因为子进程此时与主进程的作用是一样的所以也可以对物理内存的数据进行读写
fork子过程拷贝页表是阻塞的
从而达到内存共享子进程对内存数据进行读写实现异步持久化 copy-on-wirte技术
当出现读写操作时一个进行读读取共享内存一个进行写当执行写操作时内存中的数据read-only会被拷贝一份数据放在内存中给其他线程进行读取
每更新一次或者说更新的时候每有进程来读取都会有一个新的数据副本 AOF模式 appendfsync always表示执行一次命令主进程接收到命令分配内存进行执行然后持久化到硬盘——安全
appendfsync everysec将命令执行放入缓冲区中然后每秒将缓冲区中的数据写入AOF文件如果途中宕机有丢掉数据的风险
appendsync no这个的话写命令完成后它会被放到AOF缓冲区但是缓冲区的数据什么时候写回给磁盘是由操作系统决定的 进行配置
save :禁用rdb
开启AOFappendonly yes 重启后也会数据持久化到硬盘
注意AOF记录的操作的命令数只要你是个命令都会被记录到AOF配置文件中而rdb文件记录的是值只有不同的值才会被记录到其中有对象treeset和hashset
所以说AOF文件会比RDB文件大的多会记录对同一个key的多次写操作 执行BGREWRITEAOF命令
重写AOF 总结
RDB宕机恢复速度AOF宕机恢复速度因为RDB里面放的是数据AOF放的是命令还需要执行所以肯定慢些赛
RDB数据恢复优先级AOF因为数据完整性较低rdb可以充当一个备份的作用比如主从集群时rdb文件能够帮助恢复数据
RDB系统资源占用较高容易丢数据备份时间较长save xxx xxx需要考虑时间长短一次备份而AOF主要磁盘IO资源因为其他线程需要重写命令 Redis的主从架构
像我们redis的话其实大部分都是用在读上面
我们单节点的并发能力是有限的可以试想一下把读写操作进行分离主节点进行写操作从节点进行读操作
从节点是主节点fork得到的主从数据同步 1.端口以及文件调试测试
创建三个文件7001,7002,7003 1.首先开启3个节点需要准备三份不同的配置文件和目录配置文件所在的目录就是工作目录
将配置文件分别拷贝到文件目录中
修改工作目录以及port sed -i -e s/6379/7001/g -e s/dir .\//dir \/etc\/7001\//g 7001/redis.conf
发现以及配置成功工作目录以及端口成功被修改
3.还需要修改每个节点声明的IP因为虚拟机本身有多个IP为了避免混乱需要再redis.conf中指定每一个实例的绑定IP信息
声明IP地址成功 2.主从配置
先redis-cli -p 端口号当前节点连接端口
然后slaveof设置主从 数据同步完成
3.数据同步原理第一次同步为全局同步 1.其实就是rdb文件从机调用slaveof命令后——从机请求mastermaster判断从机是不是第一次数据同步是的话就将rdb文件发送给从机主机执行bgsave命令生成并发送rdb从而实现数据同步第一次是从机主动请求的 2.然后从机先清空本地数据然后加载rdb文件 3.后面主机再对数据更新主机会自动给从机主动发送repl_baklog命令从机接收到命令后执行 repl_baklog
它是针对部分复制储存未来新增的命令里面有偏移量offset就是增量同步 4.增量同步
增量同步就是全量同步后主从同步数据而方式
流程 1.slave进行重启后因为从机宕机了所以主机的写数据从机是不知道的 2.从机醒来后会向主机发送请求然后请求判断id固然是一样的然后从repl_baklog中获取从机offset后的数据 3.然后从机执行 注意如果欠的数据一圈了因为repl_baklog大小是有上限的写满后会覆盖最早的数据而从机slave断开的时间又很久——导致数据被覆盖无法增量同步只能全量同步(可以将repl_baklog 文件大小设置大一点 或者 尽量不要让从机长时间宕机)
5.主从配置优化 1.在master中的配置文件配置repl-diskless-sync yes启用无磁盘复制这样我们的数据不会经过磁盘读写而是直接将数据放到网络中通过网络进行传输 如果网络非常之慢的话就还是用磁盘复制 2.可以适当提高repl_baklog的大小因为我们出现全量同步的原因就是repl_baklog小了数据量大过了这个圈从而导致覆盖 3.限制master上slave节点的数量当从节点过多可以采用主-从链式结构减轻主机压力 6.问:master主机怎么判断从机slave是不是第一次同步数据
Replication id数据集的标记id一致则是同一数据集每一个master都有唯一Replication idslave从机会继承主机master的Replication id第一次主机和从机标记中的偏移量是一样的也就是数据是一致的
offset偏移量当主机数据写入那么repl——baklog中的数据会越来越多。而从机完成同步时也会记录同步的offset如果从机salve的offsetmaster主机的offset就说明从机的数据落后于主机需要更新
主机首先会根据Replication id进行判断因为从机一开始也是自己的主机所以id肯定是不一样的如果是第一次那么将主机id给到从机并将offset传入然后从机保存版本信息那么就表示了从机与主机数据一致 1.主从机先进行连接然后从机发送增量同步请求 2.主机说你的id与我的不匹配你是第一次来不能给你增量同步只能全量同步 3.从机开始全量同步 然后接收主机的数据并将自己之前数据清空进行同步
