复制（replication）
master slave
架构做成主从架构，一主多从，主负责写，并且将数据同步复制到其他的slave节点，从节点负责读。所有的读请求全部走从节点
master下面跟太多slave节点会影响性能，slave节点下面再跟slave节点
查看集群状态
info replication
redis replication -> redis主从架构 -> 读写分离架构 -> 可支持水平扩展的读高并发架构
redis replication的核心机制
1.redis采用异步方式复制数据到slave节点，不过从redis2.8开始，slave node会周期性的确认自己每次复制的数据量
2.一个master node可以配置多个slave node
3.slave node也可以连接其他的slave node
4.slave node做复制的时候，是不会block master node的正常工作
5.slave node在做复制的时候，也不会block对自己的查询操作，它会用旧的数据集来提供服务，但是在复制完成的时候，需要删除旧数据集吗，加载新数据集，这个时候就会暂停对外服务了
6.slave node主要用来进行横向扩容，做读写分离，扩容的slave node可以挺高读的吞吐量
实现原理
- slave第一次或者重连到master上以后，会向master发送一个SYNC的命令
- master收到SYNC的时候，会做两件事
a) 执行bgsave（rdb的快照文件）
b)master会把新收到的修改命令存到缓冲区
主从不一致，将主的rdb文件复制到从即可
缺点：没有办法对master进行动态选举
复制的方式
- 基于rdb文件的复制（第一次连接或者重连的时候）
- 无硬盘复制
- 增量复制
主从架构的核心原理
当启动一个slave node的时候，它会发送一个PSYNC命令给master node
如果这是slave node重新连接master node，那么master node 仅仅会复制给slave部分缺少的数据，如果是slave node第一次连接master node，开始full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有命令缓存在内存汇总，RDB文件生成完毕之后，master会建这个RDB发送给slave，slave会先写入本地磁盘，让后再从本地磁盘加载到内存中。然后master会建内存中缓存的写命令发送给slave，slave也会同步这些数据。
slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node
主从复制的断点续传
从redis2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下载区，而不是从头开始复制一份
无磁盘化复制
master在内存中直接创建rdb，然后发送给slave，不会再本地磁盘生成rdb文件
repl-diskless-sync
repl-diskless-sync-delay 等待一定时长再开始复制，因为要等更多slave重新连接过来
过期key处理
slave不会过期key，只会等master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave
哨兵机制（sentinel）
这是一个高可用集群，不是一个高性能集群
哨兵之间可以互相监控
- 监控master和salve是否正常运行
- 如果master出现故障，那么会把其中一台salve升级为master
这个在master node 故障时，自动检测，并且将某个slave node自动切换为master node的过程，叫做主备切换。这个过程，实现了redis的主从架构下的高可用
sentinel node
哨兵的介绍
sentinel ，中文名是哨兵
哨兵是redis集群架构中非常重要的一个组件，主要功能如下
- 集群监控，负责监控redis master和slave 进程是否正常工作
- 消息通知，如果某个redis实力有故障，那么哨兵负责发送消息作为警报通知给管理员
- 故障转移，如果master node 挂掉了，会自动转移到slave node上
- 配置中心，如果故障转移发生了，通知client客户端新的master地址
哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作
- 故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题
- 即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的。
哨兵的核心知识
- 哨兵至少需要3个实例，来保证自己的健壮性
- 哨兵+redis主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性
哨兵主备切换的数据丢失问题
异步复制
集群脑裂
集群（Redis Cluster）
redis3.0以后的功能
高性能集群
原来一致性hash,
根据key的hash值取模服务器的数量（应用层面）
slot（槽）的概念，在redis集群中一共会有16384个槽
根据key的CRC16算法，得到的结构再对16384进行取模。假如有3个节点16384/3=5000多
node1 0 5460
node2 5461 10922
node3 10923 16383
节点新增
删除节点
支撑N个redis master node，每个master node都可以挂载多个slave node
读写分离架构：对于每个master来说，写就写到master，然后读就从对应的slave去读
高可用：因为每个master都有slave节点，如果master挂掉，redis cluster这套机制，就会自动将某个slave切换成master
redist clust(多master + 读写分离 + 高可用)
我们只需要基于redis cluster去搭建redis集群即可，不需要手工去搭建replication复制+主从架构+读写分离+哨兵集群+高可用
市面上提供了集群方案
1.redis shardding 而且jedis客户端就支持shardding操作 sharddingJedis
增加和减少节点的问题，pre shardding
3台虚拟机redis，但我部署了9个节点，每一台部署3个redis增加cpu利用率
9个节点单独拆分到9台服务器
2.codis
3.twemproxy
以前redis如果要搞多个节点，每个节点存储一部分数据，得借助一些中间件来实现，如codis，twemproxy，读写redis中间件，redis中间件将数据分布式存储在多台机器上的redis示实例中
redis cluster vs replication + sentinel
如果数据量很少，主要是承载高并发高性能的场景，比如你的缓存一般就几个G，单机足够了
replication，一个master，多个slave，要多个slave跟你要求的吞吐量有关系，然后自己搭建一个sentinal集群，去保证redis主从架构的高可用，就可以了
redis cluster，主要是针对海量数据+高并发+高可用的场景，如果数据量很大，建议用redis cluster
redis高并发：主从架构，一主多从，单主用来写入数据，单机几万QPS，多从用来查询数据，多个从市里可以提供每秒10w的QPS
reids高可用：主从+哨兵
参考博客
[1]
