redis持久化策略
1、数据文件.rdb
2、更新日志.aof
RDB 详解
redis.conf 文件，找到 SNAPSHOTTING 对应内容
1 RDB核心规则配置（重点）
save <seconds> <changes># save ""save 900 1
save 300 10
save 60 10000
默认开启数据压缩
rdbcompression yes
解说：配置存储至本地数据库时是否压缩数据，默认为yes。Redis采用LZF压缩方式，但占用了一点CPU的时间。若关闭该选项，但会导致数据库文件变的巨大。建议开启。
触发RDB快照
1 在指定的时间间隔内，执行指定次数的写操作
2 执行save（阻塞， 只管保存快照，其他的等待） 或者是bgsave （异步）命令
3 执行flushall 命令，清空数据库所有数据，意义不大。
4 执行shutdown 命令，保证服务器正常关闭且不丢失任何数据，意义...也不大。
通过RDB文件恢复数据
将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。在实际开发中，一般会考虑到物理机硬盘损坏情况，选择备份dump.rdb 。可以从下面的操作演示中可以体会到。
RDB 的优缺点
优点：
1 适合大规模的数据恢复。
2 如果业务对数据完整性和一致性要求不高
缺点：
1 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
2 备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。
所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。
AOF 详解
AOF ：Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
1 redis 默认关闭，开启需要手动把no改为yes
appendonly yes
指定更新日志条件
# appendfsync always
appendfsync everysec# appendfsync no
解说：
always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全）
everysec：出厂默认推荐，每秒异步记录一次（默认值）
no：不同步
配置重写触发机制
auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb
解说：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G，64M太小了。
根据AOF文件恢复数据
正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。从下面的操作演示中体会。
AOF的重写机制
BgRewriteAof异步执行aof文件重写操作，会创建一个当前aof文件的体积优化版本
若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。
缓存渗透
单节点使用双重检测锁
如果你的服务器是一个集群，那么仍然存在不同的服务器同时加载的问题
解决办法是基于远端缓存做个分布式锁，实施起来稍微繁琐一点
如果读数据库时间较长，并且并发进入的请求又比较多，可能会出现线程池满的情况。
另外一个办法就是，有一个异步的任务，在后台自动刷，相当于预热，这样性能肯定是最好的，就是开发上麻烦点。
缓存穿透
是指在缓存里查不到数据，直接查数据库了，如果大并发就会造成缓存雪崩（请求直接到库，可能造成宕机），给两种解决方案：
1、加锁计数，首次查库后存缓存。
2、由于是基于servlet，可以用布隆过滤器。
4.redis中的sorted set
zset由一个dict和skiplist组成，数据结构如下
字典的作用：可以在O(1)时间复杂度内通过对象查找到分值，如zscore命令
跳表的作用：避免每次按分值区间查找（zrange)或者rank（zrank)的时候都要进行排序
值得一提的是，虽然zset使用了dict和skiplist来保存有序集合元素，但这两种数据结构都会通过指针来指向共享的相同元素的成员和分值。
写的比较好
https://www.jianshu.com/p/b8dbd020b43a
resdis跳跃表
