Redis 集群基础知识

Redis 主从： 

       单节点 redis 服务处理高并发能力有限，可以使用主从集群实现数据读写分离提高 redis 服务高并发处理能力，一般实现一主多从，主节点负责写数据，并将数据同步给从节点，从节点负责读数据

       确定主节点与从节点信息：在从节点配置文件中配置 replicaof  主节点ip  主节点端口号

       主从数据同步流程：

       1. 从节点向主节点发送同步数据请求，并发送主节点的 run id 和 offset 信息

       2. 主节点接受到请求信息后，先判断一下 run id（运行Id）是不是自己

           2.1 如果不是自己的 run id ，表是当前节点第一次过来同步数据需要全量数据同步，主节点先将自己的 run id、offset 、版本信息等数据发送给从节点 ，从节点保存主节点信息 ，然后主节点执行 bgsave 指令将缓存数据保存到 rdb 文件中，然后将 rdb 文件发送给从节点，从节点接受到文件后清空本地缓存数据，加载 rdb 文件将数据缓存到内存中，在主节点创建 rdb 文件至发送 rdb 文件时间段内，可能会处理新的指令并将新指令写入缓存区中，然后发送给从节点，从节点接受并执行指令，现在主从节点的数据就一致了，后续主节点执行指令后会将指令发送给从节点

          2.2 如果是自己 run id , 表示不是第一次同步数据只用增量同步数据，主节根据从节点发送的 offset 信息与自己的 offset 比较，获取未同步的数据发送给从节点，

          注意：主节点的 offset 会随着缓存区中数据增多变大，缓存区: replication_backlog_buffer

 Redis 哨兵集群： 

          使用主从集群如果出现主节点宕机，导致数据不能写入问题，需要手动选择一个从节点做为新的主节点，但是这样做不能保证服务高可用，所以使用哨兵机制监测主从节点 自动故障恢复、通知信息

          如果主节点服务出现故障，哨兵会自动在从节点中选择一个做新的主节点，并通知客户端更改信息访问新的主节点，等老的主节点重启后会变成从节点同步新的主节点信息

          哨兵选举机制：1. 从节点优先级 2. 从节点 offset 值的大小 3. 运行id 

      注意: 从节点的 offset 值的大小，offset 值越大说明从节点与主节点中的数据越接近数据越完整

         哨兵集群脑裂问题：

                使用哨兵监测主从节点，可能因为网络抖动出现 脑裂 问题，例如, 一段时间内有超过半数的哨兵节点无法检测到主节点心跳，客观的认为主节点已经故障，在剩下的从节点中选择一个新的主节点，实际上老主节点并没有故障还在处理请求信息，等一段时间老的主节点重新连接上哨兵，会被哨兵强制为 从节点向新的主节点同步数据并将自己的数据清空，导致数据丢失问题，

        解决方案：可以在文件中配置从节点最小连接数与数据同步间隔时间，如果不满足配置信息拒绝接受新数据

分片集群：

        哨兵加主从群集虽然能满足大量数据下高可用，但是海量数据还是会出现redis 读写数据性能问题，为了解决海量数据 redis 数据读写瓶颈，只能多加几组主从集群提高读写效率，但是在写数据时，会出现数据不知道要存放到那个主节点问题，此时可以使用集群分片解决问题

         客户端存数据时，可以根据 key 做分片算法将数据映射到某个主节点保存数据，目前主流做法将整个集群分为 16384 个 hash 槽， 随后把 16384 个hash槽分段给每个主从节点，在存数据时先将 key 进行 hash 计算拿到 hash 值，然后与16384 进行取模再判断当前 key 落到那个区间，可以找到对应的主节点保存数据

         分片集群虽然解决了海量数据读写问题，也引出了新的问题，比如再写数据时发现某个主节点故障，导致某一个区间的数据无法保存，这时需要一个监控机制 帮助集群故障恢复，目前主流解决方案，让每个主节点相互监测，当多个主节点发现某个主节点，在一段时间内没有发送心跳信息就将其标注为故障，如果有一半以上的主节点将其标注，客观认为该主机点已经故障，便从故障主从集群中投票选举一个从节点作为新的主节点，同时通知其它机器新主节点的信息