Redis（七）高可用
一.高可用的概念
高可用(High Availability)是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。
通过三大要点解释高可用：
(1)单点是系统可用的大敌，应该尽量在系统设计的过程中避免单点
(2)保证系统高可用，架构设计的核心准则是：冗余
(3)每次出现故障需要人工介入恢复势必会增加系统的不可服务时间，应实现自动故障转移。
二.高可用架构Sentinel
1.Redis主从复制可将主节点数据同步给从节点，从节点此时有两个作用
(1)一旦主节点宕机，从节点作为主节点的备份可以随时顶上来
(2)扩展主节点的读能力分担主节点读压力
一旦主节点宕机，需要手动将从节点晋升成主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，使用Sentinel可以替代手动，自动实现以上操作
2.Sentinel配置
sentinel monitor mymaster 127.0.0.1 6379 1
sentinel down-after-milliseconds mymaster 10000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1命令讲解
sentinel monitor mymaster 127.0.0.1 6379 1 名称为mymaster的主节点名，1表示将这个
主服务器判断为失效至少需要 1个 Sentinel 同意 （只要同意 Sentinel 的数量不达标，自动故
障迁移就不会执行）
down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数
failover过期时间，当failover开始后，在此时间内仍然没有触发任何failover操作，当前
sentinel 将会认为此次failover失败
parallel-syncs 选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服
务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。
如果从服务器被设置为允许使用过期数据集， 那么你可能不希望所有从服务器都在同⼀时间
向新的主服务器发送同步请求， 因为尽管复制过程的绝大部分步骤都不会阻塞从服务器， 但
从服务器在载入主服务器发来的 RDB ⽂文件时， 仍然会造成从服务器在一段时间内不能处理
命令请求： 如果全部从服务器一起对新的主服务器进行同步， 那么就可能会造成所有从服务
器在短时间内全部不可用的情况出现。
3.Sentinel三⼤大⼯工作任务
监控（Monitoring）： Sentinel 会不不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API
向管理理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始
一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并
让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器
时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务
器。
4.冷备和热备的特点分析
冷备
概念：冷备份发生在数据库已经正常关闭的情况下，当正常关闭时会提供给我们一个完
整的数据库
优点：
是非常快速的备份方法（只需拷⽂文件）
低度维护，高度安全
缺点：
单独使用时，只能提供到“某一时间点上”的恢复
再实施备份的全过程中，数据库必须要作备份而不能作其他工作。也就是说，在冷
备份过程中，数据库必须是关闭状态
热备
概念：热备份是在数据库运行的情况下，采用archivelog mode方式备份数据库的方法
优点：
备份的时间短
备份时数据库仍可使用
可达到秒级恢复
缺点
若热备份不成功，所得结果不可用于时间点的恢复
因难于维护，所以要非常仔细小心
5.Sentinel是怎么工作的？
主观下线：
概念主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做
出的下线判断
主观下线特点：
如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内， 对向
它发送 PING 命令的 Sentinel 返回⼀一个有效回复（valid reply）， 那么 Sentinel 就会将
这个服务器标记为主观下线
服务器对 PING 命令的有效回复可以是以下三种回复的其中⼀一种：
返回 +PONG 。
返回 -LOADING 错误。
返回 -MASTERDOWN 错误。
客观下线
客观下线概念：
指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL
is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断。 （一个
Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来
询问对方是否认为给定的服务器已下线。）
客观下线特点：
从主观下线状态切换到客观下线状态并没有使用严格的法定人数算法（strong quorum
algorithm）， 而是使用了流⾔言协议： 如果 Sentinel 在给定的时间范围内， 从其他
Sentinel 那里接收到了足够数量的主服务器下线报告， 那么 Sentinel 就会将主服务器
的状态从主观下线改变为客观下线。 如果之后其他 Sentinel 不再报告主服务器已下
线， 那么客观下线状态就会被移除。
客观下线注意点：
客观下线条件只适用于主服务器： 对于任何其他类型的 Redis 实例， Sentinel 在将它
们判断为下线前不需要进行协商， 所以从服务器或者其他 Sentinel 永远不会达到客观
下线条件。 只要一个 Sentinel 发现某个主服务器进入了客观下线状态， 这个 Sentinel
就可能会被其他 Sentinel 推选出， 并对失效的主服务器执行自动故障迁移操作。
三.高可用集群Cluster(3.0之后版本出现)
1.Redis 集群的数据分片
概念：Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个
槽.集群的每个节点负责一部分hash槽
举个例子,比如当前集群有3个节点,那么:
节点 A 约包含 0 到 5500号哈希槽.
节点 B 约包含5501 到 11000 号哈希槽.
节点 C 约包含11001 到 16384号哈希槽.
查看集群信息redis-cli -p 7000 cluster nodes | grep master
这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C
中得部分槽到D上. 如果我想移除节点A,需要将A中的槽移到B和C节点上,然后将没有任何
槽的A节点从集群中移除即可. 由于从一个节点将哈希槽移动到另一个节点并不会停止服
务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.
Redis 集群的主从复制模型
为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主
从复制模型,每个节点都会有N-1个复制品. 在我们例子中具有A，B，C三个节点的集群,在没有
复制模型的情况下,如果节点B失败了，那么整个集群就会以为缺少5501-11000这个范围的槽
而不可用.Redis集群做主从备份解决了这个问题
Redis 一致性保证
主节点对命令的复制工作发生在返回命令回复之后， 因为如果每次处理命令请求都需要等待
复制操作完成的话， 那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和
一致性之间做出权衡。 注意：Redis 集群可能会在将来提供同步写的方法。 Redis 集群另外
一种可能会丢失命令的情况是集群出现了网络分区， 并且一个客户端与至少包括一个主节点
在内的少数实例被孤立。
手动测试故障转移
redis-cli -p 7000 debug segfault
redis-cli -p 7001 cluster nodes | grep master2.水平分片与垂直分片
水平切分与垂直切分相比，相对来说稍微复杂一些。因为要将同一个表中的不同数据拆分到
不同的数据库中。 分片是一种基于数据库分成若干片段的传统概念扩容技术，它将数据库分
割成多个碎片并将这些碎片放置在不同的服务器上。
垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非常
低，相互影响很小，业务逻辑非常清晰的系统。按照业务维度将不同数据放入不同的表
四.twemproxy服务端分片
1.概念：
Twemproxy，也叫nutcraker。是一个twtter开源的一个redis和memcache快速/轻量级代理服务
器; Twemproxy是一个快速的单线程代理程序，支持Memcached 和Redis。Redis代理中间件
twemproxy是一种利用中间件做分片的技术。twemproxy处于客户端和服务器的中间，将客户端
发来的请求，进行一定的处理后（sharding），再转发给后端真正的redis服务器
2.作用：
Twemproxy通过引入一个代理层，可以将其后端的多台Redis或Memcached实例进行统一管理与
分配，使应用程序只需要在Twemproxy上进行操作，而不用关心后面具体有多少个真实的Redis或
Memcached存储
3.特性：
(1)支持失败节点自动删除
(2)可以设置重新连接该节点的时间
(3)可以设置连接多少次之后删除该节点
(4)减少了客户端直接与服务器连接的连接数量
自动分片到后端多个redis实例上
多种哈希算法
md5，crc16，crc32，crc32a，fnv1_64，fnv1a_64，fnv1_32，fnv1a_32，hsieh，
murmur，jenkins
多种分片算法
ketama（一致性hash算法的一种实现），modula，random