Redis的持久化之RDB

Redis是基于内存的，必须要考虑的一个问题就是：当redis服务挂了之后，之前的数据怎么重新加载到内存？那么必须要考虑一种存放历史数据的解决方案。

RDB：指定的时间间隔对数据进行快照存储。

假如开始拍快照时间为10：00，整个快照落库持久化完成大概需要5分钟，即10：05此次快照拍完。而在10：04的时候b被改成了5，那么在rdb生成的结果里b是存的4还是5呢？是的，用大腿想也能想到肯定是存的4，但是如果让你来着设计这个RDB持久化怎么去实现呢?

• A方案:使用一个进程阻塞系统,系统拍照的时候我不准用户改动数据，等我快照拍完了你再改。用户肯定不同意。
• B方案:使用一个进程且不阻塞系统，继续让用户改数据，并同时将数据持久化落库，那就意味着一有数据改动就得重新拍照，那这个快照拍到什么时候能生成？此路不通。
• C方案:分叉（fork）一个子进程去把10：00当时那个点的数据a先落库（bgsave），主进程继续为用户服务，当用户改了数据b时，触发copyonwrite 将b的原始引用拷贝给子进程，主线程里的b引用新指向内存里的5。

• RDB的优点
• 适用于灾难恢复，也可以根据需求恢复到不同版本的数据集.
• 与AOF相比,在恢复大的数据集的时候，RDB方式会更快
• 最大化redis的性能，存RBB主进程只管fork子进程。
• RDB的缺点
• 可能会丢失数据
• 虽然fork同步操作非常快，同步大数据量时，fork也会阻塞主进程