Redis从基础到进阶(二)

一、Redis高级应用

1.1 发布与订阅

Redis提供了发布订阅功能，可以用于消息的传输Redis的发布订阅机制包括三个部分，publisher，subscriber和Channel

发布者和订阅者都是Redis客户端，Channel则为Redis服务器端。发布者将消息发送到某个的频道，订阅了这个频道的订阅者就能接收到这条消息。

当客户端向某个频道发送消息时，Redis首先在redisServer中的pubsub_channels中找出键为该频道的结点，遍历该结点的值，即遍历订阅了该频道的所有客户端，将消息发送给这些客户端。然后，遍历结构体redisServer中的pubsub_patterns，找出包含该频道的模式的结点，将消息发送给订阅了该模式的客户端。

1.2 事务

所谓事务(Transaction) ，是指作为单个逻辑工作单元执行的一系列操作
Redis的事务是通过multi、exec、discard和watch这四个命令来完成的。
Redis的单个命令都是原子性的，所以这里需要确保事务性的对象是命令集合。
Redis将命令集合序列化并确保处于同一事务的命令集合连续且不被打断的执行
Redis不支持回滚操作

1.3 事务机制

1. 事务开始在RedisClient中，有属性flags，用来表示是否在事务中flags=REDIS_MULTI
2. 命令入队RedisClient将命令存放在事务队列中（EXEC,DISCARD,WATCH,MULTI除外）
3. 事务队列multiCmd *commands 用于存放命令
4. 执行事务RedisClient向服务器端发送exec命令，RedisServer会遍历事务队列,执行队列中的命令,最后将执行的结果一次性返回给客户端。如果某条命令在入队过程中发生错误，redisClient将flags置为REDIS_DIRTY_EXEC，EXEC命令将会失败返回

二.高可用方案

“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。CAP的A AP模型单机的Redis是无法保证高可用性的，当Redis服务器宕机后，即使在有持久化的机制下也无法保证不丢失数据。所以我们采用Redis多机和集群的方式来保证Redis的高可用性。单进程+单线程 + 多机（集群）

1.1作用

读写分离
一主多从，主从同步
主负责写，从负责读
提升Redis的性能和吞吐量
主从的数据一致性问题

数据容灾
从机是主机的备份
主机宕机，从机可读不可写
默认情况下主机宕机后，从机不可为主机
利用哨兵可以实现主从切换，做到高可用

1.2原理与实现

（1）复制流程
保存主节点信息
当客户端向从服务器发送slaveof(replicaof) 主机地址（127.0.0.1）端口（6379）时：从服务器将主机ip（127.0.0.1）和端口（6379）保存到redisServer的masterhost和masterport中。
从服务器将向发送SLAVEOF命令的客户端返回OK，表示复制指令已经被接收，而实际上复制工作是在OK返回之后进行。
建立socket连接
slaver与master建立socket连接slaver关联文件事件处理器该处理器接收RDB文件（全量复制）、接收Master传播来的写命令（增量复制）
主服务器accept从服务器Socket连接后，创建相应的客户端状态。相当于从服务器是主服务器的Client端。
发送ping命令
Slaver向Master发送ping命令
1、检测socket的读写状态
2、检测Master能否正常处理
Master的响应：
1、发送“pong” , 说明正常
2、返回错误，说明Master不正常
3、timeout，说明网络超时
权限验证
主从正常连接后，进行权限验证主未设置密码（requirepass=“”），从也不用设置密码（masterauth=“”）主设置密码(requirepass!=""),从需要设置密码(masterauth=主的requirepass的值)或者从通过auth命令向主发送密码。

（2）同步数据
Redis的同步功能分为同步(sync)和命令传播(command propagate)

---

**全量同步** Redis的全量同步过程主要分三个阶段： **同步快照阶段：** aster创建并发送快照RDB给Slave，Slave载入并解析快照。Master同时将此阶段所产生的新的写命令存储到缓冲区。 **同步写缓冲阶段：** Master向Slave同步存储在缓冲区的写操作命令。 **同步增量阶段：** Master向Slave同步写操作命令。

