Redis — Redis 集群方案

📋 本文节选自《Redis 面试题》，返回 查看全部章节

四、集群方案

30. 哨兵模式

![ ][nbsp 2]

哨兵的介绍

sentinel，中文名是哨兵。哨兵是 redis 集群机构中非常重要的一个组件，主要有以下功能：

• 集群监控：负责监控 redis master 和 slave 进程是否正常工作。
• 消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
• 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
• 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。

哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。

• 故障转移时，判断一个 master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题。
• 即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。

哨兵的核心知识

• 哨兵至少需要 3 个实例，来保证自己的健壮性。
• 哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。
• 对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。

31. 官方Redis Cluster 方案(服务端路由查询)

![ ][nbsp 3]

• redis 集群模式的工作原理能说一下么？在集群模式下，redis 的 key 是如何寻址的？分布式寻址都有哪些算法？了解一致性 hash 算法吗？

简介

• Redis Cluster是一种服务端Sharding技术，3.0版本开始正式提供。Redis Cluster并没有使用一致性hash，而是采用slot(槽)的概念，一共分成16384个槽。将请求发送到任意节点，接收到请求的节点会将查询请求发送到正确的节点上执行

方案说明

1、 通过哈希的方式，将数据分片，每个节点均分存储一定哈希槽(哈希值)区间的数据，默认分配了；16384 个槽位

2、 每份数据分片会存储在多个互为主从的多节点上；

3、 数据写入先写主节点，再同步到从节点(支持配置为阻塞同步)；

4、 同一分片多个节点间的数据不保持一致性；

5、 读取数据时，当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点；

6、 扩容时时需要需要把旧节点的数据迁移一部分到新节点；

• 在 redis cluster 架构下，每个 redis 要放开两个端口号，比如一个是 6379，另外一个就是 加1w的端口号，比如 16379。

• 16379 端口号是用来进行节点间通信的，也就是 cluster bus 的东西，cluster bus 的通信，用来进行故障检测、配置更新、故障转移授权。cluster bus 用了另外一种二进制的协议，gossip 协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。

节点间的内部通信机制

• 基本通信原理
• 集群元数据的维护有两种方式：集中式、Gossip 协议。redis cluster 节点间采用 gossip 协议进行通信。

分布式寻址算法

• hash 算法（大量缓存重建）
• 一致性 hash 算法（自动缓存迁移）+ 虚拟节点（自动负载均衡）
• redis cluster 的 hash slot 算法

优点

• 无中心架构，支持动态扩容，对业务透明
• 具备Sentinel的监控和自动Failover(故障转移)能力
• 客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可
• 高性能，客户端直连redis服务，免去了proxy代理的损耗

缺点

• 运维也很复杂，数据迁移需要人工干预
• 只能使用0号数据库
• 不支持批量操作(pipeline管道操作)
• 分布式逻辑和存储模块耦合等

32. 基于客户端分配

![ ][nbsp 4]简介

• Redis Sharding是Redis Cluster出来之前，业界普遍使用的多Redis实例集群方法。其主要思想是采用哈希算法将Redis数据的key进行散列，通过hash函数，特定的key会映射到特定的Redis节点上。Java redis客户端驱动jedis，支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool

优点优势在于非常简单，服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强

缺点

• 由于sharding处理放到客户端，规模进一步扩大时给运维带来挑战。
• 客户端sharding不支持动态增删节点。服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。连接不能共享，当应用规模增大时，资源浪费制约优化

33. 基于代理服务器分片

![ ][nbsp 5]简介

• 客户端发送请求到一个代理组件，代理解析客户端的数据，并将请求转发至正确的节点，最后将结果回复给客户端

特征

• 透明接入，业务程序不用关心后端Redis实例，切换成本低
• Proxy 的逻辑和存储的逻辑是隔离的
• 代理层多了一次转发，性能有所损耗

业界开源方案

• Twtter开源的Twemproxy
• 豌豆荚开源的Codis

34. Redis 主从架构

