如何保证 Redis 高可用和高并发（主从 + 哨兵 + 集群）
1. 概述
Redis 作为一种高性能的内存数据库，普遍用于目前主流的分布式架构系统中。为了提高系统的容错率，使用多实例的 Redis 也是必不可免的，但同样复杂度也相比单实例高出很多。
那么如何保证 Redis 的高并发和高可用？
Redis 主要有三种集群方式用来保证高并发和高可用：主从复制，哨兵模式和集群。
2. 主从复制
在分布式系统中为了解决单点问题，通常会把数据复制多个副本部署到其他机器，满足故障恢复和负载均衡等需求。Redis 也是如此，它为我们提供了复制功能，实现了相同数据的多个 Redis 副本。
复制功能是高可用 Redis 的基础，哨兵和集群都是在复制的基础上实现高可用的。
在复制的概念中，数据库分为两类。一类是主数据库（master），一类是从数据库（slave）。 master 可以进行读写操作，当写操作发生变化时，会自动将数据同步给 slave。
slave 一般只提供读操作，并接收主数据库同步过来的数据。
一个 master 可以对应多个 slave。一个 slave 只能对应一个 master。
引入主从复制的目的有两个：
读写分离，分担 master 的压力；
二是容灾备份。
Redis 的复制拓扑结构可以支持单层或多层复制关系，根据拓扑复杂性可以分为以下三种：一主一从、一主多从、树状主从结构。
2.1 一主一从
1、建立复制
参与复制的 Redis 实例划分为主节点（master）和从节点（slave）。默认情况下，Redis 都是主节点。每个从节点只能有一个主节点，而主节点可以同时具有多个从节点。复制的数据流是单向的，只能由主节点复制到从节点。
配置复制的方式有以下三种 ：
配置文件
配置文件中加入
slaveof {masterHost } {masterPort}，随 Redis 启动生效。启动命令
在 redis-server 启动命令后加入
--slaveof {masterHost} {masterPort }生效。客户端命令
Redis 服务器启动后，直接使用命令
slaveof {masterHost} { masterPort}生效。
综上所述，slaveof 命令在使用时，可以运行期动态配置，也可以提前写到配置文件中。
为了方便测试，我们在同一台虚拟机上启动 2 个 Redis 实例，端口分别为 6379 和 6380，由于在同一台机器上，所以需要修改 6380 的配置文件，主要修改以下几个选项：
此时分别启动 6379 和 6380，这里的 6379 端口由于之前的操作所以存在一部分数据，而 6380 由于上面配置文件的改动，所以并不会存在数据。
6379：
6380：
注：可通过以下命令进入指定端口的客户端
然后在127.0.0.1:6380执行如下命令：
slaveof 配置都是在从节点发起，这时 6379 作为主节点，6380 作为从节点。
复制关系建立后再去执行命令，可以看到如下：
slaveof 本身是异步命令，执行 slaveof 命令时，节点只保存主节点信息后返回，后续复制流程在节点内部异步执行。主从节点复制成功建立后，可以使用 info replication 命令查看复制相关状态。
2、断开复制
slaveof 命令不但可以建立复制，还可以在从节点执行以下命令来断开与主节点复制关系。
例如在 6380 节点上执行 slaveof no one 来断开复制。流程如下：
断开与主节点复制关系；
从节点晋升为主节点。
从节点断开复制后并不会抛弃原有数据，只是无法再获取主节点上的数据变化。
3、切主
通过 slaveof 命令还可以实现切主操作，所谓切主是指把当前从节点对主节点的复制切换到另一个主节点。执行 slaveof {newMasterIp} {newMasterPort}命令即可。
流程如下：
断开与旧主节点复制关系；
与新主节点建立复制关系；
删除从节点当前所有数据；
对新主节点进行复制操作。
4、只读
默认情况下，从节点使用以下命令配置为只读模式。
由于复制只能从主节点到从节点，对于从节点的任何修改主节点都无法感知，修改从节点会造成主从数据不一致。因此建议线上不要修改从节点的只读模式。
5、传输延迟
实际上，主从节点一般部署在不同机器上，复制时的网络延迟就成为需要考虑的问题，Redis 为我们提供了以下参数用于控制是否关闭 TCP_NODELAY，默认关闭。
当关闭时，主节点产生的命令数据无论大小都会及时地发送给从节点，这样主从之间延迟会变小，但增加了网络带宽的消耗。适用于主从之间的网络环境良好的场景，如同机架或同机房部署。
当开启时，主节点会合并较小的 TCP 数据包从而节省带宽。默认发送时间间隔取决于 Linux 的内核，一般默认为 40 毫秒。这种配置节省了带宽但增大主从之间的延迟。适用于主从网络环境复杂或带宽紧张的场景，如跨机房部署。
2.2 一主多从
一主多从针对读较多的场景，读由多个从节点来分担，但节点越多，主节点同步到从节点的次数也越多，影响带宽，也加重主节点的稳定。
在实际场景中，主从节点一般部署在不同机器上，上面演示的操作虽然在一台机器，但实际上就是一主一从的模式，这里演示在 3 台虚拟机上演示一主多从。
对于配置方式同样采取上述方式进行配置，但还存在slaveof命令之外的配置方式，在redis.conf配置文件中可通过配置replicaof 的方式来配置：
在未配置之前，我们查看主节点和两个从节点的数据：
然后通过配置文件的方式来配置并启动。
1、主节点配置
实际上主节点无需做过多配置，但为了安全性可以配置从节点密码（这里不对配置文件做过多介绍，见文末附）：
我这里为了方便演示不做任何配置。
2、从节点配置
两从节点和主节点配置也类似，但从节点需要指定主节点的 IP 和端口，如下：
3、启动
在启动从节点时发现同步失败，报错如下：
首先想到的是防火墙问题，在网上寻找解决方案时说是没有开放端口，防火墙相关操作如下：
但开启防火墙之后还是不能解决问题，最后的解决方案为：
在 redis 主服务器上的redis.conf中修改bind字段，将：
修改为：
或者直接注释掉 bind 字段。
其主要原因是如果Redis主服务器绑定了127.0.0.1，那么跨服务器 IP 的访问就会失败，从服务器用 IP 和端口访问主节点的时候，主服务器发现本机 6379 端口绑在了 127.0.0.1 上，也就是只能本机才能访问，外部请求会被过滤，这是 Linux 的网络安全策略管理的。如果 bind 的 IP 地址是192.168.153.128，那么本机通过localhost和127.0.0.1、或者直接输入命令redis-cli登录本机 Redis 也就会失败了。只能加上本机 IP 才能访问到。
所以，在研发、测试环境可以考虑bind 0.0.0.0，线上生产环境建议绑定 IP 地址。
配置完成之后，启动从节点会自动同步数据。
然后通过info replication命令在主节点查看角色信息：
另外的错误
如果启动报如下错误：
可能的原因如下：
你的主服务器自定义了密码，那么从服务器在连接时要指定主服务器的密码（上面测试未设置密码）；
主服务器设置成了 slave 模式（从服务器），登录客户端，用
slaveof no one命令改回来。我就是设置 IP 时把主节点设置为自己了。
4、测试验证
然后我们在主节点（master）添加数据，看从节点（slave）是否可以获取到，如果能获取，说明数据已经同步到了从节点，如下：
主节点：
从节点：
2.3 树状主从
树状主从结构，它可以使得从节点不但可以复制主节点数据，同时可以作为其他从节点的主节点继续向下层复制。
通过引入复制中间层，可以有效降低主节点负载和需要传送给从节点的数据量，它解决了一主多从的缺点（主节点推送次数多压力大）。
对于其搭建这里不做演示，因为一般用得少。
3. Redis Sentinel
3.1 主从复制的问题
Redis 的主从复制模式可以将主节点的数据改变同步给从节点，这样从节点就可以起到两个作用：
作为主节点的一个备份，一旦主节点出了故障不可达的情况，从节点可以作为后备顶上来，并且保证数据尽量不丢失(主从复制是最终一致性)。
从节点可以扩展主节点的读能力，一旦主节点不能支撑住大并发量的读操作，从节点可以在一定程度上帮助主节点分担读压力。
但是主从复制也带来了以下问题：
一旦主节点出现故障，需要手动将一个从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令其他从节点去复制新的主节点，整个过程都需要人工干预。
主节点的写能力受到单机的限制。
主节点的存储能力受到单机的限制。
其中第一个问题就是 Redis 的高可用问题，可以通过 Redis Sentinel 实现高可用。第二、三个问题属于 Redis 的分布式问题，需要使用 Redis Cluster，这里先说 Redis Sentinel。
3.2 可用性分析
为了方便描述，这里先对几个名词做一下解释：
Redis 主从复制模式下，一旦主节点出现了故障不可达，需要人工干预进行故障转移，无论对于 Redis 的应用方还是运维方都带来了很大的不便。
对于应用方来说无法及时感知到主节点的变化，必然会造成一定的写数据丢失和读数据错误，甚至可能造成应用方服务不可用。
对于 Redis 的运维方来说，整个故障转移的过程是需要人工来介入的，故障转移实时性和准确性上都无法得到保障。
当主节点出现故障时，Redis Sentinel 能自动完成故障发现和故障转移，并通知应用方，从而实现真正的高可用。
Redis Sentinel 是一个分布式架构，其中包含若干个 Sentinel 节点和 Redis 数据节点，每个 Sentinel 节点会对数据节点和其余 Sentinel 节点进行监控，当它发现节点不可达时，会对节点做下线标识。如果被标识的是主节点，它还会和其他 Sentinel 节点进行协商，当大多数 Sentinel 节点都认为主节点不可达时，它们会选举出一个 Sentinel 节点来完成自动故障转移的工作，同时会将这个变化实时通知给 Redis 应用方。整个过程完全是自动的，不需要人工来介入，所以这套方案很有效地解决了 Redis 的高可用问题。
注：这里的分布式是指 Redis 数据节点、Sentinel 节点集合、客户端分布在多个物理节点的架构。
Redis Sentinel 与 Redis 主从复制模式相比只是多了若干 Sentinel 节点，所以 Redis Sentinel 并没有针对 Redis 节点做了特殊处理。
从逻辑架构上看，Sentinel 节点集合会定期对所有节点进行监控，特别是对主节点的故障实现自动转移。
下面以 1 个主节点、2 个从节点、3 个 Sentinel 节点（官方文档中建议为 3 个）组成的 Redis Sentinel 为例子进行说明。
整个故障转移的处理逻辑有下面 4 个步骤：
主节点出现故障，此时两个从节点与主节点失去连接，主从复制失败；
每个 Sentinel 节点通过定期监控发现主节点出现了故障；
多个 Sentinel 节点对主节点的故障达成一致，选举出其中一个节点（假如为 sentinel-3）作为领导者负责故障转移。
Sentinel 领导者节点执行了自动化故障转移，包括通知客户端，重新选择主节点，建立新的复制关系等等。
3.3 主要功能
通过上面介绍的 Redis Sentinel 逻辑架构以及故障转移的处理，可以看出 Redis Sentinel 具有以下几个功能：
监控：Sentinel 节点会定期检测 Redis 数据节点、其余 Sentinel 节点是否可达；
通知：Sentinel 节点会将故障转移的结果通知给应用方；
主节点故障转移：实现从节点晋升为主节点并维护后续正确的主从关系；
配置提供者：在 Redis Sentinel 结构中，客户端在初始化的时候连接的是 Sentinel 节点集合，从中获取主节点信息。
同时看到，Redis Sentinel 包含了若个 Sentinel 节点，这样做也带来了两个好处
对于节点的故障判断是由多个 Sentinel 节点共同完成，这样可以有效地防止误判；
Sentinel 节点集合是由若干个 Sentinel 节点组成的，这样即使个别 Sentinel 节 点不可用，整个 Sentinel 节点集合依然是健壮的。
但是 Sentinel 节点本身就是独立的 Redis 节点，只不过它们有一些特殊，它们不存储数据，只支持部分命令。
3.4 部署
这里仍然使用三台服务器搭建 Redis Sentinel，3 个 Redis 实例（1 主 2 从）+ 3 个哨兵实例，即一主两从三哨兵。
3.4.1 部署 Redis 节点
通过在主从复制踩的坑，我们这边直接把 Redis 实例的配置文件配置好。
1、主节点配置
2、从节点配置
基本配置和主节点相同，bind 地址各自对应各自的。
3、启动
先启动主节点，在启动 2 个从节点。
注：我这里清空了主节点的所有数据（FLASHALL），生产环境勿用。
然后查看主从关系：
3.4.2 部署 Sentinel 节点
3 个 Sentinel 节点的部署方法和配置是完全一致的，在 Redis 源码包下存在sentinel.conf文件，Sentinel 节点的默认端口是 26379。
1、配置文件
2、启动 Sentinel 节点
Sentinel 节点的启动方法有两种，两种方法本质上是—样的。
使用 redis-sentinel 命令
redis-server 命令加 --sentinel 参数
启动之后如下：
Sentinel 节点本质上是一个特殊的 Redis 节点，所以也可以通过 info 命令来查询它的相关信息，从下面 info 的 Sentinel 片段来看，Sentinel 节点找到了主节点 192.168.153.128:6379，发现了它的两个从节点。
至此 Redis Sentinel 已经搭建起来了，整体上还是比较容易的，但是需要注意的是 Redis Sentinel 中的数据节点和普通的 Redis 数据节点在配置上没有任何区别，只不过是添加了一些 Sentinel 节点对它们进行监控。
3.5 高可用测试
Sentinel 主要作用就是高可用，此时我们模拟主机宕机，即关掉主节点。
此时，在从节点通过info replication发现192.168.153.130变为了主节点，如下：
192.168.153.130
192.168.153.129
此时，通过哨兵机制，选举了新的主节点，并把从节点重新选择了新选举出来的主节点。
需要注意的是，主从切换后配置文件会被自动更改。
3.6 部署建议
1、Sentinel 节点不应该部署在一台物理机器上
这里特意强调物理机是因为一台物理机做成了若干虚拟机或者现今比较流 行的容器，它们虽然有不同的 IP 地址，但实际上它们都是同一台物理机，同一台物理机意味着如果这台机器有什么硬件故障，所有的虚拟机都会受到影响，为了实现 Sentinel 节点集合真正的高可用，请勿将 Sentinel 节点部署在同一台物理机器上。
2、部署至少三个且奇数个的 Sentinel 节点
3 个以上是通过增加 Sentinel 节点的个数提高对于故障判定的准确性，因为领导者选举需要至少一半加 1 个节点，奇数个节点可以在满足该条件的基础上节省一个节点。这是因为：
在节点数量是奇数个的情况下， 集群总能对外提供服务（即使损失了一部分节点）；
如果节点数量是偶数个，会存在集群不能用的可能性（脑裂成两个均等的子集群的时候）；
假如集群 1 ，有 3 个节点，3/2=1.5 ，即集群想要正常对外提供服务（即 leader 选举成功），至少需要 2 个节点是正常的。换句话说，3 个节点的集群，允许有一个节点宕机。
假如集群 2，有 4 个节点，4/2=2，即想要正常对外提供服务（即 leader 选举成功），至少需要 3 个节点是正常的。换句话说，4 个节点的集群，也允许有一个节点宕机。
那么问题就来了， 集群 1 与集群 2 都有允许 1 个节点宕机的容错能力，但是集群 2 比集群 1 多了 1 个节点。在相同容错能力的情况下，本着节约资源的原则，集群的节点数维持奇数个更好一些。
3、只有一套 Sentinel，还是每个主节点配置一套 Sentinel
Sentinel 节点集合可以只监控一个主节点，也可以监控多个主节点。 那么在实际生产环境中更偏向于哪一种部署方式呢，下面分别分析两种方案的优缺点。
方案一：一套 Sentinel，很明显这种方案在一定程度上降低了维护成本，因为只需要维护固定个数的 Sentinel 节点，集中对多个 Redis 数据节点进行管理就可以了。但是这同时也是它的缺点，如果这套 Sentinel 节点集合出现异常，可能会对多个 Redis 数据节点造成影响。还有如果监控的 Redis 数据节点较多，会造成 Sentinel 节点产生过多的网络连接，也会有一定的影响。
方案二：多套 Sentinel，显然这种方案的优点和缺点和上面是相反的，每个 Redis 主节点都有自己的 Sentinel 节点集合，会造成资源浪费。但是优点也很明显，每套 Redis Sentinel 都是彼此隔离的。
那么如何选择呢？
如果 Sentinel 节点集合监控的是同一个业务的多个主节点集合，那么使用方案一，否则一般建议采用方案二。
4. Redis 集群
前面我们知道 Sentinel 解决了高可用问题，但是它也存在一个缺点，由于一主二从每个节点都存储着全部数据，随着业务庞大，数据量会超过节点容量，即便是 Redis 可以配置清理策略，但也有极限，于是需要搭建 Redis 集群，将数据分别存储到不同的 Redis 上，并且可以横向扩展。
Redis Cluster（集群）是 Redis 的分布式解决方案（Redis 官方推荐），在 3.0 版本正式推出，有效地解决了 Redis 分布式方面的需求。当遇到单机内存、并发、流量等瓶颈时，可以采用 Cluster 架构方案达到负载均衡的目的。
既然它是分布式存储，也就有说每台 Redis 节点上存储不同的数据。把整个数据按分区规则映射到多个节点，即把数据划分到多个节点上，每个节点负责整体数据的一个子集。
比如我们库有 900 条用户数据，有 3 个 Redis 节点，将 900 条分成 3 份，分别存入到 3 个 Redis 节点：
关于数据的分布及分区规则这里不做细讲，可自行百度，Redis Cluser 主要采用的是哈希槽（hash slot）。
4.1 集群说明
搭建集群有以下 3 种方式：
依照 Redis 协议手工搭建，使用 cluster meet、cluster addslots、cluster replicate 命令。
5.0 之前使用由 ruby 语言编写的 redis-trib.rb，在使用前需要安装 ruby 语言环境。
5.0 及其之后 Redis 摒弃了 redis-trib.rb，将搭建集群的功能合并到了 redis-cli。
因此这里直接采用第三种方式搭建，而集群中至少应该有奇数个节点，所以至少有三个节点，官方推荐三主三从的配置方式，所以按照官方推荐搭建一个三主三从的集群。
由于是三主三从，所以需要准备 6 台 Redis，这里启用 6 台虚拟机（内存 1G，实力不允许，就这点资本了🙃），配置相同，如下：
4.2 节点配置
三主三从，即三组一主一从。组内是主从关系，可以实现高可用；组间是集群关系，实现分工存储。
随意对应，无任何规则。
修改 redis.conf配置文件，所有的节点的配置文件都是类似的：
配置之后 6 台 Redis 启动：
4.3 搭建集群
通过redis-cli的方式搭建集群也有两种：
1、创建集群主从节点
说明：--cluster-replicas 1 ，1 表示每个主节点需要 1 个从节点。
通过该方式创建的带有从节点的机器不能够自己手动指定主节点，不符合我们的要求。所以如果需要指定的话，需要自己手动指定，先创建好主节点后，再添加从节点。
2、创建集群并指定主从节点
① 创建集群主节点
先创建集群主节点，按照上面定义的主节点，然后在任一节点下执行如下命令：
需要注意以下问题：
记录下每个 M 后如
a7e948208badf171d19dbfe2d444ea7295bdbf60的字符串，在添加从节点时需要；如果服务器存在着防火墙，那么在进行安全设置的时候，除了 Redis 服务器本身的端口，比如 6379 要加入允许列表之外，Redis 服务在集群中还有一个叫集群总线端口，其端口为客户端连接端口加上 10000，即
6379 + 10000 = 16379。所以开放每个集群节点的客户端端口和集群总线端口才能成功创建集群。
② 添加集群从节点
添加集群从节点，命令如下：
说明：上述命令把 192.168.153.129:6379节点加入到 192.168.153.128:6379节点的集群中，并且当做 node_id 为 a7e948208badf171d19dbfe2d444ea7295bdbf60的从节点。如果不指定 --cluster-master-id 会随机分配到任意一个主节点。如下：
有 3 个节点，依次执行以下 3 条命令：
注：不要把主从节点顺序颠倒了，否者会出现以下错误：
4.4 集群管理
1、检查集群
任意连接一个集群节点，进行集群状态检查
2、集群信息查看
检查 key、slots、从节点个数的分配情况。
4.5 redis-cli --cluster 参数参考
redis-cli –-cluster命令后有很多参数配置：
5. 总结
回到我们最初的问题：如何保证 Redis 的高并发和高可用？
一般来说，使用 Redis 主要是用作缓存，如果数据量大，一台机器肯定是不够的，肯定要考虑如何用 Redis 来加多台机器，保证 Redis 是高并发的，还有就是如何让 Redis 保证自己不是挂掉以后就直接死掉了，即 Redis 高可用。
对于高可用，通过 Redis 主从架构 + 哨兵可以实现高可用，一主多从，任何一个实例宕机，可以进行主备切换。一般来说，很多项目其实就足够了，单主用来写入数据，单机几万 QPS，多从用来查询数据，多个从实例可以提供每秒 10w 的 QPS。
对于高并发，那么就需要 Redis 集群，多主多从，使用 Redis 集群之后，可以提供每秒几十万的读写并发。
附：配置文件详解
redis.conf
sentinel.conf
版权声明: 本文为 InfoQ 作者【Ayue、】的原创文章。
原文链接:【http://xie.infoq.cn/article/51b6930655799b44fa9d2fc5f】。文章转载请联系作者。
🏆 InfoQ写作平台-签约作者 🏆 2019.10.16 加入
个人站点：javatv.net | 学习知识，目光坚毅
评论