Java复习--Redis

Posted 2022-03-02 赵jc

Redis复习

• 一为什么使用MQ？
• 消息队列的缺点
• RabbitMQ
• • RabbitMQ是什么
  • RabbitMQ的特点
  • AMQP是什么？
  • RabbitMQ如何保证消息的可靠性？
• Redis基础知识
• • Redis是什么？
  • Redis能干嘛（Redis的应用场景）
  • Redis的特点
  • Redis的优缺点
  • 为什么要使用Redis做缓存
  • Redis的数据类型
  • Redis是单线程的(Redis6.0之后引入多线程)
  • Redis内存淘汰策略
• Redis事务
• • Redis中事务的一些特性
  • 事务的相关命令
  • 监控 Watch
• Redis持久化机制
• • RDB
  • • RDB的特点
    • RDB的触发机制
    • 如何恢复rdb文件
    • 优缺点
  • AOF
  • • 容错机制
    • 优缺点
  • 如何选择合适的持久化
• 缓存异常
• • 数据一致性
  • • 背景
    • 解决方案
    • 先删除缓存，后更新数据库
    • 先删除缓存，后更新数据库
  • 缓存穿透（大面积查不到）
  • • 概念
    • 解决方案
  • 缓存击穿（量太大，缓存过期！）
  • • 概念
    • 解决方案
  • 缓存雪崩(断电/宕机)
  • • 概念
    • 解决方案
• Redis主从复制
• • 相关概念
  • 主从复制的应用
  • 主从复制的意义
  • 主从复制的方式（分类）
  • • 一主二从模式
    • 层层链路模式
• Redis哨兵模式
• • 相关概念
  • 优缺点
  • 主节点宕掉后，会从从节点选举一个新的master，选举的标准是什么？

一为什么使用MQ？

使用MQ的场景很多，主要有三个：解耦、异步、削峰

• 解耦：A服务可以将消息放在MQ当中，其他的服务可以直接从MQ当中获取消息并进行处理即可，A服务和B服务没有实际的关联，提高了系统的灵活性和扩展性
• 异步：可以将一些非核心的流程，如日志，短信，右键等通过MQ的方式去异步处理，这样做的好处是缩短主流程的响应时间，提升用户的体验
• 削峰：MQ的本质就是业务排队，所以面对突然到来的高并发，现在MQ中排好队一个一个来。削峰的好处就是避免高并发压垮系统的关键组件（如某个核心的服务或者数据库等）

解耦场景：A系统发送数据到BCD三个系统，通过接口调用发送，如果E系统也要用这个数据呢？那如果C系统现在不需要用这个数据了呢？A系统负责人几乎崩溃…

如果使用MQ，A系统产生一条数据，发送到MQ里面去，如果那个系统需要数据自己去MQ里面取数据，A系统压根不需要考虑消息发给谁，不需要维护这个代码，也不需要考虑人家是调用成功，失败超时等情况

通过一个MQ，Pub/Sub发布订阅消息 这么一个模型，A系统就跟其他系统彻底解耦了
异步场景：A系统接受了一个请求，需要在自己本地写如数据库，还要在BCD三个系统写入数据库，自己本地需要3ms，BCD三个系统分别需要300ms，450ms，200ms，最终请求的总时延时953ms接近1s，用户体验极差，一般互谅网的企业，对于用户的直接操作，一般要求是每个请求必须在200ms以内完成，对用户几乎是无感知的

如果使用MQ，那么A系统连续发送3条消息到MQ队列当中，假如耗时5ms，A系统从接受一个请求到返回最终响应给用户总是尝试8ms，大大减少了响应时间

削峰场景：每天0:00到12:00，A系统风平浪静，每秒并发请求数量就50个，结果每次一道12:00-13:00美妙的并发请求就会突然暴增到5000个，但A服务最大的处理能力是2000个，所以当大量请求时服务器会垮掉
使用MQ，将5000个请求写入MQ，A系统慢慢从MQ中拉取请求，在自己的能力范围内处理请求就可以了，这样下来哪怕是高峰期，系统也可以正常使用，但是会有大量的请求积压在MQ当中（可能有上百个），但是短暂的高峰期挤压是ok的，因为高峰期过了之后，A系统就会很快地将积压的消息处理掉（高峰期过后，MQ每秒进入50个请求，但是A系统仍然会以2000个请求的速度去处理）

消息队列的缺点

