redis重点总结
在正常的业务流程中，用户发送请求，然后到缓存中查询数据。如果缓存中不存在数据的话，就会去数据库查询数据。数据库中有的话，就会更新缓存然后返回数据，数据库中也没有的话就会给用户返回一个空。
1.缓存击穿
1.1概念
缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。和缓存雪崩不同的是，缓存击穿是指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。
1.2解决方案
- 设置热点数据永远不过期。（常用
- 加互斥锁，进行排队
2.缓存雪崩
2.1概念
缓存雪崩是指缓存同一时间大面积的失效或者缓存服务器宕机，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。
2.2解决方案
- 缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。（常用
- 一般并发量不是特别多的时候，使用最多的解决方案是加锁排队。
- 给每一个缓存数据增加相应的缓存标记，记录缓存的是否失效，如果缓存标记失效，则更新数据缓存。
3.缓存穿透
3.1概念
缓存穿透是指缓存和数据库中都没有的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉。
3.2解决方案
- 接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
- 从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击
- 采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力
4.主从复制原理
实现主从复制 ( Master-slave Replication)的工作原理 :
- slave从节点服务启动并连接到Master之后，它将主动发送一个SYNC命令
- Maser服务主节点收到同步命令后将启动后台存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后。Mastr将传送整个数据库文件到Slave，以完成一次完全同步
- 而slave从节点服务在接收到数据库文件数据之后将其存盘并加载到内存中
此后，Master主节点继续将所有已经收集到的修改命令，和新的修改命令依次传送给Slaves，slave将在本次执行这些数据修改命令，从而达到最终的数据同步。
如果Master和Slave之间的链接出现断连现象，Slave可以自动重连Master，但是在连接成功之后，一次完全同步将被自动执行。
5.Redis持久化
Redis是基于内存存储的nosql数据库 但是也可以持久化数据到硬盘当中
redis有两种持久化方式，分别是 rdb 和 aof
5.1rdb
rdb的触发方式分为两种：自动触发、手动触发
优点：存储的数据是按照二进制形式进行存储，比较紧凑，存储和恢复都比较快
缺点：当进行存盘的时候，在存盘开始到存盘完成的这段时间的数据，并没有立即的持久化到硬盘当中，如果服务器宕机，就可能发生数据丢失。
5.1.1手动触发
rdb在手动触发当中呢，使用的主要是save和bgsave命令。
1.save
save命令执行后，会阻塞当前服务器，知道RDB完成为止，但是当你数据量大的时候，就会出现造成过长时间的阻塞
2.bgsave
bgsave命令执行后，Redis的主进程就会fork一个子进程来完成RDB的过程，完成后自动结束。所有使用bgsave时，造成主进程阻塞的时间只为fork阶段的那一下。与save相比，阻塞时间短。
5.1.2自动触发
场景一：可通过配置redis.conf文件，定义触发规则使得rdb自动执行
比如 save 900 1 表示 在900s内，至少执行了一次写操作，就会自动触发bgsave
场景二：在执行shutdown命令时，如果没有开启AOF持久化功能，那么就会自动执行一次bgsave
场景三：主从同步（master和slave建立同步机制
5.2aof
aof的触发方式也分为 自动触发和手动触发
优点：aof存储中，数据丢失的少，精准度高
缺点：存储的文件越来越大 需要瘦身 恢复数据也慢
5.2.1手动触发
执行 bgrewriteaof命令。 该命令会使主进程 redis-server 创建出一个子进程 bgrewriteaof，由该子进程完成 rewrite过程。而在 rewrite 期间，redis-server 仍是可以对外提供读写服务的。
5.2.2自动触发
修改配置文件
首先指定aof文件的名称。
AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。
5.3AOF与RDB对比
- RDB快照的存储是全量存储，每次执行时，会将数据以二进制流的方式全部存储到硬盘当中。
- AOF是增量存储，他存储的是数据库中每次进行数据修改时的命令，将命令以增量的方式存储在硬盘当中。他的恢复也是将命令从头到尾执行一遍进行恢复。
在Redis 4.0版本后采用混合模式
在正常的存储过程中采用RDB快照的方式，而当RDB执行时，采用AOF存储，这样既提高了数据存储和恢复的效率，也减少了丢失的数据（并不是不会丢失）。
6.Redis的key过期策略
过期策略通常有以下三种
- 定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。
- 惰性过期：只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。
- 定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。
7.Redis的内存淘汰机制
Redis的内存淘汰策略是指在Redis的用于缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据。
全局的键空间选择性移除
- noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。
- allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。（这个是最常用的）
- allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。
设置过期时间的键空间选择性移除
-
volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。
-
volatile-random当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。
的键空间选择性移除 -
volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。
-
volatile-random当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。
-
volatile-ttl当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。
