高可用 redis 集群搭建及原理详解
一 原理介绍
更多干货
分布式实战(干货)
spring cloud 实战(干货)
mybatis 实战(干货)
spring boot 实战(干货)
React 入门实战(干货)
构建中小型互联网企业架构(干货)
1Redis 集群的数据分片
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 节点从集群中移除即可. 由于从一个节点将哈希槽移动到另一个节点并不会停止服务, 所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.
2Redis 集群的主从复制模型
为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用, 所以集群使用了主从复制模型, 每个节点都会有 N-1 个复制品.
在我们例子中具有 A,B,C 三个节点的集群, 在没有复制模型的情况下, 如果节点 B 失败了, 那么整个集群就会以为缺少 5501-11000 这个范围的槽而不可用.
然而如果在集群创建的时候 (或者过一段时间) 我们为每个节点添加一个从节点 A1,B1,C1, 那么整个集群便有三个 master 节点和三个 slave 节点组成, 这样在节点 B 失败后, 集群便会选举 B1 为新的主节点继续服务, 整个集群便不会因为槽找不到而不可用了
不过当 B 和 B1 都失败后, 集群是不可用的.
3Redis 一致性保证
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
下载安装 redis
配置集群
集群测试
将 redis 配置成服务
Jedis 客户端使用
Redis 扩展
添加 slave 节点
删除节点
详见操作文档, 地址:
https://download.csdn.net/download/qq_27384769/10274739
来源: http://blog.csdn.net/qq_27384769/article/details/79479020