李建彪-汽车之家 IDC 多活实践之缓存同步实战指南

汽车之家服务端基础架构组系统架构师 李建彪 公司职位汽车之家服务端基础架构组系统架构师 拥有多年传统行业、互联网行业系统架构经验。擅长微服务架构、传统应用迁移上云、云原生架构、异地多活架构。现负责汽车之家服务网格落地以及云原生服务治理、云原生可观测架构的相关工作。 汽 车 之 家容 灾/双 活 建 设介 绍 目录 之 家缓 存 同 步 工 具 核 心 技 术 解 析 之 家 缓 存 同 步平 台建 设 后 续 工 作 汽车之家双活建设背景 之家双活建设背景 双活建设的大背景是因为2023年7月份出现的机房级故障，当时资讯的文章、产品库车系页等打开存在问题，公司大部分业务都部署在亦庄，恰好亦庄机房发生故障。为了能够规避之家单侧机房的故障影响业务，基于业务特点实施双活建设。 之家双活建设的目标 RTO（Recovery Time Objective）即恢复时间目标，主要指所能容忍的服务恢复时间 RPO（Recovery Point Objective）即数据恢复点目标，主要指所能容忍的数据丢失量 容灾架构思考 项目目标 Ø容灾架构的演进，涉及机房资源、研发投⼊的成本，并非⼀蹴⽽就Ø以合适的成本满⾜项目的建设目标，同时兼顾未来的扩展性Ø之家路线：同城双中⼼（同城双活）->两地三中⼼（兼顾异地灾备） Ø定性：防⽌因单机房故障，看选核⼼读业务不受影响，保障业务的连续性。 Ø定量：RTO小于3分钟，RPO小于1分钟。 之家双活建设 C端双活范围：围绕看、选、买、用梳理场景落地双活 双活实施 双活范围 总结23年的经验，从机器梳理、场景梳理开始，推进架构改造落地，最终完成有效性验证： 依赖检查 缓存双活 故障演练 效果保鲜 流量改造 同城双活架构 采用双活架构，同城机房一侧故障，保障核心业务读不间断，写20分钟内恢复 架构说明 双机房同时接收流量，⽆状态节点对等部署，有状态节点主从双边部署，或独立双边部署+⼯具数据同步。 数据同步 应用、中间件配置+数据结构实时同步，消息、缓存数据按需同步。双边应用连接同⼀主库，负载均衡读库。 容灾切换 流量负载均衡、自动故障发现及转移，业务使用域名访问中间件，中间件故障转移时切换DNS解析，自动故障恢复。 编排动作 主从模式集群⼈⼯决策切换，分布式集群自动切换。 缓存同步工具适用场景-1 容忍短暂(20~100ms)缓存不一致的双活业务场景 缓存同步工具适用场景-2 之家缓存同步工具核心技术解析 之家缓存同步方案-三方服务 之家IDC双活、灾备背景下，现有缓存同步工具存在“代码不可控、侵占专线、能力局限”等问题，迫切需要对Redis缓存同步方案进行升级改造（自研-自主可控） 问题描述： 1、工具部署在三方云平台上，无法进行私有化部署，稳定性不可控、网络拓扑不合理（临时方案） 2、代码不可见，不可为特殊场景进行定制化开发3、专线出现网络抖动，会触发大量全量同步，引起复制风暴影响专线带宽，从而影响线上业务 自研方案-工具侧 同步工具概念架构图、概念定义、关键技术 关键技术： Ø协议分析、模拟Ø全量同步Ø增量同步Ø避免全量同步Ø大Key处理ØKafka中转站Ø限流机制 概念定义： •自研同步工具名称：AutoSync-Redis (简称ASR)•模拟Slave端的Producer：ASR-Producer•消费Kafka中Redis指令的Consumer：ASR-Consumer 自研方案-工具侧[协议分析] 协议模拟示例： 自研方案-工具侧[全量同步、增量同步] 全量同步关键步骤： 全量同步关键步骤： 1、ASR-Producer模拟从节点从“源redis”拉取全量数据RDB到本地存储； 2、Loader组件会解析出一些信息，包括DB、Key、Type等，然后放到Pipe中。3、从Pipe出来后先进行过滤，DB、Key、Slot这些级别的过滤，用户可以设置黑白名单。4、将过滤后的同步指令发送到kafka，ASR-Consumer消费同步指令到目标redis。 1、如果网络没有问题，全量同步后直接进入增量同步阶段； 2、如果中间出现网络情况出现断网或者任务中断重启后，会从独立redis[同步工具单独部署的redis]中获取同步偏移量并进行断点续传的流程； 自研方案-工具侧[避免全量同步] 一组参考配置： •repl-backlog-size 600mb #假设网格恢复为60秒，每秒的写入为10M•repl-backlog-ttl 0 #不主动释放缓存•client-output-buffer-limit normal 0 0 0 #对客户端的缓存不做限制•repl-timeout 120 #延长复制超时时间到120秒•repl-ping-replica-period 10 #10秒一次心跳 自研方案-工具侧[消息顺序、大key处理、限流] 分片设计 Redisslot消息保证 命令会被切分成多个，按顺序放入同一个partition内，Consumer通过匹配分片数量同步。 使用Redis计算key的算法，保证相同key的执行顺序一致。 自研方案-工具侧[消息数量check] 数据“丢失”： 迁移场景：RDB恢复后有大量KEY“丢失” 在源端一些已经过期的或快要过期的key，不会在目标端进行被正确写入，所以会有“丢失”的现象。 同步场景：key数量总有明显差异 同步场景中，key的数量不可能100%一致（因为有过期时间等因素），除非可以暂停写入进行全量比较。 方案： 除了同步工具的监控指标上报，定时进行Scan命令进行实时对比，对重要业务数据进行监控。 自研方案-工具侧[延迟优化] 背景【同步写入延迟】： 最初AOF/RDB使用的策略是，未达到“大key”定义的情况下，直接发送到kafka。这样的策略会导致高频、小包写入的时候，cpu、网络io消耗巨大但实际吞吐量很低，导致网络延迟。 方案： Parition计算前置，根据时间/数量两个维度来聚合相同Partiion消息，使时间/数量维度内的key，打包为一个kafka消息，减少不必要的消耗。 •例子：120GRDB同步时间高达1.5小时，aof在高频写入时期，延迟高达30s，更改后RDB时间节省55%左右，aof延迟保持在100ms以内。 之家缓存同步平台建设 之家缓存同步平台-任务调度平台 建设“统一任务调度平台”来保证多同步任务的管理、配置、调度、监控等。 前面的介绍了“自研Redis同步工具(AutoSync-Redis)”的设计，如果要实现成平台层的产品还需要考虑规模化落地的场景。单独开发一个同步工具是远远不够的，需要建设一个“统一任务调度平台”来保证多同步任务的管理、配置、调度、监控等。 之家缓存同步平台-可观测架构 基于之家云原生可观测云平台能力，搭建缓存同步工具可观测体系。 之家缓存同步平台-故障恢复 之家缓存同步平台-故障恢复 之家缓存同步平台-整体架构 缓存同步工具性能测试 全量 廊坊→亦庄 ü2分区，8g数据->6分钟ü2分区，20g数据->7分钟ü2分区，108g数据->27分钟 亦庄→廊坊 ü2分区，8g数据->8分钟ü2分区，20g数据->10分钟ü2分区，108g数据->30分钟 增量 廊坊→亦庄 ü2分区，每秒写入<500key->TP95：8.9msü2分区，每秒写入<1000key->TP95：12.08msü2分区，每秒写入<2000key->TP95：46.4msü2分区，每秒写入<5000key->TP95：67.3msü2分区，每秒写入<10000key->TP95：103.0ms 亦庄→廊坊 测试结果 ü2分区，每秒写入<500key->TP95：10.7msü2分区，每秒写入<1000key->TP95：15.49msü2分区，每秒写入<2000key->TP95：33.5msü2分区，每秒写入<5000key->TP95：42.8msü2分区，每秒写入<10000key->TP95：97.4ms 对标“三方服务”10G同步耗时3-8分钟，120G同步耗时20-30分钟(其中分区数=4，耗时20分钟,分区数=2,耗时30分钟) 之家缓存同步平台-产品展示 之家缓存同步平台-产品展示 消费者节点详情 之家缓存同步平台-产品展示[可观测] 后续 探索双向同步方案 技术难点： 回环问题：添加集群标识、同步消息元数据扩展 感谢大家观看