分布式缓存平台方案

 

1、总体说明

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

缓存平台目标

 

1.1、采取redis的原因

  1. 由VMWare支持,开发活跃。社区非常成熟,包括StackOverflow/暴雪/新浪微博/Flickr等公司广泛使用。
  2. 高性能:100k+TPS。
  3. 功能丰富。K/V存储的Value不仅仅支持string,还支持list、hash、set、sorted set。大量的原子操作。基本涵盖了memcached的功能。
  4. 支持经典的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直连方式性能要差,但也有优势:

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

 

在性能完全满足业务需求的场景,可考虑使用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提升为主。

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

 

4、分布式方案

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

Redis sharding+clientside routing

 

 

目前redis的最佳实践是pre-sharding + clientside routing来做分布式方案,其cluster方案还不成熟。

4.1、垂直扩展

    pre-sharding,创建足够多的分片实例,部署在有限的几台物理机上。当缓存增长时,可通过扩大物理机内存,或将实例迁移到另外的物理机上,并扩大每个实例的最大内存设置,来达到整体扩容的目的。

    故障切换流程同样适用于实例迁移。

4.2、水平扩展

    当一个分片实例的内存容量增长到已经不合适放在一台物理机上时,势必要进行分片数量的增加。涉及到缓存数据的重新分布,可通过jd-redis-bridge来做。

Jd-redis-bridge原理图

 

 

5、容量管理

        预先规划,合理配置。按照业务缓存数据增长量来提前规划分片数量,权衡成本和收益,配合垂直扩展和水平扩展来适应缓存的增长。

实践:

  • 仔细设计数据结构和codec
  • CPU不是瓶颈,内存和网络才是
  • hash-max-zipmap-entries <n> /  hash-max-zipmap-value <n>
  • 设置maxmemory,设置预警规则
  • 合理设置缓存项逐出策略
  • 合理设置缓存项过期时间

6、安全

6.1、配置安全

屏蔽或修改危险命令:

  • rename-command SHUTDOWN
  • rename-command CONFIG youdontknow

6.2、访问安全

    直连方式

        ClientSDK通过token获取相应的集群拓扑配置。

    Proxy方式

        Redis的auth协议被用作client的token,proxy与后端server不需要认证。

6.3、内置安全机制

    为redis实例配置passwd

7、运维和管理平台

7.1、集群和实例管理

  • 集群/实例/应用元信息管理
  • 可视化的集群拓扑图
  • 访问令牌、配置管理
  • Slowlog查看
  • info/config信息查看

7.2、监控

  • 针对集群实例、或者不同的角色(Master/Slave)的重点指标设置监控规则
  • 全局规则/集群特有规则

7.3、统计

  • 各集群重要指标的趋势
  • 重要指标的TOPn
  • 重要指标项按使用部分占比
  • 重要配置项占比

7.4、管理工具

  • 动态配置
  • web端命令行
  • 实时搜索特定指标或配置
  • 实例迁移、故障切换、批量部署
  • 可编排管理脚本(DSL风格)

7.5、自监控

    缓存管理平台中各个组件的运行情况的监控。

猜你喜欢

转载自blog.csdn.net/weixin_42343424/article/details/85682524