目录
“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。CAP的A AP模型
单机的Redis是无法保证高可用性的，当Redis服务器宕机后，即使在有持久化的机制下也无法保证不丢失数据。
所以我们采用Redis多机和集群的方式来保证Redis的高可用性。
单进程+单线程+多机（集群）
主从复制
Redis支持主从复制功能，可以通过执行slaveof（Redis5以后改成replicaof）或者在配置文件中设置slaveof（Redis5以后改成replicaof）来开启复制功能。
- 主对外从对内，主可写从不可写
- 主挂了，从不可为主
主从配置
主无需特殊配置
从Redis配置
修改从服务器上的redis.conf文件：
# slaveof <masterip> <masterport>
# 表示当前【从服务器】对应的【主服务器】的IP是192.168.10.135，端口是6379。
replicaof 127.0.0.1 6379作用
读写分离
一主多从，主从同步
主负责写，从负责读
提升Redis的性能和吞吐量
主从的数据一致性问题
数据容灾
从机是主机的备份
主机宕机，从机可读不可写
默认情况下主机宕机后，从机不可为主机
利用哨兵可以实现主从切换，做到高可用
原理与实现
复制流程：
保存主节点信息
当客户端向从服务器发送slaveof(replicaof)主机地址（127.0.0.1）端口（6379）时：从服务器将主机ip和端口号保存到redisServer的masterhost和masterport中。
Struct redisServer{
char *masterhost;//主服务器ip
int masterport;//主服务器端口
} ;从服务器将向发送slaveof命令的客户端返回OK，表示复制指令已经被接收，而实际上复制工作是在OK返回之后进行。
建立socket连接
slaver与master建立socket连接
slaver关联文件事件处理器
该处理器接收RDB文件（全量复制）、接收Master传播来的写命令（增量复制）
主服务器accept从服务器Socket连接后，创建相应的客户端状态。相当于从服务器是主服务器的Client端。
发送ping命令
Slaver向Master发送ping命令
- 检测socket的读写状态
- 检测Master能否正常处理
Master的响应：
- 发送pong，说明正常
- 返回错误，说明Master不正常
- timeout，说明网络超时
权限验证
主从正常连接后，进行权限验证
主未设置密码（requirepass=""），从也不设置密码（masterauth=""）
主设置密码（requirepass！=""），从需要设置密码（masterauth=主的requirepass的值）
或者从通过auth命令向主发送密码
发送端口信息
在身份验证步骤之后，从服务器将执行命令REPLCONF listening-port，向主服务器发送从服务器的监听端口号。
同步数据
Redis 2.8之后分为全量同步和增量同步
命令传播
当同步数据完成后，主从服务器就会进入命令传播阶段，主服务器只要将自己执行的写命令发送给从服务器，而从服务器只要一直执行并接收主服务器发来的写命令。
同步数据集
实现方法
Redis的同步功能分为同步（sync）和命令传播（command propagate）。
1）同步操作
- 通过从服务器发送到sync命令给主服务器
- 住服务器生成RDB文件并发送给从服务器，同时发送保存所有写命令给从服务器
- 从服务器清空之前数据并执行解释RDB文件
- 保持数据一致（还需要命令传播过程才能保持一致）
2）命令传播操作：
同步操作完成后，主服务器执行写命令，改命令发送给从服务器并执行，使主从保存一致。
缺陷
没有全量同步和增量同步的概念，从服务器在同步时，会清空所有数据。
主从服务器断线后重复制，主服务器会重新生成RDB文件和重新记录缓冲区的所有命令，并全量同步到从服务器上。
新版
Redis 2.8以后
实现方式
在Redis 2.8之后使用psync命令，具备完整重同步和部分重同步模式。
- Redis的主从同步，分为全量同步和增量同步
- 只有从机第一次连接上主机是全量同步
- 断线重连有可能触发全量同步也有可能是增量同步（master判断runid是否一致）
- 除此以外的情况都是增量同步
全量同步
Redis的全量同步过程主要分三个阶段：
- 同步快照阶段：Master创建并发送快照RDB给slave，slave载入并解析快照。Master同时将此阶段所产生的新的写命令存储到缓冲区
- 同步写缓冲阶段：Master向slave同步存储在缓冲区的写操作命令
- 同步增量阶段：Master向slaver同步写操作命令
增量同步
- Redis增量同步主要指slave完成初始化后开始正常工作时，Master发生的写操作同步到slave的过程
- 通常情况下，Master每执行一个写命令就会向slave发送相同的写命令，然后slave接收并执行
心跳检测
在命令传播阶段，从服务器默认会以每秒一次的频率向主服务器发送命令：
replconf ack <replication_offset>
#ack : 应答#replication_offset ：从服务器当前的复制偏移量
- 检测主从的连接状态
检测主从服务器的网络连接状态
通过向服务器发送INFO replication命令，可以列出从服务器列表，可以看出从最后一次向主发送命令距离现在过了多少秒。lag的值应该在0或1之间跳动，如果超过1则说明主从之间的连接有故障 - 辅助实现min-slaves
Redis可以通过配置防止主服务器在不安全的情况下执行写命令
min-slaves-to-write 3 （min-replicas-to-write 3）
min-slaves-max-lag 10 （min-replicas-max-lag 10）
上面的配置表示：从服务器的数量少于3个，或者三个从服务器的延迟（lag）值都大于或等于10秒时，主服务器将拒绝执行写命令。这里的延迟值就是上面INFOreplication命令的lag值 - 检测命令丢失
如果因为网络故障，主服务器传播给从服务器的写命令在半路丢失，那么当从服务器向主服务器发送 REPLCONF ACK 命令时，主服务器将发觉从服务器当前的复制偏移量少于自己的复制偏移量，然后主服务器就会根据从服务器提交的复制偏移量，在复制积压缓冲区里面找到从服务器缺少的数据，并将这些数据重新发送给从服务器。（补发） 网络不断增量同步：网断了，再次连接时
哨兵模式
哨兵（sentinel）是Redis的高可用性（High Availability）的解决方案：
由一个或多个sentinel实例组成sentinel集群可以监视一个或多个主服务器和多个从服务器。
当主服务器进入下线状态时，sentinel可以将该主服务器下的某一个从服务器升级为主服务器继续提供服务，从而保证Redis的高可用性。
部署方案
执行流程
启动并初始化Sentinel
Sentinel是一个特殊的Redis服务器
不会进行持久化
Sentinel实例启动后
subscribe —sentinel—:hello每个Sentinel会创建两个连向主服务器的网络连接
命令连接：用于向主服务器发送命令，并接收响应
订阅连接：用于订阅主服务器的--sentinel-:hello频道
获取主服务器信息
Sentinel默认每10s一次，向被监视的主服务器发送info命令，获取主服务器和其下属从服务器的信息。
获取从服务器信息
当Sentinel发现主服务器有新的从服务器出现时，Sentinel还会向从服务器建立命令连接和订阅连接。在命令连接建立后，Sentinel还是默认10s一次，向从服务器发送info命令，并记录从服务器的信息。
接收来自主服务器和从服务器的频道信息
当Sentinel与主服务器或者从服务器建立起订阅连接之后，Sentinel就会通过订阅连接，向服务器发送以下命令
subscribe —sentinel—:helloSentinel彼此之间只创建命令连接，而不创建订阅连接，因为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（故障转移）操作。
哨兵Leader选举
Raft
Raft协议是用来解决分布式系统一致性问题的协议。
Raft协议描述的节点共有三种状态：Leader、Follower、Candidate。
term：Raft协议将时间切分为一个个的Term（任期），可以认为是一种"逻辑时间"。
Sentinel的leader选举流程
- 某Sentinel认定master客观下线后，该Sentinel会先看看自己有没有投过票，如果自己已经投过票给其他Sentinel了，在一定时间内，自己就不会成为Leader。
- 如果该Sentinel还没投过票，那么它就成为Candidate。
- Sentinel需要完成几件事情：
- 更新故障转移状态为start
- 当前epoch加1，相当于进入一个新term，在Sentinel中epoch就是Raft协议中的term。
- 向其他节点发送is-master-down-by-addr命令请求投票。命令会带上自己的epoch。
- 给自己投一票（Leader、leader_epoch）
- 当其他哨兵收到此命令时，可以同意或者拒绝它成为领导；（通过判断epoch）
- Candidate会不断的统计自己的票数，直到它发现认同它成为Leader的票数超过一半而且超过它配置的quorum，这时它就成为了Leader。
- 其他Sentinel等待Leader从slave选出master后，检测到新的master正常工作后，就会去掉客观下线的标识。
故障转移
当选举出Leader Sentinel后，Leader Sentinel会对下线的主服务执行故障转移操作，主要有三个步骤：
- 它会将失效Master的其中一个slave升级为新的Master，并让失效Master的其他slave改为复制新的Master
- 当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master
- Master和slave服务器切换后，Master的redis.conf、slave、的redis.conf和sentinel.conf的配置文件的内容都会发生改变，即，Master主服务器的redis.conf配置文件中会多一行replicaof的配置，sentinel.conf的监控目标会随之调换
主服务器的选择
哨兵Leader根据以下规则从客观下线的主服务器的从服务器中选择出新的主服务器。
- 过滤掉主观下线的节点
- 选择slave-priority最高的节点，如果有则返回，没有就继续选择
- 选择出复制偏移量最大的系节点，因为复制偏移量越大则数据复制的越完整，如果有就返回了，没有就复制
- 选择run_id最小的节点，因为run_id越小说明重启次数越少
集群与分区
- 性能的提升
单机Redis的网络I/O能力和计算资源是有限的，将请求分散到多台机器，充分利用多台机器的计算能力可网络带宽，有助于提高Redis总体的服务能力。 - 存储能力的横向扩展
即使Redis的服务能力能够满足应用需求，但是随着存储数据的增加，单台机器受限于机器本身的存储容量，将数据分散到多台机器上存储使得Redis服务可以横向扩展。
分区的方式
范围分区
根据id数字的范围比如1--10000、100001--20000.....90001-100000，每个范围分到不同的Redis实例中
好处： 实现简单，方便迁移和扩展
缺陷： 热点数据分布不均，性能损失
非数字型key，比如uuid无法使用(可采用雪花算法替代) 分布式环境
主键 雪花算法
是数字
能排序
hash分区
利用简单的hash算法即可：
Redis实例=hash(key)%N
key:要进行分区的键，比如user_id
N:Redis实例个数(Redis主机)
好处：支持任何类型的key， 热点分布较均匀，性能较好
缺陷： 迁移复杂，需要重新计算，扩展较差（利用一致性hash环）
client端分区
对于一个给定的key，客户端直接选择正确的几点进行读写。许多Redis客户端都实现了客户端分区（JedisPool），也可以自行编程实现
部署方案
客户端选择算法
hash
普通hash
hash(key)%N
hash：可以采用hash算法，比如CRC32、CRC16等
N：是Redis的个数
普通hash的优势
实现简单，热点数据分布均匀
普通hash的缺陷
节点数固定，扩展的话需要重新计算
查询时必须用分片的key来查，一旦key改变，数据就查不出来了，所有要使用不易改变的key进行分片
一致性hash
利用一致性hash环
普通hash是对主机数量取模，而一致性hash是对2^32（4 294 967 296）取模。我们把2^32想象成一个圆，就像钟表一样，钟表的圆可以理解成由60个点组成的圆，而此处我们把这个圆想象成由2^32个点组成的圆
假设我们有3台缓存服务器，服务器A、服务器B、服务器C，那么，在生产环境中，这三台服务器肯定有自己的IP地址，我们使用它们各自的IP地址进行哈希计算，使用哈希后的结果对2^32取模式算出的结果一定是一个0到2^32-1之间的一个整数，我们就用算出的这个整数，代表服务器A、服务器B、服务器C，既然这个整数肯定处于0到2^32-1之间，那么，上图中的hash环上必定有一个点与这个整数对应，也就是服务器A、服务器B、服务C就可以映射到这个环上
优点
添加或移除节点时，数据只需要做部分的迁移，添加效果是一样的。
proxy端分区
在客户端和服务端引入一个代理或代理集群，客户端将命令发送到代理上，由代理根据算法，将命令路由到相应的服务器上。常见的代理有Codis（豌豆荚）和TwemProxy（Twitter）。
部署架构
Codis由豌豆荚于2014年11月开源，基于Go和C开发，是近期涌现的、国人开发的优秀开源软件之一。
Codis 3.x由以下组件组成：
- Codis Server：基于redis-3.2.8分支开发。增加了额外的数据结构，以支持slot有关的操作以及数据迁移
- Codes Proxy：客户端连接的Redis代理服务，实现了Redis协议。除部分命令不支持以外（不支持的命令列表），表现的和原生的Redis没有区别（就像Twemproxy）。
- 对于同一个业务集群而言，可以同时部署多个codis-proxy实例；
- 不同codis-proxy之间由codis-dashboard保证状态同步。
- Codis Dashboard：集群管理工具，支持codis-proxy、codis-server的添加、删除，以及数据迁移等操作。在集群状态发生改变时，codis-dashboard维护集群下所有codis-proxy的状态的一致性。
- 对于同一个业务集群而言，同一个时刻codis-dashboard只能有0个或者1个；
- 所有对集群的修改都必须通过codis-dashboard完成。
- Codis Admin：集群管理命令行工具。
- 可用于控制codis-proxy、codis-dashboard状态以及访问外部存储。
- Codis FE：集群管理页面。
- 多个集群实例共享可以共享同一个前端展示页面；
- 通过配置文件管理后端codis-dashboard列表，配置文件可自动更新。
- Storage：为集群状态提供外部存储。
- 提供Namespace概念，不同集群的会按照不同product name进行组织；
- 目前仅提供了Zookeeper、Etcd、Fs三种实现，但是提供了抽象的interface可自动扩展。
分片原理
Codis将所有的key默认划分为1024个槽位（slot），它首先对客户端传过来的key进行crc32运算计算哈希值，再将hash后的整数值对1024这个整数进行取模得到一个余数，这个余数就是对应key的槽位。
Codis的槽位和分组的映射关系就保存在codis proxy当中。
实例之间槽位同步
codis proxy存在单点问题，需要做集群。
不同proxy之间需要同步映射关系
在Codis中使用的是Zookeeper（Etcd）来保存映射关系
Codis将槽位关系存储在zk中，并且提供了一个Dashboard可以用来观察和修改槽位关系，当槽位关系变化时，Codis Proxy会监听到变化并重新同步关系，从而实现多个Codis Proxy之间共享相同的槽位关系配置。
扩容&自动均衡
新增一组redis（一主一从）
Codis-Server配置（Redis）
启动codis中的redis-3.2.8实例
利用admin/codis-sever-admin.sh启动
如果配置多个需要修改config/redis.conf (redis.conf默认6379）
启动Codis Server
#启动Codis Server
./admin/codis-server-admin-6381.sh start
./admin/codis-server-admin-6382.sh start通过web管理
添加新组、添加主机、添加从机后
点击“Rebalance All Slots”
通过codis客户端添加数据
优点&缺点
优点
- 对客户端透明，与codis交互方式和redis本身交互一样
- 支持在线数据迁移，迁移过程对客户端透明有简单的管理和监控界面
- 支持高可用，无论是redis数据存储还是代理节点
- 自动进行数据的均衡分配
- 最大支持1024个redis实例，存储容量海量
- 高性能
缺点
- 采用自有的redis分支，不能与原版的redis保持同步
- 如果codis的proxy只有一个的情况下，redis的性能会下降20%左右
- 某些命令不支持
1928
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
