简介
Redis Cluster 是 Redis3.0 版本后推出的分布式解决方案,当遇到单机内存、并发等瓶颈时,可使用此方案来解决。
- 主从模式和哨兵模式只能保证高可用,每一台机器存储的内容是相同的。
- Cluster 能够让 Redis 存储更多的内容,集群里 master 之间的内容是不同的。另外每一个 master 还可以配置自己的 slave 达到高可用
分区规则
Redis Cluste r采用了哈希分区的“虚拟槽分区”方式
所有的键根据哈希函数 (CRC16[key]&16383) 映射到 0-16383 槽内,共 16384(214)个槽位,每个节点维护部分槽及槽所映射的键值数据
缺陷
- 键的批量操作支持有限,比如mset, mget,如果多个键映射在不同的槽,就不支持了
- 键事务支持有限,当多个键分布在不同节点时无法使用事务
- 键是数据分区的最小粒度,不能将一个很大的键值对映射到不同的节点
- 不支持多数据库
- 复制结构只支持单层结构,不支持树型结构
通信协议——Gossip
Gossip协议的主要职责就是信息交换,信息交换的载体就是节点之间彼此发送的Gossip消息,常用的Gossip消息有ping消息、pong消息、meet消息、fail消息
- meet消息:用于通知新节点加入,消息发送者通知接收者加入到当前集群,meet消息通信完后,接收节点会加入到集群中,并进行周期性ping pong交换
- ping消息:集群内交换最频繁的消息,集群内每个节点每秒向其它节点发ping消息,用于检测节点是否在线和状态信息,ping消息发送封装自身节点和其他节点的状态数据;
- pong消息:当接收到ping meet消息时,作为响应消息返回给发送方,用来确认正常通信,pong消息也封闭了自身状态数据;
- fail消息:当节点判定集群内的另一节点下线时,会向集群内广播一个fail消息
以上的所有消息格式为:消息头、消息体。消息头包含发送节点自身状态数据(比如节点ID、槽映射、节点角色、是否下线等),接收节点根据消息头可以获取到发送节点的相关数据。
节点定时任务
路由重定向
下线
主观下线
客观下线
许多个主观就是客观,生活中可不能这样。