作者: andylin02学习章节第24章 分布式周期性任务系统Distributed Periodic Scheduling基于论文《Reliable Cron across the Planet》Google 2015ACM Queue关键词分布式Cron、Paxos协议、惊群效应、领头人选举、幂等性、状态同步一、引言当“定时任务”遇上“行星级规模”在之前的章节中我们系统学习了Google如何通过GSLB实现全球流量调度第19章、如何通过Maglev实现数据中心内部负载均衡第20章、如何通过过载保护第21章和连锁故障防御第22章确保系统韧性。然而在SRE的日常运维中还有一个看似简单却极其关键的组件被严重低估——定时任务系统Cron。从大数据平台每小时将日志导入Hive到电商平台双11零点准时切换活动页面到游戏平台定期清理挂机用户——定时任务是分布式系统的“隐性骨架”。当一个组织的定时任务需求从几十个增长到几万个时传统的Linux Cron将彻底失效。本章回答了Google如何设计一个行星级的分布式Cron系统使其在单机故障时依然可靠在整点负载尖峰时依然稳定在数千个Cron任务并发执行时依然有序。核心观点单机的cron在“行星级”规模面前彻底失效。Google通过Paxos共识协议构建高可用的领头人-追随者架构用幂等性设计应对部分失败用任务延展机制打散惊群效应实现了一个可以跨越整个地球运行的、可靠的分布式周期调度系统。补充说明本章基于Google 2015年在ACM Queue上发表的《Reliable Cron across the Planet》论文该文后被收录于《SREGoogle运维解密》作为第24章章节名由原文的“Reliable Cron across the Planet”改为“Distributed Periodic Scheduling”分布式周期性任务系统。二、核心观点速览维度核心要点为什么需要分布式Cron单机cron存在单点故障业务规模扩大后需求无法满足核心设计选择任务存储于外部高可用存储 Paxos集群管理关键状态架构模式领头人-追随者Leader-Follower架构仅Leader可执行/修改任务状态同步基于Paxos的只增日志append-only log每条任务状态变更追加一条记录两大存储方案外部存储Spanner 本地快照与日志压缩惊群效应整点大量任务同时触发Google通过任务延展机制打散负载领头人切换新Leader需判断前Leader是否已执行操作——幂等性设计 状态查询运维启示分布式系统设计的核心权衡可用性 vs 一致性 vs 性能三、详细内容拆解3.1 为什么单机的Cron不行——一个看似简单的问题可能很多同学不太理解既然linux的cron这么好用为什么还要兴师动众地做一套分布式的cron系统业务场景的现实需求场景典型任务如果cron宕机大数据平台每小时将在线系统日志导入Hive数据延迟 → 下游分析全错电商运营618、双11零点切换活动页面无法零点生效 → 运营事故用户服务每5分钟扫描投诉表执行补偿逻辑用户体验下降游戏平台每15分钟扫描在线用户踢掉挂机者资源被无效占用当这些任务集中在一台crontab机器上时单点故障是最大的风险——如果这台机器挂掉所有定时任务全部失效。如果恰巧这些cron任务没有备份就又会开始经典的会上甩锅环节了。3.2 分布式Cron的核心架构Paxos Leader-FollowerGoogle的分布式Cron系统采用了一个经典的模式使用Paxos协议组成一个Paxos集群由Leader来进行cron任务的状态更新与执行操作。架构的两个核心组件任务存储层存储Cron任务本身的定义通常几千到上万个变更不频繁。Google推测使用Spanner或配置文件/配置系统。状态管理层使用Paxos集群管理任务的关键状态。每一个任务需要记录两条关键数据——一条是begin一条是end。这两条数据必须在Paxos集群中同步因为它们代表了cron任务的关键执行状态。3.3 状态同步Paxos的“只增日志”特性Paxos协议本质上是一个只能新增的日志append-only log——在每次状态变化后同步地新增一条记录。这个特性带来了两个必须解决的问题问题解决方案日志无限增长定期压缩日志将快照保存在本地存储中同时备份到远端分布式存储日志需要可靠存储在系统内部存储少量数据或使用外部高可用存储Google的选择是日志和快照在本地存储中都会有一份同时快照会被备份在远端的分布式存储中。如果系统整体崩溃还可以用快照将服务恢复出来。3.4 领头人选举与状态分离在分布式Cron系统中只有一个副本——领头人Leader——是唯一可以修改共享状态的副本也是唯一可以启动Cron任务的副本。一旦Paxos集群中的Leader失去了Leader身份它就不应该再与datacenter scheduler进行任何交互了。这种严格的状态分离确保了系统的正确性不会有多个节点同时执行同一个Cron任务。3.5 部分失败分布式系统中最棘手的挑战这是本章最具技术深度的部分。由于一次Cron任务的执行过程会多次与scheduler通信部分失败几乎必然会发生。场景描述RPC #1和RPC #2都完成了但在RPC #3开始前Paxos发生了Leader切换。新Leader面临的关键问题前Leader已经执行到哪一步了RPC #1和#2是否已经完成Google的两种解决方案方案核心逻辑适用场景状态查询新选出的Leader需要知道之前的RPC是否都完成了需要从外部查询这些任务的状态需要依赖公司内的具体基础设施幂等性设计将外部RPC都实现成幂等请求idempotent这样新的Leader可以安全地重试更通用、更推荐幂等性设计的本质是让同一个请求被多次执行也不会产生额外的副作用。如果RPC #1被执行了两次结果与执行一次完全相同。这是分布式系统中最常见也最强大的容错手段。3.6 惊群效应Thundering Herd整点时刻的系统崩溃运维大型Cron系统面临的核心挑战之一惊群效应当大量Cron任务都配置在整点00:00执行时会在同一瞬间产生海量请求可能导致Scheduler瞬间过载大量任务超时或失败系统进入连锁故障Google的解决方案任务延展机制Google在设计过程中给cron做了个简单扩展具体的时间配置位置可以直接写一个问号?表示任意时间都可以这样cron系统就可以根据负载来动态地选择任务的具体执行时间将高峰负载打散。尽管做了这些之后理论上cron的执行在整点还是会有尖峰——这也是由定时任务的性质决定的。Google的cron系统执行次数统计显示整点仍然有明显尖刺。3.7 本章的核心启示启示一分布式系统的“边界权衡”无处不在本章通过Cron系统的设计展示了一个分布式系统设计者必须面对的经典权衡三角维度Cron中的体现可用性Paxos集群容忍节点故障任务继续执行一致性Leader唯一性保证同一任务不被重复执行性能任务延展机制打散负载牺牲“精确时间”换取系统稳定性启示二简单设计 vs 复杂系统如果我们稍微牺牲一些依赖上的要求可以做出相对简单的系统来Google的经验表明并非每个组织都需要如此复杂的分布式Cron系统。对于大多数公司来说Kubernetes的CronJob可能就足够了。启示三监控系统与Cron的关系时序监控系统如第6章讨论的四个黄金指标和周期性任务系统共享相同的基础设施需求海量时序数据的存储与查询。本章的Cron系统为SRE提供了执行周期性监控检查的基础设施而Monarch则为Cron系统的执行提供了监控能力——两者是相互依赖的。四、第24章知识点脑图总结五、总结一句话记住本章分布式Cron Paxos集群保证高可用 Leader唯一性保证正确性 幂等设计应对部分失败 任务延展打散惊群效应让定时任务在行星级规模下可靠运行。关键点一句话概括单机Cron的问题单点故障导致所有定时任务失效无法满足大规模业务需求Paxos的角色提供分布式一致性确保集群中只有一个LeaderLeader的职责唯一可以修改状态和启动Cron任务的节点状态日志Paxos的只增日志需定期压缩以防无限增长部分失败Leader切换时通过幂等性设计或状态查询保证任务不被重复/遗漏惊群效应整点大量任务同时触发导致系统过载任务延展机制使用?占位符让Cron根据负载动态选择执行时间部署建议大多数公司可用K8s CronJob替代复杂的分布式Cron行动建议本周内完成盘点当前系统中所有依赖单机Cron的定时任务识别哪些任务如果失效会产生业务影响一个月内完成对关键定时任务建立备份机制如双机互备或迁移到K8s CronJob评估Cron任务的整点负载分布识别是否存在惊群效应风险一个季度内完成如已使用K8s评估将核心Cron任务迁移到CronJob的可行性对关键Cron任务建立监控和告警确保任务执行失败时能够及时发现长期坚持为Cron任务建立幂等性设计规范确保失败重试不会产生副作用定期审查Cron任务的执行结果识别并优化不合理的调度模式六、高频考点自测问题1为什么单机的cron不能满足大规模分布式系统的需求参考答案当业务规模扩大后定时任务的需求会从几十个增长到几千甚至上万个。单机cron存在单点故障问题——如果这台机器宕机所有定时任务全部失效。在大数据平台每小时日志导入、电商运营零点活动切换、游戏平台定期清理挂机用户等场景中这种单点故障会导致严重的业务影响。问题2Google分布式Cron系统的核心架构是怎样的参考答案Google采用Paxos协议组成一个Paxos集群由Leader来进行cron任务的状态更新与执行操作。任务定义存储在外部高可用存储中而任务的关键状态每条任务的begin和end在Paxos集群中同步。Paxos本质上是一个只能新增的日志每次状态变化后同步新增一条记录需要定期压缩以防止日志无限增长。问题3什么是“部分失败”Google如何应对参考答案在分布式Cron系统中一次任务执行过程会多次与scheduler通信。部分失败指的是在通信过程中部分RPC已完成、但部分未完成时发生了Leader切换。新Leader不知道前Leader执行到了哪一步。Google采用两种应对方案①通过外部系统查询任务状态确定前Leader的执行进度②将外部RPC实现成幂等请求让新Leader可以安全地重试不会产生副作用。问题4什么是惊群效应Google如何解决参考答案当大量Cron任务都配置在整点如00:00执行时会在同一瞬间产生海量请求导致scheduler瞬间过载、大量任务超时或失败。这就是惊群效应。Google的解决方案是任务延展机制在时间配置中使用?占位符表示“任意时间都可以”让cron系统根据负载动态选择任务的具体执行时间将高峰负载打散。问题5分布式Cron系统的设计体现了哪些分布式系统的经典权衡参考答案本章体现了分布式系统设计中三个核心维度的权衡①可用性Paxos集群容忍节点故障保证任务继续执行②一致性Leader唯一性保证同一任务不会被重复执行③性能任务延展机制打散整点负载牺牲“精确时间”换取系统稳定性。这个“可用性-一致性-性能”的三角权衡是分布式系统设计的永恒主题。七、延伸阅读推荐《Reliable Cron across the Planet》GoogleACM Queue 2015本章的原始论文《Google SRE工作手册》第23章“Managing Critical State”Paxos协议在关键状态管理中的应用《The Chubby Lock Service for Loosely-Coupled Distributed Systems》Mike Burrows2006Google分布式锁服务本章Cron系统依赖的底层基础设施《Designing Data-Intensive Applications》Martin Kleppmann分布式系统中共识算法Paxos/Raft的深入讲解Kubernetes CronJob官方文档https//kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/学习下一章预告第25章“数据处理管道”——Google如何构建和处理大规模数据处理管道涉及批处理、流处理和数据管道的可靠性设计。本文为个人学习笔记仅用于知识分享。如有错误欢迎指正。 点赞 收藏 分享让更多开发者看到这篇深度解析❤️ 如果觉得有用请给个赞支持一下作者 《SRE：Google 运维解密》读书笔记25: 分布式周期性任务系统 - 当“定时任务”遇上“行星级规模”
作者: andylin02学习章节第24章 分布式周期性任务系统Distributed Periodic Scheduling基于论文《Reliable Cron across the Planet》Google 2015ACM Queue关键词分布式Cron、Paxos协议、惊群效应、领头人选举、幂等性、状态同步一、引言当“定时任务”遇上“行星级规模”在之前的章节中我们系统学习了Google如何通过GSLB实现全球流量调度第19章、如何通过Maglev实现数据中心内部负载均衡第20章、如何通过过载保护第21章和连锁故障防御第22章确保系统韧性。然而在SRE的日常运维中还有一个看似简单却极其关键的组件被严重低估——定时任务系统Cron。从大数据平台每小时将日志导入Hive到电商平台双11零点准时切换活动页面到游戏平台定期清理挂机用户——定时任务是分布式系统的“隐性骨架”。当一个组织的定时任务需求从几十个增长到几万个时传统的Linux Cron将彻底失效。本章回答了Google如何设计一个行星级的分布式Cron系统使其在单机故障时依然可靠在整点负载尖峰时依然稳定在数千个Cron任务并发执行时依然有序。核心观点单机的cron在“行星级”规模面前彻底失效。Google通过Paxos共识协议构建高可用的领头人-追随者架构用幂等性设计应对部分失败用任务延展机制打散惊群效应实现了一个可以跨越整个地球运行的、可靠的分布式周期调度系统。补充说明本章基于Google 2015年在ACM Queue上发表的《Reliable Cron across the Planet》论文该文后被收录于《SREGoogle运维解密》作为第24章章节名由原文的“Reliable Cron across the Planet”改为“Distributed Periodic Scheduling”分布式周期性任务系统。二、核心观点速览维度核心要点为什么需要分布式Cron单机cron存在单点故障业务规模扩大后需求无法满足核心设计选择任务存储于外部高可用存储 Paxos集群管理关键状态架构模式领头人-追随者Leader-Follower架构仅Leader可执行/修改任务状态同步基于Paxos的只增日志append-only log每条任务状态变更追加一条记录两大存储方案外部存储Spanner 本地快照与日志压缩惊群效应整点大量任务同时触发Google通过任务延展机制打散负载领头人切换新Leader需判断前Leader是否已执行操作——幂等性设计 状态查询运维启示分布式系统设计的核心权衡可用性 vs 一致性 vs 性能三、详细内容拆解3.1 为什么单机的Cron不行——一个看似简单的问题可能很多同学不太理解既然linux的cron这么好用为什么还要兴师动众地做一套分布式的cron系统业务场景的现实需求场景典型任务如果cron宕机大数据平台每小时将在线系统日志导入Hive数据延迟 → 下游分析全错电商运营618、双11零点切换活动页面无法零点生效 → 运营事故用户服务每5分钟扫描投诉表执行补偿逻辑用户体验下降游戏平台每15分钟扫描在线用户踢掉挂机者资源被无效占用当这些任务集中在一台crontab机器上时单点故障是最大的风险——如果这台机器挂掉所有定时任务全部失效。如果恰巧这些cron任务没有备份就又会开始经典的会上甩锅环节了。3.2 分布式Cron的核心架构Paxos Leader-FollowerGoogle的分布式Cron系统采用了一个经典的模式使用Paxos协议组成一个Paxos集群由Leader来进行cron任务的状态更新与执行操作。架构的两个核心组件任务存储层存储Cron任务本身的定义通常几千到上万个变更不频繁。Google推测使用Spanner或配置文件/配置系统。状态管理层使用Paxos集群管理任务的关键状态。每一个任务需要记录两条关键数据——一条是begin一条是end。这两条数据必须在Paxos集群中同步因为它们代表了cron任务的关键执行状态。3.3 状态同步Paxos的“只增日志”特性Paxos协议本质上是一个只能新增的日志append-only log——在每次状态变化后同步地新增一条记录。这个特性带来了两个必须解决的问题问题解决方案日志无限增长定期压缩日志将快照保存在本地存储中同时备份到远端分布式存储日志需要可靠存储在系统内部存储少量数据或使用外部高可用存储Google的选择是日志和快照在本地存储中都会有一份同时快照会被备份在远端的分布式存储中。如果系统整体崩溃还可以用快照将服务恢复出来。3.4 领头人选举与状态分离在分布式Cron系统中只有一个副本——领头人Leader——是唯一可以修改共享状态的副本也是唯一可以启动Cron任务的副本。一旦Paxos集群中的Leader失去了Leader身份它就不应该再与datacenter scheduler进行任何交互了。这种严格的状态分离确保了系统的正确性不会有多个节点同时执行同一个Cron任务。3.5 部分失败分布式系统中最棘手的挑战这是本章最具技术深度的部分。由于一次Cron任务的执行过程会多次与scheduler通信部分失败几乎必然会发生。场景描述RPC #1和RPC #2都完成了但在RPC #3开始前Paxos发生了Leader切换。新Leader面临的关键问题前Leader已经执行到哪一步了RPC #1和#2是否已经完成Google的两种解决方案方案核心逻辑适用场景状态查询新选出的Leader需要知道之前的RPC是否都完成了需要从外部查询这些任务的状态需要依赖公司内的具体基础设施幂等性设计将外部RPC都实现成幂等请求idempotent这样新的Leader可以安全地重试更通用、更推荐幂等性设计的本质是让同一个请求被多次执行也不会产生额外的副作用。如果RPC #1被执行了两次结果与执行一次完全相同。这是分布式系统中最常见也最强大的容错手段。3.6 惊群效应Thundering Herd整点时刻的系统崩溃运维大型Cron系统面临的核心挑战之一惊群效应当大量Cron任务都配置在整点00:00执行时会在同一瞬间产生海量请求可能导致Scheduler瞬间过载大量任务超时或失败系统进入连锁故障Google的解决方案任务延展机制Google在设计过程中给cron做了个简单扩展具体的时间配置位置可以直接写一个问号?表示任意时间都可以这样cron系统就可以根据负载来动态地选择任务的具体执行时间将高峰负载打散。尽管做了这些之后理论上cron的执行在整点还是会有尖峰——这也是由定时任务的性质决定的。Google的cron系统执行次数统计显示整点仍然有明显尖刺。3.7 本章的核心启示启示一分布式系统的“边界权衡”无处不在本章通过Cron系统的设计展示了一个分布式系统设计者必须面对的经典权衡三角维度Cron中的体现可用性Paxos集群容忍节点故障任务继续执行一致性Leader唯一性保证同一任务不被重复执行性能任务延展机制打散负载牺牲“精确时间”换取系统稳定性启示二简单设计 vs 复杂系统如果我们稍微牺牲一些依赖上的要求可以做出相对简单的系统来Google的经验表明并非每个组织都需要如此复杂的分布式Cron系统。对于大多数公司来说Kubernetes的CronJob可能就足够了。启示三监控系统与Cron的关系时序监控系统如第6章讨论的四个黄金指标和周期性任务系统共享相同的基础设施需求海量时序数据的存储与查询。本章的Cron系统为SRE提供了执行周期性监控检查的基础设施而Monarch则为Cron系统的执行提供了监控能力——两者是相互依赖的。四、第24章知识点脑图总结五、总结一句话记住本章分布式Cron Paxos集群保证高可用 Leader唯一性保证正确性 幂等设计应对部分失败 任务延展打散惊群效应让定时任务在行星级规模下可靠运行。关键点一句话概括单机Cron的问题单点故障导致所有定时任务失效无法满足大规模业务需求Paxos的角色提供分布式一致性确保集群中只有一个LeaderLeader的职责唯一可以修改状态和启动Cron任务的节点状态日志Paxos的只增日志需定期压缩以防无限增长部分失败Leader切换时通过幂等性设计或状态查询保证任务不被重复/遗漏惊群效应整点大量任务同时触发导致系统过载任务延展机制使用?占位符让Cron根据负载动态选择执行时间部署建议大多数公司可用K8s CronJob替代复杂的分布式Cron行动建议本周内完成盘点当前系统中所有依赖单机Cron的定时任务识别哪些任务如果失效会产生业务影响一个月内完成对关键定时任务建立备份机制如双机互备或迁移到K8s CronJob评估Cron任务的整点负载分布识别是否存在惊群效应风险一个季度内完成如已使用K8s评估将核心Cron任务迁移到CronJob的可行性对关键Cron任务建立监控和告警确保任务执行失败时能够及时发现长期坚持为Cron任务建立幂等性设计规范确保失败重试不会产生副作用定期审查Cron任务的执行结果识别并优化不合理的调度模式六、高频考点自测问题1为什么单机的cron不能满足大规模分布式系统的需求参考答案当业务规模扩大后定时任务的需求会从几十个增长到几千甚至上万个。单机cron存在单点故障问题——如果这台机器宕机所有定时任务全部失效。在大数据平台每小时日志导入、电商运营零点活动切换、游戏平台定期清理挂机用户等场景中这种单点故障会导致严重的业务影响。问题2Google分布式Cron系统的核心架构是怎样的参考答案Google采用Paxos协议组成一个Paxos集群由Leader来进行cron任务的状态更新与执行操作。任务定义存储在外部高可用存储中而任务的关键状态每条任务的begin和end在Paxos集群中同步。Paxos本质上是一个只能新增的日志每次状态变化后同步新增一条记录需要定期压缩以防止日志无限增长。问题3什么是“部分失败”Google如何应对参考答案在分布式Cron系统中一次任务执行过程会多次与scheduler通信。部分失败指的是在通信过程中部分RPC已完成、但部分未完成时发生了Leader切换。新Leader不知道前Leader执行到了哪一步。Google采用两种应对方案①通过外部系统查询任务状态确定前Leader的执行进度②将外部RPC实现成幂等请求让新Leader可以安全地重试不会产生副作用。问题4什么是惊群效应Google如何解决参考答案当大量Cron任务都配置在整点如00:00执行时会在同一瞬间产生海量请求导致scheduler瞬间过载、大量任务超时或失败。这就是惊群效应。Google的解决方案是任务延展机制在时间配置中使用?占位符表示“任意时间都可以”让cron系统根据负载动态选择任务的具体执行时间将高峰负载打散。问题5分布式Cron系统的设计体现了哪些分布式系统的经典权衡参考答案本章体现了分布式系统设计中三个核心维度的权衡①可用性Paxos集群容忍节点故障保证任务继续执行②一致性Leader唯一性保证同一任务不会被重复执行③性能任务延展机制打散整点负载牺牲“精确时间”换取系统稳定性。这个“可用性-一致性-性能”的三角权衡是分布式系统设计的永恒主题。七、延伸阅读推荐《Reliable Cron across the Planet》GoogleACM Queue 2015本章的原始论文《Google SRE工作手册》第23章“Managing Critical State”Paxos协议在关键状态管理中的应用《The Chubby Lock Service for Loosely-Coupled Distributed Systems》Mike Burrows2006Google分布式锁服务本章Cron系统依赖的底层基础设施《Designing Data-Intensive Applications》Martin Kleppmann分布式系统中共识算法Paxos/Raft的深入讲解Kubernetes CronJob官方文档https//kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/学习下一章预告第25章“数据处理管道”——Google如何构建和处理大规模数据处理管道涉及批处理、流处理和数据管道的可靠性设计。本文为个人学习笔记仅用于知识分享。如有错误欢迎指正。 点赞 收藏 分享让更多开发者看到这篇深度解析❤️ 如果觉得有用请给个赞支持一下作者