• 系统可用性降低：系统引入的外部依赖越多，越容易挂掉
• 系统复杂性提高：加入了消息队列之后，要考虑很多方面的问题，比如：一致性问题、如何保证这个消息不被重复消费、如何保证消息的可靠性传输等
• 一致性问题：如果A系统处理完了直接返回，人们都以为处理好了，但要是BCD三个系统里BC写入数库成功了，但是C写入数据库失败了，这是数据就不一致了

RabbitMQ

RabbitMQ是什么

简而言之RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件，简而言之就是消息中间件
RabbitMQ服务器使用Erlang语言编写的

RabbitMQ的特点

• 可靠性：RabbitMQ使用一些机制来保证可靠性，例如持久化、传输确认及发布确认等
• 灵活的路由：在消息进入队列之前，通过交换器来路由信息
• 扩展性：多个RabbitMQ节点可以组成一个集群，也可以根据实际业务情况动态的扩展到集群中去
• 支持多种协议：RabbitMQ除了支持原生的AMQP协议还支持STOMP，MQTT等多种消息中间件协议
• 支持多用语言：RabbitMQ支持所有常用的语言

AMQP是什么？

RabbitMQ就是AMQP协议的Erlang实现，是一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准,为面向消息的中间件设计。

RabbitMQ如何保证消息的可靠性？

生产者到RabbitMQ：事务机制和COnfirm机制（注意事务机制和Confirm机制是互斥的，不能共存）
RabbitMQ自身：持久化、集群、普通模式、镜像模式
RabbitMQ到消费者：死信机制、消息补偿机制

Redis基础知识

Redis是什么？

Redis（Remote Dictionary Server）远程字典服务！是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、key-value数据库，并提供多种语言的API。是免费和开源的！是当下最热门的NoSQL技术之一！也被人们称之为结构化数据库！Redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并在此基础上实现master-slave（主从）同步。

Redis能干嘛（Redis的应用场景）

• 内存存储、持久化（内存中是断电即失、所以持久化很重要（人rdb、aof））
• 效率高、可用于高速缓存
• 分布式会话（分布式Session）
• 发布订阅系统（消息队列）
• 地图信息分析
• 计时器、计数器（浏览量）
• …

Redis的特点

• 多样的数据类型
• 持久化
• 集群
• 事务
• …

Redis的优缺点

优点：

• 读写性能极高
• 支持数据持久化
• 支持事务
• 支持主从复制
  缺点：
• 数据库容易受到物理内存的限制，不能做海量数据的高性能读写
• 主机宕机后，宕机前有部分数据未能及时同步到从机

为什么要使用Redis做缓存

从高并发来说：

• 直接操作缓存能承受的最大请求远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求就会直接到缓存这里，而不用经过数据库了

从高性能上来说：

• 用户第一次访问数据库的某些数据，因为是从硬盘上读取的所以过程会比较慢，将该用户访问的数据存在缓存中，下一次在访问这些数据的时候就可以直接从缓存中去了，操作缓存就是操作内存，所以速度相当快

Redis的数据类型

Redis-Key
以下是常见的Redis-Key的命令

127.0.0.1:6379> keys * #查看所有的key
(empty list or set)
127.0.0.1:6379> set name zjc #设置key
OK
127.0.0.1:6379> set age 1
OK
127.0.0.1:6379> keys * 
1) "name"
2) "age"
127.0.0.1:6379> exists name #查看key是否存在
(integer) 1
127.0.0.1:6379> exists name1
(integer) 0
127.0.0.1:6379> move name 1	#移除key
(integer) 1
127.0.0.1:6379> keys *
1) "age"
127.0.0.1:6379> expire name 10 #设置key的到期时间
(integer) 0
127.0.0.1:6379> ttl name	#查看key的到期时间
(integer) -2
127.0.0.1:6379> ttl name
(integer) -2
127.0.0.1:6379> get name 
(nil)
127.0.0.1:6379> type name	#查看key的类型
none
127.0.0.1:6379> type age
string

Redis有五种常用的数据类型：String、Hash、Set、List、SortedSet（Zset），以及三种特殊的数据类型：Bitmap、HyPerLogLog、Geospatial。其中HyperLogLog、Bitmap底层都是String数据类型，Geospatial的底层是Zset数据类型

