• 传统架构里面的备份、Hot Standby、双活、多活这种架构之外，对于保证分布式存储系统的高可靠和高可用，数据在系统中一般存储多个副本。当某个存储节点出故障时，系统能够自动将服务切换到其他的副本，从而实现自动容错。
      分布式存储系统通过复制协议将数据同步到多个存储节点，并确保多个副本之间的数据一致性。同一份数据有多个副本，仅有一个为主副本 Primary，其他的副本为备份副本 Backup，数据从主副本复制到备份副本，采用最终一致性来保证数据和事物的完整。

    考虑问题

    脑裂

    选举

    redis高可用部署架构

    • sentinel 哨兵机制

      • sentinel 检测原理

        • 每隔10s，每个sentinel会向主节点和从节点发送info replication命令获取最新的主从拓扑结构
        • 每隔2s，每个sentinel节点向redis节点的 sentinel :hello频道发送该sentinel节点对主节点判断及当前sentinel信息，其他sentinel节点也会订阅该频道，了解各个sentinel节点以及他们对主节点的判断
        • 每隔1s，每个sentinel节点会向所有redis节点以及其他sentinel节点发送ping命令做一次心跳检测，确认各个节点是否可达

      • 特点

        • 一套sentinel集群至少3个节点，sentinel节点通过raft算法选举，节点个数为奇数
        • 1套sentinel集群可以监控多套redis主从
        • 建议部署方式：相同业务使用同一套sentinel集群进行监控。
        • Client 端需要修改连接方式，配置由原来直连域名，修改为配置sentinel集群信息+redis主节点标识名
        • sentinel只对主节点进行failover，从节点故障只做主观下线判断，没有后续的处理操作
        • sentinel不是中间件，应用只会在初次连接的时候请求sentinel返回一个redis主节点的连接池，实际上是直连redis主节点的。（持续订阅sentinel，当redis发生故障切换，会重新返回一个主节点连接池）

      • 痛点

        • 客户端原生JedisSentinelPool只拿到redis主节点的连接池，无法支持读写分离
        • 应用端需要修改连接配置（这个其实不算很痛，可以逐步推进）
    • Redis-Cluster

    • 特点

      • 无中心分布式架构，解决高可用，扩展性问题
      • 集群中数据节点个数为奇数。每个节点代表一套redis主从（主库读写，从库备用）
      • 通过虚拟槽hash到各节点（总共16384个slots），实现数据分片
      • 无代理层，client端配置集群所有节点信息。连接集群中任一节点皆可访问整个集群数据（自动路由）
      • 据说存在不少坑，需要先部署测试一段时间再上线