DataMesh SLA保障方案

原创孙瑞琪stanley 核心杂货铺

2024年04月11日 10:28

点击上方【蓝字】关注我们

总负责人：孙瑞琪

背景介绍

DataMesh是一款缓存中间件产品，它代理服务对Redis等缓存产品的请求。它可以解决Redis用量一直增多的现状下，客户端不一致运维效率低、PHP短链接性能差等问题，规范使用标准，并为应用服务使用缓存提供坚实的稳定性保障。

从上图可以看到，DataMesh是Sidecar部署的代理组件。应用服务的缓存读写都要经过DataMesh，业务上有强依赖性，这要求DataMesh自身服务等级需要足够高。所以，我们需要在协议、架构和产品功能等多个方面，保证中间件服务的稳定。DataMesh SLA的目标是至少达到99.999%

架构特性

要提升服务等级，就需要根据架构特性分析潜在的稳定性隐患，再根据隐患场景，制定应对预案。

1.DataMesh分层结构

DataMesh逻辑架构上分三层

应用层为服务客户端入口
中间件层包括DataMesh本体和高可用相关组件
数据产品层即底层缓存产品

2.稳定性隐患

这里，我们根据每个模块的特点，思考下可能存在的隐患类型

应用层

应用层作为数据入口，访问异常会直接影响数据流量，而不同的客户端使用方式上会有巨大差异。

多接入语言（PHP，JAVA，GO），多种SDK（Jedis，Lettuce，Redission）

不同SDK访问协议上有差异，例如，默认连接池配置、建立连接后是否默认SELECT DB等等。

流量冲击，qps或大key突增打爆代理

除了客户端差异，还需要关注流量重启，防止redis被打爆，造成缓存雪崩、缓存击穿、缓存穿透等等

中间件层

中间件层的各个组件。datamesh相关的，包含daemonset、守护进程和代理进程三个；另外，还有datamesh依赖的第三方组件，如apoll、prometheus等等。各组件异常，都可能影响代理稳定和性能

1.代理异常，流量失败

例如，配置异常、启动失败、退出或无响应等，导致客户端无法访问

2.依赖的组件异常

这里是指依赖的公司内的其它系统，例如发布系统，配置中心等等。如果没有做好解耦，会极大影响服务等级

3.资源不足，代理性能差

或者影响服务资源

数据产品层

数据产品层作为数据底座，任何集群变更，或节点异常、网络延迟等等，会可能影响流量

1.主动运维（扩缩容、主从切换、slot迁移）

2.网络异常，单点网络延迟高、断开；集群网络不可访问

如何实现高可用

针对上面提到的稳定性隐患，我们设计了一系列架构模型，来解决各种异常。这里简单介绍一下DataMesh的高可用方案，方便理解可能出现的故障和解决措施

1.如何做到秒级恢复

代理的停顿时间是直接影响服务等级的，所以需要有一定的自愈能力。

DaemonSet进程

Daemonset进程会初始化宿主机上的配置、执行文件，保证每个节点上都有datamesh配置
更新Mesh版本，会预更新daemonset，保证节点上版本号统一
新增Node节点，daemonset会预拉取mesh sidecar镜像，避免拉镜像延迟问题

Sidecar控制进程

对Mesh Proxy进程健康检查，进程异常会重启，检查心跳5s，出现异常的时候，可以立即重启恢复
父进程提供管控接口，管理container健康检查，做mesh proxy平滑升级等功能

2.如何实现大规模部署

前面提到，DataMesh是Sidecar结构部署，意味着每个服务节点上都会挂一个DataMesh Container。

但是，节点多带来的问题是，发布升级会相对复杂。

在3.1的部署架构里，我们提到，每个POD中的控制进程，都可以定位灰度配置，启动指定的版本。根据这个功能我们可以设计灵活的版本灰度

把版本灰度能力细化到服务之后，我们就可以圈定升级范围。第一步，灰度非核心服务，这个步骤会做热更新；验证没问题后，灰度部分核心应用；充分验证之后再做全量更新。