• String：String是最常用的一种数据类型，普通的key-value存储都可以归为此类。其中Value既可以是数字也可以是字符串。使用场景：常规的key-value缓存应用。使用场景：微博数，粉丝数
• Hash：Hash也是一个key-value的键值对，不过此时的value也是一个key-value的值
• Set：Set是一个无序的天然去重的集合，即key-Set。此外还提供了交集、并集等一系列直接操作集合的方法。使用场景：求一些公共好友、共同关注比较方便
• List：List是一个有序可重复的集合 ，其遵循先进先出的原子，底层是依赖双向链表实现的，因此支持正向、反向双重查找。使用场景：获取最新恢复消息的类似功能
• SortedSet（Zset）：Set的可排序版。使用场景：排行榜
• Bitmap：位图，Bitmap可以想象成一个以位为单位的数组，数组中每个单元只能存0或者1，使用场景：使用Bitmap实现统计功能更省空间（如果数据只有两种状态0或者1）
• Hyperloglog：一种用于传统基数的数据类型集合(基数：不重复的元素，比如1.3.5.7.8为5，可以接收误差)
• Geospatial；主要用于存储地理位置信息，bong对存储的信息进行操作。使用场景：朋友的定位、附近的人、搭车距离

Redis是单线程的(Redis6.0之后引入多线程)

我们需要明白Redis是很快的，官方表示，Redis是基于内存操作，CPU不是Redis的性能瓶颈，Redis的瓶颈是根据机器的内存和网络带宽有关，既然可以使用单线程，就用单线程来实现了！
Redis是用c语言写的，官方提供的数据为1000000+的QPS，完全不比同样使用key-value的Memecache差！

Redis为什么单线程还那么快？

误区1：高性能服务器一定是多线程吗？
误区2：多线程（CPU会进行上下文切换）一定比单线程效率高？

核心：效率：CPU > 内存 > 硬盘 Redis是将所有的数据全部放在内存中，所有说使用单线程去操作效率就是最高的（多线程CPU上下文会切换，会消耗时间）对内存系统来说，如果没有上下文切换效率就是最高的！

Redis内存淘汰策略

Redis是不断的删除一些过期的数据，但是肯定也有许多没有设置过期时间的数据也会越来越多，那么Redis内存不够用的时候是怎么处理的呢？答案就是淘汰策略（当Redis内存超过最大允许的内存之后，Redis就会触发内存淘汰策略，删除一些不常用的数据，以保证Redis服务器的正常运行）

• 1、noeviction:添加数据时，如果redis判断该操作会导致占用内存大小超过内存限制，就返回error，然后啥也不干
• 2、allkeys-lru:添加数据时，如果redis判断该操作会导致占用内存大小超过内存限制，就会扫描所有的key，淘汰一些最近未使用的key
• 3、volatile-lru:添加数据时，如果redis判断该操作会导致占用内存大小超过内存限制，扫描那些设置里过期时间的key，淘汰一些最近未使用的key
• 4、allkeys-random:添加数据时，如果redis判断该操作会导致占用内存大小超过内存限制，就会扫描所有的key，随机淘汰一些key
• 5、volatile-random:添加数据时，如果redis判断该操作会导致占用内存大小超过内存限制，扫描那些设置里过期时间的key，随机淘汰一些key
• 6、volatile-ttl:添加数据时，如果redis判断该操作会导致占用内存大小超过内存限制，扫描那些设置里过期时间的key，淘汰一些即将过期的key
• 7、volatile-lfu:添加数据时，如果redis判断该操作会导致占用内存大小超过内存限制，就会淘汰一些设置了过期时间的，并且最近最少使用的key
• 8、allkeys-lfu:添加数据时，如果redis判断该操作会导致占用内存大小超过内存限制，就会扫描所有的key，淘汰一些最近最少使用的key

Redis事务

Redis中事务的一些特性

• Redis事务的本质：一组命令的集合！一个事务中所有的命令都会被序列化，在事务执行过程中，会按照顺序执行！
• 一次性、顺序性、排他性！执行一系列的命令！
• Redis事务没有隔离级别的概念！
• Redis单条命令保存原子性，但是事务不保证原子性！
• 所有命令在事务中，并没有直接被执行！只有发起执行命令的时候才会执行！

事务的相关命令

开始事务（multi）
命令入队（…）
执行事务(执行事务)

127.0.0.1:6379> multi	#开启事务
OK
#命令入队
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> exec	#执行事务
1) OK
2) OK
3) "v2"
4) OK

监控 Watch

悲观锁：

• 很悲观，认为什么时候都会出现问题，无论做什么都会加锁！

乐观锁：

• 很乐观，认为什么时候都不会出现问题，所以不会上锁！更新数据的时候去判断一下，在此期间是否有人修改过这个数据
• 获取version
• 更新的时候比较version

Redis持久化机制

为了能够多次重复使用Redis数据以及防止系统故障，我们需要将Redis中的数据写入到磁盘空间，这就是持久化。
Redis提供了两种不同的持久化方法可以将数据存储在磁盘中，一种叫快照RDB，另一种交只追加文件AOF

