哪个网站生鲜配送做的好,建设综合信息网站需要多少钱,网站数据库空间大小,网站建设服务费是否无形资产六、Redis 灾备方案
6.1 存储方案
6.1.1 基础对比
RDB持久化AOF持久化原理周期性fork子进程生成持久化文件每次写入记录命令日志文件类型二进制dump快照文件文本appendonly日志文件触发条件默认超过300s间隔且有1s内超过1kb数据变更永久性每秒fsync一次文件位置配置文件中指…六、Redis 灾备方案
6.1 存储方案
6.1.1 基础对比
RDB持久化AOF持久化原理周期性fork子进程生成持久化文件每次写入记录命令日志文件类型二进制dump快照文件文本appendonly日志文件触发条件默认超过300s间隔且有1s内超过1kb数据变更永久性每秒fsync一次文件位置配置文件中指定目录日志文件appendonly.aof写入方式fork后子进程同步写快照对读写性能影响小速度高每次写入追加日志文件格式RDB二进制密集结构AOF日志易读文本格式数据一致性快照间隔时间内可能丢失部分写实时写入保证数据完整性故障恢复直接加载快照文件重建数据集恢复更快根据日志回放还原每个写操作性能影响fork时可能短暂阻塞客户端每次写带来额外I/O开销自动回收清理过期快照AOF重写动态缩小日志扩展作为主从复制基础主从 replicate依赖AOF日志选择原则冷备,部分大容量场景热备,追求数据安全与一致性
6.1.2 核心配置
RDB
save 60 10000RDB最多丢1分钟的数据那么尽量就是每隔1分钟都生成一个快照
AOF
auto-aof-rewrite-percentage 100: 就是当前AOF大小膨胀到超过上次100%上次的两倍auto-aof-rewrite-min-size 64mb: 根据你的数据量来定16mb32mb
备份方案
写crontab定时调度脚本去做数据备份【48 小时】每小时都copy一份rdb的备份到一个目录中去仅仅保留最近48小时的备份【月】每天都保留一份当日的rdb的备份到一个目录中去仅仅保留最近1个月的备份【清理】每次copy备份的时候都把太旧的备份给删了【灾备】每天晚上将当前服务器上所有的数据备份发送一份到远程的云服务上去
每小时copy一次备份删除48小时前的数据
crontab -e0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.shredis_rdb_copy_hourly.sh
#!/bin/sh cur_datedate %Y%m%d%k
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir /usr/local/redis/snapshotting/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_datedel_datedate -d -48hour %Y%m%d%k
rm -rf /usr/local/redis/snapshotting/$del_date每天copy一次备份
crontab -e0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.shredis_rdb_copy_daily.sh#!/bin/sh cur_datedate %Y%m%d
rm -rf /usr/local/redis/snapshotting/$cur_date
mkdir /usr/local/redis/snapshotting/$cur_date
cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_datedel_datedate -d -1month %Y%m%d
rm -rf /usr/local/redis/snapshotting/$del_date每天一次将所有数据上传一次到远程的云服务器上去
rsync
快速恢复
场景数据恢复方案Redis进程挂掉直接基于AOF日志文件进行数据恢复AOF文件记录了每个写操作的指令重启Redis进程后通过重播AOF文件中的指令来恢复数据最多可能丢失一秒的数据。Redis进程所在机器挂掉重启机器后尝试重启Redis进程尝试直接基于AOF日志文件进行数据恢复。如果AOF文件未破损可直接重启Redis进程进行恢复。若AOF文件破损可以使用redis-check-aof工具修复。当前最新的AOF和RDB文件出现丢失/损坏尝试基于当前机器上最新的RDB数据副本进行数据恢复。如果RDB文件丢失或损坏可以从其他备份中恢复数据。当前机器上的所有RDB文件全部损坏从远程的云服务上拉取最新的RDB快照来恢复数据。发现有重大的数据错误如某个小时上线的程序导致数据错乱选择某个更早的时间点的RDB数据副本进行恢复将数据恢复到更早的状态。例如发现某个时刻的数据错误可以选择较早的RDB备份进行恢复。
6.2 缓存灾备处理
主从机制冗余备份【对等副本】
策略确保缓存系统采用主从机制即在集群中的某一部分缓存不可用时可以通过其他节点补充上去保持系统的稳定运行。方案确保缓存系统采用主从机制并及时修复故障节点保证系统的冗余备份可用性。
部分用户降级【部分降级】
策略如果缓存导致应用可用性下降可以考虑通过降级方案让一部分用户先用起来减轻系统压力等待缓存恢复。方案根据系统承受能力设计降级方案将一部分用户转移到备用系统或者采用降级功能保证核心用户的使用体验。
逐步减少降级量【逐步恢复】
策略一旦部分用户降级以减少系统压力可以逐步减少降级量逐步恢复系统的正常状态。方案一旦缓存系统恢复正常逐步恢复所有用户的使用权限直至所有用户都能正常使用系统功能。
后台Worker预热缓存数据【提前预热】
策略当缓存系统故障后后台Worker可以负责预热缓存数据重新建立缓存以尽快恢复系统的性能。方案通过后台Worker程序根据业务规则和数据特性预热缓存数据尽快恢复系统的性能。
6.3 过期策略【重点】
策略介绍
https://help.aliyun.com/zh/redis/support/how-does-apsaradb-for-redis-evict-data-by-default
volatile-lru默认从已设置过期时间Expire的Key中删除最近最少使用的KeyLRU算法且不会考虑Key是否已经过期。volatile-lfu从已设置过期时间Expire的Key中删除最不常用的KeyLFU算法。volatile-random从已设置过期时间Expire的Key中随机删除一些Key。volatile-ttl从已设置过期时间Expire的Key中根据存活时间TTL从小到大排序进行删除。allkeys-lru从所有Key中删除最近最少使用的KeyLRU算法。allkeys-lfu从所有Key中删除最不常用的KeyLFU算法。allkeys-random从所有Key中随机删除一些Key。noeviction不删除任何Key当内存达到上限时将无法写入新数据数据库会返回错误信息。
数据删除策略
惰性删除主节点在处理读取命令时会检查键是否超时如果超时则执行删除命令并异步发送删除命令给从节点。从节点不会主动删除超时数据而是依赖主节点发送的删除命令。 定时删除Redis主节点通过内部定时任务循环采样一定数量的键当发现采样的键超时时执行删除命令并将删除命令同步给从节点。 当你发现这些内容对你有帮助时为了支持我的工作不妨给一个免费的⭐Star这将是对我最大的鼓励感谢你的陪伴与支持一起在技术的路上共同成长吧点击链接GitHub | Gitee
