redis高可用方案

【单机版】

        缺点：单机故障、容量瓶颈、qps瓶颈

【主从】

        读写分离、容灾备份，

        缺点：主机挂了之后是没有办法完成自从主从切换的

【哨兵】

        哨兵是在主从的基础上升级的，先搭建主从，再搭建哨兵。哨兵节点监控主机，如果主机挂掉了，那么从从机上选出一个从机替换主机。

        sentinel，哨兵是redis集群中非常重要的一个组件，主要功能：（1）集群监控：负责监控redis master和slave进程是否正常工作；（2）消息通知：如果某个redis实例有故障,那么哨兵负责发送消息作为警报发给管理员；(3)故障转移：如果master Node宕机了，会自动转移到slave node节点；（4）配置中心：如果故障发生转移了，通知client客户端新的master

        哨兵用于实现redistribution集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，相互协同工作。故障转移时，判断一个master node是否宕机了，需要大部分的哨兵都同意才行（大多数原则）。即使部分哨兵节点挂掉了，哨兵集群还能正常工作的。哨兵通常需要3个实例来保证自己的健壮性。哨兵+redis主从架构是不保证数据零丢失的，只能保证redis集群的高可用。对于哨兵+redis这种复杂的部署架构，尽量在测试环境和生产环境都进行充足的测试和演练。

【redis sharding】

        redis cluster出现之前，业界普遍使用的多redis实例集群方式，其主要思想就是采用hash算法将redis数据的key进行散列，通过hash函数，特定的key会映射到特定的redis节点。Java的redis客户端驱动jedis，支持redis sharding功能，即sharding jedis以及结合缓存池的shardingJedisPool，服务端控制则采用sharding proxy

        优点:非常简单，服务端的redis实例彼此独立,但无相关关联，每个redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强

        缺点:sharding处理放到客户端，操作由客户端控制，服务另起sharding proxy,运维难度加大。客户端的sharding不支持动态增删节点，服务端的redis实例群拓扑结构有变化时，每个客户端都需要更新调整，链接不能共享，应用规模增大时，浪费资源限制优化

【cluster】

        在哨兵的基础上升级的，类似于哨兵模式。但是是一个类似哨兵的模式，通过hash算法给出每个是选择哪个服务。每个主从类  哨兵模块之间的数据不是共享的，相互之间没关系。

        redis cluster是一种服务端的sharding技术，3.0版本正式提供，采用slot的概念，一共分成16384个槽。将请求发送到任意节点，接收到请求的节点将会查询请求发送到正确的节点进行。

        相关方案：   通过哈希的方式，将数据分片，每个节点均分存储一定的hash区间的数据（默认分配了16384个槽位）。 每份数据分片会存储在多个互为主从的多个节点上。  数据写入先写主节点，再从主节点复制到对应的从节点（支持配置为阻塞同步）。  同一分片多个节点之间数据不保持强一致性。 读取数据时，当客户端操作的key没有分配在该节点时，redis会转回反向指令。指向正确的节点。  扩容时需要把旧节点的数据迁移一部分到新节点。

        在redis cluster架构下，每个redis要开放两个端口，比如一个是6379，另外一个就是+10000的端口：16379，其中16379是为了进行节点之间的通讯的，也就是cluster bus的通讯，用来进行故障检测，配置更新，故障转移授权的。cluster bus用了另外一种二进制协议，gossip协议，用于节点之间进行高效的数据交换，占用更少的处理时间和网络带宽。

        优点：无中心架构，支持动态扩容，对业务透明。具备sentinel的监控和自动failover能力。客户端不需要连接集群所有节点，链接集群中的任意一个节点即可。高性能，客户端直接连接redis服务，免去了proxy代理的损耗。

      缺点：运维发杂，数据迁移需要人共干预。只能使用0号数据库。不支持批量操作（pipline操作）。分布式逻辑和存储模块耦合。