目录
方案设计的场景
项目中以redis为主要数据源,所有查询都查询redis以提高程序并发能力。数据库仅做为持久化数据备份,当redis出现宕机情况,可以从数据库中恢复数据。
- 提问:为什么不使用redis自带的持久化文件进行恢复?
- redis持久化策略有两种AOF、RDB,AOF是将每一条操作命令记录到文件中,配置上默认是每秒一次写入文件,AOF文件过大时可以使用rewrite进行指令整理;RDB是redis数据快照,有save和bgsave两种方式生成RDB文件,前者是会阻塞主进程,后者是由主进程fork一个子进程进行异步操作,但相对占用更多的内存资源,但数据过大时还是会导致客户端暂停服务。
- AOF对数据的完整性保存的较好,但AOF文件较大,恢复速度较RDB慢,损失1秒数据;RDB一般做冷备,五分钟或者更长时间进行一次备份,损失数据量较大,但恢复速度快,文件不易较AOF不易损坏。
- 这两种AOF虽然损失一定性能,但数据完整性较好,建议开启;RDB仅在业务闲时进行备份即可。但考虑到我们在业务中使用redis作为类似持久化存储的方案,还是需要完全保证数据完整性,数据库中有完整数据,使用恢复程序,读取数据库再重建redis数据的方式进行恢复。(不过数据库数据可能也会不准,而且数据恢复程序导致开发量增大了,可能在数据结构调整、脏数据清理时程序还是有点用的。)
为了进一步减少对redis的访