3.如何实现故障转移

我们使用DataMesh的初衷，除了统一，还希望提升Redis稳定性。所以，DataMesh需要有应对各种Redis异常的能力。这个功能，不是架构优化能解决的，需要代理本身有恢复能力

DataMesh故障转移

这个能力，DataMesh依赖连接隔离实现。客户端对代理的连接和代理对Redis的连接隔离，当出现后端异常时，DataMesh可以重制命令队列，尝试更新Redis节点、更新拓扑，甚至更新Redis到新集群，当后端连接恢复后，重发命令。这样，就能做到不影响流量的情况下，做故障转移

如何达到5个9 SLA

要达到99.999%的SLA标准，

DataMesh还在持续迭代，所以针对高可用手段，要持续验证是不是能生效。为了保持长久而稳定的服务等级，需要模拟异常场景，并对特殊场景做定期演练验证

4.1

异常场景假设

针对前面分析的隐患点，我们可以对各个模块，提出可能出现的异常假设，然后分析解决方案和验证方式

	异常假设	异常分析	处理方案
应用层	客户端建立的连接异常，导致性能问题	连接数过多可能会导致datamesh内存占用过大，影响代理性能；连接数过少，会代理能力会下降，造成rt上涨	1.通过动态调整端口数控制单链接客户端连接数 2.客户端连接数告警，超过阈值提示重启客户端
客户端未配置超时时间，连接被慢请求阻塞	在pipeline场景下，单条命令执行时间过长会影响队列后续命令RT	1.DataMesh配置后端超时5s，作为超时时间兜底
发送命令时会带有特殊命令（client setname等等）	datamesh有支持的命令集，不会拓传非标命令	特殊的客户端命令，在datamesh测mock返回结果，适配客户端连接
有流量激增，慢请求或者大key请求，导致redis性能变差	异常流量请求可能打爆redis	1.datamesh的流量监控，突发流量尖刺会告警 2.datamesh可配置大key日志，检测并拒绝超大key请求
中间件层	代理进程异常退出、挂起无响应	代理失效的情况下，流量会掉底，需要快速恢复代理进程	datamesh守护进程，每3秒探测一次代理进程，退出或无响应会拉起新进程
datamesh启动异常，无法拉起	进程或配置异常，无法启动datamesh，节点无法接收流量	1.ecs状态下，启动失败会有告警 2.容器状态下datamesh启动失败，会触发poststart检查失败，阻塞服务进程拉起，避免流量进入
配置中心无法访问，无法同步配置	无法获取配置，启动会失败	1.配置中心异常，启动失败符合预期，在此期间不应该有变更。 2.启动失败会告警 3.运行状态下，流量不会受影响
datamesh代理bug，命令大量报错	datamesh bug导致命令异常，流量会受影响，需要紧急回滚	1.datamesh返回报错有监控打点，超过一定数据会告警 2.回滚在lone上一键操作后重启服务
异常流量重启，大量命令报错	错误命令导致报错，datamesh层需要拦截异常命令，避免对redis造成影响	datamesh有支持的命令集，非标的请求可以直接拒绝，避免对redis造成流量冲击
资源占用过多，触发容器资源limit或触发资源限流	资源占用异常可能导致datamesh性能下降	配置了CPU，内存阈值及异常上涨的告警，有异常一剑重启恢复
Redis产品层	主动运维：扩容、缩容、主从切换	datamesh需要适配dba日常运维动作，流量不受影响，且自动恢复	datamesh需要适配redis cluster协议的各种异常，自动恢复
节点断开	某些节点断网，造成某一节点流量中断	datamesh连接是否异常，自动重连，更新拓扑
网络高延迟	单点网络异常，可能会造成流量受损，或者触发集群切换，	datamesh检测命令或者ping是否超时，超时重建连接，更新拓扑
集群宕机无法恢复	redis集群以不可用且无法恢复，导致流量掉底	datamesh需要支持检测并切换到新集群

