Redis持久化机制（保证Redis挂掉后再重启数据可以进行恢复）
Redis支持两种持久化操作。
一种是持久化快照(snapshotting,RDB)
一种是只追加文件(append-only file,AOF)
1、快照 snapshotting 持久化(RDB） 缺点：两次持久化时间太长。
Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本，Redis创建快照后，可以对快照进行备份，可以将快照复制到其他服务器从而具有相同数据的服务器副本（Redis主从结构，主要用来提高Redis性能），
还可以将快照留在原地以便重启服务器的时候使用。
快照持久化Redis默认采用持久化方式，在redis.conf配置文件中默认有以下配置：
save 900 1 #同下
save 300 10 #在300秒后，如果有10个key变化，自动触发BGSAVE命令创建快照。
bgsave开始fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据写入RDB文件。
（linux系统中用户态是无法直接操作物理内存，操作系统会分配一个虚拟内存，来映射物理内存）
2、AOF（append-only file）持久化 优点：数据更完善。
与快照持久化相比，AOF持久化实时性更好，是主流持久化方案。默认redis是没有开启的AOF。
在redis.conf中配置appendonly yes
开启AOF持久化以后，执行一条会更改Redis中的数据命令，Redis会将该命令写入到内存缓存server.aof_buf中
然后根据appendsync配置决定什么时候同步到硬盘的AOF文件中。
AOF文件的保存位置和RDB文件位置相同，都是通过dir参数设置，文件默认名是appendonly.aof。
every sec是默认。
bgrewriteaof,可以让Aof执行重写功能，达到最少命令的效果。
Redis bigkey
如果一个key对应的value所占的内存比较大，那么这个key可以看做bigkey，
一般来说：具体String类型的value超过10kb,复合类型的value包含元素超过5000个。
复合类型（不一定包含的元素越多，占用的内存就越多）
bigkey有什么危害？
除了会消耗更多的内存空间，bigkey对性能也有比较大的影响。
1、发现bigkey？
redis-cli -p 6379 --bigkeys 来查找
2、分析RDB文件
前提是要持久化了RDB文件。