请选择 进入手机版 | 继续访问电脑版
 找回密码
 立即注册
首页 社区 数据库 京东面试官:Redis 这些我必问

京东面试官:Redis 这些我必问

猿梦 2022-11-19 19:26:18
本尊谢紫南洗干净^本王他说清楚—缓存好处:高性能 + 高并发数据库查询耗费了800ms,其他用户对同一个数据再次查询 ,假设该数据在10分钟以内没有变化过,并且 10 分钟之内有 1000 个用户 都查询了同一数据,10 分钟之内,那 1000 每个用户,每个人查询这个数据都感觉很慢 800ms比如 :某个商品信息,在 一天之内都不会改变,但是这个商品每次查询一次都要耗费2s,一天之内被浏览 100W次mysql 单机也就 2000qps,缓存单机轻松几万几十万qps,单机 承载并发量是 mysql 单机的几十倍。在中午高峰期,有 100W 个用户访问系统 A,每秒有 4000 个请求去查询数据库,数据库承载每秒 4000 个请求会宕机,加上缓存后,可以 3000 个请求走缓存 ,1000 个请求走数据库。缓存是走内存的,内存天然可以支撑4w/s的请求,数据库(基于磁盘)一般建议并发请求不要超过 2000/sredis 单线程 ,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=150value = {}有序列表 ,元素可以重复可以通过 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 zhangsanzadd board 72 wangwuzadd board 96 liszadd board 62 zhaoliu自动排序为:96 lisi85 zhangsan72 wangwu62 zhaoliu获取排名前 3 的用户 : zrevrange board 0 396 lisi85 zhangsan72 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 clusterhash算法->一致性 hash 算法-> redis cluster->hash slot算法redis cluster :自动对数据进行分片,每个 master 上放一部分数据,提供内置的高可用支持,部分master不可用时,还是可以继续工作cluster bus 通过进行通信,故障检测,配置更新,故障转移授权,另外一种二进制协议,主要用于节点间进行高效数据交换,占用更少的网络带宽和处理时间key进行hash,然后对节点数量取模,最大问题只有任意一个 master 宕机,大量数据就要根据新的节点数取模,会导致大量缓存失效。key进行hash,对应圆环上一个点,顺时针寻找距离最近的一个点。保证任何一个 master 宕机,只受 master 宕机那台影响,其他节点不受影响,此时会瞬间去查数据库。缓存热点问题:可能集中在某个 hash区间内的值特别多,那么会导致大量的数据都涌入同一个 master 内,造成 master的热点问题,性能出现瓶颈。解决方法:给每个 master 都做了均匀分布的虚拟节点,这样每个区间内大量数据都会均匀的分布到不同节点内,而不是顺时针全部涌入到同一个节点中。redis cluster 有固定 个 hash slot,对每个key计算 CRC16 值,然后对取模,可以获取 key对应的 hash slotredis cluster 中每个 master 都会持有部分 slot ,当一台 master 宕机时候,会最快速度迁移 hash slot到可用的机器上(只会短暂的访问不到)走同一个 hash slot 通过 hash tag实现集群元数据:包括 hashslot->node之间的映射表关系,master->slave之间的关系,故障的信息集群元数据集中式存储(storm),底层基于zookeeper(分布式协调中间件)集群所有元数据的维护。好处:元数据的更新和读取,时效性好,一旦变更,其他节点立刻可以感知。缺点:所有元数据的更新压力全部集中在一个地方,可能会导致元数据的存储有压力。goosip: 好处:元数据的更新比较分散,有一定的延时,降低了压力。缺点:更新有延时,集群的一些操作会滞后。(reshared操作时configuration error)自己提供服务的端口号+ ,每隔一段时间就会往另外几个节点发送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

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册