我要评论单节点redis问题：
- 数据丢失：实现redis数据持久化，保存在磁盘
- 存储能力：搭建分片集群，利用插槽机制实现动态扩容
- 并发能力：搭建主从集群，实现读写分离
- 故障回复：利用redis哨兵，实现检测和自动恢复
redis持久化
rdb持久化
redis数据备份文件，也被叫做redis数据快照，就是把内存中所有数据都记录到磁盘，当redis实例故障重启后，从磁盘读取快照文件恢复数据
——主动宕机会自动执行一次rdb
save //由redis主进程执行rdb，会阻塞所有命令 bgsave //开启子进程执行rdb，避免主进程受到影响
redis内部有触发rdb的机制，可以在redis.conf文件找到：
redis配置文件中的rdb持久化规则 save 900 1 # 900秒（15分钟）内，如果至少有1个key被修改，则执行bgsave save 300 10 # 300秒（5分钟）内，如果至少有10个key被修改，则执行bgsave save 60 10000 # 60秒（1分钟）内，如果至少有10000个key被修改，则执行bgsave 禁用rdb持久化（生产环境慎用） save ""
rdb的其他配置也可以在redis.conf文件设置：
# rdb持久化压缩配置（默认开启，建议不开启，压缩会消耗cpu，磁盘不值钱） rdbcompression yes # 是否压缩rdb文件，yes开启压缩，no关闭压缩 # rdb文件名称配置 dbfilename dump.rdb # rdb文件的名称 # rdb文件保存目录配置 dir ./ # rdb文件保存的目录路径
bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据，完成fork读取内存数据并写入rdb文件
fork采用copy-on-write技术：
- 当主进程执行读操作时，访问共享内存
- 当主进程执行写操作时，则会拷贝一份数据看，执行写操作
rdb总结
rdb方式bgsave基本流程：
- → fork主进程得到一个子进程，共享内存空间
- → 子进程读取内存数据并写入新的rdb文件
- → 用新的rdb文件替代旧的rdb文件
rdb执行时机：
默认是服务停止时
rdb的缺点：
- rdb执行间隔时间长，两次rdb之间写入数据有丢失的风险
- fork子进程、压缩、写入rdb文件比较耗时
aof持久化
因为是记录命令，aof文件比rdb文件大，而且aof会记录对同一个key的多次写操作，但只有最后一次写操作才有意义
——执行bgrewriteaof命令，可以让aof文件执行重写功能，用最少命令达到相同效果
aof默认关闭，需要修改redis.conf配置文件来开启aof
# aof持久化开关 appendonly yes # 是否开启aof功能，默认是no # aof文件名称 appendfilename "appendonly.aof" # aof文件的名称
aof的命令记录的频率也可以通过redis.conf文件配置
//表示每执行一次写命令，立即记录到aof文件 appendfsync always //写命令执行完先放入aof缓冲区，然后每个1秒将缓冲区数据写到aof文件（默认）3 appendfsync everysec //写命令执行完先放入aof缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
| 策略 | 配置值 | 同步时机 | 数据安全 | 性能影响 | 适用场景 |
|---|---|---|---|---|---|
| always | appendfsync always | 每次写命令后立即同步 | 最高（零丢失） | 最低（性能差） | 金融交易、支付系统 |
| everysec | appendfsync everysec | 每秒同步一次（默认） | 较高（最多丢失1秒） | 中等（推荐） | 大多数生产环境 |
| no | appendfsync no | 由操作系统决定（通常30秒） | 最低（可能丢失>30秒） | 最高（性能最好） | 缓存、非关键数据 |
redis会在触发阈值时自动去重写aof文件，阈值可在redis.conf中配置
//aof文件比上次文件增长超过多少百分比则触发重写 auto-aof-rerite-percentage 100 //aof文件体积最小多大以上才触发重写 auto-aof-rerite-min-size 64mb
aof和rdb对比
aof和rdb各有优缺点，如果对数据安全性要求高，在实际开发中会结合两者使用
| 对比维度 | rdb | aof |
|---|---|---|
| 持久化方式 | 定时对整个内存做快照 | 记录每一次执行的命令 |
| 数据完整性 | 不完整，两次备份之间会丢失 | 相对完整，取决于刷盘策略 |
| 文件大小 | 会有压缩，文件体积小 | 记录命令，文件体积很大 |
| 宕机恢复速度 | 很快 | 慢 |
| 数据恢复优先级 | 低，因为数据完整性不如aof | 高，因为数据完整性更高 |
| 系统资源占用 | 高，大量cpu和内存消耗（fork子进程） | 低，主要是磁盘io资源但aof重写时会占用大量cpu和内存资源 |
| 使用场景 | 可以容忍数分钟的数据丢失，追求更快的启动速度 | 对数据安全性要求较高常见 |
redis主从
单节点redis的并发能力有上限，要进一步提高redis的并发能力需要搭建主从集群，实现读写分离.
搭建方式存储于文件redis集群.md下
数据同步原理
通过master判断slave是不是第一次来同步数据需要掌握两个重要概念：
- replication id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid
- offset ：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新
- 因此slave做数据同步，必须向master声明自己的replication id 和offset，master才可以判断到底需要同步哪些数据
一、主从第一次同步是全量同步：
结合两个重要概念后：
全量同步流程：
- slave节点请求增量同步
- master节点判断replid，发现不一致，拒绝增量同步
- master将完整内存数据生成rdb，发送rdb到slave
- slave清空本地数据，加载master的rdb
- master将rdb期间的命令记录在repl_baklog,并持续将log中的命令发给slave
- slave执行接收到的命令，保持于master之间的同步
二、主从第一次同步是全量同步，但如果slave重启后同步则执行增量同步
注意：repl_baklog大小上限，写满后会覆盖最早的数据。如果slave断开时间过久，导致尚未备份的数据被覆盖，则无法基于log做增量同步，只能再次全量同步
优化redis主从集群方案：
- 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步的磁盘io
- redis单节点上的内存占用不要太大，减少rdb导致的过多磁盘io
- 适当提高repl_baklog的大小，发现slave宕机尽快实现故障恢复，尽可能避免全量同步
- 限制一个master上的slave节点数量，如果实在过多slave则采用主-从-从链式结构，减少master压力
redis主从总结
全量同步和主从同步的区别：
- 全量同步：master将完整内存数据生成rdb，发送到slave。后续命令则记录在repl_baklog，逐个发送给slave
- 增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令交给slave
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持代码网。
发表评论