主从、哨兵、分片

redis主从：
redis单节点的并发能力有上限，可以通过搭建主从集群来提高单节点的并发能力。在从集群中如果是写操作应该访问master，master会将集群数据同步给从节点。如果是读操作，应该访问从节点，这样可以分担系统中的并发压力。

redis主从同步原理总结：
1.在从节点第一次同步或者断开重连时，主节点需要判断从节点是不是第一次来同步。如果是第一次来同步，那么就将自己的全部数据发送给从节点（全量同步）。否则主节点就只发送从节点缺少的数据（增量同步）。正常情况下当主节点进行写数据的时候，可以将主节点的命令传播给从节点保持实时同步。
2.每一个主节点都有自己的master_replid，并且每个主节点的master_replid都不一样，但是当主从关系初次建立好之后，每个从节点的master_replid都与自己主节点的master_replid一致。这样就可以判断当前从节点是不是第一次来从主节点同步数据。
3.当做好判断以后，就开始同步数据，如果要执行全量同步那么主节点开始一个单独的进程，执行bgsave命令，将内存中的数据生成RDB文件。发送生成的RDB文件发送给从节点。但是当从节点因为网络故障、宕机等原因，导致从节点不能实时收到主节点传播的命令，这时候主从两者之间就会出现了数据差异，当从节点网络恢复的时候就会去重连主节点，要求主节点将差异的数据，也就是命令重新发送一份。
4.在第一次建立连接的时候，主节点会记录一个环形数组repl_backlog，记录所有的写操作命令。属性offset来记录写入数据的长度，写入操作越多，offset操作越大。主从的offset相同代表数据一致。从节点的offset值在正常情况下每接收到一个主节点的操作就会offset加一，代表者主节点传递过来的数据有多少。主节点的offset和从节点的offset差值为需要同步的数据。
5.repl_backlog中记录了redis处理过的命令以及offset，包括主节点当前的offset和从节点已经复制到的offset

如果一定使用全量同步可以使用以下调优方式
1.在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO。
2.Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
3.适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
4.限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

引入一个新问题：
当主从集群中，从节点故障以后恢复过来，可以从主节点同步数据，但是当主节点故障以后呢？所以这里引入一个哨兵机制。哨兵机制可以实现主从集群的故障恢复。

哨兵原理：
哨兵会实时检测主从节点是不是按照预期进行工作。如果检测到主节点故障以后，哨兵会将一个从节点提升为主节点，之前故障的主节点在恢复以后也以新的主节点为主。当发生这种故障转移的时候，哨兵会将最新的角色信息推送给redis的所有节点。

服务监测选举故障转移机制：
1.哨兵每隔一段时间，都会向集群的每个实例发送ping命令。如果哨兵发现某个节点没有按照规定的时间返回响应，那么哨兵就会主观认为该实例下线。还有一种情况若超过指定数量的哨兵都主管认为该实例下线了，那么该实例就是客观下线。
2.当发现有主节点宕机以后，这时候就要选举新的主节点了，选举的时候首先判断从节点和主节点断开的时间长短，如果断开的时间超过指定的值那么就直接排除该从节点,数据相差太大，不能选举为主节点。然后判断从节点的优先级，值越小优先级越高。（如果某一个从节点的优先级是0，那么该从节点永远不会被选举。）但是如果所有的从节点优先级都一样那么就根据offset的值做判断，值越大选取为主节点的优先级越高。当所有的offset值都一样，那么就根据从节点的运行
id进行判断，运行id越小优先级越高。
3.当选取了其中一个从节点作为主节点之后，就要进行故障转移操作，首先哨兵会给新选举的从节点发送执行salveof no one，让该节点称为新的主节点。给其他从节点slaveof ip port 命令称为主节点的从节点，最后将故障节点标记为从节点，故障恢复后会自动称为新的从节点。

redis分片集群
主从和哨兵可以解决高可用，高并发的问题，但是仍然没有解决海量数据的存储问题，高并发写的问题，所以引入了redis分片集群。在主从集群中存在主从节点之间的数据同步问题，单节点的内存不能太大，否则存在大量的磁盘io，会影响redis的性能，不能满足海量数据存储的问题。同时主从集群有多个从节点，但是只有一个主节点，无法满足高并发写的问题。

使用分片集群可以解决以上问题：
在分片集群中可以将海量的数据分片存储在多个主节点中，每个主节点保存不同的数据，与此同时每个主节点还可以有多个从节点。多个主节点之间可以通过ping检测彼此的健康状态。

redis如何判断某个key在那个实例上？
在分片集群中总共有16348个散列插槽。每一个节点都会分配一定数量的散列插槽。用来判断数据存储在哪里。也就是说，redis的数据不是与节点绑定，而是与插槽绑定，当我们读写数据时，redis对key做哈希运算，得到的结果和16384进行取余，就计算出来了这个key的插槽位置。然后就可以在相关的位置上进行读写操作。在哈希运算的时候如果key中包含了{}，则根据{}之间的字符串计算，不包含{}的时候则根据整个字符串进行计算。{wubainian}name:根据wubainian进行计算。