Redis 的三种部署模式

提前叠个 buff：这个文章不涉及图（画起来比较麻烦），只是记录我的胡思乱想。

redis 从单点 -> 集群总共有三个部署模式：单机模式，主从模式，哨兵模式，集群模式

单机模式

新手入门模式。单机模式意味着 Redis 是单点的，部署在一台服务器，挂了就挂了，用在本地测试还可以，但是生产环境就算了。

优势

部署简单
省钱，一台服务器就可以了
不涉及主从复制等，数据强一致

劣势

单点意味着稳定性基本上为 0，挂了就挂了
吞吐量受限于单机资源

主从模式

当流量越来越大，单台机器资源不能无限增长，就需要水平扩展到多个节点，使用多个节点分散承接读流量。

主从模式为主节点承接写流量，从节点承接读流量，二者数据一致通过主节点异步复制（全量复制 / 增量复制）到从节点。

优势

读流量被分摊到多个节点上，读流量支持力度变大
当主节点宕机/不可用时，可以手动切换主节点继续提供服务

劣势

当主节点宕机/不可用时手动切换节点，切换过程中 redis （主节点）不可用，并且会丢失主节点 / 从节点之间未同步的数据
稳定性还是不够，依赖手动切换。不适用于生产。
写流量还是让主节点独自承受，写流量还是靠单机资源支撑

哨兵模式

哨兵模式主要解决主从模式中手动切换的部分，本质上哨兵代替了人，通过 gossip 协议监控主节点的健康情况。

优势

不用手动切换主节点了，切换过程中虽然 redis 也是不可用的，但是这个时间会极大的降低

劣势

sentinel 与主节点多了一层心跳检测，有可能 sentinel 与主节点的网络抖动导致重新选举主节点。
redis 主从节点吞吐因心跳检测可能稍微降低。

集群模式

集群模式主要解决了两个问题：写流量水平扩展 & 哨兵与主节点的网络抖动。

集群模式主要的架构为：主节点平分 16384 个槽，集群支持主节点的动态上线/下线（需要 rehash），主节点与从节点通过心跳关联，主节点失联后从节点有权发起选举成为主节点（raft 算法）。

优势

自管理集群内主从节点上下线，减少因外部集群网络抖动之类的发起的无效选举
数据按照 slot 存放在多个节点，客户端通过服务端主节点的重定向跳转到具体的槽，可动态调整数据分布
减少了集群整体不可用的概率，某一主节点宕机只影响一部分数据的访问
写流量 & 数据平分到多个节点，集群的写请求瓶颈得到缓解

劣势

集群间状态同步使用 gossip 协议，节点数较多存在较多的心跳网络流量
主节点的上线/下线需要进行 rehash ，当节点内数据较多耗时较长

redis 节点间复制有两种：全量复制 & 部分复制

全量复制

出现场景

从节点刚上线需要同步主节点的数据
从节点切换脑裂后从节点偏移量与主节点不一致的时间点
从节点偏移量不在主节点的复制缓冲区中

过程

从节点向主节点发起同步数据的请求
主节点通过 bgsave 形成当前数据的快照，发给从节点
从节点删除历史数据，加载主节点发过来 RDB 文件
从节点拉取主节点缓冲区数据，加载到自身的内存中，并更新当前的偏移量

部分复制

出现场景

全量复制出现场景之外的场景
主从日常复制

过程

主节点将命令同步到缓冲区（AOF）
从节点拉取缓冲区数据，更新到自身的节点中，并更新当前的偏移量

本文首发于cartoon的博客

转载请注明出处:https://cartoonyu.github.io