既然是分布式,自然具备分布式系统的基本特性:可扩展、高可用、一致性。
Redis 集群通过划分 hash 槽来分片,进行数据分享。 Redis 集群采用主从模型,提供复制和故障转移功能,来保证 Redis 集群的高可用。 根据 CAP 理论,Consistency、Availability、Partition tolerance 三者不可兼得,而 Redis 集群的选择是 AP。Redis 集群节点间采用异步通信方式,不保证强一致性,尽力达到最终一致性。
redis
节点或者从哪个 redis
节点 读取数据。其主要思想是采用 哈希算法 将 Redis
数据的 key
进行散列,通过 hash
函数,特定的 key
会 映射 到特定的 Redis
节点上。Redis Sharding
,Redis Sharding
是 Redis Cluster
出来之前,业界普遍使用的 Redis
多实例集群 方法。Java
的 Redis
客户端驱动库 Jedis
,支持 Redis Sharding
功能,即 ShardedJedis
以及 结合缓存池 的 ShardedJedisPool
。Twemproxy
和 Codis
。Twemproxy
也叫 nutcraker
,是 twitter
开源的一个 redis
和 memcache
的 中间代理服务器 程序。Twemproxy
作为 代理,可接受来自多个程序的访问,按照 路由规则,转发给后台的各个 Redis
服务器,再原路返回。Twemproxy
存在 单点故障 问题,需要结合 Lvs
和 Keepalived
做 高可用方案。Codis
是一个 分布式 Redis
解决方案,对于上层应用来说,连接 Codis-Proxy
和直接连接 原生的 Redis-Server
没有的区别。Codis
底层会 处理请求的转发,不停机的进行 数据迁移 等工作。Codis
采用了无状态的 代理层,对于 客户端 来说,一切都是透明的。Proxy
和底层 Redis
的 高可用,数据分片 和 自动平衡,提供 命令行接口 和 RESTful API
,提供 监控 和 管理 界面,可以动态 添加 和 删除 Redis
节点。Redis
实例,然后由 Redis
将请求 转发 给 正确 的 Redis
节点。Redis Cluster
实现了一种 混合形式 的 查询路由,但并不是 直接 将请求从一个 Redis
节点 转发 到另一个 Redis
节点,而是在 客户端 的帮助下直接 重定向( redirected
)到正确的 Redis
节点。Redis
实例上,可以平滑的进行节点 扩容/缩容,支持 高可用 和 自动故障转移,运维成本低。Redis-trib
工具,缺乏 监控管理,需要依赖 Smart Client
(维护连接,缓存路由表,MultiOp
和 Pipeline
支持)。Failover
节点的 检测过慢,不如 中心节点 ZooKeeper
及时。Gossip
消息具有一定开销。无法根据统计区分 冷热数据。Redis
集群相对 单机 在功能上存在一些限制,需要 开发人员 提前了解,在使用时做好规避。key
批量操作 支持有限。mset
、mget
操作,目前只支持对具有相同 slot
值的 key
执行 批量操作。对于 映射为不同 slot
值的 key
由于执行 mget
、mget
等操作可能存在于多个节点上,因此不被支持。key
事务操作 支持有限。key
在 同一节点上 的 事务操作,当多个 key
分布在 不同 的节点上时 无法 使用事务功能。key
作为 数据分区 的最小粒度hash
、list
等映射到 不同的节点。Redis
可以支持 16
个数据库(db0 ~ db15
),集群模式 下只能使用 一个 数据库空间,即 db0
。注意
如果数据库中有任何一个槽没有得到处理,那么集群处于下线状态。
MEET
- 请求接收方加入发送方所在的集群。PING
- 集群中每个节点每隔一段时间(默认为一秒)从已知节点列表中随机选出五个节点,然后对这五个节点中最久没联系的节点发送 PING 消息,以此检测被选中的节点是否在线。PONG
- 当接收方收到发送方发来的 MEET 消息或 PING 消息时,会返回一条 PONG 消息作为应答。FAIL
- 当一个主节点 A 判断另一个主节点 B 已经进入 FAIL 状态时,节点 A 会向集群广播一条关于节点 B 的 FAIL 消息,所有收到这条消息的节点都会立即将节点 B 标记为已下线。PUBLISH
- 当节点收到一个 PUBLISH 命令时,节点会执行这个命令,并向集群广播一条 PUBLISH 消息,所有接受到这条消息的节点都会执行相同的 PUBLISH 命令。个人理解:MOVED 这种操作有点类似 HTTP 协议中的重定向。
<yes/no>
- 如果配置”yes”则开启集群功能,此 redis 实例作为集群的一个节点,否则,它是一个普通的单一的 redis 实例。<filename>
- 注意:虽然此配置的名字叫“集群配置文件”,但是此配置文件不能人工编辑,它是集群节点自动维护的文件,主要用于记录集群中有哪些节点、他们的状态以及一些持久化参数等,方便在重启时恢复这些状态。通常是在收到请求之后这个文件就会被更新。<milliseconds>
- 这是集群中的节点能够失联的最大时间,超过这个时间,该节点就会被认为故障。如果主节点超过这个时间还是不可达,则用它的从节点将启动故障迁移,升级成主节点。注意,任何一个节点在这个时间之内如果还是没有连上大部分的主节点,则此节点将停止接收任何请求。<factor>
- 如果设置成0,则无论从节点与主节点失联多久,从节点都会尝试升级成主节点。如果设置成正数,则 cluster-node-timeout 乘以 cluster-slave-validity-factor 得到的时间,是从节点与主节点失联后,此从节点数据有效的最长时间,超过这个时间,从节点不会启动故障迁移。假设 cluster-node-timeout=5,cluster-slave-validity-factor=10,则如果从节点跟主节点失联超过 50 秒,此从节点不能成为主节点。注意,如果此参数配置为非 0,将可能出现由于某主节点失联却没有从节点能顶上的情况,从而导致集群不能正常工作,在这种情况下,只有等到原来的主节点重新回归到集群,集群才恢复运作。<count>
- 主节点需要的最小从节点数,只有达到这个数,主节点失败时,它从节点才会进行迁移。更详细介绍可以看本教程后面关于副本迁移到部分。