Redis主从、哨兵、Cluster特性
Redis主从复制
特点：
a、多个redis节点，有且仅有一个主节点master，多个从节点slave。
b、只要网络正常，master节点会一直将自己的数据同步更新给所有slave节点(异步的方式)。
c、master节点可读可写，slave节点只读。
优点：
a、支持主从复制，maser节点会自动将数据同步给slaves节点，可以进行读写分离
b、master是以非阻塞的方式为slaves提供服务。所以在同步期间，客户端仍然可以提交读写请求。
缺陷：
a、master节点宕机，宕机前有部分数据未能及时同步给slave，客户端重连到可用slave后，会出现数据不一致的问题。
b、不具备故障自动转移，master节点宕机会导致整个集群不能执行写操作，需要等待机器从起或者客户端手动切换到可用slave。
c、单个master节点内存有限且不易设置过大，否则会导致持久化文件过大，影响数据恢复和主从同步效率。
Redis哨兵模式
特点：
a、redis提供了哨兵的命令，哨兵是一个独立的进程，独立运行。
b、哨兵通过定时给每个redis节点发送命令，检查所有(包括master和slave)节点是否运行正常。
c、也可以配置多哨兵模式，各个哨兵之间还会互相监控(客户端是连接的是哨兵，而不是master节点)。
d、当哨兵检测到master宕机，它会自动进行选举，将其中一个slave升级为master，然后通过发布订阅模式通知其它slave，修改配置文件，让它们切换主节点。
投票选举过程：当任何一个哨兵发现master下线时(主观下线)，会询问其它哨兵，投票决定该master是否下线。如果超过半数哨兵投票，则进行failover操作，并通过发布订阅模式其它哨兵把自己监控的master切为slave(客观下线) 。最后在所有slave中选举一个新的master节点。
优点：
a、哨兵模式是基于主从模式的，具有主从的所有优点。
b、当master宕机后，可实现故障自动转移。
缺陷：
a、当master节点宕机后，哨兵会判断是否下下线然后选举新的master节点，这个过程中会出现访问瞬断。
b、哨兵模式只有一个master节点对外提供写服务，没法支持很高的并发。
c、单个master节点内存有限且不易设置过大，否则会导致持久化文件过大，影响数据恢复和主从同步效率。
Cluster模式
特点：
a、redis-cluster采用去中心结构，所有redis节点彼此互联(ping-pong机制)。
b、主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。
c、节点的fail是通过集群中超过半数节点检测失效时才失效。
d、客户端与redis节点直连，不需要中间proxy层，客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。
e、redis-cluster把所有物理节点映射到 [0-16383] 上(不一定是平均分配)，cluster负责维护node，slot、value。
f、当需要在redis集群中放置一个key-value时，根据CRC16(key) % 16384 的值，决定将一个key放到哪个slot中。
优点：
a、具有主从的所有优点，同时也支持故障自动转移(投票机制)。
b、可线性扩展到1000多个节点，节点可动态添加或删除。
c、每个节点和其它节点连接，而且这些连接保持活跃，这样连接集群中任一节点就可以获取到其它节点数据。
缺陷：
a、只支持具有相同slot值的key执行批量操作。如：mset、mget。
b、不支持多数据库空间。单机下Redis支持16个数据库，集群模式下只能使用一个数据库空间，即db 0。
c、redis-cluster采用虚拟槽分区，可能存在数据倾斜问题。
Twemproxy集群
特点：
通过 twemproxy 代理对 redis key 进行分片计算，分配到多个redis 实例中的其中一个。
数据倾斜解决方案：
a、如果是bigvalue，可以将这个 key 打散，然后分别对应一个个小value，再存放到redis集群中。
b、将 hotkey 所在的节点的部分 slot 迁移到其它节点上。
c、对于只读的 hotkey，可以采用不同 hotkey 前缀的多副本方法：
比如有 N 个redis节点，计算出一个1~N的随机数，然后作为前缀与 hotkey 拼接得到 tempkey。程序会优先访问 tempkey，如果查不到数据，再访问原来的 hotkey，并将 hotkey 的值写给 tempkey。这样下一次访问 hotkey 时，压力就分散到不同redis节点上了。另外 tempkey 的过期时间是 hotkey 的过期时间加上一个较小的随机正整数，保证在 hotkey 过期后，所有 tempkey 不会同时过期而造成缓存雪崩。
