没有公司自己做网站软文广告经典案例

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

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

单机模式

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

优势

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

劣势

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

主从模式

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

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

优势

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

劣势

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

哨兵模式

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

优势

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

劣势

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

集群模式

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

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

优势

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

劣势

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

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

全量复制

出现场景

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

过程

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

部分复制

出现场景

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

过程

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

本文首发于cartoon的博客

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