redis缓存面试题,大厂面试题详解：如何用Redis实现分布式锁？
redis缓存面试题,大厂面试题详解：如何用Redis实现分布式锁？详细介绍
本文目录一览： 大数据分析师面试题：Redis的耐久化战略
【导读】众所周知，大数据分析师的面试流程与其他行业的不大一样，比如你面试一份文员工作，只需要携带简历就可以了，不过要想面试成功大数据分析师，不仅需要携带简历，还要做好考试的准备，这是每一个大数据分析师的入职必经流程，今天小编就来和大家说说大数据分析师面试题：Redis的耐久化战略，希望对各位考生有所帮助。
一、RDB介绍
RDB 是 Redis 默许的耐久化计划。在指定的时间距离内，实行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。
可以在redis.windows.conf配备文件中修正save来进行相应的配备
注意事项
60秒内10000条数据则保存
这儿有三个save，只需满意其间任意一条就可以保存
比方：
(1)在redis中保存几条新的数据，用kill -9粗暴杀死redis进程，模仿redis缺点失常退出，导致内存数据丢掉的场景(或许在，也或许不在，根据save的状况)
(2)手动设置一个save检查点，save 5 1
写入几条数据，等候5秒钟，会发现自动进行了一次dump rdb快照，在dump.rdb中发现了数据
失常停掉redis进程，再从头发起redis，看方才刺进的数据还在
二、AOF介绍
AOF ：Redis 默许不打开。它的呈现是为了补偿RDB的缺乏(数据的不一致性)，所以它采用日志的方法来记载每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令早年到后实行一次以结束数据的恢复作业。(appendonly yes)
注意事项注意事项
可以在redis.windows.conf中进行配备
打开AOF
将appendonly 的no 改为 yes
下面是文件名可以运用默许的文件名，也可以自己改
注意事项
appendfsync运用默许的everysec就可以了
以上就是小编今天给大家整理发送的关于大数据分析师面试题：Redis的耐久化战略的相关内容，希望对各位考生有所帮助，想知道更多关于数据分析师的基本要求有哪些，关注小编持续更新数据分析师岗位解析。
Redis 面试宝典之 Redis 如何处理已经过期的数据？
本文讲的是 Redis 的键值过期之后的 数据处理 ，讲的是正常情况下的 数据清理 ，但面试者常常会把两个概念搞混，以至于和期望的工作失之交臂。我们本文的职责之一就是帮读者朋友搞清楚二者的区别，相信看完本文你就会对二者的概念有一个本质上的认识。
我们本文的面试题是，Redis 如何处理已过期的数据？
在 Redis 中维护了一个过期字典，会将所有已经设置了过期时间的键值全部存储到此字典中，例如我们使用设置过期时间的命令时，命令如下：
此命令表示 5s 之后键值为 mykey:java 的数据将会过期，其中 ex 是 expire 的缩写，也就是过期、到期的意思。
过期时间除了上面的那种字符类型的直接设置之外，还可以使用 expire key seconds 的方式直接设置，示例如下：
获取键值的执行流程是，当有键值的访问请求时 Redis 会先判断此键值是否在过期字典中，如果没有表示键值没有设置过期时间（永不过期），然后就可以正常返回键值数据了；如果此键值在过期字典中则会判断当前时间是否小于过期时间，如果小于则说明此键值没有过期可以正常返回数据，反之则表示数据已过期，会删除此键值并且返回给客户端 nil ，执行流程如下图所示：
这是键值数据的方法流程，同时也是过期键值的判断和删除的流程。
本文的面试题考察的是你对 Redis 的过期删除策略的掌握，在 Redis 中为了平衡空间占用和 Redis 的执行效率，采用了两种删除策略，上面的回答不完全对，因为他只回答出了一种过期键的删除策略，和此知识点相关的面试题还有以下这些：
常见的过期策略，有以下三种：
面试中问到Redis持久化的原理，本篇在做详细解答
我们知道redis是一个 高效的分布式内存数据库 ，由于是操作内存所以性能非常之快，通常用它来做分布式缓存，用来提高微服务的高性能，但是因为是内存操作，所以当出现服务器故障，断电等情况就会造成 内存数据丢失 ，不可恢复，因此redis 引入了持久化机制来将内存数据写入磁盘，从而保障了Redis的数据不被丢失。
Redis有两种持久化的方式，一种是RDB，另外种是AOF。
RDB是将Redis内存中数据的快照存储在磁盘内，是Redis的默认持久化方案。
RDB持久化默认有三种策略
可在redis.conf中配置，会以一段时间内达到指定修改的次数为规则来触发快照操作，快照文件名为dump.rdb。每当Redis服务重启的时候都会从该文件中把数据加载到内存中。
在60秒内有10000次操作即触发RDB持久化。
没有满足第一种条件时，在900秒内有1次操作即触发RDB持久化。
没有满足第二种条件时，在300秒内有10次操作即触发RDB持久化。
RDB持久化除了可以根据配置中的策略来触发外，还可以使用save和bgsave命令手动来触发。这两个命令的区别在于save会阻塞服务器进程。在执行save命令的过程中，服务器不能处理任何请求，但是bgsave（background save，后台保存）命令会通过一个子进程在后台处理数据RDB持久化。本质上save和bgsave调用的都是rdbSave函数，所以Redis不允许save和bgsave命令同时执行，当然这也是为了避免RDB文件数据出现不一致性的问题。
每次都是一个大文件，备份写入IO操作笔记大，很容易耗时，影响进程资源使用。
如果最近一次进程崩溃，那么最近一次数据备份后的数据就被丢失。
文件直接就可以当冷备使用
AOF（Append Only File）以独立日志的方式记录每次的写命令，可以很好地解决了数据持久化的实时性。系统重启时可以重新执行AOF文件中的命令来恢复数据。AOF会先把命令追加在AOF缓冲区，然后根据对应策略写入硬盘。
AOF的实现流程有三个步骤
步骤一
把命令追加到AOF缓冲区，
步骤二
将缓冲区的内容写入程序缓冲区
步骤三
将程序缓冲区的内容写入文件
当AOF持久化功能处于开启状态时，服务器每执行完一个命令就会将命令以协议格式追加写入redisServer结构体的aof_buf缓冲区。而在服务重启的时候会把AOF文件加载到缓冲区中。
AOF有 三种触发机制
·always：每次发生数据变更都会被立即记录到磁盘，性能较差，但数据完整性比较好。
·everysec：每秒钟将aof_buf缓冲区的内容写入AOF文件，如果宕机，就会有1秒内的数据丢失。
·no：将数据同步操作交给操作系统来处理，性能最好，但是数据可靠性最差。在配置文件中设置appendonly=yes后，若没有指定apendfsync，默认会使用everysec选项。
写入指令随着时间的推移，记录了很多重复的指令，导致数据量非常大。
RDB优先级高于AOF
RDB小，AOF较大
RDB慢，AOF快
RDB快，AOF慢
java面试中redis，mongodb类的，会问哪些问题，怎么回答
1、可能会问nosql和关系型数据库的区别：
优点：
1）成本：nosql数据库简单易部署，基本都是开源软件，不需要像使用Oracle那样花费大量成本购买使用，相比关系型数据库价格便宜
2）查询速度：nosql数据库将数据存储于缓存之中，关系型数据库将数据存储在硬盘中，自然查询速度远不及nosql数据库
3）存储数据的格式：nosql的存储格式是key,value形式、文档形式、图片形式等等，所以可以存储基础类型以及对象或者是集合等各种格式，而数据库则只支持基础类型
4）扩展性：关系型数据库有类似join这样的多表查询机制的限制导致扩展很艰难
缺点：
1）维护的工具和资料有限，因为nosql是属于新的技术，不能和关系型数据库10几年的技术同日而语。
2）不提供对sql的支持，如果不支持sql这样的工业标准，将产生一定用户的学习和使用成本
3）不提供关系型数据库对事物的处理
2、介绍下redis和mongodb：
自行google。
3、应用场景：
redis：
a.主要是做热点数据缓存。
b.数据过期处理。
c.消息队列等功能。
d.计数，例如投票等。
mongodb：
mongodb的主要目标是在键/值存储方式（提供了高性能和高度伸缩性）以及传统的RDBMS系统（丰富的功能）架起一座桥梁，集两者的优势于一身。mongo适用于以下场景：
a.网站数据：mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
b.缓存：由于性能很高，mongo也适合作为信息基础设施的缓存层。在系统重启之后，由mongo搭建的持久化缓存可以避免下层的数据源过载。
c.大尺寸、低价值的数据：使用传统的关系数据库存储一些数据时可能会比较贵，在此之前，很多程序员往往会选择传统的文件进行存储。
d.高伸缩性的场景：mongo非常适合由数十或者数百台服务器组成的数据库。
e.用于对象及JSON数据的存储：mongo的BSON数据格式非常适合文档格式化的存储及查询。
4、支持的数据类型:
内容比较多，自行将网上的信息整理一下。
面试碰到分布式技术面试题该怎么解答？
1.1. Redis 有什么数据类型？分别用于什么场景？
数据类型可以存储的值操作STRING字符串、整数或者浮点数对整个字符串或者字符串的其中一部分执行操作
对整数和浮点数执行自增或者自减操作LIST列表从两端压入或者弹出元素
读取单个或者多个元素
进行修剪，只保留一个范围内的元素SET无序集合添加、获取、移除单个元素
检查一个元素是否存在于集合中
计算交集、并集、差集
从集合里面随机获取元素HASH包含键值对的无序散列表添加、获取、移除单个键值对
获取所有键值对
检查某个键是否存在ZSET有序集合添加、获取、删除元素
根据分值范围或者成员来获取元素
计算一个键的排名
What Redis data structures look like
1.2. Redis 的主从复制是如何实现的？
从服务器连接主服务器，发送 SYNC 命令；
主服务器接收到 SYNC 命名后，开始执行 BGSAVE 命令生成 RDB 文件并使用缓冲区记录此后执行的所有写命令；
主服务器 BGSAVE 执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
1.3. Redis 的 key 是如何寻址的？
背景
（1）redis 中的每一个数据库，都由一个 redisDb 的结构存储。其中：
redisDb.id 存储着 redis 数据库以整数表示的号码。
redisDb.dict 存储着该库所有的键值对数据。
redisDb.expires 保存着每一个键的过期时间。
（2）当 redis 服务器初始化时，会预先分配 16 个数据库（该数量可以通过配置文件配置），所有数据库保存到结构 redisServer 的一个成员 redisServer.db 数组中。当我们选择数据库 select number 时，程序直接通过 redisServer.db[number] 来切换数据库。有时候当程序需要知道自己是在哪个数据库时，直接读取 redisDb.id 即可。
（3）redis 的字典使用哈希表作为其底层实现。dict 类型使用的两个指向哈希表的指针，其中 0 号哈希表（ht[0]）主要用于存储数据库的所有键值，而 1 号哈希表主要用于程序对 0 号哈希表进行 rehash 时使用，rehash 一般是在添加新值时会触发，这里不做过多的赘述。所以 redis 中查找一个 key，其实就是对进行该 dict 结构中的 ht[0] 进行查找操作。
（4）既然是哈希，那么我们知道就会有哈希碰撞，那么当多个键哈希之后为同一个值怎么办呢？redis 采取链表的方式来存储多个哈希碰撞的键。也就是说，当根据 key 的哈希值找到该列表后，如果列表的长度大于 1，那么我们需要遍历该链表来找到我们所查找的 key。当然，一般情况下链表长度都为是 1，所以时间复杂度可看作 o(1)。
寻址 key 的步骤
当拿到一个 key 后，redis 先判断当前库的 0 号哈希表是否为空，即：if (dict->ht[0].size == 0)。如果为 true 直接返回 NULL。
判断该 0 号哈希表是否需要 rehash，因为如果在进行 rehash，那么两个表中者有可能存储该 key。如果正在进行 rehash，将调用一次_dictRehashStep 方法，_dictRehashStep 用于对数据库字典、以及哈希键的字典进行被动 rehash，这里不作赘述。
计算哈希表，根据当前字典与 key 进行哈希值的计算。
根据哈希值与当前字典计算哈希表的索引值。
根据索引值在哈希表中取出链表，遍历该链表找到 key 的位置。一般情况，该链表长度为 1。
当 ht[0] 查找完了之后，再进行了次 rehash 判断，如果未在 rehashing，则直接结束，否则对 ht[1]重复 345 步骤。
1.4. Redis 的集群模式是如何实现的？
Redis Cluster 是 Redis 的分布式解决方案，在 Redis 3.0 版本正式推出的。
Redis Cluster 去中心化，每个节点保存数据和整个集群状态，每个节点都和其他所有节点连接。
Redis Cluster 节点分配
Redis Cluster 特点：
所有的 redis 节点彼此互联(PING-PONG 机制)，内部使用二进制协议优化传输速度和带宽。
节点的 fail 是通过集群中超过半数的节点检测失效时才生效。
客户端与 redis 节点直连,不需要中间 proxy 层。客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。
redis-cluster 把所有的物理节点映射到[0-16383] 哈希槽 (hash slot)上（不一定是平均分配）,cluster 负责维护 node、slot、value。
Redis 集群预分好 16384 个桶，当需要在 Redis 集群中放置一个 key-value 时，根据 CRC16(key) mod 16384 的值，决定将一个 key 放到哪个桶中。
转自：葡萄皮吃饱了
京东面试官：Redis 这些我必问
缓存好处：高性能 + 高并发
数据库查询耗费了800ms，其他用户对同一个数据再次查询 ，假设该数据在10分钟以内没有变化过，并且 10 分钟之内有 1000 个用户 都查询了同一数据，10 分钟之内，那 1000 每个用户，每个人查询这个数据都感觉很慢 800ms 比如 ：某个商品信息，在 一天之内都不会改变，但是这个商品每次查询一次都要耗费2s，一天之内被浏览 100W次 mysql 单机也就 2000qps,缓存单机轻松几万几十万qps,单机 承载并发量是 mysql 单机的几十倍。
在中午高峰期，有 100W 个用户访问系统 A，每秒有 4000 个请求去查询数据库，数据库承载每秒 4000 个请求会宕机，加上缓存后，可以 3000 个请求走缓存 ，1000 个请求走数据库。 缓存是走内存的，内存天然可以支撑4w/s的请求，数据库（基于磁盘）一般建议并发请求不要超过 2000/s
redis 单线程 ，memcached 多线程 redis 是单线程 nio 异步线程模型
一个线程+一个队列
redis 基于 reactor 模式开发了网络事件处理器，这个处理器叫做文件事件处理器，file event handler，这个文件事件处理器是单线程的，所以redis 是单线程的模型，采用 io多路复用机制同时监听多个 socket,根据socket上的事件来选择对应的事件处理器来处理这个事件。 文件事件处理器包含：多个 socket,io多路复用程序，文件事件分派器，事件处理器（命令请求处理器、命令恢复处理器、连接应答处理器） 文件事件处理器是单线程的，通过 io 多路复用机制监听多个 socket，实现高性能和线程模型简单性 被监听的 socket 准备好执行 accept,read,write,close等操作的时候，会产生对应的文件事件，调用之前关联好的时间处理器处理 多个 socket并发操作，产生不同的文件事件，i/o多路复用会监听多个socket，将这些 socket放入一个队列中排队。事件分派器从队列中取出socket给对应事件处理器。 一个socket时间处理完后，事件分派器才能从队列中拿到下一个socket，给对应事件处理器来处理。
文件事件： AE_READABLE 对应 socket变得可读（客户端对redis执行 write操作） AE_WRITABLE 对应 socket 变得可写（客户端对 redis执行 read操作） I/O 多路复用可以同时监听AE_REABLE和 AE_WRITABLE ，如果同时达到则优先处理 AE_REABLE 时间 文件事件处理器： 连接应答处理器 对应 客户端要连接 redis 命令请求处理器 对应 客户端写数据到 redis 命令回复处理器 对应 客户端从 redis 读数据
流程：
一秒钟可以处理几万个请求
普通的 set,get kv缓存
类型 map结构，比如一个对象（没有嵌套对象）缓存到 redis里面，然后读写缓存的时候，可以直接操作hash的字段（比如把 age 改成 21，其他的不变） key=150 value = {
}
有序列表 ，元素可以重复 可以通过 list 存储一些列表型数据结构，类似粉丝列表，文章评论列表。 例如：微信大 V的粉丝，可以以 list 的格式放在 redis 里去缓存 key=某大 V value=[zhangsan,lisi,wangwu] 比如 lrange 可以从某个元素开始读取多少个元素，可以基于 list 实现分页查询功能，基于 redis实现高性能分页，类似微博下来不断分页东西。 可以搞个简单的消息队列，从 list头怼进去（lpush），list尾巴出来 (brpop)
无序集合，自动去重 需要对一些数据快速全局去重，（当然也可以基于 HashSet，但是单机） 基于 set 玩差集、并集、交集的操作。比如：2 个人的粉丝列表整一个交集，看看 2 个人的共同好友是谁？ 把 2 个大 V 的粉丝都放在 2 个 set中，对 2 个 set做交集（sinter）
排序的 set，去重但是可以排序，写进去的时候给一个分数，自动根据分数排序
排行榜：
zadd board score username
例如： zadd board 85 zhangsan zadd board 72 wangwu zadd board 96 lis zadd board 62 zhaoliu
自动排序为： 96 lisi 85 zhangsan 72 wangwu 62 zhaoliu
获取排名前 3 的用户 ： zrevrange board 0 3 96 lisi 85 zhangsan 72 wangwu
查看zhaoliu的排行 ：zrank board zhaoliu 返回 4
内存是宝贵的，磁盘是廉价的 给key设置过期时间后，redis对这批key是定期删除+惰性删除 定期删除： redis 默认每隔 100ms随机抽取一些设置了过期时间的 key，检查其是否过期了，如果过期就删除。 注意：redis是每隔100ms随机抽取一些 key来检查和删除，而不是遍历所有的设置过期时间的key（否则CPU 负载会很高，消耗在检查过期 key 上） 惰性删除： 获取某个key的时候， redis 会检查一下，这个key如果设置了过期时间那么是否过期，如果过期了则删除。 如果定期删除漏掉了许多过期key，然后你也没及时去查，也没走惰性删除，如果大量过期的key堆积在内存里，导致 redis 内存块耗尽，则走内存淘汰机制。
内存淘汰策略：
LRU 算法：
缓存架构（多级缓存架构、热点缓存） redis 高并发瓶颈在单机，读写分离，一般是支撑读高并发，写请求少，也就 一秒一两千，大量请求读，一秒钟二十万次。
一主多从，主负责写，将数据同步复制到其他 slave节点，从节点负责读，所有读的请求全部走从节点。主要是解决读高并发。、 主从架构->读写分离->支撑10W+读QPS架构
master->slave 复制，是异步的 核心机制：
master持久化对主从架构的意义： 如果开启了主从架构，一定要开启 master node的持久化，不然 master宕机重启数据是空的，一经复制，slave的数据也丢了
主从复制原理：
第一次启动或者断开重连情况：
正常情况下： master 来一条数据，就异步给 slave
全年 99.99%的时间，都是出于可用的状态，那么就可以称为高可用性 redis 高可用架构叫故障转移，failover，也可以叫做主备切换，切换的时间不可用，但是整体高可用。 sentinal node(哨兵)
作用：
quorum = 1 （代表哨兵最低个数可以尝试故障转移，选举执行的哨兵） master 宕机，只有 S2 存活，因为 quorum =1 可以尝试故障转移，但是没达到 majority =2 （最低允许执行故障转移的哨兵存活数）的标准，无法执行故障转移
如果 M1 宕机了，S2,S3 认为 master宕机，选举一个执行故障转移，因为 3 个哨兵的 majority = 2，所以可以执行故障转移
丢数据：
解决方案：
sdown 主观宕机，哨兵觉得一个 master 宕机（ping 超过了 is-master-down-after-milliseconds毫秒数） odown 客观宕机，quorum数量的哨兵都觉得 master宕机 哨兵互相感知通过 redis的 pub/sub系统，每隔 2 秒往同一个 channel里发消息（自己的 host,ip,runid），其他哨兵可以消费这个消息 以及同步交换master的监控信息。 哨兵确保其他slave修改master信息为新选举的master 当一个 master被认为 odown && marjority哨兵都同意，那么某个哨兵会执行主备切换，选举一个slave成为master（考虑 1. 跟master断开连接的时长 2. slave 优先级 3.复制 offset 4. runid） 选举算法：
quorum 数量哨兵认为odown->选举一个哨兵切换->获得 majority哨兵的授权（quorum majority 需要 majority个哨兵授权，quorum >= majority 需要 quorum 哨兵授权） 第一个选举出来的哨兵切换失败了，其他哨兵等待 failover-time之后，重新拿confiuration epoch做为新的version 切换，保证拿到最新配置，用于 configuration传播（通过 pu/sub消息机制，其他哨兵对比 version 新旧更新 master配置）
高并发：主从架构 高容量：Redis集群，支持每秒几十万的读写并发 高可用：主从+哨兵
持久化的意义在于故障恢复数据备份（到其他服务器）+故障恢复（遇到灾难，机房断电，电缆被切）
AOF 只有一个，Redis 中的数据是有一定限量的，内存大小是一定的,AOF 是存放写命令的，当大到一定的时候，AOF 做 rewrite 操作，就会基于当时 redis 内存中的数据，来重新构造一个更小的 AOF 文件，然后将旧的膨胀很大的文件给删掉，AOF 文件一直会被限制在和Redis内存中一样的数据。AOF同步间隔比 RDB 小，数据更完整
优点：
缺点：
AOF 存放的指令日志，数据恢复的时候，需要回放执行所有指令日志，RDB 就是一份数据文件，直接加载到内存中。
优点：
缺点：
AOF 来保证数据不丢失，RDB 做不同时间的冷备
支持 N 个 Redis master node,每个 master node挂载多个 slave node 多master + 读写分离 + 高可用
数据量很少，高并发 -> replication + sentinal 集群 海量数据 + 高并发 + 高可用 -> redis cluster
hash算法->一致性 hash 算法-> redis cluster->hash slot算法
redis cluster :自动对数据进行分片，每个 master 上放一部分数据，提供内置的高可用支持，部分master不可用时，还是可以继续工作 cluster bus 通过 16379进行通信，故障检测，配置更新，故障转移授权，另外一种二进制协议，主要用于节点间进行高效数据交换，占用更少的网络带宽和处理时间
key进行hash，然后对节点数量取模，最大问题只有任意一个 master 宕机，大量数据就要根据新的节点数取模，会导致大量缓存失效。
key进行hash，对应圆环上一个点，顺时针寻找距离最近的一个点。保证任何一个 master 宕机，只受 master 宕机那台影响，其他节点不受影响，此时会瞬间去查数据库。 缓存热点问题： 可能集中在某个 hash区间内的值特别多，那么会导致大量的数据都涌入同一个 master 内，造成 master的热点问题，性能出现瓶颈。 解决方法： 给每个 master 都做了均匀分布的虚拟节点，这样每个区间内大量数据都会均匀的分布到不同节点内，而不是顺时针全部涌入到同一个节点中。
redis cluster 有固定 16384 个 hash slot,对每个key计算 CRC16 值，然后对16384取模，可以获取 key对应的 hash slot redis cluster 中每个 master 都会持有部分 slot ,当一台 master 宕机时候，会最快速度迁移 hash slot到可用的机器上（只会短暂的访问不到） 走同一个 hash slot 通过 hash tag实现
集群元数据：包括 hashslot->node之间的映射表关系，master->slave之间的关系，故障的信息 集群元数据集中式存储（storm），底层基于zookeeper（分布式协调中间件）集群所有元数据的维护。好处：元数据的更新和读取，时效性好，一旦变更，其他节点立刻可以感知。缺点：所有元数据的更新压力全部集中在一个地方，可能会导致元数据的存储有压力。 goosip: 好处：元数据的更新比较分散，有一定的延时，降低了压力。缺点：更新有延时，集群的一些操作会滞后。（reshared操作时configuration error）
自己提供服务的端口号+ 10000 ，每隔一段时间就会往另外几个节点发送ping消息，同时其他几点接收到ping之后返回pong
故障信息，节点的增加和移除， hash slot 信息
meet:某个节点发送 meet给新加入的节点，让新节点加入集群中，然后新节点就会开始于其他节点进行通信 ping:每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据 ping:返回ping和meet，包含自己的状态和其他信息 fail:某个节点判断另一个节点fail之后，就发送 fail 给其他节点，通知其他节点，指定的节点宕机了
ping 很频繁，且携带元数据，会加重网络负担 每个节点每秒会执行 10 次 ping，每次选择 5 个最久没有通信的其他节点 当如果发现某个节点通信延迟达到了 cluster_node_timeout /2 ，那么立即发送 ping， 避免数据交换延迟过长，落后时间太长（2 个节点之间 10 分钟没有交换数据，整个集群处于严重的元数据不一致的情况）。 每次ping，一个是带上自己的节点信息，还有就是带上1/10其他节点的信息，发送出去，进行数据交换 至少包含 3 个其他节点信息，最多包含总节点-2 个其他节点的信息
客户端发送到任意一个redis实例发送命令，每个redis实例接受到命令后，都会计算key对应的hash slot，如果在本地就本地处理，否则返回moved给客户端，让客户端进行重定向 （redis-cli -c）
通过tag指定key对应的slot,同一个 tag 下的 key，都会在一个 hash slot中，比如 set key1:{100} 和 set key2:{100}
本地维护一份hashslot->node的映射表。 JedisCluster 初始化的时候，随机选择一个 node，初始化 hashslot->node 映射表，同时为每个节点创建一个JedisPool连接池，每次基于JedisCluster执行操作，首先JedisCluster都会在本地计算key的hashslot，然后再本地映射表中找到对应的节点，如果发现对应的节点返回moved，那么利用该节点的元数据，更新 hashslot->node映射表（重试超过 5 次报错）
hash slot正在迁移，那么会返回ask 重定向给jedis,jedis 接受到ask重定向之后，，会重定向到目标节点去执行
判断节点宕机： 如果一个节点认为另外一个节点宕机了， 就是pfail,主观宕机 如果多个节点都认为另外一个节点宕机了，那么就是fail，客观宕机（跟哨兵原理一样） 在cluster-node-timeout内，某个节点一直没有返回 pong,那么就被认为是 pfail 如果一个节点认为某个节点pfail了，那么会在gossip消息中，ping给其他节点，如果超过半数的节点认为pfail了，那么就会变成fail。 从节点过滤： 对宕机的 mster node ，从其所有的 slave node中，选择一个切换成 master node 检查每个 slave node与master node断开连接的时间，如果超过了cluster-node-timeout * cluster-slave-validity-factor，那么就没资格切换成 master（和哨兵一致） 从节点选举： 每个从节点，根据自己对 master 复制数据的 offset，设置一个选举时间，offset越大（复制数据越多）的从节点，选举时间越靠前，所有的 master node 开始投票，给要进行选举的 slave进行投票，如果大部分 master node(N/2 +1) 都投票给某个从节点，那么选举通过，从节点执行主备切换，从节点切换成主节点 总结：和哨兵很像，直接集成了 replication 和 sentinal
方案： 事前：保证 redis 集群高可用性 （主从+哨兵或 redis cluster），避免全盘崩溃 事中：本地 ehcache 缓存 + hystrix 限流（保护数据库） & 降级，避免 MySQL被打死 事后： redis持久化，快速恢复缓存数据，继续分流高并发请求
限制组件每秒就 2000 个请求通过限流组件进入数据库，剩余的 3000 个请求走降级，返回一些默认 的值，或者友情提示 好处 ：
4000 个请求黑客攻击请求数据库里没有的数据 解决方案：把黑客查数据库中不存在的数据的值，写到缓存中，比如： set -999 UNKNOWN
读的时候，先读缓存，缓存没有，就读数据库，然后取出数据后放入缓存，同时返回响应 更新的时候，删除缓存，更新数据库 为什么不更新缓存： 更新缓存代价太高（更新 20 次，只读 1 次），lazy思想，需要的时候再计算，不需要的时候不计算
方案：先删除缓存，再修改数据库
方案：写，读路由到相同的一个内存队列（唯一标识，hash，取模）里，更新和读操作进行串行化（后台线程异步执行队列串行化操作），（队列里只放一个更新查询操作即可，多余的过滤掉，内存队列里没有该数据更新操作，直接返回 ）有该数据更新操作则轮询取缓存值，超时取不到缓存值，直接取一次数据库的旧值
TP 99 意思是99%的请求可以在200ms内返回 注意点：多个商品的更新操作都积压在一个队列里面（太多操作积压只能增加机器），导致读请求发生大量的超时，导致大量的读请求走数据库 一秒 500 写操作，每200ms，100 个写操作，20 个内存队列，每个队列积压 5 个写操作，一般在20ms完成
方案：分布式锁 + 时间戳比较
10台机器，5 主 5 从，每个节点QPS 5W ，一共 25W QPS（Redis cluster 32G + 8 核 ，Redis 进程不超过 10G）总内存 50g，每条数据10kb，10W 条数据1g，200W 条数据 20G，占用总内存不到50%，目前高峰期 3500 QPS
作者： mousycoder
redis面试之数据结构
redis是面试中最常问的中间件，关于数据结构主要集中在列举和用法。下面我们就数据结构和主要的使用方式做一个描述。
大家都知道redis的几种数据结构，包括string （字符串),hash（哈希），list（列表），set（集合），zset（有序集合）。下面我们来列举一下关于这几种结构的常用命令和一些使用场景。
string是redis的最基本的数据类型。
string类型是二进制安全的，也就是说string里可以包含任何的数据类型。
string类型的值最大能存储512MB
1、 普通的单值缓存
2、对象数据缓存(json格式)
3、分布式锁的应用
4、计数器的使用，使用INCR和DECR
redis hash 是一个string类型的field(字段)和value(值)的映射表，很适合存储对象。
hash最适合的就是做对象缓存
list是redis的字符串列表，可以选择将值插入到头部或尾部。
1、 可以利用list的头部尾部增删属性实现栈和队列
2、 可以用来实现时间轴模型，根据时间依次插入数据，使用LPUSH插入和LRANGE获取最近范围的数据
set是redis的无序集合，是通过哈希表实现的，因此任何操作(添加、删除和测试成员的存在性等)的时间复杂度是O(1)。(无论集合中包含多少元素，时间都是常量)
1、 可以根据set集合的不可重复的特性，统计一些像网站访问IP啊，访问用户啊这些信息，无论访问多少次，SADD加入的都只有一条。
2、 也可以使用SRANDMEMBER和SPOP获取数据的随机性 ，做一些抽奖的小程序等随机功能
3、 作为集合，可以利用交并运算等计算一些复杂的逻辑关系，比如说人物关系之间的网络关系。
ZSet和set类似，都是字符串的非重复集合。不同之处在于，ZSet的每个成员都与分数相关，分数是用来进行排序的。然后可以使用分数来取一个范围内的数
应用场景：
ZSet是有序的集合，可以使用它来做一个排行榜。
面试问题redis有哪些集群方案
多个同构twemproxy（配置相同）同时工作，接受客户端的请求，根据hash算法，转发给对应的redis。
优点：- 开发简单，对应用几乎透明- 历史悠久，方案成熟
缺点：- 代理影响性能- lvs和twemproxy会有节点性能瓶颈- redis扩容非常麻烦- twitter内部已放弃使用该方案，新使用的架构未开源
Codis：
ZooKeeper：存放路由表和代理节点元数据分发Codis-Config的命令Codis-Config :集成管理工具，有web界面Codis-Proxy :无状态代理，兼容Redis协议对业务透明Codis-Redis：基于2.8版本，二次开发加入slot支持和迁移命令
优点：- 开发简单，对应用几乎透明- 性能比Twemproxy好- 有图形化界面，扩容容易，运维方便
缺点：- 代理依旧影响性能- 组件过多，需要很多机器资源- 修改了redis代码，导致和官方无法同步，新特性跟进缓慢- 开发团队准备主推基于redis改造的reborndb
Redis Cluster：
P2P模式，无中心化把key分成16384个slot每个实例负责一部分slot客户端请求若不在连接的实例，该实例会转发给对应的实例。通过Gossip协议同步节点信息
优点：- 组件all-in-box，部署简单，节约机器资源- 性能比proxy模式好- 自动故障转移、Slot迁移中数据可用- 官方原生集群方案，更新与支持有保障
缺点：- 架构比较新，最佳实践较少- 多键操作支持有限（驱动可以曲线救国）- 为了性能提升，客户端需要缓存路由表信息- 节点发现、reshard操作不够自动化
大厂面试题详解：如何用Redis实现分布式锁？
说一道常见面试题：
一个很简单的答案就是去使用 Redission 客户端。Redission 中的锁方案就是 Redis 分布式锁得比较完美的详细方案。
那么，Redission 中的锁方案为什么会比较完美呢？
正好，我用 Redis 做分布式锁经验十分丰富，在实际工作中，也 探索 过许多种使用 Redis 做分布式锁的方案，经过了无数血泪教训。
所以，在谈及 Redission 锁为什么比较完美之前，先给大家看看我曾经使用 Redis 做分布式锁是遇到过的问题。
我曾经用 Redis 做分布式锁是想去解决一个用户抢优惠券的问题。这个业务需求是这样的：当用户领完一张优惠券后，优惠券的数量必须相应减一，如果优惠券抢光了，就不允许用户再抢了。
在实现时，先从数据库中先读出优惠券的数量进行判断，当优惠券大于 0，就进行允许领取优惠券，然后，再将优惠券数量减一后，写回数据库。
当时由于请求数量比较多，所以，我们使用了三台服务器去做分流。
这个时候会出现一个问题：
如果其中一台服务器上的 A 应用获取到了优惠券的数量之后，由于处理相关业务逻辑，未及时更新数据库的优惠券数量；在 A 应用处理业务逻辑的时候，另一台服务器上的 B 应用更新了优惠券数量。那么，等 A 应用去更新数据库中优惠券数量时，就会把 B 应用更新的优惠券数量覆盖掉。
看到这里，可能有人比较奇怪，为什么这里不直接使用 SQL：
原因是这样做，在没有分布式锁的协调下，优惠券数量可能直接会出现负数。因为当前优惠券数量为 1 的时候，如果两个用户通过两台服务器同时发起抢优惠券的请求，都满足优惠券大于 0 每个条件，然后都执行这条 SQL 说了句，结果优惠券数量直接变成 -1 了。
还有人说可以用乐观锁，比如使用如下 SQL:
这种方式就在一定几率下，很可能出现数据一直更新不上，导致长时间重试的情况。
所以，经过综合考虑，我们就采用了 Redis 分布式锁，通过互斥的方式，以防止多个客户端同时更新优惠券数量的方案。
当时，我们首先想到的就是使用 Redis 的 setnx 命令，setnx 命令其实就是 set if not exists 的简写。
当 key 设置值成功后，则返回 1，否则就返回 0。所以，这里 setnx 设置成功可以表示成获取到锁，如果失败，则说明已经有锁，可以被视作获取锁失败。
如果想要释放锁，执行任务 del 指令，把 key 删除即可。
利用这个特性，我们就可以让系统在执行优惠券逻辑之前，先去 Redis 中执行 setnx 指令。再根据指令执行结果，去判断是否获取到锁。如果获取到了，就继续执行业务，执行完再使用 del 指令去释放锁。如果没有获取到，就等待一定时间，重新再去获取锁。
乍一看，这一切没什么问题，使用 setnx 指令确实起到了想要的互斥效果。
但是，这是建立在所有运行环境都是正常的情况下的。一旦运行环境出现了异常，问题就出现了。
想一下，持有锁的应用突然崩溃了，或者所在的服务器宕机了，会出现什么情况？
这会造成死锁——持有锁的应用无法释放锁，其他应用根本也没有机会再去获取锁了。这会造成巨大的线上事故，我们要改进方案，解决这个问题。
怎么解决呢？咱们可以看到，造成死锁的根源是，一旦持有锁的应用出现问题，就不会去释放锁。从这个方向思考，可以在 Redis 上给 key 一个过期时间。
这样的话，即使出现问题，key 也会在一段时间后释放，是不是就解决了这个问题呢？实际上，大家也确实是这么做的。
不过，由于 setnx 这个指令本身无法设置超时时间，所以一般会采用两种办法来做这件事：
1、采用 lua 脚本，在使用 setnx 指令之后，再使用 expire 命令去给 key 设置过期时间。
2、直接使用 set(key,value,NX,EX,timeout) 指令，同时设置锁和超时时间。
以上两种方法，使用哪种方式都可以。
释放锁的脚本两种方式都一样，直接调用 Redis 的 del 指令即可。
到目前为止，我们的锁既起到了互斥效果，又不会因为某些持有锁的系统出现问题，导致死锁了。这样就完美了吗？
假设有这样一种情况，如果一个持有锁的应用，其持有的时间超过了我们设定的超时时间会怎样呢？会出现两种情况：
出现第一种情况比较正常。因为你毕竟执行任务超时了，key 被正常清除也是符合逻辑的。
但是最可怕的是第二种情况，发现设置的 key 还存在。这说明什么？说明当前存在的 key，是另外的应用设置的。
这时候如果持有锁超时的应用调用 del 指令去删除锁时，就会把别人设置的锁误删除，这会直接导致系统业务出现问题。
所以，为了解决这个问题，我们需要继续对 Redis 脚本进行改动……毁灭吧，累了……
首先，我们要让应用在获取锁的时候，去设置一个只有应用自己知道的独一无二的值。
通过这个唯一值，系统在释放锁的时候，就能识别出这锁是不是自己设置的。如果是自己设置的，就释放锁，也就是删除 key；如果不是，则什么都不做。
脚本如下：
或者
这里，ARGV[1] 是一个可传入的参数变量，可以传入唯一值。比如一个只有自己知道的 UUID 的值，或者通过雪球算法，生成只有自己持有的唯一 ID。
释放锁的脚本改成这样：
可以看到，从业务角度，无论如何，我们的分布式锁已经可以满足真正的业务需求了。能互斥，不死锁，不会误删除别人的锁，只有自己上的锁，自己可以释放。
一切都是那么美好！！！
可惜，还有个隐患，我们并未排除。这个隐患就是 Redis 自身。
要知道，lua 脚本都是用在 Redis 的单例上的。一旦 Redis 本身出现了问题，我们的分布式锁就没法用了，分布式锁没法用，对业务的正常运行会造成重大影响，这是我们无法接受的。
所以，我们需要把 Redis 搞成高可用的。一般来讲，解决 Redis 高可用的问题，都是使用主从集群。
但是搞主从集群，又会引入新的问题。主要问题在于，Redis 的主从数据同步有延迟。这种延迟会产生一个边界条件：当主机上的 Redis 已经被人建好了锁，但是锁数据还未同步到从机时，主机宕了。随后，从机提升为主机，此时从机上是没有以前主机设置好的锁数据的——锁丢了……丢了……了……
到这里，终于可以介绍 Redission（开源 Redis 客户端）了，我们来看看它怎么是实现 Redis 分布式锁的。
Redission 实现分布式锁的思想很简单，无论是主从集群还是 Redis Cluster 集群，它会对集群中的每个 Redis，挨个去执行设置 Redis 锁的脚本，也就是集群中的每个 Redis 都会包含设置好的锁数据。
我们通过一个例子来介绍一下。
假设 Redis 集群有 5 台机器，同时根据评估，锁的超时时间设置成 10 秒比较合适。
第 1 步，咱们先算出集群总的等待时间，集群总的等待时间是 5 秒（锁的超时时间 10 秒 / 2）。
第 2 步，用 5 秒除以 5 台机器数量，结果是 1 秒。这个 1 秒是连接每台 Redis 可接受的等待时间。
第 3 步，依次连接 5 台 Redis，并执行 lua 脚本设置锁，然后再做判断：
再额外多说一句，在很多业务逻辑里，其实对锁的超时时间是没有需求的。
比如，凌晨批量执行处理的任务，可能需要分布式锁保证任务不会被重复执行。此时，任务要执行多长时间是不明确的。如果设置分布式锁的超时时间在这里，并没有太大意义。但是，不设置超时时间，又会引发死锁问题。
所以，解决这种问题的通用办法是，每个持有锁的客户端都启动一个后台线程，通过执行特定的 lua 脚本，去不断地刷新 Redis 中的 key 超时时间，使得在任务执行完成前，key 不会被清除掉。
脚本如下：
其中，ARGV[1] 是可传入的参数变量，表示持有锁的系统的唯一值，也就是只有持有锁的客户端才能刷新 key 的超时时间。
到此为止，一个完整的分布式锁才算实现完毕。总结实现方案如下：
这个分布式锁满足如下四个条件：
当然，在 Redission 中的脚本，为了保证锁的可重入，又对 lua 脚本做了一定的修改，现在把完整的 lua 脚本贴在下面。
获取锁的 lua 脚本：
对应的刷新锁超时时间的脚本：
对应的释放锁的脚本：
到现在为止，使用 Redis 作为分布式锁的详细方案就写完了。
我既写了一步一坑的坎坷经历，也写明了各个问题和解决问题的细节，希望大家看完能有所收获。
最后再给大家提个醒，使用 Redis 集群做分布式锁，有一定的争议性，还需要大家在实际用的时候，根据现实情况，做出更好的选择和取舍。
原文 https://www.cnblogs.com/siyuanwai/p/16011836.html