aftership大规模任务调度在的高可用实践

大规模任务调度在AfterShip个人介绍 分布式 主导的开源项主导的开源项AfterShip-由单⼀产品 SaaS产品闭 「以订单更新为例，需要定时轮询各个平台，不同平台的优先级不一样 「以包 为例，需要定时去轮询合作的快递物流商，同时⽤户查询任务优先级更⾼ 连接的⼚商很多，每天需要反复调度任务数量到 千万级基础设施分布在全球各地带来的⾼延时，需 异步不同⼚商的服务SLA⽆保障，需 可重状态更新都需要主动轮询，需 延时调不同⼚商服务性能不一样，需 “主动保护“(Rate不同⼚商任务优先级不一样，需 优先级功需要一个能运⾏“千万级别“优先级任务的 基于FIFO处理波峰任务需 核⼼问题是什么在FIFO服务之上实现了一如何解决「引入任务队列来解决延时和优先级的功能，同时解耦业务逻辑⽀持队列RateRabbitMQ功能和性能满足需求，Beanstalkd功能和性能满足需求，单副本⽆法满足Kafka延时功能⽆法满足，从设计上MQ-优先级功能⽆法满足，⼯程复杂不太适合引Pulsar优先级功能⽆法满足，⼯程复杂不太适合引入，但社区活跃，tfy 功能和性能满足需求，设 简单，适合中短期引选 Y的原「功能和性能满足的前提下，选择系统设计简单、可靠且符合团队技术栈的选型Y通过RestfulAPI任务⽀ TTL、延时和⾃动重通 Namespace⽀持多租⽀持容量横向扩容以 迁可扩展多 引擎，目前只⽀ 为什么是基于Redis数据结构和命令丰富，适合来实现任务状态迁任务队列的本ReachMax注TTRTimeToY-ReadyQueue(listTimerSet(zset)-⽤来实现延迟任务的排序，由 ReadyQueue⾥⾯DeadLetter(list存放重试次数到达上JobPool(string)-单独 JobID⽽不拷⻉任务，从⽽节省 Y任务写在不抢占过多Redis资源前提下尽量做到实原子迁A,B，那么A⾥⾯如果有任务则会优 必须需要直接从TimerSet消费也可以，使⽤ReadyQueue是为了 可以依赖RedisBlockingPop实现多队列消费和 timeout等待功能Cluster ClusterCluster

ClusterCluster 引擎，目前⽀持Redis和 appendonlyyes开启AOF，避免重 noeviction-Redis作 no-appendfsync-on-rewriterewrite时做fsync避免阻塞主进程导致超appendfsyncalways对于数据可靠性要求⽐较⾼时使⽤，一般是repl-backlog-size-根据写入量适当调大，减少full使 RedisSentinel做故障⾃动切设置Redis最大FY单个队列最大⻓度受限于单 Redis容目前只⽀持 ⽀持磁 服务作为二⽀ RedisCluster模 特性:指数回退重架构设计简架构设计简消费者实例数量降低问题定 分钟级延时降 可扩展容 容 以 扩

容 以 扩系统可观察性包含什么明确最核⼼指标，太多符合问题定位逻辑，先统 组织要有逻辑，「有指标但组织地不好约等于没有细 Tracing容易在异步化流程被中断，最好是在基 SDK去做好串为了保证数据完整性我们通过业务层去做了数据追踪，再根据这些数据容 以 扩迁