Redis持久化：
Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以Redis提供了持久化！
RDB（Redis DataBase）
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是SnapShot快照，它恢复时是将快照文件直接读到内存里。
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了。再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何io操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效，RDB的缺点是最后一次持久化的数据可能丢失。我们默认的就是RDB，一般情况下不需要修改这个配置！
触发机制：
1.save的规则满足的情况下，会自动触发RDB规则
2.执行flushall命令，也会触发我们的RDB规则
3.退出redis，也会产生rdb文件
4.备份就自动生成一个dump.rdb
AOF（Append Only File）
将我们的所有命令都记录下来,history,恢复的时候就把这个文件全部执行一遍！
以日志的形式来记录每个写操作。将redis执行过的所有指令记录下来，只许追加文件，但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的化就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
优点：
1.每一次修改都同步，文件的完整会更加好！
2.每秒同步一次，可能会丢失一秒的数据
缺点：
1.相对于数据文件来说，aof远远大于rdb，修复的速度也比rdb慢！
2.aof运行效率也比rdb慢，所以我们redis默认的配置就是rdb持久化。
扩展：
同时开启两种持久化方式：
在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下aof文件保存的数据集要比RDB文件保存的数据集要完整。
RDB的数据不实时，同时使用两者时服务器重启也只会找aof文件，那要不要只使用aof呢，作者建议不要，因为RDB更适合用于备份数据库（aof在不断变化不好备份）,快速重启，而且不会有aof可能会有bug,可以留着作为一个万一的手段.
性能建议
因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留 save 900 1 这条规则。
如果Enable AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite 的最后将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。
如果不Enable AOF ，仅靠 Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构。
Redis缓存
考虑的问题就是：缓存穿透、缓存击穿与失效时的雪崩效应
缓存穿透
缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要存储层去查询，失去了缓存的意义。
在大流量时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。
解决方案
有多种方法可以有效的解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存储的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被bitmap拦截掉，从而避免了对底层系统的查询压力。
另外也有一个更有简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。
缓存雪崩
缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一个时刻同时失效，请求全部转发到DB,DB瞬时压力过重雪崩。
解决方案
Redis高可用
这个思想的含义是：既然·redis有可能挂掉，那我多增设几台redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。
缓存失效时的雪崩效应对底层系统的冲击非常可怕，大多数系统设计这考虑用加索或者队列的方式保证缓存的单线程写，从而避免失效时大量的并发请求落到底层存储系统上。
这里分享一个简单方案就是将缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
限流降级
这个解决方案的思想是：在缓存失效后，通过加索或者队列来控制读数据库写缓存的线程数量，比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
缓存击穿
对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的去呗在于这里针对某一个key缓存，前者则是很多key。
缓存在某个时间点过期的时候，刚好在这个时间点对这个key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回射缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
解决方案：
设置热点数据永不过期
从缓存层面，没有设置过期时间，所以不出现热点key过期后产生的问题。
加互斥锁：
分布式锁：使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待即可，这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。
