分布式缓存平台方案

1、总体说明

1.1、采取redis的原因

1.2、平台总体架构

2、多协议支持方案

3、高可用（HA）方案

3.1、基础设施

3.2、故障检测

3.3、故障切换

4、分布式方案

4.1、垂直扩展

4.2、水平扩展

5、容量管理

6、安全

6.1、配置安全

6.2、访问安全

6.3、内置安全机制

7、运维和管理平台

7.1、集群和实例管理

7.2、监控

7.3、统计

7.4、管理工具

7.5、自监控

1、总体说明

以redis为底层存储设施，建设高性能、高可用、可扩展、易于运维和管理的缓存平台，以灵活满足各种缓存应用场景。

1.1、采取redis的原因

由VMWare支持，开发活跃。社区非常成熟，包括StackOverflow/暴雪/新浪微博/Flickr等公司广泛使用。
高性能：100k+TPS。
功能丰富。K/V存储的Value不仅仅支持string，还支持list、hash、set、sorted set。大量的原子操作。基本涵盖了memcached的功能。
支持经典的Master/Slave高可用部署架构，支持缓存内容的持久化。

redis提供的这些特性，便于达成我们的目标。在此之上，按照实际的业务需求，进行扩展和辅助工具的开发，建立完善的统一管理平台。

1.2、平台总体架构

Redis server pool

独立部署一系列redis server或者将现有已经部署的redis server纳入管理，形成逻辑上统一的缓存资源池。

Gather servers

部署一系列分布式采集应用节点，分别对所有的redis server和redis proxy进行信息采集，存储的同时发送到实时监控服务。

监控服务

对采集传输的数据进行实时分析，使用预定义的一系列规则进行报警。

Stat/Analysis服务

部署一系列分布式统计应用节点，分别对原始采集数据进行准实时统计汇总并存储。原始采集信息统计完毕之后删除。集中存储所有的统计结果。统计节点本地系统同时存储本节点负责的统计结果，以便展现。

Config/Meta/Manage Servers

负责将变动的集群信息（节点拓扑、路由和读写策略等）push到相应的proxy。负责提供配置和元信息服务，以便应用端的Client SDK来polling变更。负责控制各个物理机上的Agent，对redis实例进行部署管理和配置文件同步。

Agent

部署在缓存资源池中各个物理机上，负责本机redis实例的部署和配置文件同步。

Client SDK

Client SDK为应用提供操作redis集群数据的API。利用polling到的集群配置元信息（节点拓扑、路由和读写策略等），访问后端的redis server节点。SDK负责监控配置信息变更（比如故障切换、服务节点迁移等），动态重启底层的连接池。对应用透明。

Proxy

Client SDK相对比较复杂，而且需要适应多种开发语言。因此可以把Client SDK的功能后移到中间的proxy层，通过proxy来对应用屏蔽这些复杂性。Redis proxy是实现了redis 协议的无状态的server，无论何种语言的redis客户端都可访问它。应用通过load balance设备来访问后端的多个proxy server。

管理平台

包括对以上各个组件的统一管理，以及一系列运维管理工具。

2、多协议支持方案

缓存平台对外提供的协议或接口，除了本身就支持的redis协议外，还可通过proxy中间件提供memcached、REST等协议。

虽然proxy方式比native直连方式性能要差，但也有优势：

底层实现可替换
满足多协议需求
屏蔽底层设施中复杂的分布式路由、故障切换、读写策略等
可以自由使用现成的多语言客户端

在性能完全满足业务需求的场景，可考虑使用proxy。否则，可使用专用的redis客户端SDK。

3、高可用（HA）方案

3.1、基础设施

底层支持：Master/Slave复制、AOF日志持久、RDB快照持久

扩展：jd-redis-dumper。

3.1.1、Master/Slave复制

典型部署场景

在运营经验上，链式复制优于1->n的复制方式。

通过跨机房复制，提高本地读性能。

复制机制

redis采用异步方式保证最大的复制效率，同时对master性能影响最小。不支持同步方式，而是通过复制的可靠性配置来保证数据的安全。

