redis-cluster的安装管理

Posted 2020-09-17

redis-cluster的安装管理

 

声明：

本文只允许用于个人学习交流使用，如有错误之处请多多指正。

文档版本：Version 1.0

修改记录：2015-10-30

环境介绍

系统环境：RedHat Enterprise Linux Server release 6.2 (Santiago)

内核版本：Linuxzxt-02.com 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64x86_64 x86_64 GNU/Linux

软件版本：redis-3.0.5

主机名：redis-01.com、redis-02.com

主机IP：192.168.1.193 192.168.1.176

安装所需软件环境：

Zlib、ruby（必须1.9.2以上）、rubygem、gem-redis

注：在阅读文本文档之前需要读者知道的是本文档以及目前网络上的大部分相近的文档都来源于http://redis.io。如果您的英文阅读能较好的话建议您阅读Reis官方文档。http://redis.io/topics/cluster-spec

http://redis.io/topics/cluster-tutorial

redis-cluster简介：

Redis 集群是一个可以在多个Redis节点之间进行数据共享的设施（installation）。Redis 集群不支持那些需要同时处理多个键的Redis 命令，因为执行这些命令需要在多个Redis 节点之间移动数据，并且在高负载的情况下，这些命令将降低Redis 集群的性能，并导致不可预测的行为。

Redis 集群通过分区（partition）来提供一定程度的可用性（availability）：即使集群中有一部分节点失效或者无法进行通讯，集群也可以继续处理命令请求。

Redis集群提供了以下两个好处：

将数据自动切分（split）到多个节点的能力。

当集群中的一部分节点失效或者无法进行通讯时，仍然可以继续处理命令请求的能力

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 集群另外一种可能会丢失命令的情况是集群出现了网络分区，

本文出自 “无名之辈” 博客，转载请与作者联系！