目录
- 架构为啥要设计
- Redis 支持的四种架构模式
- 单机模式
- 性能分析
- 优点
- 缺点
- 主从复制(读写分离)
- 结构
- 性能分析
- 优点
- 缺点
- 适用场景
- 哨兵模式
- 结构
- 优点
- 缺点
- 应用场景
- 集群模式
- 可用性和可扩展性分析
- 单机模式
- 主从模式
- 哨兵模式
- 集群模式
- 总结
本文主要以 Redis 为例,对比分析不同模式下的
优缺点
,以及 系统
可用性
和
可扩展性
,不涉及每个模式的原理实现。
架构为啥要设计
并发量的不断提高
是根本原因,要想系统不崩溃,接住这泼天的流量,需要及时找到当前新系统的瓶颈,可能是redis,mysql 或者其他组件
,解决瓶颈,提高对高并发的支持- 举个例子,自己干活就是
单机模式
(只能接待几个客户,而且忙死),夫妻店就是主从模式
(可以接待更多的客户),搞一个团队就是集群模式
,可以招待更多的客户。这几种是常见的架构,具体的 开源框架,要看它支持哪些架构。 如何看公司的系统是啥架构,直接看配置文件里关于redis 的配置就可以了
所以架构考虑的是 可用性 和 可扩展性,可以对比不同模式下的系统可用性和可扩展性。
扩展性又分为纵向扩展(加内存,加处理器,提高单机能力)和横向扩展(加单机,多个单机直接性能翻倍)。
Redis 支持的四种架构模式
- 单机模式
- 主从复制(读写分离)
- 哨兵模式
- 集群模式
单机模式
性能分析
- 顾名思义,就是一个
Redis实例节点
,读写数据都找它,根据官网,单机模式如果是简单的 kev-value 读写,QPS(每秒查询速率)可支持 10w 并发,实际情况可能有复杂对象的读写,一般小于 10w。
优点
- 单机模式最大的好处就是部署简单,不存在数据同步的问题
缺点
存在单点故障
,也就是加入某个时刻,这个Redis实例故障了,那系统直接没法对外提供读写功能了,所以如果不想有单点故障,就得换其他模式。 单点故障不是只有redis有,任何的单个节点,都存在单点故障,是通病- 如果系统用户激增,上千万用户同时访问 Redis,QPS 达到 10 万+。这些请求过来,单机 Redis 直接就挂了。系统的瓶颈就出现在 Redis 单机问题上,此时我们可以通过主从复制解决该问题,实现系统的高并发。
主从复制(读写分离)
结构
主从复制
(从从节点的角度,从节点复制主节点的数据),主从同步
(从主节点的角度,主节点会给从节点同步数据),读写分离
(从读写操作的角度,读操作和写操作可以访问不同的redis实例),说的都是同一个模式- 主从复制架构里,必须只有一个
主节点
,从节点的个数不定。如果是一个从节点
,就叫一主一从
- 从功能上,
写操作只能访问主节点
,这个是由主节点和从节点之间数据同步的方式决定的,主从模式下,只能主节点给从节点同步数据,来保证数据的一致性。读操作就可以访问所有节点了
,因为读操作不改变数据的状态。
性能分析
- 估算性能的时候可以简单叠加,比如一个实例支持并发是10w,那两个实例就是20w
- 由于主从模式,读写是分开的,可以看出,对于
一主两从
,读可以读三个节点,那读性能就是 30w;写只能写主机点,写性能就是10w。
优点
使系统具备了读性能的水平扩展的能力
(如果用户变得更多,并且绝大多数都是读操作,那我就一直加从节点,分摊读数据的压力)优化了单点故障
,如果主节点故障了,就手动切换
某一个从节点为主节点,继续提供写服务。可以看出这块还能优化
缺点
- 主从模式虽然提高了系统读性能,但是写性能仍然受限,由于从节点存的是数据的备份,系统的存储性能也受限(只有一个主节点存数据,而不是 n 个节点都存)
- 主节点故障,需要手动切换,手动指定哪个是主节点,哪个是从节点,很麻烦
适用场景
- 高并发读,但是写不多的场景;同时对系统故障不那么敏感
哨兵模式
结构
- 包含
哨兵节点
和数据节点
,数据节点中包含主节点
和从节点
- 从Redis实例的角度看,哨兵和数据节点都是一样的
- 哨兵节点:特殊的 Redis 节点,
不存储数据
,用来监控数据节点,如果主节点挂了,及时选举出新的主节点 - 数据节点:主节点和从节点都是数据节点。主节点只能有一个,功能同主从模式。
优点
- 解决了单点故障的问题,可以自动选举主节点
- 是对主从模式的进一步优化
缺点
- 扩展性 同 主从模式一样,受限于单点写性能和存储性能(但是对一般小公司来说够用了)
应用场景
- 大多数小公司会选用哨兵模式,大型互联网公司得上集群模式
集群模式
集群模式可理解为 多主多从
架构,从而可以改善系统的写能力,进一步提高系统的可用性。是大公司的首选
可用性和可扩展性分析
单机模式
- 可用性 和 可扩展性 均不高
- 可用性差是因为 一旦故障,则直接没法提供服务
- 可扩展性不高是因为如果系统用户激增,读写请求 10w+,系统还得崩,没法直接加服务来缓解
主从模式
- 相比
单机模式
- 提高了系统部分
横向可扩展性
,具体是可以方便的通过加从节点
的方式提高系统的读请求处理能力 - 提供了系统的
可用性
,但远达不到高可用,具体是当读操作猛增,可通过加从节点让系统不崩,或主节点挂了,可以手动切换主节点,继续提供服务
哨兵模式
- 相比
主从模式
- 提供了系统的
可用性
,具体是如果主节点挂了,系统会自动选举新的主节点,减少了故障时间,从而提高了系统的可用性
集群模式
- 相比
主从模式,哨兵模式
- 提高了系统的
可用性
,可以通过添加主节点
或从节点
,任意的提高系统的读、写能力,不管用户怎么增加,我都能hold住 - 提高了系统的
可扩展性
,同理 - 至此,完成了系统的
高可用性
和高可扩展性
总结
- 面对不同的业务场景,可根据需要 确认当前可使用哪个架构模式 解决当前系统的瓶颈
- 思路是如果并发量不断提高,你怎么优化系统的架构。
- 本文只是从 Redis 的角度出发,如果再跳出一层,站在全局的角度,可优化的方案又是怎样呢