redis 哨兵模式

notes/Redis_哨兵模式.md

@@ -0,0 +1,86 @@
+# Redis Sentinel
+
+## 一、复制
+
+为了解决单点问题，保证数据的安全性，Redis 提供了复制机制，用于满足故障恢复和负载均衡等需求。通过复制机制，Redis 可以通过多个副本保证数据的安全性，从而提供高可用的基础，Redis 的哨兵模式和集群模式都是在复制机制的基础上实现高可用的。
+
+### 1.1 建立复制关系
+
+想要对两个 Redis 节点建立主从复制关系，可以通过以下三种方式来实现：
+
+- 在从节点的配置文件中配置 `slaveof{masterHost}{masterPort}` 选项；
+- 在从节点启动时候加入 `--slaveof{masterHost}{masterPort }`参数；
+- 直接在从节点的交互式命令行中执行 `slaveof{masterHost}{masterPort}` 命令。 
+
+主从节点复制关系建立后，可以使用 `info replication` 命令查看相关的复制状态。需要注意的是每个从节点只能有一个主节点，但主节点可以同时拥有多个从节点，复制行为是单向的，只能由主节点复制到从节点，因此从节点默认都是只读模式，即 `slave-read-only` 的值默认为`yes`。
+
+### 1.2 断开复制关系
+
+在启动后，如果想要断开复制关系，可以通过在从节点上执行 `slaveof no one` 命令，此时从节点会断开与主节点的复制关系，但并不会删除原有的复制成功的数据，只是无法再获取主节点上的数据。
+
+通过 slaveof 命令还可以实现切换主节点的操作，命令如下：
+
+```shell
+slaveof{newMasterIp} {newMasterPort}
+```
+
+需要注意的是，当你从一个主节点切换到另外一个主节点时，该从节点上的原有的数据会被完全清除，然后再执行复制操作，从而保证该从节点上的数据和新主节点上的数据相同。
+
+### 1.3 复制机制原理
+
+
+
+### 1.4 复制机制缺陷
+
+复制机制最主要的缺陷在于，一旦主节点出现故障，从节点无法自动晋升为主节点，需要通过手动切换来实现，这样无法达到故障的快速转移，因此也不能实现高可用。基于这个原因，就产生了哨兵模式。
+
+
+
+## 二、哨兵模式原理
+
+哨兵模式的主要作用在于它能够自动完成故障发现和故障转移，并通知客户端，从而实现高可用。哨兵模式通常由一组 Sentinel 节点和一组（或多组）主从复制节点组成，架构如下：
+
+![下载](C:\Users\ciic\Desktop\下载.png)
+
+### 2.1 架构说明
+
+#### 1. Sentinel 与 Redis Node
+
+Redis  Sentinel 就是一个特殊的 Redis 节点。在哨兵模式创建时，需要通过配置指定 Sentinel 与 Redis Master Node 之间的关系，然后 Sentinel 会从主节点上获取所有从节点的信息，之后 Sentinel 会定时向主节点和从节点发送`info`命令获取其拓扑结构和状态信息。
+
+#### 2. Sentinel 与 Sentinel 
+
+基于 Redis 的发布订阅功能， 每个 Sentinel 节点会向主节点的 `__sentinel__： hello` 频道上发送该 Sentinel 节点对于主节点的判断以及当前 Sentinel 节点的信息 ，同时每个 Sentinel 节点也会订阅该频道， 来获取其他 Sentinel 节点的信息以及它们对主节点的判断。
+
+#### 3. 心跳机制
+
+通过以上两步所有的 Sentinel 节点以及它们与所有的 Redis 节点之间都已经彼此感知到，之后每个 Sentinel 节点会向主节点、 从节点、 以及其余 Sentinel 节点定时发送 ping 命令作为心跳检测， 来确认这些节点是否可达。  
+
+### 2.2 故障转移原理
+
+ 每个 Sentinel 都会定时进行心跳检查，当发现某个主节点出现心跳检测超时的情况时，此时认为该主节点已经不可用，这种判定称为主观下线。
+
+之后该 Sentinel 节点会通过 `sentinel ismaster-down-by-addr` 命令向其他 Sentinel 节点询问对主节点的判断， 当 quorum 个 Sentinel 节点都认为该节点故障时，则执行客观下线，即认为该节点已经不可用。这也同时解释了为什么必须需要一组 Sentinel 节点，因为单个 Sentinel 节点很容易对故障状态做出误判。这里 quorum 的值是我们在哨兵模式搭建时指定的，后文会有说明，通常为 `Sentinel节点总数/2+1`，即半数以上节点做出主观下线判断就可以执行客观下线。
+
+因为故障转移的工作只需要一个 Sentinel 节点来完成，所以 Sentinel 节点之间会再做一次选举工作， 基于 Raft 算法选出一个 Sentinel 领导者来进行故障转移的工作。 
+
+被选举出的 Sentinel 领导者就开始进行故障转移， 具体步骤如下：
+
+1. 在从节点列表中选出一个节点作为新的主节点，选择方法如下：
+
+   + 过滤不健康或者不满足要求的节点；
+
+   + 选择 slave-priority（优先级）最高的从节点， 如果存在则返回， 不存在则继续；
+   + 选择复制偏移量最大的从节点 ， 如果存在则返回， 不存在则继续；
+   + 选择 runid 最小的从节点。 
+
+2. Sentinel 领导者节点会对选出来的从节点执行 slaveof no one 命令让其成为主节点。
+3. Sentinel 领导者节点会向剩余的从节点发送命令，让他们从新的主节点上复制数据。
+4. Sentinel 领导者会将原来的主节点更新为从节点， 并对其进行监控， 当其恢复后命令它去复制新的主节点。 
+
+## 三、哨兵模式搭建
+
+## 四、客户端连接
+
+
+