增量同步
同步Redis增量同步主要指Slave完成初始化后开始正常工作时，Master发生的写操作同步到Slave的过程。
通常情况下，Master每执行一个写命令就会向Slave发送相同的写命令，然后Slave接收并执行

1.3哨兵模式

哨兵（sentinel）是Redis的高可用性(High Availability)的解决方案：由一个或多个sentinel实例组成sentinel集群可以监视一个或多个主服务器和多个从服务器。当主服务器进入下线状态时，sentinel可以将该主服务器下的某一从服务器升级为主服务器继续提供服务，从而保证redis的高可用性。
执行流程启动并初始化Sentinel
Sentinel是一个特殊的Redis服务器不会进行持久化Sentinel实例启动后每个Sentinel会创建2个连向主服务器的网络连接命令连接：用于向主服务器发送命令，并接收响应；订阅连接：用于订阅主服务器的—sentinel—:hello频道。

向主服务器和从服务器发送消息(以订阅的方式)
默认情况下，Sentinel每2s一次，向所有被监视的主服务器和从服务器所订阅的—sentinel—:hello频道上发送消息，消息中会携带Sentinel自身的信息和主服务器的信息

接收来自主服务器和从服务器的频道信息
当Sentinel与主服务器或者从服务器建立起订阅连接之后，Sentinel就会通过订阅连接，向服务器发送以下命令：subscribe—sentinel—:hello
Sentinel彼此之间只创建命令连接，而不创建订阅连接，因为Sentinel通过订阅主服务器或从服务器，就可以感知到新的Sentinel的加入，而一旦新Sentinel加入后，相互感知的Sentinel通过命令连接来通信就可以了。

检测主观下线状态
Sentinel每秒一次向所有与它建立了命令连接的实例(主服务器、从服务器和其他Sentinel)发送PING命令
实例在down-after-milliseconds毫秒内返回无效回复(除了+PONG、-LOADING、-MASTERDOWN外)
实例在down-after-milliseconds毫秒内无回复（超时）Sentinel就会认为该实例主观下线(SDown)
检查客观下线状态
当一个Sentinel将一个主服务器判断为主观下线后Sentinel会向同时监控这个主服务器的所有其他Sentinel发送查询命令
判断它们是否也认为主服务器下线。如果达到Sentinel配置中的quorum数量的Sentinel实例都判断主服务器为主观下线，则该主服务器就会被判定为客观下线(ODown)。
选举Leader Sentinel
当一个主服务器被判定为客观下线后，监视这个主服务器的所有Sentinel会通过选举算法（raft），选出一个Leader Sentinel去执行failover（故障转移）操作

1.4哨兵leader选举

Sentinel的leader选举流程

1、某Sentinel认定master客观下线后，该Sentinel会先看看自己有没有投过票，如果自己已经投过票给其他Sentinel了，在一定时间内自己就不会成为Leader。
2、如果该Sentinel还没投过票，那么它就成为Candidate。
3、Sentinel需要完成几件事情：更新故障转移状态为start当前epoch加1，相当于进入一个新term，在Sentinel中epoch就是Raft协议中的term。向其他节点发送is-master-down-by-addr命令请求投票。命令会带上自己的epoch。给自己投一票（leader、leader_epoch）
4、当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；（通过判断epoch）
5、Candidate会不断的统计自己的票数，直到他发现认同他成为Leader的票数超过一半而且超过它配置的quorum，这时它就成为了Leader。
6、其他Sentinel等待Leader从slave选出master后，检测到新的master正常工作后，就会去掉客观下线的标识。
故障转移
当选举出Leader Sentinel后，Leader Sentinel会对下线的主服务器执行故障转移操作，主要有三个步骤：

1. 它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master；
2. 当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。
3. Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行replicaof的配置，sentinel.conf的监控目标会随之调换。
   . 主服务器的选择
   哨兵leader根据以下规则从客观下线的主服务器的从服务器中选择出新的主服务器。
