Redis集群（Cluster）学习笔记
Redis Cluster 简介
redis是一个开源的key value存储系统，受到了广大互联网公司的青睐。redis3.0版本之前只支持单例模式，在3.0版本及以后才支持集群；
redis集群采用P2P模式，是完全去中心化的，不存在中心节点或者代理节点；
redis集群是没有统一的入口的，客户端（client）连接集群的时候连接集群中的任意节点（node）即可，集群内部的节点是相互通信的（PING-PONG机制），每个节点都是一个redis实例；
为了实现集群的高可用，即判断节点是否健康（能否正常使用），redis-cluster有这么一个投票容错机制：如果集群中超过半数的节点投票认为某个节点挂了，那么这个节点就挂了（fail）。这是判断节点是否挂了的方法；
那么如何判断集群是否挂了呢? -> 如果集群中任意一个节点挂了，而且该节点没有从节点（备份节点），那么这个集群就挂了。这是判断集群是否挂了的方法；
那么为什么任意一个节点挂了（没有从节点）这个集群就挂了呢？ -> 因为集群内置了16384个slot（哈希槽），并且把所有的物理节点映射到了这16384[0-16383]个slot上，或者说把这些slot均等的分配给了各个节点。当需要在Redis集群存放一个数据（key-value）时，redis会先对这个key进行crc16算法，然后得到一个结果。再把这个结果对16384进行求余，这个余数会对应[0-16383]其中一个槽，进而决定key-value存储到哪个节点中。所以一旦某个节点挂了，该节点对应的slot就无法使用，那么就会导致集群无法正常工作。
综上所述，每个Redis集群理论上最多可以有16384个节点。
集群搭建需要的环境
Redis集群至少需要3个节点，因为投票容错机制要求超过半数节点认为某个节点挂了该节点才是挂了，所以2个节点无法构成集群。
要保证集群的高可用，需要每个节点都有从节点，也就是备份节点，所以Redis集群至少需要6台服务器（3主3从）。因为我没有那么多服务器，也启动不了那么多虚拟机，所在这里搭建的是伪分布式集群，即一台服务器虚拟运行6个redis实例，修改端口号为（7000-7005），当然实际生产环境的Redis集群搭建和这里是一样的。
修改redis.conf开启集群，修改端口号，然后复制六份redis.conf
cluster-enabled yes #默认是被注释掉的
启动6个redis实例 ./redis-server redis.conf（启动过程省略），查看进程是否启动成功
启动成功后，会在启动所在目录中生成nodes.conf文件，并生成唯一ID，该ID将由该特定实例永久使用，以使该实例在群集的上下文中具有唯一的名称。每个节点都使用该ID而不是IP或端口记住其他每个节点。IP地址和端口可能会更改，但是唯一的节点标识符在节点的整个生命周期中都不会改变。我们将此标识符简称为Node ID。
创建集群
redis5以上使用redis-cli即可创建；redis3、redis4需要安装ruby和gem环境，通过源码中的redis-trib.rb文件创建。这里我们使用redis-cli创建。
#执行redis-cli
./redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1
--cluster-replicas 1 表示集群主节点需要多少个从节点，即3台服务器构成集群，每台服务器设置1台从服务器，所以我们用了6台
使用redis-cli连接集群
最后加上两条redis集群基本命令：
cluster info #查看当前集群信息
cluster nodes #查看集群里有多少个节点
Redis集群配置参数
cluster-enabled<yes/no>：如果是，则在特定的Redis实例中启用Redis Cluster支持。否则，该实例将像往常一样作为独立实例启动。
cluster-config-file<filename>：请注意，尽管有此选项的名称，但它不是用户可编辑的配置文件，而是Redis Cluster节点每次发生更改时都会自动持久保存集群配置的文件（状态，基本上是状态），为了能够在启动时重新阅读它。该文件列出了诸如群集中其他节点之类的内容，它们的状态，持久变量等等。通常，由于收到某些消息，此文件将被重写并刷新到磁盘上。
cluster-node-timeout<milliseconds>：Redis群集节点不可用的最长时间（不将其视为失败）。如果主节点无法访问的时间超过指定的时间长度，则它的从节点将对其进行故障转移。此参数控制Redis Cluster中的其他重要事项。值得注意的是，在指定的时间内无法到达大多数主节点的每个节点都将停止接受查询。
cluster-slave-validity-factor<factor>：如果设置为零，则从服务器将始终尝试对主服务器进行故障转移，而不管主服务器和从服务器之间的链接保持断开状态的时间长短。如果该值为正，则将最大断开时间计算为节点超时值乘以此选项提供的系数，如果节点是从节点，则如果断开主链接的时间超过指定的时间，它将不会尝试启动故障转移。例如，如果节点超时设置为5秒，而有效性因子设置为10，则从服务器与主服务器断开连接超过50秒将不会尝试对其主服务器进行故障转移。请注意，如果没有从属能够对其进行故障转移，则任何非零的值都可能导致Redis群集在主服务器发生故障后不可用。在这种情况下，只有当原始主服务器重新加入集群后，集群才会返回可用状态。
cluster-migration-barrier<count>：一个主机将保持连接的最小数量的从机，以便另一个从机迁移到不再被任何从机覆盖的主机。有关更多信息，请参见本教程中有关副本迁移的相应部分。
cluster-require-full-coverage<yes/no>：如果设置为yes，默认情况下，如果某个节点未覆盖一定比例的密钥空间，集群将停止接受写入。如果该选项设置为no，即使仅可以处理有关密钥子集的请求，群集仍将提供查询。
————————————————
版权声明：本文为CSDN博主「q42368773」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/q42368773/article/details/102595160
