一、redis是用C语言开发的一个开源的高性能键值对内存数据库，可用作数据库、缓存、消息代理：
性能优秀，读写速度非常快；线程安全；丰富的数据类型；支持数据持久化；
高性能：执行耗时久且结果不经常变动的sql，将结果放进缓存，查询时间短。
经典场景是：电商平台，某个产品一天之内信息都不变，但每次查询耗时2S（放进缓存可能就是每次2ms），一天内100万次浏览；
高并发：redis缓存作为缓冲，支持高性能的主从复制的集群策略。MySQL并不好支持高并发，单机最多支撑到2000qps，而缓存单机支撑的并发量一秒几万十几万，是MySQL的几十倍并发量。；
可用作分布式锁，功能可用其他中间件替代（如zookeeper）
redis内部使用一个redisObject对象表示所有key和value。redisObject包含type(表示一个value对象具体是何种数据类型)、encoding（表示不同数据类型在redis内部的存储方式）
1、redis五种主要的数据类型：String、Hash、list、set、sortedSet有序集合
（1）String是redis最基本类型，二进制安全故redis的string类型可包含任何数据，例如jpg图或者序列化的对象，简单的set/get；
（2）Hash是一个键值（key-value）集合，redis的hash是一个string的key和value的映射表，适合存储对象，常用命令hget、hset、hgetall；
（3）list列表是简单的字符串列表，按照插入顺序排序（有序且可重复）。
1 可做粉丝列表：key=某大V，value=[张三、李四、王五]
2可做文章的评论列表
3通过lrange命令，从某个元素开始读取多少个元素，可基于list实现分页查询。基于redis实现简单的高性能分页，做类似微博下拉不断分页的东西，性能高
4 做简单的消息对列，从list头放进去，从list尾巴拿出来
常用命令：lpush、lpop、rpush、rpop、lrange(获取部分列表)。redis的list的实现是双向链表
（4）set是string的无序集合，通过hashtable实现。set中元素无序且不重复。
做交集、并集、差集操作，比如交集可以是两个人的共同微博粉丝
常用命令sadd、spop、smembers、sunion
（5）sortedSet与set的区别就是有序，常用命令zadd、zrange、zrem、zcard。
sortedSet关联了一个double类型权重的参数score，redis就是通过score来为集合中的成员进行从小到大排序。
sortedSet内部使用hashmap和跳跃表skipList来保证数据的存储和有序，hashmap放的是成员到score的映射，跳跃表放的是所有成员，排序依据是hashmap里存的score，跳跃表查询效率高，实现简单：
做排行榜：zadd board 命令，是给score的
zadd board 85 张三
zadd board 90 王五
zadd board 80 李四
zrevrange board 0 99 获取排名前100的用户
zrank board 李四 可看到用户在排行榜里的排名
2、redis的架构模式：
（1）单机版：多个客户端对应一个redis服务器，特点是简单，但是内存容量有限，处理能力有限，无法高可用，不支持高并发；
（2）主从复制：多个从redis服务器从一个主redis服务器拷贝数据，多个客户端从从redis服务器get数据（也可从主redis服务器get），从服务器仅提供读操作，主服务器提供写操作。
优点：用户从主redis服务器复制多个从redis服务器，两者数据相同，主服务器更新数据到从服务器，降低了主服务器的读压力，再转交从库
缺点：未解决主服务器的写压力
注：关于主从架构的，文章后面有详细的说明，请直接移步文章末尾
（3）哨兵：监听主节点的存活状态，如果主节点挂掉，从节点能继续提供缓存功能（主从节点结合哨兵模式能解决单点故障问题，提高redis可用性）
（4）集群（proxy型）
3、redis怎么用
结合springboot使用，一种是通过RedisTemplate使用，另一种是使用spring cache集成Redis（注解的方式）
redis注解：
@cacheable根据方法的请求参数对其结果进行缓存 @cacheable(value = ""，key = "")
@cacheable（value=“user”，key="#id"）
public User getUser(int id){
return xxxmap.get(id);
}
@cachePut，与@cacheable作用一样，不同的是它每次都会出发真实方法的调用@cachePut（value=“”，key=""）
@cachePut（value=“user”，key="#user.id"）
public User saveUser(User user){
return user;
}
@cacheEvict 根据条件对缓存进行清空@cacheEvict（value=“”，key=""）
@cacheEvict（value=“user”，key="#id"）
public void deleteUser(int id){
removeUser( id );
}
二、使用redis有什么缺点？
1、缓存与DB双写一致性问题：分布式环境下非常容易出现缓存与数据库间数据一致性问题
我们只能采取合适的策略去降低缓存与数据库间数据不一致的概率，而无法保证两者间的强一致性
（1）有强一致性要求的数据，不要用缓存
（2）采取正确更新策略，更新数据库后及时更新缓存，或者先更新DB再删缓存，删缓存失败可提供补偿，用消息队列
2、缓存雪崩：即缓存在同一时间大面积失效，这时来了一拨请求，全怼到DB上导致DB连接异常
解决办法就是，方法1：在往redis存数据的时候，设置缓存的失效时间加一个随机值，避免集体失效
方法2 ：若redis是集群部署，将热点数据均匀分布在不同redis库中，也能避免全部失效，或者设置热点数据永不过期，有更新操作就更新缓存就好了
方法3： 建立备份缓存，缓存A和缓存B，A设置超时时间B不设置，先从A读缓存，A没有读B并且更新A，B
雪崩实际出现的场景：电商，定时午夜12点刷新缓存（即设置的缓存失效时间是午夜12点），但是12点有个秒杀活动，活动开始时大量用户涌入但缓存失效了，所有请求全怼到数据库上了，DB挂了
3、缓存穿透：即请求数据库和缓存中不存在的数据，导致所有请求到DB上，从而DB连接异常
解决办法1：接口层增加校验，比如用户鉴权，参数做校验，不合法的直接return，比如id<=0的直接拦截
解决办法2：redis里的布隆过滤器，利用高校的数据结构和算法快速断定你这个key是否在数据库中，不存在则return，存在就去查DB刷新KV再return
4、缓存击穿：与雪崩有点像，某个key是热点，大量请求同时访问它，在这个key失效的瞬间，持续的大并发直接落到数据库上，在key这个点上击穿了缓存
解决办法：设置热点数据永不过期，或者加上互斥锁
使用互斥锁(mutex key)
业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。
SETNX，是「SET if Not eXists」的缩写，也就是只有不存在的时候才设置，可以利用它来实现锁的效果。
public String get(key) {
String value = redis.get(key);
if (value == null) { //代表缓存值过期
//设置3min的超时，防止del操作失败的时候，下次缓存过期一直不能load db
if (redis.setnx(key_mutex, 1, 3 * 60) == 1) { //代表设置成功
value = db.get(key);
redis.set(key, value, expire_secs);
redis.del(key_mutex);
} else { //这个时候代表同时候的其他线程已经load db并回设到缓存了，这时候重试获取缓存值即可
sleep(50);
get(key); //重试
}
} else {
return value;
}
}三、单线程redis为什么这么快？
redis是单线程工作模型。快的原因是1 纯内存操作 2、单线程操作，避免经常的上下文切换 3、采用非阻塞I/O多路复用机制
1、纯内存操作：redis将所有数据放在内存中，是不需要从磁盘读取数据，0次IO。
2、单线程操作：（1）简化了算法实现 （2）避免了线程切换和加锁释放锁带来的消耗。（3）缺点是阻塞，若一个命令执行时间过长，会造成其他命令的阻塞。
3、非阻塞I/O多路复用机制：I/O多路复用实际上是指多个连接的管理可以在同一进程，多路是指多个网络连接，复用的是同一个线程。在网络服务中，I/O多路复用起的作用是一次性把多个连接的事件通知业务代码处理，处理方式由业务代码决定。
pS：I/O多路复用机制涉及到了redis的线程模型，这里扩展一下：
redis的线程模型
（1）文件事件处理器file event handler(单线程模式运行，redis基于reactor模式开发的网络事件处理器)：
采用IO多路复用机制同时监听多个socket，并将socket放入一个队列中，每次从队列中取一个socket给事件分派器来处理（并行访问-->串行访问）
文件事件处理器包括：多个socket、IO多路复用程序、文件事件分派器、事件处理器
（2）文件事件：
1 当socket变得可读时，比如客户端对redis执行write操作或close操作，或者有新的可以应答的socket出现（客户端对redis执行connect操作），socket会产生一个AE_READABLE事件；
2 当socket变得可写时（客户端对redis执行read操作），socket会产生一个AE_WRITABLE事件；
3 IO多路复用程序同时监听AE_WRITABLE和AE_READABLE两种事件，若一个socket同时产生了这两种事件，文件事件分派器优先处理AE_READABLE事件
（3）文件事件处理器：若是客户端要连接redis，那么会为socket关联连接应答处理器；
若是客户端要写数据到redis，那么会为socket关联命令请求处理器；
若是客户端要从redis读数据，那么会为socket关联命令回复处理器；
四、redis的过期策略及内存淘汰机制（过期策略和内存淘汰机制是要结合使用的，才能保证过期的key全部删除干净）
设置了过期时间的数据，并不一定到时间了就立马会被删除，只是数据过期了，要根据redis的淘汰策略来看
1、redis采用定期删除+惰性删除策略：
定期删除是随机检查设了过期时间的key，来删除
惰性删除是，当你查询某个key时，redis检查一下，过期了就删除
2、redis的淘汰策略有7种（redis4加了一种访问频率最少，最不经常使用的KV淘汰），推荐allkeys-LRU最近最少使用淘汰策略：
已设置过期时间中有三种策略：1最近最少使用less recently use的数据淘汰、2剩余时间最短time to live的数据淘汰、3随机选择数据淘汰
4从所有KV 中对最近最少使用的数据淘汰、
5从所有KV中随机淘汰、
6不淘汰策略，若超过最大内存额返回错误信息、
7通过统计访问频率，将访问频率最少的也就是最不经常使用的KV淘汰
另：LRU算法的实现：继承LinkedHashMap，构造方法据给定初始化大小调用super方法，并重写删除最老entry数据方法
public class LRUCache<k,v> extends LinkedHashMap<k,v>{
private final int CACHE_SIZE;
public LRUCache( int cacheSize){
super( (int)Math.ceil( cacheSize / 0.75) + 1 , 0.75f， true)；
//设置一个hashmap的初始大小，同时最后一个true指的是让LinkedHashMap按照访问顺序来进行排序，最近访问的放在头，最早访问的放在尾
CACHE_SIZE = cacheSize；
}
@override
protected boolean removeEldestEntry(){
return size() > CACHE_SIZE;
//当map中的数据量大于指定的缓存个数时，自动删除最老的数据
}
}
阿里云redis开发规范解读
-------开始-----
1、key命名设计：可读性、可管理性、简洁性
规范建议使用冒号进行分割拼接，因为很多redis客户端是根据冒号分类的： apps:app:1、apps:app:2、apps:app:3
2、value设计：拒绝bigkey
规范建议String类型的value控制在10kb范围内，因为redis随着value不断增长，在超过10kb后，性能明显下降
3、控制key的生命周期：设定过期时间
尽可能对每个Key都设置过期时间
4、时间复杂度为O（n）的命令需要注意N的数量
以list为例，元素数量越多，命令的性能越差，而redis 是单线程的，若出现一个慢命令，会导致之后的命令耗时增长。这也是jdk1.8对hashmap进行链条冲突优化：当entry数量不少于64时，如果冲突链表长度达到8，会将其转化为红黑树，因为链表长度越长，性能越差。
5、禁用命令：KEYS、FLUSHDB、FLUSHALL等
这些命令在搭建redis环境的时候就应该禁用掉（在config配置文件中通过rename-command禁用）。
FLUSHDB、FLUSHALL这两个命令是会删库数据的
6、推荐使用批量操作提升操作效率
批量命令包括原生命令（mget、mset、hmget、hmset、LPUSH key value）、非原生命令（Pipeline）
7、monitor命令控制使用时间
monitor命令一般是用来观察redis服务端都在执行哪些命令并实时输出。规范建议控制monitor命令的使用时间，是因为随着monitor命令的执行时间越长，越多数据积压在输出缓冲区，从而导致输出缓冲区占用内存越来越大
-----结束-----
一、redis与memcached的区别（为什么选择redis而不用memcached）/mem ca qu/
1、存储方式：memcache把数据全部存在内存中，断电就会挂掉，数据不能超过内存大小，而redis部分数据会存在磁盘上，能保证数据持久性
2、支持的数据类型：memcache只支持简单的key-value，redis支持五种数据类型
3、value大小：redis可以达到1GB，而memcache只有1MB
4、redis内存使用率比memcached高，由于其组合式的压缩，采用hash结构来做k-v存储；
5、性能上，redis只使用单核，每一个核上redis在存储小数据时比memcached性能更高，而memcached可使用多核，在大数据量时比redis性能高；
6、集群模式：memcached原生不支持集群模式，redis目前是支持原生cluster集群模式的；
二、redis的主从架构
1、redis不能支撑高并发的瓶颈是单机，qps大概上万到几万不等，所以要用集群的缓存架构
2、redis要支撑超过10万+的高并发要怎么做？
解决方案就是读写分离，一般来说，对缓存一般都是用来支撑读高并发的，写的请求是比较少的。
此处读写分离，就是用主从架构，一主多从，主负责写并同步数据到从节点（是异步同步数据的），从节点提供读操作
3、redis replication 以及master持久化对于主从架构的安全意义
redis replication --> 主从架构 --> 读写分离 --> 水平扩容支撑读高并发
（1）图解redis replication 基本原理
（2）redis replication核心机制：
1 redis 采用异步方式复制数据到slave节点，redis 2.8开始，slave节点会周期性地确认自己每次复制的数据量
2 一个master节点可配置多个slave节点
3 slave node 也可以连接其他slave node
4 slave node做复制时，是不会阻塞master node正常工作的
5 slave node复制时，也不会阻塞对自己的查询操作，它会用旧的数据集来提供服务。复制完成时，需要删除旧数据集，加载新数据集，这时就会暂停对外服务。
6 slave node 主要用来进行横向扩容，做读写分离，扩容的slave node可提高读的吞吐量
（3）master持久化对于主从架构的安全保障的意义
主从架构，必须建议开启master node的持久化
不建议用slave node作为master node的数据热备，因为如果关掉master的持久化，可能在master宕机重启时，数据是空的，然后一经复制，slave node的数据也丢了。
即使采用了高可用机制，slave node可自动接管master node，但是也可能哨兵sential还没检测到master失败了，master node就自动重启了，还是可能导致上面的所有slave node数据清空故障。
4、redis 主从架构
***redis高并发：主从架构，一主多从，主写从读，单机几万QpS，数据量很大就要用redis集群；
***redis高可用：主从架构部署，加上哨兵，就可实现任一实例宕机，自动进行主备切换。
（1）主从架构的核心原理
当启动一个slave node时，它会发送一个psync命令给master node。
如果这是slave node重新连接master node，那么master node仅仅会复制给slave node部分缺少的数据。
否则，会触发一次full resynchronization(全量复制)，开始时master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕后，master会将这个RDB文件发给slave，slave会先将RDB文件写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。（整个过程涉及RDB文件和写命令两部分数据）
slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份RDB数据服务所有slave node。
（2）主从复制的断点续传
redis2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断了，那么可以接着上次复制的地方，继续复制，而不是从头重新复制。
master node会在内存中维护一个backlog，master和slave都会保存一个replica offset还有一个master id。
offset就是保存在backlog中的，如果master和slave网络连接断了，slave会让master从上次的replica offset开始继续复制，但是如果在backlog中没有找到对应的offset，就会执行一次resynchronization
（3）无磁盘化复制：master在内存中直接创建RDB，发送给slave，不会在自己本地落地磁盘了。
repl-diskless-sync no ,默认是no的，默认不进行无磁盘化复制，修改为yes则会
repl-diskless-sync-delay 等待一定时长再开始复制，因为要等更多的slave重新连接过来
（4）过期key处理：
slave不会过期key，只会等待master过期key
如果master过期了一个key，通过LRU淘汰了一个key，会模拟一条del命令发送给slave。
主从复制：从节点仅提供读操作，主节点提供写操作，对于读多写少的状况，给主节点配置多个从节点可提高响应效率
主从复制的完整流程：
（1）、slave node执行slaveof[ masterIP ][ masterPort ]保存主节点信息：
slave node启动，仅保存master node的信息，包括master node的host和IP，但是复制还没开始。master的host和IP是redis.conf里面的slaveof配置的
（2）、slave node从节点的定时任务发现主节点信息，建立和主节点的socket连接：
slave node内部有个定时任务，每秒检查是否有新的master node要连接和复制，如果有，就建立socket连接
（3）、从节点发送Ping信号，主节点返回Pong，两边能相互通信
口令认证，如果master设置了requirePass，那么slave node必须发送masterauth的口令过去认证
（4）、连接建立后，主节点第一次执行全量复制，将所有数据发送给从节点（数据同步）
（5）、主节点把当前的数据同步给从节点后，便完成了复制的建立过程。接下来主节点会持续的把写命令异步发送给从节点，保证主从数据一致性；
对第（4）点的补充说明：
----开始----
数据同步相关的核心机制：第一次slave连接master时，执行全量复制的细节机制
- （1）master和slave都会维护一个offset：master会在自身不断累加offset，slave也会在自身不断累加offset。slave每秒都会上报自己的offset给master，同时master会保存每个slave的offset（不是特定用在全量复制的）
- （2）backlog：master node有一个backlog，默认1MB大小。master给slave复制数据时，会将数据同步一份在backlog中。backlog主要是用来做全量复制中断后的增量复制的（断点续传）
- （3）master run id：info server命令，可以看到master run id
- 如果根据host+IP定位master node是不可靠的。因为如果master node重启或数据出现了变化，那么slave应该根据不同的run id区分，run id不同就要做全量复制，如果需要不更改run id 重启redis，可用redis-cli debug reload
- （4）psync：从节点使用psync从master node进行复制，psync runid offset
- master会根据自身的情况返回响应信息，可能是FULLRESYNC runid offset促发全量复制，可能是CONTINUE触发增量复制。
全量复制：
- （1）master执行bgsave，会在本地生成一份RDB快照文件
- （2）master node将RDB快照文件发送给slave node，若RDB复制时间超过60s（repl-timeout），那么slave就认为复制失败，可适当调大这个参数
- 对于千兆网卡的机器，一般每秒传输100MB，6G文件很可能超过60S
- （3）master在生成RDB时，会将所有新的写命令缓存在内存中，在slave保存了RDB后，再将新的命令复制给slave
- client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区（就是前面缓存新的写命令的地方）持续消耗超过64MB或者一次性超过256MB，那么停止复制，复制失败
- （4）slave node 接收到RDB后，清空自己的旧数据，然后从磁盘中重新加载RDB到自己的内存中，同时基于旧的数据版本对外提供服务
- （5）如果slave开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF文件
如果复制的数据量在4-6G之间，很可能全量复制时间消耗到1分半到2分钟
增量复制：
- （1）如果全量复制过程中，master-slave网络连接中断，那么slave重连master时，会触发增量复制
- （2）master直接从自身的backlog中获取部分丢失的数据，发送给slave，默认backlog就是1MB
- （3）master就是根据slave发送的psync中的offset来从backlog中获取数据的（可参考“数据同步相关的核心机制”的第（4）点）
heartbeat：
主从节点互相都会发送heartbeat信息
master默认每隔10秒发送一次heartbeat，slave每隔1秒发送一个heartbeat
异步复制： master每次接收到写命令后，先在内部写入数据，然后异步发送给slave
----结束----
主从复制的问题：
（1）、一旦主节点宕机，从节点晋升为主节点，同时需要修改应用方的主节点地址，还要命令所有从节点去复制新的主节点，整个过程需要人工干预；
（2）、主节点的写能力、存储能力受到单机的限制
问题1 的解决方案是核心在于提高redis主从架构下的高可用性（主节点挂掉了，如何保证系统仍能接续使用？（slave节点挂掉是不会影响可用性的））：
使用 哨兵sentinal node：redis高可用架构，叫做故障转移，也可叫做主备切换。在master node故障时，自动检测，并将某个slave node自动切换为master node的过程叫做主备切换，实现redis主从架构下的高可用性。
（5）哨兵介绍
- 1 功能包括 主节点存活检测、主从运行情况检测、自动故障转移、主从切换（也叫主备切换）
集群监控：不断检查主、从服务器是否正常运行（监控master和slave进程是否正常工作）
消息通知：被监控的某个redis实例有故障，哨兵会通过API脚本向管理员或者其他应用程序发出通知
自动故障转移：当主节点不能正常工作时，哨兵会开始一次自动的故障转移操作，将与失效主节点是主从关系的其中一个从节点升级为新的主节点，并将其他从节点指向新的主节点，避免了人工干预
配置提供者：哨兵模式下，客户端应用在初始化时连接的是哨兵节点集合，从中获取主节点信息。故障转移发生后，通知client客户端新的master地址。
- 2 哨兵本身也是分布式的，作为一个哨兵集群去运行，协同工作：
故障转移时，判断一个master node是否宕机了，需要大部分哨兵都同意才行，涉及到了分布式选举的问题；
即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的。
目前采用的sentinal 2 版本，主要是让故障转移的机制和算法变得更加健壮简单。
（6）哨兵核心
- 1 哨兵集群至少需要3个实例，来保证自己的健壮性；
- 2 哨兵+redis主从的部署架构，只能保证redis集群的高可用性，不能保证数据0丢失；
- 3 哨兵+redis主从的架构，尽量在测试环境和生产环境都进行充分的演练；
（7）为什么redis哨兵集群只有2个节点无法正常工作？
前提：哨兵集群必须部署2个以上节点。
若仅部署了2个哨兵实例，quorum = 1
configuration ： quorum = 1
master宕机，s1和s2中只要有一个哨兵认为master宕机就可以进行切换（参数quorum决定在认为master宕机时需要几个哨兵认可，若quorum=2时，即要有2个哨兵认为master宕机才能进行切换），同时s1、s2中会选举出一个哨兵来执行故障转移
同时这个时候，需要majority大多数哨兵都是运行的，2个哨兵的majority就是2（3的majority=2,4的majority=2,5的majority=3），2个哨兵都运行着，就可以允许执行故障转移。但是如果整个m1和s1所在的机器宕机了，那么哨兵只有一个了，此时就没有majority来允许执行故障转移了，虽然还有一台机器还有一个R1，但是故障转移不会执行。
（8）经典的3节点哨兵集群
configuration： quorum = 2，majority=2
如果M1所在机器宕机了，那么还剩S2、S3两个哨兵，S2和S3一致认为master宕机，然后选举出一个来执行故障转移
同时3个哨兵的majority是2，所以还剩下的2个哨兵运行着，就可以允许执行故障转移。
（9）两个丢失数据的场景：
- 场景1：哨兵、主从架构下的异步复制数据丢失：master node接收写的请求并返回成功，此时数据还在master内存中。由于master复制数据到slave是异步的，可能还没复制数据，master就挂了，此时哨兵检测到master挂了，选举新的master供读写操作，那么旧的master还未复制的那部分数据就丢了
- 场景2：脑裂问题：master主节点，出现了异常性的有相同数据，相同工作的两个节点（集群脑裂导致的数据丢失）
- 图例：
- 脑裂问题图描述：主节点与从节点哨兵集群所在的网络失去联系。哨兵以为原主节点出故障了。选举出新的master，而实际上原主节点依旧正常工作着，此时整个环境中存在两个master，客户端client可能与原master处于同一个网络，连接正常，继续写数据到原master。当管理员发现问题，原master再次恢复时会被作为一个slave挂到新的master上，自己的数据清空，重新从新的master复制数据，就出问题了（后client写入原master的那部分数据丢了）
- 解决方案：两个配置min-slaves-to-write 2, min-slaves-max-lag 10, 可减少异步复制数据和脑裂导致的数据丢失（这两个配置的意思是，要求至少有2个slave，数据复制和同步的延时不能超过10秒）
- 详解：
- 对场景1，min-slaves-max-lag可确保，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么旧拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低到可控范围内。
- 客户端client写数据到master的速度可能大于master复制数据到slave的速度，master可能已经缓存了2000条数据了，而slave才复制了1200条，此时master宕机的话就会丢失800条，而设置了min-slaves-to-write和min-slaves-max-lag就是限制了如果延时超过10S，master就先不接受写请求了，客户端自己在内存中暂时缓存，尝试写其他master或者停顿一段时间。一般这种情况会在客户端做降级，写到磁盘里，在client对外接收请求，再做降级，做限流，减慢请求涌入的速度，或者client会采取将数据临时灌入一个kafka中，每隔10分钟去队列里取一次，尝试重新发回master。
- 对场景2，如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求。这样脑裂后的旧master就不会接受client的新数据，避免了数据丢失。上面的配置确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack消息，就拒绝新的写请求，因此在脑裂场景下如此设置，最多丢失10秒的数据。
（10）redis哨兵的7个核心底层原理（包含slave选举算法）
- --1-- sdown和odown转换机制：sdown和odown是两种失败状态
- sdown是主观宕机，就是一个哨兵如果自己觉得一个master宕机了，那么就是主观宕机；
- odown是客观宕机，如果quorum数量的哨兵都觉得一个master宕机了，那么就是客观宕机；
- sdown达成的条件：如果一个哨兵去ping一个master，超过了is-master-down-after-milliseconds指定的毫秒数之后，就主观认为master宕机了；
- sdown到odown转换的条件：如果一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那么master是sdown了，那么就认为是odown了，客观认为master宕机。
- --2-- 哨兵集群的自动发现机制： 哨兵之间的相互发现是通过redis的pub/sub系统实现的。
- 每个哨兵都会往_sentinal_ :hello 这个channel里发送一个消息，其他哨兵去这个channel订阅消息，这时候所有其他哨兵都可以消费到这个消息，并感知到其他哨兵的存在；
- 每隔两秒钟，每个哨兵都会往自己监控的某个master+slave对应的_sentinal_ :hello这个channel里发送一个消息，内容是自己的host、ip和runid,还有对这个master的监控配置；
- 每个哨兵也会去监听自己监控的每个master+slave对应的_sentinal_ :hello这个channel，然后去感知到同样在监听这个master+slave的其他哨兵的存在；
- 每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步。
- --3-- slave配置的自动纠正：
- 哨兵会负责自动纠正slave的一些配置，比如slave如果要成为潜在的master候选人，哨兵会确保slave在复制现有master的数据；
- 如果slave连接到了一个错误的master上，比如故障转移后，那么哨兵会确保他们连接到正确的master上（哨兵会确保其他slave修改配置）。
- --4-- slave-->master选举算法：
- 如果一个master被认为odown了，而且majority哨兵都允许了主备切换，那么某个哨兵就会执行主备切换操作，此时首先是要选举一个slave出来；
- 会考虑slave的一些信息：
- （1）跟master断开连接的时长：（先筛选掉不适合做master的）如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master（slave跟master的数据相差可能很多了）：
- （down-after-milliseconds * 10）+ milliseconds_since_master_is_in_SDOWN_state ；
- 接下来会对slave进行排序
- （2）slave优先级：按照slave优先级进行排序，slave-priority越低，优先级越高（slave-priority默认100）；
- （3）复制offset：如果slave priority相同，那么看replica offset，哪个slave复制了超多的数据，offset越靠后，优先级就越高；
- （4）run id：如果前两个条件都相同，那么选一个run id较小的那个slave。
- --5-- quorum 和 majority：
- 每次一个哨兵要做主备切换，首先要quorum数量的哨兵都认为sdown(即odown客观认为master宕机了)，然后选举出一个哨兵来做切换，这个哨兵还得得到majority哨兵的授权才能正式执行切换；
- 如果quorum<majority，比如5个哨兵，majority就是3，quorum设为2，那么就要3个哨兵授权就可以执行切换；
- 如果quorum>=majority，那么必须quorum数量的哨兵都授权，比如5个哨兵，quorum设为5，那么必须5个哨兵都同意授权才能执行切换。
- --6-- configuration epoch：
- 执行切换的那个哨兵，会从要切换到的新master那里得到一个configuration epoch，这就是一个version号，每次切换的version都必须是唯一的；
- 如果第一个选举出的哨兵切换失败了，那么其他哨兵会等待一个failover-timeout时间，然后接替继续执行切换，此时会重新获取一个新的configuration epoch，作为新的version号。
- --7-- configuration传播：
- 哨兵完成切换后，会在自己本地更新生成最新的master配置，然后同步给其他哨兵，就是之前的pub/sub消息机制；
- 这里之前的version号就很重要了，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换后，新的master配置是跟着新的version的，其他哨兵都是根据版本号大小来更新自己的master配置的。
三、持久化
如果只把redis当作缓存服务器，那么完全不用考虑持久化，但是大多数服务器架构中，redis不单单只做缓存服务器，还可以作为数据库保存业务数据，就需要持久化。
Redis的两种数据持久化方式：RDB、AOF(append-only file追加)
1、RDB：快照存储数据持久化方式。将redis某一时刻的内存数据保存到硬盘的文件中，默认保存的文件名为dump.rdb，在redis服务器启动时，会重新加载dump.rdb文件中的数据到内存中恢复数据。
三种生成RDB文件的方式：
（1）save命令（占用主进程，阻塞其他客户端请求）、
（2）bgsave命令（新增子进程来同步数据，当forks子进程数据量大时也会阻塞）、
（3）服务器配置自动触发（redis.conf中配置 save 300 10 多少秒内至少达到多少次写操作就备份数据）
优点：（1）与AOF相比，通过rdb文件恢复数据比较快；（2）rdb文件非常紧凑，适合数据备份；（3）使用子进程进行数据备份，对redis服务器性能影响小；
缺点：（1）服务器宕机的话，而没有触发设置同步数据的条件，可能会丢失某段时间内的数据；
（2）save方式会造成服务器阻塞；
（3）bgsave方式在forks子进程时数据量大，也会发生阻塞；
（4）兼容性差：RDB文件需要满足特定格式，老版本redis不兼容新版本的RDB文件。
2、AOF：append-only file，记录客户端对服务器的每次写操作命令，并将这些写操作以Redis协议追加保存到以后缀aof文件末尾。在redis服务器重启时，会加载并运行aof文件的命令，恢复数据。
开启AOF持久化方式，redis默认不开启，可通过redis.conf文件配置：appendonly yes
写入.aof文件的三种策略：appendfsync always（每个写操作都保存到.aof文件） / everysec（默认，每秒写入一次.aof文件，最多会丢失1秒的数据） / no（不推荐）
优点：AOF只是追加日志文件，对服务器性能影响小，备份数据速度比RDB快，消耗内存少；兼容性好
缺点：生成的日志文件太大；恢复数据的速度比RDB慢；对性能影响大
3、当RDB和AOF两种方式都开启时，Redis会优先使用AOF日志文件来恢复数据，因为AOF保存的文件比RDB更完整。
四、redis的并发竞争问题如何解决？
单进程单线程模式，采用队列模式将并发访问变为串行访问
五、redis常用管理命令
# dbsize 返回当前数据库 key 的数量
# info 返回当前redis服务器状态和一些统计信息
# monitor 实时监听并返回redis服务器接收到的所有请求信息
# shutdown 把数据同步保存到磁盘上，并关闭redis服务
# flushdb 慎用，删除当前数据库中所有key,此方法不会失败
# flushall 慎用，删除全部数据库中所有key，此方法不会失败
另：查询key是否存在：exists key +key名字
删除key: del key key2 ...
六、redis客户端与服务端之间的通讯协议：RESP。实现简单、快速解析、可读性好；
七：redis设置过期时间的四种方式：
1、expire key seconds ：设置key在n秒后过期
2、pexpire key milliseconds ：设置key在n毫秒后过期
3、expireat key timestamp ：设置key在某个时间戳（精确到秒）之后过期
4、pexpireat key millisecondsTimestamp： 设置key在某个时间戳（精确到毫秒）之后过期
八、redis三种删除策略
定时删除：设置键的过期时间并设置一个定时任务，当键达到过期时间，立即执行对键的删除操作。缺点是过期键多的话对应的删除任务也多，占CPU
惰性删除：从键空间获取键时，检查键是否过期，过期就删除否则返回该键。 缺点是过期键可能不会被删除（没查询这个键），占内存
定期删除：每隔一点时间，程序对数据库检查，删除过期键