RDB

RDB的特点

• 核心：在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。（在主从复制中，rdb就是备用了！备份到从机上面！）
• 详细过程：Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。我们默认的就是RDB，一般情况下不需要修改这个配置！
• 有时候在生产环境我们会将这个文件进行备份！
• rdb保存的文件是dump.rdb （都是在我们的配置文件修改保存的名称）

RDB的触发机制

• 1、save的规则满足的情况下，会自动触发rdb规则
• 2、执行 flushall 命令，也会触发我们的rdb规则！
• 3、退出redis，也会产生 rdb 文件！

如何恢复rdb文件

• 1、只需要将rdb文件放在我们redis启动目录就可以，redis启动的时候会自动检查dump.rdb 恢复其中的数据！
• 2、查看需要存在的位置

优缺点

优点：

• 1、适合大规模的数据恢复！
• 2、对数据的完整性要不高！（60分钟5次修改，如果59分钟的时候宕机了，最后一次的修改的数据就获取不到了）

缺点

• 1、需要一定的时间间隔进程操作！如果redis意外宕机了，这个最后一次修改数据就没有的了！

AOF

• 核心：将我们的所有命令都记录下来，history，恢复的时候就把这个文件全部在执行一遍！
• 详细过程：以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件 但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
• aof保存的是 appendonly.aof 文件
• AOF采用文件追加方式，文件会越来越大，为了避免出现此种情况，新增了重写机制。当AOF文件超过一定的阈值，Redis会 fork一个新的进程来将我们的文件进行重写！

容错机制

如果这个 aof 文件有错误，这时候 redis 是启动不起来的吗，我们需要修复这个aof文件
redis 给我们提供了一个工具 redis-check-aof --fix

优缺点

# appendfsync always # 每次修改都会 sync。消耗性能 
appendfsync everysec # 每秒执行一次 sync，可能会丢失这1s的数据！
# appendfsync no # 不执行 sync，这个时候操作系统自己同步数据，速度最快！

优点：
针对上面的三种机制

• 1、每一次修改都同步，文件的完整会更加好！
• 2、每秒同步一次，可能会丢失一秒的数据
• 3、从不同步，效率最高的！

缺点：

• 1、相对于数据文件来说，aof远远大于 rdb，修复的速度也比 rdb慢！
• 2、Aof 运行效率也要比 rdb 慢，所以我们redis默认的配置就是rdb持久化！

如何选择合适的持久化

• 如果数据不是那么敏感，且可以从其他地方重新生成补回得的，那么可以关闭持久化
• 如果数据比较重要，且可以承受数分钟的数据丢失，那么可以使用RDB
• 如果需要保证数据一点都不能丢失，则可以使用AOF

Redis缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题比较复杂。如果对数据的一致性要求很高，那么就不能使用缓存。
另外的一些典型问题就是，缓存穿透、缓存雪崩和缓存击穿。目前，业界也都有比较流行的解决方案。

缓存异常

数据一致性

背景

背景：使用到缓存，无论是在本地内存做缓存还是使用Redis做缓存，那么就会存在数据同步的问题，造成数据库与缓冲数据不一致的问题

解决方案

1. 先更新数据库，后更新缓存
2. 先更新缓存，后更新数据库
3. 先删除缓存，后更新数据库
4. 先更新数据库，后删除缓存

第一种方案存在的问题：在并发更新数据库场景下，会将脏数据刷到缓存中
第二种方案存在的问题：如果先更新缓存，但是数据库更新失败了，也会造成诗句不一致的问题
所以一般不使用第一二种方案，而使用三四种方案

先删除缓存，后更新数据库

第三种方案也会出现问题，此时来了两个请求，请求A（更新操作）和请求B（查询操作）

1. 请求A进行写操作，删除缓存（但还未更新数据库）
2. 请求B查询时发现缓存不存在
3. 请求B去数据库查询得到的是旧值
4. 请求B将旧值写入到缓存中
5. 请求A将新值更新到数据库中

上述情况就会导致数据不一致，而且如果不给缓存设置哦过期时间策略，该数据永远是脏数据，那么该如何解决呢
答案一：延时双删
伪代码：

public void write（String key, Object data） 
	Redis.delkey（key）;
	db.uppdateDate(data);
	Thread.sleep(1000);
	Redis.delkey(key);

• 先淘汰缓存
• 再写数据库
• 休眠一秒，再次淘汰缓存（这么做，可以将1s内所造成的缓存脏数据，再次删除）确保请求结束后，写请求可以再次删除读请求造成的缓存脏数据

