一、持久化
RDB:快照
AOF:日志文件存储
| 持久化方式 | RDB | AOF |
|---|---|---|
| 占用存储空间 | 小（数据级：压缩） | 大（指令级：重写） |
| 存储速度 | 慢 | 快 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 会丢失数据 | 依据策略决定 |
| 资源消耗 | 高/重量级 | 低/轻量级 |
| 启动优先级 | 低 | 高 |
RDB与AOF的选择之惑
对数据非常敏感，建议使用默认的AOF持久化方案
AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据。
注意：由于AOF文件存储体积较大，且恢复速度较慢
数据呈现阶段有效性，建议使用RDB持久化方案
数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段点数据恢复通常采用RDB方案
注意：利用RDB实现紧凑的数据持久化回事Redis降的很低
综合对比
RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
如不能承受数分钟以内的的数据丢失，对业务数据非常敏感，选用AOF
如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
灾难恢复选用RDB
双保险策略，同时开启RDB和AOF，重启后，Redis优先使用AOF来恢复数据，降低丢失数据的量
二、集群
1.主从复制
一个master多个slave
2.哨兵模式
在一个master多个slave 加上哨兵，防止master死机重新选举master
3.集群
三、企业级解决方案
1、缓存预热
缓存预热就是系统启动前，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题。用户直接查询事先被预热的缓存数据。
2.缓存雪崩
主要原因：在一个较短的时间内，缓存中较多的key集中过期
3.缓存击穿
主要原因：某个热点key过期，该key的访问量巨大
4.缓存穿透