notes/Redis_集群模式.md

@@ -0,0 +1,41 @@
+# Redis Cluster
+
+## 一、集群模式介绍
+
+Redis Cluster 是 Redis 官方提供的分布式实现，在 Redis 3.0 版本正式推出，通过集群模式可以扩展单机的性能瓶颈，同时也可以通过横向扩展来实现扩容。此外，Redis 集群模式还提供了副本迁移机制，用于保证数据的安全和提高集群的容错能力，从而实现高可用。
+
+### 1.1 数据分区
+
+Redis Cluster 采用虚拟槽进行分区，槽是集群内数据管理和迁移的基本单位。所有的键根据哈希函数映射到 16384 个整数槽内，每个节点负责维护一部分槽及槽上的数据，计算公式如下：
+
+```shell
+HASH_SLOT = CRC16(key) mod 16384
+```
+
+### 1.2 节点通讯
+
+在 Redis 分布式架构中，每个节点都存储有整个集群所有节点的元数据信息，这是通过 P2P 的 Gossip 协议来实现的。集群中的每个节点都会单独开辟一个 TCP 通道，用于节点之间彼此通信，通信端口号在基础端口上加 10000；每个节点定期通过特定的规则选择部分节点发送 ping 消息，接收到 ping 信息的节点用 pong 消息作为响应，通过一段时间的彼此通信，最终所有节点都会达到一致的状态，每个节点都会知道整个集群全部节点的状态信息，从而到达集群状态同步的目的。
+
+### 1.3 请求路由
+
+#### 1. 请求重定向
+
+在集群模式下，Redis接收到命令时会先计算键对应的槽，然后根据槽找出对应的目标节点，如果目标节点就是此时所在的节点，则直接处理命令，否则返回 MOVED 重定向消息给客户端，通知客户端去正确的节点上执行操作。
+
+#### 2. Smart 客户端
+
+Redis 的大多数客户端都采用 Smart 客户端支持集群协议， Smart 客户端会在内部缓存槽与节点之间的映射关系，从而在本机就可以查找到正确的节点，这样可以保证 IO 效率的最大化。如果客户端还接收到 MOVED 重定向的消息，则代表客户端内部的缓存已经失效，此时客户端会去重新获取映射关系然后刷新本地缓存。
+
+#### 3. ASK 重定向
+
+当集群处于扩容阶段时，此时槽上的数据可能正在从源节点迁移到目标节点，在这个期间可能出现一部分数据在源节点， 而另一部分在目标节点情况。此时如果源节点接收到命令并判断出键对象不存在， 说明其可能存在于目标节点上， 这时会返回给客户端 ASK 重定向异常。
+
+ASK 重定向与 MOVED 重定向的区别在于：收到 ASK 重定向时说明集群正在进行数据迁移， 客户端无法知道什么时候迁移完成，因此只是临时性的重定向， 客户端不会更新映射缓存。 但是 MOVED 重定向说明键对应的槽已经明确迁移到新的节点， 因此需要更新映射缓存。
+
+### 1.4 故障转移
+
+
+
+## 二、集群模式搭建
+
+## 三、客户端连接