答案二：更新与读取操作进行异步串行化

• 异步串行化
• 读操作去重

先删除缓存，后更新数据库

这一种情况也会出现问题，比如更新数据库成功了，但是再删除缓存阶段出错了没有删除成功，那么此时在读取缓存的话每次都是错误的数据

解决方案：利用消息队列进行删除补偿

1. 请求A先对数据库进行更新操作
2. 再对Redis进行删除操作删除失败，报错
3. 此时Redis的key作为消息体发送到消息队列中去
4. 系统接收到消息队列发送的消息后再次对Redis进行删除操作

缓存穿透（大面积查不到）

概念

缓存穿透的概念很简单，用户想要查询一个数据，发现redis内存数据库没有，也就是缓存没有命中，于是向持久层数据库查询。发现也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中（秒杀！），于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透。

解决方案

• 布隆过滤器

布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力；

• 缓存空对象

当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源；

但是这种方法会存在两个问题：

1. 如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多 的空值的键；
2. 即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于 需要保持一致性的业务会有影响。

缓存击穿（量太大，缓存过期！）

概念

这里需要注意和缓存击穿的区别，缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中
对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。
当某个key在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访问数据库来查询最新数据，并且回写缓存，会导使数据库瞬间压力过大。

解决方案

• 设置热点数据永不过期
  从缓存层面来看，没有设置过期时间，所以不会出现热点 key 过期后产生的问题。
• 加互斥锁
  分布式锁：使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。

缓存雪崩(断电/宕机)

概念

缓存雪崩，是指在某一个时间段，缓存集中过期失效。Redis 宕机！
产生雪崩的原因之一，比如在写本文的时候，马上就要到双十二零点，很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。

其实集中过期，倒不是非常致命，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，这个时候，数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知
的，很有可能瞬间就把数据库压垮。

解决方案

• redis高可用
  这个思想的含义是，既然redis有可能挂掉，那我多增设几台redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。（异地多活！）
• 限流降级
  这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
• 数据预热
  数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

Redis主从复制

相关概念

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master/leader)，后者称为从节点(slave/follower)；

• 数据的复制是单向的，只能由主节点到从节点。
• Master以写为主，Slave 以读为主。
• 默认情况下，每台Redis服务器都是主节点；
• 一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

主从复制的应用

• 1、数据热备份：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
• 2、故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务 的冗余。
• 3、负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
• 4、高可用（集群）基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复 制是Redis高可用的基础。

主从复制的意义

一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的（宕机），原因如下：

• 1、从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大；

2、从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有内存用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G。
电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是"多读少写"。
对于这种场景，我们可以使如下这种架构：

主从复制，读写分离！ 80% 的情况下都是在进行读操作！减缓服务器的压力！架构中经常使用！ 一主二从！
只要在公司中，主从复制就是必须要使用的，因为在真实的项目中不可能单机使用Redis！

主从复制的方式（分类）

一主二从模式

默认情况下，每台Redis服务器都是主节点；
我们一般情况下只用配置从机就好了！认老大！ 一主 （79）二从（80，81）

层层链路模式

上一个连接的是Master，下一个连接 Salove！这时候也可以完成我们的主从复制！

谋朝篡位

如果没有老大了，这个时候能不能选择一个老大出来呢？ 使用（slaveof no one）手动选出一个老大！

Redis哨兵模式

相关概念

主从复制，由于是我们手动选择主机所以不方便，所以引入了哨兵模式（自动的选择主机）
主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel（哨兵） 架构来解决这个问题。
谋朝篡位的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例

这里的哨兵有两个作用:

• 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
• 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover[故障转移]操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

优缺点

优点：

• 1、哨兵集群，基于主从复制模式，所有的主从配置优点，它全有
• 2、 主从可以切换，故障可以转移，系统的可用性就会更好
• 3、哨兵模式就是主从模式的升级，手动到自动，更加健壮！
  缺点：
• 1、Redis 不好啊在线扩容的，集群容量一旦到达上限，在线扩容就十分麻烦！
• 2、实现哨兵模式的配置其实是很麻烦的，里面有很多选择！

主节点宕掉后，会从从节点选举一个新的master，选举的标准是什么？

• 选择健康状态从节点（排除主观下线、断线），排除5秒钟没有心跳的、排除主节点失联超过10*down-after-millisecends。
• 选择最高优先级中复制偏移量最大的从机。
• 如果还没有选出来，则按照ID排序，获取运行ID最小的从节点。