redis-崩溃如何快速回复-RDB

做内存快照就需要考虑两个问题

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读写效率下降