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

汽车之家IDC多活实践 之缓存同步方案 李建彪 汽车之家服务端基础架构组系统架构师 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 李建彪 汽车之家服务端基础架构组系统架构师 拥有多年传统行业、互联网行业系统架构经验。擅长微服务架构、传统应用迁移上云、云原生架构、异地多活架构。现负责汽车之家服务网格落地以及云原生服务治理、云原生可观测架构的相关工作。 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 汽车之家容灾/双活建设介绍 之家缓存同步平台建设 目录之家缓存同步工具核心技术解析 后续工作 01汽车之家双活建设背景 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 之家双活建设背景 双活建设的大背景是因为2023年7月份出现的机房级故障，当时资讯的文章、产品库车系页等打开存在问题，公司大部分业务都部署在亦庄，恰好亦庄机房发生故障。为了能够规避之家单侧机房的故障影响业务，基于业务特点实施双活建设。 之家双活建设的目标 容灾架构思考 容灾架构的演进，涉及机房资源、研发投⼊的成本，并非⼀蹴⽽就 以合适的成本满⾜项目的建设目标，同时兼顾未来的扩展性 之家路线：同城双中⼼（同城双活）->两地三中⼼（兼顾异地灾备） RTO（RecoveryTimeObjective）即恢复时间目标，主要指所能容忍的服务恢复时间RPO（RecoveryPointObjective）即数据恢复点目标，主要指所能容忍的数据丢失量 项目目标 定性：防⽌因单机房故障，看选核⼼读业务不受影响，保障业务的连续性。 定量：RTO小于3分钟，RPO小于1分钟。 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 8 之家双活建设 双活范围 PC&M 小程序 用车 买车 选车 看车 App 双活实施 总结23年的经验，从机器梳理、场景梳理开始，推进架构改造 落地，最终完成有效性验证： 机器 梳理 场景 梳理 架构 改造 效果 验证 机器梳理 场景梳理 应用部署 缓存中间件 消息中间件 存储中间件 页面效果 依赖解耦 架构改造 效果验证 Redis治理 数据库双活 缓存双活 依赖检查 故障注入 效果保鲜 故障演练 流量改造 功能降级 业务熔断 C端双活范围：围绕看、选、买、用梳理场景落地双活 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 同城双活架构 internet CDN 之家IDC（廊坊） 四层LVS 之家IDC（亦庄） 七层LVS 专线时延 七层Nginx 2+ms 七层Nginx 存储服 务 负载均衡 在线服务 在线服务 应用双发 服务⽹格 K8S 服务⽹格 K8S 存储服 务 中间件 数据同步 中间件 RabbitMQ Kafka ES RabbitMQ Kafka ES 缓存 数据同步 Redis/Cluster Codis ⼴告业 务 数据库数据库 数据同步 MySQL SqlServer TiDB MySQL SqlServer TiDB 缓存 Redis/Cluster 离线服务 采用双活架构，同城机房一侧故障，保障核心业务读不间断，写20分钟内恢复 架构说明 双机房同时接收流量，⽆状态节点对等部署，有状态节 点主从双边部署，或独立双边部署+⼯具数据同步。 数据同步 应用、中间件配置+数据结构实时同步，消息、缓存数 据按需同步。双边应用连接同⼀主库，负载均衡读库。 容灾切换 流量负载均衡、自动故障发现及转移，业务使用域名访 问中间件，中间件故障转移时切换DNS解析，自动故障恢复。 编排动作 主从模式集群⼈⼯决策切换，分布式集群自动切换。 缓存同步工具适用场景-1 容忍短暂(20~100ms)缓存不一致的双活业务场景 业务闭环改造 适用适用 业务闭环改造 廊坊亦庄 应用应用 廊坊亦庄 应用应用 廊坊亦庄 应用应用 廊坊亦庄 读读读读同步 读/写写读 应用 读/写 Redis 应用 读/写 Redis 同步 Redi 写s Redis 写 Redis 写 Redis RedisRedis 缓存生成Job 写两侧,读两侧流量两侧 缓存生成Job 写一侧，读两侧流量两侧 业务双活 写一侧，读两侧 读流量两侧（写单侧） 写两侧，读两侧流量两侧 10 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 缓存同步工具适用场景-2 廊坊 应用 亦庄 应用 读/写 写 读 Redis 同步 Redis 廊坊 应用 亦庄 应用 读/写 读/写 同步 RedisRedis 最终一致性的多机房热备业务场景 廊坊 应用 亦庄 应用 读 读 写 Redis Redis 写 缓存生成Job 廊坊 应用 亦庄 应用 读 读 同步 Redis Redis 写 缓存生成 Job 业务改造 适用适用适用 写两侧,读一侧 写一侧，读一侧 写一侧，读一侧 读、写都一侧 业务热备-切换需要人工干预（RTO较高） 11 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 02之家缓存同步工具核心技术解析 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 之家缓存同步方案-三方服务 三方云平台 之家IDC双活、灾备背景下，现有缓存同步工具存在“代码不可控、侵占专线、能力局限”等问题，迫切需要对Redis缓存同步方案进行升级改造（自研-自主可控） 三方云平台 问题描述： 1、工具部署在三方云平台上，无法进行私有化部署，稳定性不可控、网络拓扑不合理（临时方案） 2、代码不可见，不可为特殊场景进行定制化开发 3、专线出现网络抖动，会触发大量全量同步，引起复制风暴影响专线带宽，从而影响线上业务 自研方案-工具侧 同步工具概念架构图、概念定义、关键技术 关键技术： 协议分析、模拟 全量同步 增量同步 避免全量同步 大Key处理 Kafka中转站 限流机制 AutoSync-Redis 概念定义： •自研同步工具名称：AutoSync-Redis(简称ASR) •模拟Slave端的Producer：ASR-Producer •消费Kafka中Redis指令的Consumer：ASR-Consumer GOPS全球运维大会暨XOps技术创新峰会2024·北京站 自研方案-工具侧[协议分析] 协议模拟示例： Master Slave +OK\r\n auth123456\r\n replconflistening-port0\r\n +OK\r\n psync?-1\r\n +FULLRESYNC90278fcd5ee74718f3ec7822d031187 33ff812f354257856\r\n $178\r\n b'REDIS0009\xfa\tredisver\x056.0.5\xfa\nredisbits\xc0@\xfa\x05cti... replconfack54257576\r\n *2\r\n$3\r\nDEL\r\n$16\r\ntytGsLZrKfrFKt7s\r\n *4\r\n$4\r\nZADD\r\n$12\r\nSgvyWALJFJve\r\n$2\r\n58\r\n$5\r\n4E1dI\r\n\n GOPS全球运维大会暨XOps技术创新峰会2024·北京站 自研方案-工具侧[全量同步、增量同步] 全量同步关键步骤： 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]中获取同步偏移量并进行断点续传的流程； 注：此同步模型，参考RedisShake项目 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 自研方案-工具侧[避免全量同步] 一组参考配置： GOPS全球运维大会暨XOps技术创新峰会2024·北京站 •repl-backlog-size600mb#假设网格恢复为60秒，每秒的写入为10M •repl-backlog-ttl0#不主动释放缓存 •client-output-buffer-limitnormal000#对客户端的缓存不做限制 •repl-timeout120#延长复制超时时间到120秒 •repl-ping-replica-period10#10秒一次心跳 18 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 自研方案-工具侧[消息顺序、大key处理、限流] 使用Redis计算key的算法，保证相同key的执行顺序一致。 Redisslot消息保证 命令会被切分成多个，按顺序放入同一个partition内，Consumer通过匹配分片数量同步。 分片设计 get[key]mset[key]zadd[key]…[key] Partition1 AOF/ RDB channel 生产者 key分区 Partition2 PartitionN 0-5000 5001-11000 11001-16383 CRC16([key])mod16384 限流机制 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 Scan Existskeys 自研方案-工具侧[消息数量check] 数据“丢失”： 迁移场景：RDB恢复后有大量KEY“丢失” 在源端一些已经过期的或快要过期的key，不会在目标端进行被正确写入，所以会有“丢失”的现象。 同步场景：key数量总有明显差异 同步场景中，key的数量不可能100%一致（因为有过期时间等因素），除非可以暂停写入进行全量比较。 方案： 巡检程序 除了同步工具的监控指标上报，定时进行Scan命令进行实时对比，对重要业务数据进行监控。 源Redis RDB/AOF 目标 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 自研方案-工具侧[延迟优化] 背景【同步写入延迟】： ConsumerN consumer kafka consumer 最初AOF/RDB使用的策略是，未达到“大key”定义的情况下，直接发送到kafka。这样的策略会导致高频、小包写入的时候，cpu、网络io消耗巨大但实际吞吐量很低，导致网络延迟。 消息10字节 消息5字节 消息N8字节 Producer … KafkaMsg KafkaMsg 高消耗低聚合 方案： Parition计算前置，根据时间/数量两个维度来聚合相同Partiion消息，使时间/数量维度内的key，打包为一个kafka消息，减少不必要的消耗。 消息10字节 消息5字节 消息8字节 消息N2字节 Producer kafka KafkaMsg 消息1 …消息n •例子：120GRDB同步时间高达1.5小时，aof在高频写入时期，延迟高达30s，更改后RDB时间节省55%左右，aof延迟保持在100ms以内。 20 02之家缓存同步平台建设 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 之家缓存同步平台