Redis知识

redis

支持高性能。高并发。使用缓存比读取数据库速度快，吞吐量高。数据存在内存中，读写速度快。缓解数据库压力。

分布式缓存

分布式缓存只要解决的是单机缓存的容量受服务器限制，并且无法保存通用的信息。

redis单线程模型

客户端基于socket连接redis的文件时间处理器，通过io多路复用程序将连接压入队列中。

为什么redis单线程还能支撑高并发

底层基于非阻塞的io多路复用机制，将连接压入队列，实际上是同步转异步操作，所以支持高并发。

纯内存操作，效率高。

单线程反而避免了多线程频繁切换上下文的操作。

redis存储的数据类型

String

hash 存对象（支付报文）

list 有序（好友列表）

set 无序，去重（去重，交集共同好友）

sorted set 有序 ，去重（排行榜）

redis设置过期时间

redis对超过过期时间的数据是如何删除的：定期删除+惰性删除，所以过期的key是不一定会被删除。

定期删除:默认每隔100ms就随机抽取一些设置了过期时间的key去删除。

惰性删除：查未删除的key，才会被删除。

内存淘汰机制：8中淘汰策略，根据业务需求自行选择。（4.0版本后增加2个）

redis如何实现高并发

设置主从架构，读写分离，主写从读，读的QPS会很高，因为一般写操作比读少很多。

高并发并且存储大量数据：redis集群

redis主从架构

master同步写，slave异步同步到其他机器，支持横向扩容，提高读的吞吐量。

如果采用主从架构，必须设置master node的持久化，不然宕机后，会清空slave的所有数据。

redis主从复制原理

启动一个slave时，先发送一个PSYNC命令给master，确认可以通信，如果是第一次连接，则master会将数据全量复制给slave，master会在后台启动一个线程，生成一个RDB快照文件发送给slave。

支持断点续传，无磁盘化复制，过期key处理（slave不会过期key，等master命令来del数据）

redis如何保证高可用性

主备切换，当master宕机，自动检测，将某个slave自动切换为master。–由哨兵完成sentinal

redis哨兵模式

集群控制：监控redis进程是否正常工作

消息通知：发现故障后，通知消息

故障转移：发现master故障后，进行主备切换

配置中心：主备切换后通知client新的master地址

哨兵需要至少3个实例，确保健壮性。

哨兵参数

quorum：配置至少需要几个哨兵认为master宕机就可以进行主备切换

majority：主备切换之前还需要其他哨兵选举，2个哨兵majority=2，所以2两哨兵只剩一个的情况下，不能进行主备切换

哨兵核心机制

sdown和odown的转换机制

哨兵和slave集群的自动发现机制

slave配置的自动纠正

主备切换master的选举算法：slave的priority（权重）设置越低，优先级越高，offset越多，优先级越高，runid越小，优先级越高

redis哨兵主备切换造成的数据丢失问题

异步复制：master还没将数据同步之前宕机，造成数据丢失

脑裂问题：网络分区，故障，master与其他slave网络断开，形成两个master，网络恢复后，原master数据丢失。

解决方法：

min-slaves-to-write 1

min-slaves-max-lag 10

表示至少有1个slave，数据复制和同步的延迟不能超过10秒，否则master停止接受请求，减少丢失的数量。客户端可能会实行容灾机制，进行降级，将缓存写入本地缓存或者存入mq中。

redis持久化机制

默认方式–RDB快照：备份副本，将副本保存在其他服务器上，或者保存在本地，以便重启服务器的时候使用。

AOF只追加文件：实时性更好，每执行一条更改redis数据的命令，就将该命令写入硬盘的AOF文件。当文件中存放的指令大于redis中实际存在的数据量时，rewrite机制会重写新的AOF文件，删除旧AOF。

4,0版本后支持双机制混合持久化，默认关闭。AOF重写时直接把RDB内容写入AOF文件开头，但可读性比较差。

RDB和AOF的区别

RDB：优点：redis控制，一定周期时间，生成多个快照文件，适合做冷备份。

对redis性能影响比较小。

重启和恢复数据更快。

缺点：实时性比较差，可能会丢失数据，因为是周期性生成的。不适合做第一优先恢复方案。

若RDB间隔时间设置太长，每次生成RDB的文件太大，会影响redis性能。

AOF：优点：实时性比较好，1s便会同步一次，最多丢失1s的数据。

缺点：数据恢复比较慢，做冷备比较麻烦，需要手写脚本。

如何选择：我全都要。

缓存雪崩和缓存穿透

雪崩：缓存同一时间大面积失效，之后请求都落到数据库中，造成数据库短时间接收大量数据崩掉。

解决方案：发生前：保证redis集群的高可用性，发现机器宕机尽快补上，选择合适的内存淘汰机制。

发生中：本地ehcache缓存+hystrix限流&降级，避免mysql崩掉。

发生后，利用redis持久化机制保存的数据尽快恢复缓存。

穿透：大量请求缓存中不存在的key，导致直接请求数据库，不经过缓存这一层。导致数据库崩掉。

解决方案：做好参数校验。

缓存无效key：但如果每次不同的key请求，不能从根本上解决问题。若用此方法，尽量将无效key超时时间设置短一点。

布隆过滤器：判断一个给定的数据是否存在于海量数据中。需要把所有可能存在的值放入布隆过滤器中。

解决redis并发竞争key

分布式锁，zk和redis都可以实现，推荐zk。

缓存+数据库读写模式

cache aside pattern

先读缓存，没有的话，再读数据库，取出数据后放入缓存，同时返回。

更新时，先删除缓存，再更新数据库。（懒加载，等查询一次后再放入缓存）

怎么保持缓存和数据库双写时数据一致性

更新时，先删除缓存，再更新数据库

读请求和写请求串行化，串到一个内存队列中，这样可以保证数据一致性。

redis集群

redis cluster（多master+读写分离+高可用）支持海量数据，可以横向扩展master.主备切换原理和哨兵模式类似.

单机:一个主从+哨兵集群

数据分布算法

hash:一个master挂掉之后,会导致所有key找不到原有的master,导致缓存穿透,mysql被查挂.

hash一致性算法(圆环顺时针寻找法):一个master挂掉之后,会导致1/N个key找不到对应master.热点数据解决:每个master中间插入许多虚拟节点,使数据均匀分布.

hash slot:对固定的16384取模,将16384均匀分布在各个master中,若一台宕机,则将此机器的slot均匀分配给其他机器,避免缓存穿透问题.

redis cluster维护集群协议

gossip:小道留言,每个master都存有一份元数据,(hashslot与节点的映射关系,master-slave关系,故障信息等),不同节点出现了元数据的变更,则不断将元数据变更同步给其他节点.

zookeeper:集中式存储元数据.

redis分布式锁

setnx方法
redission实现