复制（master、slave）

配置过程

修改11.140和11.141的redis.conf文件，增加slaveof masterip masterport

slaveof 192.168.11.138 6379

实现原理

1. slave第一次或者重连到master上以后，会向master发送一个SYNC的命令

2. master收到SYNC的时候，会做两件事

a) 执行bgsave（rdb的快照文件）

b) master会把新收到的修改命令存入到缓冲区

缺点：没有办法对master进行动态选举

复制的方式

1. 基于rdb文件的复制（第一次连接或者重连的时候）

2. 无硬盘复制

3. 增量复制

PSYNC master run id. offset

哨兵机制

sentinel

1. 监控master和salve是否正常运行

2. 如果master出现故障，那么会把其中一台salve数据升级为master

集群（redis3.0以后的功能）

根据key的hash值取模 服务器的数量 。

hash

集群的原理

Redis Cluster中，Sharding采用slot(槽)的概念，一共分成16384个槽，这有点儿类似前面讲的pre sharding思路。对于每个进入Redis的键值对，根据key进行散列，分配到这16384个slot中的某一个中。使用的hash算法也比较简单，就是CRC16后16384取模。Redis集群中的每个node(节点)负责分摊这16384个slot中的一部分，也就是说，每个slot都对应一个node负责处理。当动态添加或减少node节点时，需要将16384个槽做个再分配，槽中的键值也要迁移。当然，这一过程，在目前实现中，还处于半自动状态，需要人工介入。Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作。为了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。这时，如果主节点失效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务。这非常类似服务器节点通过Sentinel监控架构成主从结构，只是Redis Cluster本身提供了故障转移容错的能力。

slot（槽）的概念，在redis集群中一共会有16384个槽，

根据key 的CRC16算法，得到的结果再对16384进行取模。 假如有3个节点

node1 0 5460

node2 5461 10922

node3 10923 16383

节点新增

node4 0-1364,5461-6826,10923-12287

删除节点

先将节点的数据移动到其他节点上，然后才能执行删除