1. 单机 redis
2. redis 主从实现读写分离
-
redis 高并发跟整个系统的高并发之间的关系
- redis：你要搞高并发的话，不可避免，要把底层的缓存搞得特别好
- mysql：搞并发，做到了，那么也是通过一系列复杂的分库分表，订单系统，事务要求的，QPS到几万，比较高了。
- 要做一些电商的商品详情页，真正的超高并发，QPS上十万，甚至是百万，一秒钟百万的请求量，光是 redis 是不够的，但是redis 是整个整个大型的缓存架构中，支撑高并发的架构里面，非常重要的一个环节。
-
redis 不能支持高并发的瓶颈在哪里？
- 单机
-
如果 redis 要支撑超过10万+的并发，应该怎么做？
- 单机 的 redis 几乎不太可能说 QPS 超过10万 + ，除非一些特殊情况，比如你的机器性能特别好，配置特别高，维护做的特别好等。
- 单机一般在几万。
- 如果要支撑 10万+ 的并发，就要使用读写分离，一般来说，对缓存，一般都是用来支撑读高并发的，写的请求是比较少的，可能写请求只有一秒钟几千、一两千。大量的请求都是读，一秒钟二十万次的读。
3.1 redis replication
redis replication 的核心机制
- 【1】redis 采用异步的方式复制数据到 slave节点，不过 redis 2.8 开始，slave node 会周期性地确认自己每次复制的数据量
- 【2】一个 master node 是可以配置多个 slave node 的
- 【3】slave node 也可以连接其他的 slave node
- 【4】slave node 做复制的时候，是不会 阻塞 master node 的正常工作的
- 【5】slave node 在做复制的时候，也不会 block 对自己的查询操作，它会将旧的数据集来提供服务；但是复制完成的时候，需要删除旧的数据集，加载新数据集，这个时候就会暂停对外服务了
- 【6】slave node 主要用来进行横向扩容，做读写分离，扩容的slave node 可以提高
3.2 master持久化对主从结构的安全意义
如果采用了主从架构，那么建议必须开启 master node 的持久化！
不建议使用 slave node 作为master node 的数据热备，因为那样的话，如果你关掉 master 的持久化，可能在 master宕机重启的时候是空的，然后可能已经过复制， slave node 数据也丢了。
master -》 RDB 和 AOF 都关闭了 -》 全部在内存中
master 宕机，重启，是没有本地数据可以恢复的，然后就会直接认为自己的数据是空的
master 就会将空的数据集同步到 slave 上去，所有 slave的数据全部清空 -》 100 % 的数据丢失
master 节点，必须要使用持久化机制
第二个，master的各种备份方案，要不要做，万一说本地的所有文件丢失了；从备份中挑选一份 RDB 去恢复master；这样才能确保 master 启动的时候，是有数据的。
即使采用了后续讲解的高可用机制，slave node 可以自动接管 master node，但是也可能 sentinal还没有检测到 master failure， master node就自动重启了，还是可能导致上面的所有 slave node
4. redis 主从复制、断点续传、无磁盘化复制、过期key 处理
-
主从架构的核心原理
- 当启动一个 slave node 的时候，它会发送一个 PSYNC 命令给 master
- 如果这时 slave node 重新连接 master，那么 master node 仅仅会复制给slave部分缺少的数据；否则如果是slave 第一次连接 master，那么会触发一次 full resynchronozation。
- 开始full resynchronozation的时候，master 会启动一个后台线程，开始生成一份 RDB 快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master 会将这个RDB发送给slave，slave会先写入本地磁盘，然后master会将内存中的缓存的写命令发送给 slave，slave也会同步这些数据。
- slave node 如果跟 master 有网络故障，断开了连接，会自动重连。master 如果发现有多个 slave都来重新连接，仅仅会启动一个 rdb save操作，用一份数据服务所有的 slave node
-
主从复制的断点续传
- 从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份
- master node会在内存中常见一个backlog，master和slave都会保存一个replica offset还有一个master id，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制
- 但是如果没有找到对应的offset，那么就会执行一次resynchronization
-
无磁盘化复制
- master 在内存中直接创建 RDB，等待一定时长再开始复制，因为要等更多 slave重新连接过来
-
过期 key 处理
- slave不会过期 key，只会等待 master 过期key。如果master过期了一个 key，或者通过LRU淘汰了一个key，那么会发送一个del命令给slave
5. redis replication 的完整运行流程和原理
- 【1】复制的完整流程
- 【步骤一】 slave node启动，仅仅保存master node的信息，包括master node的host和ip，但是复制流程没开始
- 【步骤二】slave node内部有个定时任务，每秒检查是否有新的master node要连接和复制，如果发现，就跟master node建立socket网络连接
- 【步骤三】slave node发送ping命令给master node
- 【步骤四】口令认证，如果master设置了requirepass，那么salve node必须发送masterauth的口令过去进行认证
- 【步骤五】master node第一次执行全量复制，将所有数据发给slave node
- 【步骤六】master node后续持续将写命令，异步复制给slave node
【2】数据同步相关的核心机制
指的就是第一次slave连接master的时候，执行的全量复制。
-
master和slave都会维护一个offset
- master会在自身不断累加offset，slave也会在自身不断累加offset
- slave每秒都会上报自己的offset给master，同时master也会保存每个slave的offset
-
backlog
- master node有一个backlog，默认是1MB大小
- master node给slave node复制数据时，也会将数据在backlog中同步写一份
- backlog主要是用来做全量复制中断后的增量复制的
-
master run id
- info server，可以看到master run id
- 如果根据host+ip定位master node，是不靠谱的，如果master node重启或者数据出现了变化，那么slave node应该根据不同的run id区分，run id不同就做全量复制
- 如果需要不更改run id重启redis，可以使用redis-cli debug reload命令
-
全量复制
- master执行bgsave，在本地生成一份rdb快照文件
- master node将rdb快照文件发送给salve node，如果rdb复制时间超过60秒（repl-timeout），那么slave node就会认为复制失败，可以适当调节大这个参数
- 对于千兆网卡的机器，一般每秒传输100MB，6G文件，很可能超过60s
- master node在生成rdb时，会将所有新的写命令缓存在内存中，在salve node保存了rdb之后，再将新的写命令复制给salve node
- client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么停止复制，复制失败
- slave node接收到rdb之后，清空自己的旧数据，然后重新加载rdb到自己的内存中，同时基于旧的数据版本对外提供服务
- 如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF
-
增量复制
- 如果全量复制过程中，master-slave网络连接断掉，那么salve重新连接master时，会触发增量复制
- master直接从自己的backlog中获取部分丢失的数据，发送给slave node，默认backlog就是1MB
- msater就是根据slave发送的psync中的offset来从backlog中获取数据的
-
异步复制
- master每次接收到写命令之后，先在内部写入数据，然后异步发送给slave node .
6. redis 主从架构下如何才能做到99.99%的高可用性？
【问题一】 首先看一下系统处于不可用是什么意思？
那么，如果你的系统可以保证在全年，99.99%的时间内，都是处于可用的状态的，那么就可以称之为高可用性。
【问题二】redis的不可用的情况
【问题三】redis基于哨兵的高可用性
7. redis 哨兵
【问题一】哨兵的介绍
-
哨兵是 redis 集群架构中非常重要的一个组件，主要功能如下：
- 【功能一】集群监控： 负责监控 redis master 和slave 进程是否正常工作
- 【功能二】消息通知： 如果某个redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员
- 【功能三】故障转移： 如果master 挂掉，会自动转移到 slave上
- 【功能四】配置中心： 如果故障转移发生了，通知 client 客户端新的 master 地址
-
哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作
- 故障转移时，判断一个 master 是宕机了，需要大部分的哨兵都统一才醒，设计到了分布式选举的问题
- 即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了
【问题二】哨兵的核心知识
哨兵至少需要3个实例（3个实例都是哨兵），来保证自己的健壮性
哨兵+redis主从的部署架构，是不会保证数据零丢失的，只能保证 redis集群的高可用性
对于哨兵+redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练
【问题三】为什么redis 哨兵集群只有2个节点无法正常工作？
哨兵集群必须部署2个以上节点
如果哨兵集群仅仅部署了个2个哨兵实例，quorum=1
master宕机，s1和s2中只要有1个哨兵认为master宕机就可以进行切换，同时s1和s2中会选举出一个哨兵来执行故障转移
同时这个时候，需要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），2个哨兵都运行着，就可以允许执行故障转移
但是如果整个M1和S1运行的机器宕机了，那么哨兵只有1个了，此时就没有majority来允许执行故障转移，虽然另外一台机器还有一个R1，但是故障转移不会执行
【问题四】经典的3节点哨兵集群
如果M1所在机器宕机了，那么三个哨兵还剩下2个，S2和S3可以一致认为master宕机，然后选举出一个来执行故障转移
同时3个哨兵的majority是2，所以还剩下的2个哨兵运行着，就可以允许执行故障转移
8. redis哨兵主备切换的数据丢失问题：异步复制、集群脑裂
【问题一】 两种数据丢失的情况
- 异步复制导致的数据丢失
- 因为 从 master 到slave 的复制是异步的，所以可能有部分数据还没有复制到 slave，master就宕机了，此时这些部分数据就流失了。
- 脑裂导致的数据丢失
- 脑裂，也就是说，某个 master 所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着
- 此时哨兵可能会认为 master 宕机了，然后开始选举，将其他slave切换成了master
- 这个时候，集群中会有两个master，也就是所谓的脑裂
- 此时虽然某个slave切换成了master，但是可能client还没来得切换到新的master，还继续写向旧的master的数据可能也丢失了。
- 因此旧的master再次回复的时候，会被作为一个slave挂到新的master上，自己的数据会被清空，重新从新的master上复制数据
解决的方法
min-slaves-to-write 1
min-slaves-max-lag 10
要求至少有1个slave，数据复制和同步的延迟不能超过10秒
如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了
上面两个配置可以减少异步复制和脑裂导致的数据丢失
【解决异步复制导致的数据丢失】
有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内
【减少脑裂的数据丢失】
如果一个 master 出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以保证，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求
这样脑裂后的旧master就不会接收client的新数据，也就避免了数据丢失
上面的配置保证了，如果跟任何一个slave丢了连接，在10秒之后发现没有slave给自己ack，那么就拒绝新的写请求。因此脑裂的场景下，最多就丢失10秒的数据。
9. redis 哨兵的多个核心底层原理的深入解析
【1】sdown 和 odown转换机制
sdown 和 odown 两种失败状态
- sdown 是主观宕机，就一个哨兵如果自己觉得一个master 宕机了，那么就是主观宕机
- odown是客观宕机，如果 quorum 数量的哨兵都觉得一个master宕机了，那么就是客观宕机
sdown 达成的条件很简单，如果一个哨兵 ping一个master，超过了 is-master-down-after-milliseconds 指定的毫秒数之后，就主观认为 master 宕机。
【2】哨兵集群的自动发现机制
哨兵互相之间的发现，是通过 redis 的 pub/sub 系统实现的，每个哨兵都会向 _sentinel_: hello 这个 channel 里发送一个消息，这时候所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在。
每隔两秒钟，每个哨兵都会向自己监控的某个 master + slvae 对应的 _sentinel_: hello 这个 channel 里发送一个消息，内容是自己的 host、ip 和 runid 还有对这个master 的监控配置
每个哨兵也会去监听自己健康的每个 master + slaves 对应的 _sentinel_: hello 这个 channel ，然后去感知到同样在监听这个master + slaves 的其他哨兵的存在
每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步
【3】slave配置的自动纠正
哨兵会负责自动纠正 slave的一些配置，比如 slave如果要称为潜在的 master候选人，哨兵会确保slave在赋值现有master的数据；如果slave连接到了一个错误的master上，比如故障转移之后，那么哨兵会确保他们连接到正确的master上
【4】slave 到 master的选举算法
如果一个 master 被认为 odown了，而且majority哨兵都允许了主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个slave来，会考虑到slave的一些信息：
- 跟master断开连接的时长
- slave优先级
- 复制offset
- run id
如果一个slave 跟master 断开连接已经超过了 down-after-milliseconds的10倍，外加 master宕机的时长，那么slave就被认为不适合选举为master
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
接下来会对slave进行排序
- 按照 slave 优先级进行排序，slave-priority（是一个配置，默认为100）越低，优先级就越高
- 如果 slave priority 相同，那么看replica offset， 哪个 slave复制了越多的数据，offset越靠后，优先级就越高
- 如果上面两个条件都相同，那么选择一个run id 比较小的那个 slave
【5】quorum 和 majority
每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个哨兵来做切换，这个哨兵还得得到majority哨兵的授权，才能正式执行切换
如果quorum < majority，比如5个哨兵，majority就是3，quorum设置为2，那么就3个哨兵授权就可以执行切换
但是如果quorum >= majority，那么必须quorum数量的哨兵都授权，比如5个哨兵，quorum是5，那么必须5个哨兵都同意授权，才能执行切换
【6】configuration epoch
哨兵会对一套 redis master + slave 进行监控，有相应的监控的配置
执行切换的那个哨兵，会从要切换到的新master（slave 到 master）那里得到一个 configuration epoch，这就是 version号，每次切换的version 号都必须是唯一的
如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待 failover-timeout 时间，然后接着继续执行切换，此时会重新获取一个新的 configuration epoch，作为新的version号
【7】configuration传播
哨兵完成切换之后，会在自己本地更新生成最新的master配置，然后同步给其他的哨兵，就是通过之前说的 pub/sub 消息机制
这里之前的version号就很重要了，因为各种消息都是通过一个channel 去发布和监听的，所以一个哨兵完成一次新的切换之后，新的master配置是跟着新的 version号的
其他的哨兵都是根据版本号的大小来更新自己的master配置的