为什么至少三个哨兵_缓存高可用、哨兵、持久化、LRU

1 Redis为什么这么快

  • 完全基于内存,数据存储在内存中,类似HashMap,查找操作时间复杂度都是O(1);
  • 数据结构简单,专门设计;
  • 单线程,避免不必要的上下文切换和竞争条件,不用考虑加锁问题,不可能出现死锁导致性能消耗;
  • 多路I/O复用,非阻塞IO;
  • 底层模型和mysql不同,直接自己构建了VM机制。

2 单线程

  • 可以通过在单机开多个Redis实例。

3 解决单机瓶颈

  • 集群的部署方式也就是Redis cluster,并且是主从同步读写分离,类似Mysql的主从同步,Redis cluster支撑N个Redis master node,每个master node都可以挂载多个slave node;
  • 这样整个Redis就可以横向扩容了,如果你要支撑更大数据量的缓存,那就横向扩容更多的master节点,每个master节点就能存放更多的数据了。

4 如何进行交互,redis如何持久化,断电怎么办

  • RDB:RDB持久化机制,是对Redis中的数据执行周期性的持久化;
  • AOF:AOF机制对每条写入命令作为日志,以append-only的模式写入一个日志文件中,因为这个模式是只追加的方式,所以没有任何磁盘寻址的开销,所以很快,有点像Mysql中的binlog;
  • RDB更适合做冷备,AOF更适合做热备,比如我杭州的某电商公司有这两个数据,我备份一份到我杭州的节点,再备份一个到上海的,就算发生无法避免的自然灾害,也不会两个地方都一起挂吧,这灾备也就是异地容灾;
  • tip:两种机制全部开启的时候,Redis在重启的时候会默认使用AOF去重新构建数据,因为AOF的数据是比RDB更完整的。

5 两种备份机制优缺点

  • RDB:
    • 他会生成多个数据文件,每个数据文件分别都代表了某一时刻Redis里面的数据,完整的数据运维设置定时任务,定时同步到远端的服务器,比如阿里的云服务,这样一旦线上挂了,你想恢复多少分钟之前的数据,就去远端拷贝一份之前的数据就好了;
    • RDB对Redis的性能影响非常小,是因为在同步数据的时候他只是fork了一个子进程去做持久化的,而且他在数据恢复的时候速度比AOF来的快;
    • RDB都是快照文件,都是默认五分钟甚至更久的时间才会生成一次,这意味着你这次同步到下次同步这中间五分钟的数据都很可能全部丢失掉;AOF则最多丢一秒的数据;
    • 还有就是RDB在生成数据快照的时候,如果文件很大,客户端可能会暂停几毫秒甚至几秒,你公司在做秒杀的时候他刚好在这个时候fork了一个子进程去生成一个大快照;
  • AOF:
    • RDB五分钟一次生成快照,但是AOF是一秒一次去通过一个后台的线程fsync操作,那最多丢这一秒的数据;
    • AOF在对日志文件进行操作的时候是以append-only的方式去写的,他只是追加的方式写数据,自然就少了很多磁盘寻址的开销了,写入性能惊人,文件也不容易破损;
    • AOF的日志是通过一个叫非常可读的方式记录的,这样的特性就适合做灾难性数据误删除的紧急恢复了;
    • 一样的数据,AOF文件比RDB还要大;
    • AOF开启后,Redis支持写的QPS会比RDB支持写的要低。

6 两者选择

  • 两者都要,单独用RDB你会丢失很多数据,单独用AOF数据恢复没RDB来的快,真出问题时候第一时间用RDB恢复,然后AOF做数据补全。

7 保证集群高可用方式

  • 哨兵集群sentinel;
  • 哨兵必须用三个实例去保证自己的健壮性,哨兵+主从并不能保证数据不丢失,但是可以保证集群的高可用;
  • 为什么要用三个实例:
    • 两个的问题:master宕机了s1和s2两个哨兵只要有一个认为你宕机了就切换了,并且会选举出一个哨兵去执行故障,但是这个时候也需要大多数哨兵都是运行的;
    • 那这样有啥问题呢?M1宕机了,S1没挂那其实是OK的,但是整个机器都挂了呢?哨兵就只剩下S2了,没有哨兵去允许故障转移了,虽然另外一个机器上还有R1,但是故障转移就是不执行;

d7a542a0f6e5e9f3b67f87150c29327b.png
  • 经典哨兵集群方式:

bb455469db5a70370893312ad76de049.png
  • M1所在的机器挂了,哨兵还有两个,两个人一看他不是挂了嘛,那我们就选举一个出来执行故障转移不就好了;
  • 哨兵组件的功能:
    • 集群监控:负责监控Redis master和slave进程是否正常工作;
    • 消息通知:如果某个Redis实例有故障,那么哨兵负责发送消息作为报警通知给管理员;
    • 故障转移:如果master node挂掉了,会自动转移到slave node上;
    • 配置中心:如果故障转移发生了,通知client客户端新的master地址。

8 主从之间数据同步方式

  • 我先说下为啥要用主从这样的架构模式,前面提到了单机QPS是有上限的,而且Redis的特性就是必须支撑读高并发的,那你一台机器又读又写,这谁顶得住啊,不当人啊!但是你让这个master机器去写,数据同步给别的slave机器,他们都拿去读,分发掉大量的请求那是不是好很多,而且扩容的时候还可以轻松实现水平扩容;
  • 你启动一台slave的时候,他会发送一个psync命令给master,如果是这个slave第一次连接到master,他会触发一个全量复制,master就会启动一个线程,生成RDB快照,还会把新的写请求都缓存在内存中,RDB文件生成后,master会将这个RDB发送给slave的,slave拿到之后做的第一件事情就是写进本地的磁盘,然后加载进内存,然后master会把内存里面缓存的那些新命名都发给slave。

9 数据传输时断网或者服务器挂了

  • 传输过程中有什么网络问题啥的,会自动重连的,并且连接之后会把缺少的数据补上的;
  • RDB快照的数据生成的时候,缓存区也必须同时开始接受新请求,不然你旧的数据过去了,你在同步期间的增量数据咋办。

10 Redis过期策略

  • Redis的过期策略,是有定期删除+惰性删除两种;
  • 定期好理解,默认100ms就随机抽一些设置了过期时间的key,去检查是否过期,过期了就删了;
  • 假如Redis里面所有的key都有过期时间,都扫描一遍?那太恐怖了,而且我们线上基本上也都是会设置一定的过期时间的;
  • 好问题,惰性删除,见名知意,惰性嘛,我不主动删,我懒,我等你来查询了我看看你过期没,过期就删了还不给你返回,没过期该怎么样就怎么样。

11 定期没删,也没查询,内存淘汰机制

  • noeviction:返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令;
  • allkeys-lru:尝试回收最少使用的键;
  • volatile-lru:尝试回收最少使用的键,但仅限于在过期集合的键;
  • allkeys-random:回收随机的键;
  • volatile-random:回收随机的键,但仅限于在过期集合的键;
  • volatile-ttl:回收在过期集合的键,并且优先回收存活时间较短的键。

参考

https://mp.weixin.qq.com/s/EjDeypra_d9Tfsn-WkJZdw​mp.weixin.qq.com
表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
相关推荐
©️2020 CSDN 皮肤主题: 数字20 设计师:CSDN官方博客 返回首页