4.2

异常加固方案

通过异常场景分析，我们将预防异常的加固手段分为三种：

1.回归测试验证场景

回归测试属于版本验证的手段，它针对版本更新时，客户端和datamesh的兼容性问题，包括协议、配置、特殊命令、连接池等等。所以要在每次版本升级前进行

测试功能点	结果预期
Lettuce、Redission、Predis混合客户端，验证不同客户端访问datamesh是否成功	可以正常建立连接，且命令正常
datamesh支持的redis协议全命令测试，验证所有命令是否能正常执行	可以正常发送命令，响应结果符合预期
客户端使用pipeline场景，测试datamesh在不同pipeline长度下，可以正常拆包、分别响应	每条命令都正常返回
测试大key，超大key请求下，datamesh请求延迟不受影响	命令正确返回，rt符合预期
测试流量冲击场景下，datamesh可以正确检测，预警	代理流量、rt正常，触发告警

2.定义运维SOP，以及运维操作演练

对于一些特殊的故障，往往需要运维人员人工干预来恢复。这些手段需要定期演练，这样才能确保出现线上问题的时候，我们的运维手段，能安全有效解决问题。

演练项	验证方式
datamesh灰度上线功能，验证灰度发布只对部分appid生效	新版本发布后，只对灰度的appid生效
验证datamesh更新daemonset能力，做配置发布或回滚	发布后，每个宿主机都更新版本
验证datamesh回滚能力，出现bug是可绕过datamesh访问	服务重启后可以恢复直连redis
验证datamesh资源泄露，或者配置异常场景，可以一键重启恢复的能力	datamesh进程可以一键重启，且不影响流量
验证有异常key攻击，需要降级的场景	异常key降级后，请求会被拒绝
验证热key流量过大，对redis造成压力，需要限流的场景	热key限流后，qps限制在预期以下

3.非预期内的异常场景演练

针对redis异常，或者redis变更的情况，验证datamesh异常恢复能力

演练项	期望结果
redis扩容，缩容操作，演练集群节点变化的场景	自动恢复，触发告警
主动/被动触发主从切换	自动恢复，触发告警
Lone配置外的主从切换，验证不在配置中心的节点，是否能智能识别	自动恢复，触发告警
Master节点迁移，验证master所在节点异常的场景下，迁移后能识别新节点，流量不中断的能力	自动恢复，触发告警
拉起新集群，并切换到新集群，验证集群异常的场景下，不中断切换到新集群的能力	切换完成后，流量自动恢复，触发告警
部分节点网络异常的场景下，流量下降但是不掉底，验证master之间不会互相影响	自动恢复，触发告警
单点网络延迟过高，触发集群主从切换，验证datamesh超时断连自愈能力	自动恢复，触发告警
杀死datamesh进程，验证进程异常退出场景下，datamesh自愈能力	守护进程拉起新的进程，自动恢复，触发告警
外部流量攻击，产生大量异常请求，验证datamesh异常隔离能力	自动隔离异常命令，触发告警
datamesh启动失败，阻塞服务pod启动，验证非正常POD不会承接流量的能力	POD启动会被阻塞，流量不会进入，触发告警

写在最后

服务稳定性建设，可以根据架构特性，提出极端异常场景的假设，这需要对整个链路足够熟悉；再根据这些假设提供解决思路和方案。

本篇文章基于DataMesh的部署特性，介绍了redis代理稳定性建设历程。实际落地过程中，经历了多次架构改进、问题修复，组件部署模式做了很多的选择与取舍。

Redis的稳定对服务非常重要，而DataMesh在保护redis访问链路的同时，维护自身稳定也相当关键，相对服务稳定性带来的收益，我们的投入绝对是值得的。随着业务规模不断增长，我们可能会遇到新的问题，稳定性也会有新的挑战需要我们攻克。

点个在看你最好看

继续滑动看下一个