Redis集群方案
Redis 集群方案分为三种:主从、Sentinel(哨兵)、Cluster。
主从
主从模式下,Redis 分为主库(master)和从库(slaver)。主库负责读写,从库只负责读。当主库发生写事件后会将数据同步至从库。主库挂了不会重新选举主库,需等主库重启之后才能继续提供写服务,此间从库仍可提供读服务。
初始化阶段:从库启动后,向主库发送 Sync 命令,主库收到 Sync 命令后,生成 RDB 快照,并缓存生成快照期间的写命令,快照生成完后,发送至从库。从库收到后根据快照和缓存的写命令初始化数据库。
同步阶段:此阶段主库每次收到写命令都会将写命令发送至从库,从库执行写命令,保证数据一致性。
缺点:如果主库挂了,集群将无法提供写服务。
Sentinel(哨兵)
Sentinel 模式是建立的主从模式之下的,前面说到如果主库挂了,集群将无法对外提供写服务,不满足高可用。Sentinel 的解决方案是引入一个 Sentinel 系统,监视多个Redis 主库以及主库下的从库,当主库挂了,Sentinel 在从库里选举一个作为新的主库。为了避免 Sentinel 的单点故障,Sentinel 也会以集群方式部署。多个 Sentinel 之间也会互相监视,多个 Sentinel 集群中存在 Leader ,由 Leader 来完成主从库的切换工作。
注意:使用 Sentinel 模式的时候,客户端不要直接连接Redis,而是连接 Sentinel 的地址,由 Sentinel 来提供具体的可提供服务的 Redis 节点,这样当master 节点挂掉以后,Sentinel 就会感知并将新的 master 节点提供给客户端。
Cluster
当单个节点数据量过大时前面两种模式都无法满足需求,这个时候可以使用 Cluster 模式,通过将数据进行分片
存储到不同的节点,解决单节点数据量过大的问题。
具体数据分片方案:集群的键空间被分割为16384个slots(即 hash 槽),通过 hash 的方式将数据分到不同的节点上。(这里都是指主库)如节点 A 包含[0~5500],节点 B 包含[5501~11000],节点 C 包含[11001~16384]。
HASH_SLOT = CRC16(key) & 16384;
当新加入或移除节点时,Redis 每个节点包含的哈希槽会发生变化,从而会进行数据迁移,不过不许用停止服务。
主库负责读写请求,从库同步主库数据,当主库挂了时,从库会被选举成主库继续提供服务。
docker-compose部署Redis-Cluster集群