• 单机的 redis，能够承载的 QPS 大概就在上万到几万不等。对于缓存来说，一般都是用来支撑读高并发的。因此架构做成主从(master-slave)架构，一主多从，主负责写，并且将数据复制到其它的slave 节点，从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容，支撑读高并发。![ ][nbsp 6]redis replication -> 主从架构 -> 读写分离 -> 水平扩容支撑读高并发redis replication 的核心机制
• redis 采用异步方式复制数据到 slave 节点，不过 redis2.8 开始，slave node 会周期性地确认自己每次复制的数据量；
• 一个 master node 是可以配置多个 slave node 的；
• slave node 也可以连接其他的 slave node；
• slave node 做复制的时候，不会 block master node 的正常工作；
• slave node 在做复制的时候，也不会 block 对自己的查询操作，它会用旧的数据集来提供服务；但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了；
• slave node 主要用来进行横向扩容，做读写分离，扩容的 slave node 可以提高读的吞吐量。

注意：

• 如果采用了主从架构，那么建议必须开启 master node 的持久化，不建议用 slave node 作为master node 的数据热备，因为那样的话，如果你关掉 master 的持久化，可能在 master 宕机重启的时候数据是空的，然后可能一经过复制， slave node 的数据也丢了。
• 另外，master 的各种备份方案，也需要做。万一本地的所有文件丢失了，从备份中挑选一份 rdb去恢复 master，这样才能确保启动的时候，是有数据的，即使采用了后续讲解的高可用机制，slave node 可以自动接管 master node，但也可能 sentinel 还没检测到 master failure，masternode 就自动重启了，还是可能导致上面所有的 slave node 数据被清空。

redis 主从复制的核心原理

• 当启动一个 slave node 的时候，它会发送一个 PSYNC 命令给 master node。
• 如果这是 slave node 初次连接到 master node，那么会触发一次 full resynchronization 全量复制。此时 master 会启动一个后台线程，开始生成一份 RDB 快照文件，
• 同时还会将从客户端 client 新收到的所有写命令缓存在内存中。 RDB 文件生成完毕后， master会将这个 RDB 发送给 slave，slave 会先写入本地磁盘，然后再从本地磁盘加载到内存中，
• 接着 master 会将内存中缓存的写命令发送到 slave，slave 也会同步这些数据。
• slave node 如果跟 master node 有网络故障，断开了连接，会自动重连，连接之后 master node仅会复制给 slave 部分缺少的数据。![ ][nbsp 7]

过程原理

1、 当从库和主库建立MS关系后，会向主数据库发送SYNC命令；

2、 主库接收到SYNC命令后会开始在后台保存快照(RDB持久化过程)，并将期间接收到的写命令缓存；起来

3、 当快照完成后，主Redis会将快照文件和所有缓存的写命令发送给从Redis；

4、 从Redis接收到后，会载入快照文件并且执行收到的缓存的命令；

5、 之后，主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致；

缺点

• 所有的slave节点数据的复制和同步都由master节点来处理，会照成master节点压力太大，使用主从从结构来解决

35. Redis集群的主从复制模型是怎样的？

• 为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型，每个节点都会有N-1个复制品

36. 生产环境中的 redis 是怎么部署的？

• redis cluster，10 台机器，5 台机器部署了 redis 主实例，另外 5 台机器部署了 redis 的从实例，每个主实例挂了一个从实例，5 个节点对外提供读写服务，每个节点的读写高峰qps可能可以达到每秒 5 万，5 台机器最多是 25 万读写请求/s。
• 机器是什么配置？32G 内存+ 8 核 CPU + 1T 磁盘，但是分配给 redis 进程的是10g内存，一般线上生产环境，redis 的内存尽量不要超过 10g，超过 10g 可能会有问题。
• 5 台机器对外提供读写，一共有 50g 内存。
• 因为每个主实例都挂了一个从实例，所以是高可用的，任何一个主实例宕机，都会自动故障迁移，redis 从实例会自动变成主实例继续提供读写服务。
• 你往内存里写的是什么数据？每条数据的大小是多少？商品数据，每条数据是 10kb。100 条数据是 1mb，10 万条数据是 1g。常驻内存的是 200 万条商品数据，占用内存是 20g，仅仅不到总内存的 50%。目前高峰期每秒就是 3500 左右的请求量。

其实大型的公司，会有基础架构的 team 负责缓存集群的运维。

37. 说说Redis哈希槽的概念？

• Redis集群没有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

38. Redis集群会有写操作丢失吗？为什么？

• Redis并不能保证数据的强一致性，这意味这在实际中集群在特定的条件下可能会丢失写操作。

39. Redis集群之间是如何复制的？

• 异步复制

40. Redis集群最大节点个数是多少？

• 16384个

41. Redis集群如何选择数据库？

• Redis集群目前无法做数据库选择，默认在0数据库。

---