【redis】闲得无聊，来聊聊当下爆火的 redis集群，顺便搭一个玩玩呗

文章目录

• 接上一篇：中心化与去中心化
• redis集群介绍
  • redis集群的数据分片
  • Redis 集群的主从复制模型
  • Redis 一致性保证
• redis集群搭建
  • 前期准备
• 集群配置
• 客户端连接集群

接上一篇：中心化与去中心化

redis主从复制

上一篇讲到了redis的主从复制与哨兵模式，不过最后也留下了个话茬：弊端：中心化。

什么是中心化？简单点说就是“中央集权”。 前面所说主从模式，一主二仆，主机一挂，全线瘫痪，虽然有哨兵盯着，扶持主机上位，仍然是麻烦。而且数据规模一旦庞大，中心化就很危险。

一个应对方法，就是去中心化。

在redis的应用场景下，就是集群分布。 本篇为Redis集群的一般介绍，没有涉及复杂难懂的分布式概念的赘述。

redis集群介绍

源自：http://www.redis.cn/topics/cluster-tutorial.html 人家写得好，我也难出其右嘛

1）Redis 集群是一个提供在多个Redis间节点间共享数据的程序集。

2）Redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据,从而达不到像Redis那样的性能,在高负载的情况下可能会导致不可预料的错误.

3）Redis 集群通过分区来提供一定程度的可用性,在实际环境中当某个节点宕机或者不可达的情况下继续处理命令. Redis 集群的优势:

自动分割数据到不同的节点上。
整个集群的部分节点失败或者不可达的情况下能够继续处理命令。

redis.conf中关于集群的介绍：redis.conf翻译与配置（五）传送门

redis集群的数据分片

Redis 集群没有使用一致性hash, 而是引入了 哈希槽的概念.

Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点,那么:

节点 A 包含 0 到 5500号哈希槽.
节点 B 包含5501 到 11000 号哈希槽.
节点 C 包含11001 到 16384号哈希槽.

这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C中得部分槽到D上. 如果我想移除节点A,需要将A中的槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可. 由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.

Redis 集群的主从复制模型

为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型,每个节点都会有N-1个复制品.

在我们例子中具有A，B，C三个节点的集群,在没有复制模型的情况下,如果节点B失败了，那么整个集群就会以为缺少5501-11000这个范围的槽而不可用.

然而如果在集群创建的时候（或者过一段时间）我们为每个节点添加一个从节点A1，B1，C1,那么整个集群便有三个master节点和三个slave节点组成，这样在节点B失败后，集群便会选举B1为新的主节点继续服务，整个集群便不会因为槽找不到而不可用了

不过当B和B1 都失败后，集群是不可用的.

Redis 一致性保证

Redis 并不能保证数据的强一致性. 这意味这在实际中集群在特定的条件下可能会丢失写操作.

第一个原因是因为集群是用了异步复制. 写操作过程:

客户端向主节点B写入一条命令.
主节点B向客户端回复命令状态.
主节点将写操作复制给他得从节点 B1, B2 和 B3.

主节点对命令的复制工作发生在返回命令回复之后， 因为如果每次处理命令请求都需要等待复制操作完成的话， 那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。 注意：Redis 集群可能会在将来提供同步写的方法。 Redis 集群另外一种可能会丢失命令的情况是集群出现了网络分区， 并且一个客户端与至少包括一个主节点在内的少数实例被孤立。

举个例子 假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点， 其中 A 、B 、C 为主节点， A1 、B1 、C1 为A，B，C的从节点， 还有一个客户端 Z1 假设集群中发生网络分区，那么集群可能会分为两方，大部分的一方包含节点 A 、C 、A1 、B1 和 C1 ，小部分的一方则包含节点 B 和客户端 Z1 .

Z1仍然能够向主节点B中写入, 如果网络分区发生时间较短,那么集群将会继续正常运作,如果分区的时间足够让大部分的一方将B1选举为新的master，那么Z1写入B中得数据便丢失了.

注意， 在网络分裂出现期间， 客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制的， 这一时间限制称为节点超时时间（node timeout）， 是 Redis 集群的一个重要的配置选项。

redis集群搭建

集群搭建需要以下三个步骤：

准备节点。
节点握手。
分配槽。

Redis Cluster由多个节点组成，节点数量至少有6个才能组成一个完整高可用的集群，其中有3个主节点和3个从节点，我们就以此为例搭建一个Redis Cluster。

前期准备

1）创建一个专用目录，将服务端和客户端放进去

2）创建6个目录，给六台机器

3）修改配置文件

记得要改六个配置文件 复制粘贴一个改好的，然后用vim下的：%s/7000/7001/g 以此类推

4）打开六个redis服务端

这样集群就搭建好了吗？ 想多了，只是开了六个机器而已。

集群配置

1）使用脚本创建集群环境，要安装ruby环境，不推荐 2）使用docker下载redis-trib的镜像运行，docker这么火，早晚都要会，那就用这个。

1、安装docker(这里面一把辛酸泪啊)[我的采坑历程：](https://blog.csdn.net/qq_43762191/article/details/108184338)
2、启动docker
3、下载镜像：docker pull inem0o.redis-trib

然后，运行：

docker run -it --net host inem0o/redis-trib create -- replicas 1  192.168.148.128:7000  192.168.148.128:7002  192.168.148.128:7003  192.168.148.128:7004  192.168.148.128:7005  192.168.148.128:7006

里面的ip自己改

replicas 1：选举一票的意思

圈出来那个地方，填yes，不要自作主张填个y，不然就再执行一次吧。

客户端连接集群

./redis-cli -c -p 7000

加了-c