实战Redis,解决高并发性能问题

1. 目的撰写本文的目的是解决微服务架构,对静态数据资源没有规整,所有微服务都是从数据库直接读取,导致性能较差,用户体验不好 。通常在高可用的分布式架构中,一般都会采用将这部分数据放到内存当中,提高系统的访问性能 。
如果采用redis这种内存型的缓存数据库,那么针对分布式架构来说,必然要考虑其高可用,因此我们必然要考虑搭建Redis的集群方案来为微服务平台提供保障 。
2. 技术体系Redis 3.0之后的版本支持Cluster 。许多公司采用的是阿里云提供的Redis服务,使用的单节点的模式 。
3. 缓存对象3.1. 公共数据公共数据:用户数据、基础字典等配置信息 。
数据类型:经过对现有公共接口数据结构的分析,基本都是以List集合的形式对外输出 。
3.2. 独立微服务数据指的是某个微服务自己使用的数据,如:报表的数据编辑实时填写缓存到Redis 。
数据类型: String、List
4. 技术方案4.1. 阿里云产品介绍4.1.1. 规格介绍 序号
规格类型
描述
适用场景
1
标准版-单副本
标准版-单副本采用单个数据库节点部署架构
l 纯缓存类业务场景 。
说明 对数据可靠性要求较高的敏感性业务,不建议使用单副本版 。
l 对Redis协议兼容性要求较高的场景 。
l 单个Redis性能压力可控的场景 。
l Redis命令相对简单,排序和计算之类的命令较少的场景 。
2
标准版-双副本
标准版-双副本采用主从(Replication)模式搭建 。
l 对Redis协议兼容性要求较高的业务 。
l Redis作为持久化数据存储使用的业务 。
l 单个Redis性能压力可控的场景 。
l Redis命令相对简单,排序和计算之类的命令较少的场景 。
3
集群版-单副本
单副本集群版实例采用集群架构,每个分片服务器采用单副本模式 。
l 数据量较大的场景 。
l 纯缓存类业务场景 。
说明 对数据可靠性要求较高的敏感性业务,不建议使用集群版-单副本 。
l QPS压力较大的场景 。
l 吞吐密集型应用场景 。
l 对数据持久化无要求的缓存类型业务场景 。
4
集群版-双副本
双副本集群版实例采用集群架构,每个分片服务器采用双副本模式 。
l 数据量较大的场景 。
l QPS压力较大的场景 。
l 吞吐密集型应用场景 。
5
读写分离实例
Redis读写分离版本由代理服务器(Proxy Servers)、主备(Master and Replica)节点及只读(Read-Only)节点组成 。
l 读取请求QPS压力较大的场景 。
l 对Redis协议兼容性要求较高的业务场景 。
l Redis作为持久化数据存储使用的业务场景 。
 
 
4.1.2. 规格性能 
4.2. 服务器配置目前,在阿里云上,由于各位服务对redis使用量较少,甚至有的服务中基本没有使用,所以当前的配置是1核1G
 
4.3. 三种架构模式4.3.1. Redis主从Redis主从模式是最简单的一种集群方案配置起来也比较简单,它的特点主要有:
l 一个master可以拥有多个slave;
l 多个slave链接同一个master,也可以链接其它slave;
l 主从复制不会阻塞master,在同步数据时,master可以继续处理client请求;
l slave 配置为slave-read-only on需要升级为主节点或者写入配置文件中, 而不能在默认slave情况下直接设置master与slave断开后会检测心跳, 重新建立连接;
l 可以直接copy DUMP文件重新重启master,在Master为空以后,slave同步数据会抹掉全部数据 。
该方案缺点较多,往Master节点写数据,同时Master节点会异步写入slave节点中 。这种方案目前使用的越来越少,不过对于个体开发并且对缓存依赖度不高的系统还是可以使用的,毕竟搭建和维护简单 。
应用场景:可用于可穿透的业务场景,如后端有DB存储,脱机影响不大的应用 。

实战Redis,解决高并发性能问题

文章插图
 

实战Redis,解决高并发性能问题

文章插图
 
4.3.2. Redis sentinel鉴于4.1.1节描述的standalone类型的架构缺点较多,故在此模式基础上,增加sentinel哨兵,用于监控master/slave运行情况、调度Redis主从切换等 。下图中对于sentinel使用了最小粒度的集群模式,最大限度地实现较小规模的高可用缓存 。
实战Redis,解决高并发性能问题

文章插图


推荐阅读