鲁达 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
上报时间