复制的可靠性（延时保证）

min-slaves-to-write <number of slaves> #最少需要存在slave数量才能允许写

min-slaves-max-lag <number of seconds> #slave落后master最大的秒数

一致性保证

slave-read-only true

3.1.2、AOF

将redis实例所有的写操作命令以redis协议文本格式追加到本机日志文件，通过replay日志来恢复数据。

可靠性保证

appendfsync always：每次追加日志同时都执行fsync持久到介质，最可靠，性能最差。

appendfsync no：只追加，不执行fsync。由操作系统保证高速缓存持久到介质，性能最高，可靠性依赖操作系统，有可能丢失尚未持久到介质的更新数据。

appendfsync everysec：每秒执行一次fsync，性能居中，最坏丢失的更新数据不超过2秒。

AOF整理

自动：auto-aof-rewrite-percentage <percent>，自动重新AOF以减少文件大小。

手动/定时：bgrewriteaof

3.1.3、RDB快照

将redis实例内存数据完整的持久到本机二进制快照文件，通过load快照文件恢复数据。

可靠性保证

stop-writes-on-bgsave-error no

策略

自动：save <after seconds> <if changes number>

手动/定期：bgsave

3.1.4、jd-redis-dumper

实现redis的复制协议的中间件。在跨机柜/交换机或者跨机房的主机上，将一个或多个实例的数据复制到jd-redis-dumper所在机器，并以AOF或RDB方式存储。通过远端的AOF和RDB来恢复数据。数据安全和Master/Slave一样，但是节约了内存资源，恢复速度要慢。

3.1.5、基础设施小结

从数据安全等级、故障恢复速度综合来看，优先级如下：

Master/Slave复制 > jd-redis-dumper > AOF > 快照

实践：

性能优先的关闭复制、AOF和快照；
master关闭rdb/aof，使用slave replication
slave上开启rdb+aof
读压力大的slave上关闭rdb+aof，通过jd-redis-dumper来备份
若开启复制或持久，预留一倍空闲内存
多实例时，由管理平台依次执行bgsave/bgrewriteaof，避免同时fork进程

3.2、故障检测

3.2.1、分布式采集器

zookeeper协调的多个采集器，定期收集所有集群和实例的info/config信息供准实时分析，同时发现故障实例，报告给故障决策组件。

3.2.2、存活报警策略

实例不存活报告次数，在某个时间范围内，到达指定值，则进行报警。

3.2.3、官方的Sentinel

分布式的故障检测组件，实践中不合适管理大量的集群。

3.3、故障切换

当发生报警后，通过人工或者故障决策组件自动确认后，开始进行故障切换。只有AOF或者RDB的，通过Agent重启实例恢复数据。有Slave的，将Slave提升为主。

192.168.110.23:6379（Master）到192.168.110.24:6379（Slave）的连接故障；
Gather/Analysis检测并分析到Master故障，Slave存活，将新的主从拓扑关系通知到Config Manage Server；
Manage Server 更改192.168.110.24:6379(Slave)的slave-read-only false，并更新配置信息；
App-1轮询到最新配置；
App-1重启连接池连接到192.168.110.24:6379(Slave)，发送读写请求；4
App-2轮询到最新配置；
App-2重启连接池连接到192.168.110.24:6379(Slave)，发送读写请求；
Gather/Analysis检测并分析到没有有效客户端连接到Master，通知Manage Server；
Config/Manage Server同时确认客户端全都更新到最新配置（客户端心跳），则对192.168.110.24:6379（Slave）发送切换为Master的命令；
若192.168.110.23:6379(原Master)恢复存活，则设置为192.168.110.24:6379（新Master）的Slave，进行数据复制。

4、分布式方案

通过在本机或跨机部署多个实例形成一个逻辑上的集群，提高整体性能，减少单点故障。每个实例作为逻辑集群的一个分片（Sharding），承担部分数据的存储和读写请求。每个分片还可以配置对应的Slave，形成一个高可用分布式的集群方案。client/proxy按照key通过特定路由算法（比如一致性hash）请求特定的分片。