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存储，脱机影响不大的应用。

 

 

4.3.2. Redis sentinel

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

 

 

应用场景：用于高可用需求场景,可用于高可用Cache,存储等场景。 内存/QPS受限于单机。

4.3.3. Redis Cluster

可直接采用官方给出的推荐方案，将node配置成主从结构。图下图所示为最小节点的Redis高并发、高可用集群。

应用场景：用于高可用需求场景,可用于大数据量高可用Cache/存储等场景。 内存/QPS不受限于单机，可受益于分布式集群高扩展性。

 

 

4.4. 数据存储格式

鉴于我们的微服务众多，为了规避key一样的情况发生。因此，需要约定下存储格式：服务名#业务分类名##key(调用的key)

公共接口数据key约定：服务器ID#user##key(调用的key)；

独立微服务数据key约定：服务器ID#服务名##users##getUsersDetail(调用的key)；

以上所有的“cs#user##”或“服务名#”开头的前缀，统一由公共接口实现，业务方使用时的入口为最后的key即可。

4.5. 可用API

接口：IRedisService

序号	接口定义	描述
1	boolean set(String key, Object value)	添加String类型的缓存数据
2	boolean set(String key, Object value, Long expireTime)	自定义有效时间的String类型缓存数据
3	Object get(String key)	读取String类型的缓存
4	void setHash(String key, Map<?,?> map)	哈希 添加Map
5	Object getHash(String key)	获取哈希数据
6	void setList(String key, Object value)	List列表添加
7	List<Object> getList(String key, long start, long end)	List列表获取	start 开始 end 结束 0 到 -1代表所有值
8	void addSet(String key, Object value)	Set集合添加
9	Set<Object> getSet(String key)	Set集合获取
10	void addZSet(String key, Object value, double scoure)	ZSet有序集合添加
11	Set<Object> getZSet(String key, double scoure, double scoure1)	ZSet有序集合获取
12	boolean expire(String key,long time)	指定某key的缓存有效时间
13	long getExpire(String key)	获取指定key的过期时间
14	void remove(String... keys)	删除一组或单个key的缓存数据
15	boolean exists(String key)	判断缓存中是否有对应的value

 

5. 运行保障

5.1. 监控指标

连接客户数

阻塞连接数

Redis占用内存

内存峰值

主从角色

master_link_status

执行命令总数和qps

上报时间