题目大概是这样:
使用一个2核CPU4GB500G磁盘，Redis实例占用2GB,写读比例为8:2，此时做RDB持久化产生的风险主要在于CPU和内存资源两方面:
1) 内存资源风险: Redis fork子进程做RDB持久化，由于写的比例是80%，那么持久化过程中，"copy-on-write"会重新分配整个实例80%d的内存副本，大约重新分配1.6G内存空间，这样整个系统的内存使用接近饱和，如果此时父进程又有大量的key写入，很快机器的内存
就被吃光，如果机器不开启Swap机制，那么就会OOM,反之如果开启了Swap则性能急剧下降，因为造成了直接和磁盘的IO，达不到Redis原有的高性能标准。
2) CPU资源风险: 虽然子进程在做RDB持久化，但生成RDB快照过程会消耗大量的CPU资源，虽然Redis处理请求是单线程的，但Redis Server还有其他线程在后台工作，例如AOF每秒刷盘,异步关闭文件描述符这些操作，由于机器只有2核CPU,这就意味着父进程占用了超过一半的CPU资源，此时子进程做RDB持久化，可能会产生CPU竞争，导致的结果就是父进程处理请求的延迟增大，子进程生成的RDB快照的时间也会变长，整个Redis Server性能下降。
3)延伸：如果Redis进程绑定了CPU,那么子进程会继承父进程争夺同一个CPU资源，整个Redis Server的性能必然会受到影响，所以如果Redis需要开启定时RDB和AOF重写，进程一定不能绑定CPU。