redis架构

主从模式：

实现读写分离，提高并发量；

实现高可用，主宕机后，把从节点提升为主节点，通过哨兵模式来自动从从节点中选出主节点；

主从同步流程：

1）从服务器连接主服务器，发送SYNC命令；
2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

哨兵模式

是在主从模式基础上建立起来的主从监控。

在主down掉后，哨兵模式通过选举重新选出主节点

链接哨兵服务器：

##连接哨兵
redis-cli -p 27002
##获取当前master的地址
SENTINEL get-master-addr-by-name mymaster

业务方通过连接哨兵服务器来获取新的主连接。
主从切换的过程中会丢失数据，因为只有一个 master，所以在切换过程中服务是不可用的。

集群模式

客户端直连redis服务，免去了proxy代理的损耗

Redis集群没有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

• key的空间被分到16384个hash slot里；

• 计算key属于哪个slot，CRC16(key) & 16384。

如果某个节点失效，会缺失部分slot，redis整个集群就不可用了。扩缩容就是移动slot，扩容时其他的redis节点会将对应的slot移动到新的节点上。

集群模式缺陷：对于批量的指令，如mget支持不完整；不支持事务；不支持数据库切换，只能使用0号数据库。数据迁移，纯手动操作，先分配slot，再将slot中对应的key迁移至新的节点。

代理模式

twemproxy，使用方法和普通redis无任何区别，设置好它下属的多个redis实例后，使用时在本需要连接redis的地方改为连接twemproxy，它会以一个代理的身份接收请求并使用一致性hash算法，将请求转接到具体redis，将结果再返回twemproxy。使用方式简便(相对redis只需修改连接端口)，对旧项目扩展的首选。 问题：twemproxy自身单端口实例的压力，使用一致性hash后，对redis节点数量改变时候的计算值的改变，数据无法自动移动到新的节点。

一致性哈希

通过一致性hash算法可以很好的解决Redis分布式的问题，且当Redis server增加或减少的时候，之前存储的缓存命中率还是比较高的。

将key和server对2^32取模，然后将数据顺时针放到最近的server上，扩容不会降低缓存命中率。