1. 目的

撰写本文的目的是解决微服务架构，对静态数据资源没有规整，所有微服务都是从数据库直接读取，导致性能较差，用户体验不好。通常在高可用的分布式架构中，一般都会采用将这部分数据放到内存当中，提高系统的访问性能。

如果采用Redis这种内存型的缓存数据库，那么针对分布式架构来说，必然要考虑其高可用，因此我们必然要考虑搭建Redis的集群方案来为微服务平台提供保障。

2. 技术体系

Redis 3.0之后的版本支持Cluster。许多公司采用的是阿里云提供的Redis服务，使用的单节点的模式。

3. 缓存对象

3.1. 公共数据

公共数据：用户数据、基础字典等配置信息。

数据类型：经过对现有公共接口数据结构的分析，基本都是以List集合的形式对外输出。

3.2. 独立微服务数据

指的是某个微服务自己使用的数据，如：报表的数据编辑实时填写缓存到Redis。

数据类型： String、List

4. 技术方案

4.1. 阿里云产品介绍

4.1.1. 规格介绍

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

5. 运行保障

5.1. 监控指标

连接客户数

阻塞连接数

Redis占用内存

内存峰值

主从角色

master_link_status

执行命令总数和qps

上报时间