做内存快照就需要考虑两个问题
1. 给哪部分数据做快照?
对全量内存数据做快照,做快照可以使用后台线程执行快照
2. 在快照期间能否有新的数据操作?
当然可以了,如果在rdb期间不能操作数据那是致命性的,
redis使用操作系统提供的写时复制技术,主线程fork子线程,主线程会复制主线程的页表如果主内存数据比较大会比较耗时
然后子线程执行bgsave,
子线程跟主线程使用相同内存区域,bgsave子线程读取主线程内存数据生产rdb文件,
当主线程修改某一数据的时候,生成数据的副本给rdb文件
3. 执行快照的频率怎么才好?
这个需要根据业务需求来说了,比较兼顾的方法是rdb期间使用aof记录
可以设置多长时间内有多少条数据被修改就执行 比如 save 60 10000 60秒内有10000条被修改就执行save等
2核CPU、4GB内存、500G磁盘，Redis实例占用2GB，写读比例为8:2，此时做RDB持久化，产生的风险主要在于 CPU资源 和 内存资源 这2方面
1. 内存资源
因为使用rdb,redis使用写时复制的技术,读的比例占80% 所以会有80%的内存副本被创建意思有1.6G的副本,可能会导致oom
2. cpu资源
因为是2核cpu,一个用来做主线程处理io和读写等操作,后台的其他功能比如aof 或者 rdb同步,会出现线程抢占的问题导致同步或者redis读写效率下降