4. 过滤掉主观下线的节点
5. 选择slave-priority最高的节点，如果由则返回没有就继续选择
6. 选择出复制偏移量最大的系节点，因为复制偏移量越大则数据复制的越完整，如果由就返回了，没有就继续4. 选择run_id最小的节点，因为run_id越小说明重启次数越少

1.5集群与分区

hash分区
利用简单的hash算法即可：
Redis实例=hash(key)%Nkey:要进行分区的键，比如user_idN:Redis实例个数(Redis主机)
好处：支持任何类型的key热点分布较均匀，性能较好
缺陷：迁移复杂，需要重新计算，扩展较差（利用一致性hash环）
一致性hash

普通hash是对主机数量取模，而一致性hash是对2^32（4 294 967 296）取模。

优点
添加或移除节点时，数据只需要做部分的迁移，比如上图中把C服务器移除，则数据4迁移到服务器A中，而其他的数据保持不变。添加效果是一样的。
hash环偏移
假设有三台机器，我们理想化的将3台服务器均匀的映射到了hash环上。也就是说数据的范围是2^32/N。但实际情况往往不是这样的。有可能某个服务器的数据会很多，某个服务器的数据会很少，造成服务器性能不平均。这种现象称为hash环偏移。

1.6官方cluster分区

Redis3.0之后，Redis官方提供了完整的集群解决方案。方案采用去中心化的方式，包括：sharding（分区）、replication（复制）、failover（故障转移）。称为RedisCluster。
RedisCluster由多个Redis节点组构成，是一个P2P无中心节点的集群架构，依靠Gossip协议传播的集群。

RedisCluster的优势
高性能
Redis Cluster 的性能与单节点部署是同级别的。
多主节点、负载均衡、读写分离
高可用
Redis Cluster 支持标准的主从复制配置来保障高可用和高可靠。
failover
Redis Cluster 也实现了一个类似 Raft 的共识方式，来保障整个集群的可用性。
易扩展
向 Redis Cluster 中添加新节点，或者移除节点，都是透明的，不需要停机。
水平、垂直方向都非常容易扩展。
数据分区，海量数据，数据存储
原生
部署 Redis Cluster 不需要其他的代理或者工具，而且 Redis Cluster 和单机 Redis 几乎完全兼容。

1.7分区

如果没有分片机制，Redis就被局限于单机所支持的内存容量。Redis的分片机制允许数据拆分存放在不同的Redis实例上，每个Redis实例只包含所有键的子集。可以减轻单台Redis的压力，提升Redis扩展能力和计算能力。如果我们只使用一个Redis实例，当Redis宕机将会直接停止服务，所以我们可以采取分片机制，将原本一台Redis实例维护的数据，改为由多个Redis实例共同维护这部分数据。
迁移
在RedisCluster中每个slot 对应的节点在初始化后就是确定的。在某些情况下，节点和分片需要变更：
新的节点作为master加入；
某个节点分组需要下线；
负载不均衡需要调整slot 分布。
此时需要进行分片的迁移，迁移的触发和过程控制由外部系统完成。包含下面 2 种：
节点迁移状态设置：迁移前标记源/目标节点。
key迁移的原子化命令：迁移的具体步骤。

1.8容灾

故障检测
集群中的每个节点都会定期地（每秒）向集群中的其他节点发送PING消息如果在一定时间内(cluster-node-timeout)，发送ping的节点A没有收到某节点B的pong回应，则A将B标识为pfail。A在后续发送ping时，会带上B的pfail信息，通知给其他节点。如果B被标记为pfail的个数大于集群主节点个数的一半（N/2 + 1）时，B会被标记为fail，A向整个集群广播，该节点已经下线。其他节点收到广播，标记B为fail。
从节点选举
raft，每个从节点，都根据自己对master复制数据的offset，来设置一个选举时间，offset越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举。
RedisCluster失效的判定：
1、集群中半数以上的主节点都宕机（无法投票）
2、宕机的主节点的从节点也宕机了（slot槽分配不连续）