aftership大規(guī)模任務(wù)調(diào)度在的高可用實踐

大規(guī)模任務(wù)調(diào)度在AfterShip個人介紹 分布式 主導(dǎo)的開源項主導(dǎo)的開源項AfterShip-由單?產(chǎn)品 SaaS產(chǎn)品閉 「以訂單更新為例，需要定時輪詢各個平臺，不同平臺的優(yōu)先級不一樣 「以包 為例，需要定時去輪詢合作的快遞物流商，同時?戶查詢?nèi)蝿?wù)優(yōu)先級更? 連接的?商很多，每天需要反復(fù)調(diào)度任務(wù)數(shù)量到 千萬級基礎(chǔ)設(shè)施分布在全球各地帶來的?延時，需 異步不同?商的服務(wù)SLA?保障，需 可重狀態(tài)更新都需要主動輪詢，需 延時調(diào)不同?商服務(wù)性能不一樣，需 “主動保護“(Rate不同?商任務(wù)優(yōu)先級不一樣，需 優(yōu)先級功需要一個能運?“千萬級別“優(yōu)先級任務(wù)的 基于FIFO處理波峰任務(wù)需 核?問題是什么在FIFO服務(wù)之上實現(xiàn)了一如何解決「引入任務(wù)隊列來解決延時和優(yōu)先級的功能，同時解耦業(yè)務(wù)邏輯?持隊列RateRabbitMQ功能和性能滿足需求，Beanstalkd功能和性能滿足需求，單副本?法滿足Kafka延時功能?法滿足，從設(shè)計上MQ-優(yōu)先級功能?法滿足，?程復(fù)雜不太適合引Pulsar優(yōu)先級功能?法滿足，?程復(fù)雜不太適合引入，但社區(qū)活躍，tfy 功能和性能滿足需求，設(shè) 簡單，適合中短期引選 Y的原「功能和性能滿足的前提下，選擇系統(tǒng)設(shè)計簡單、可靠且符合團隊技術(shù)棧的選型Y通過RestfulAPI任務(wù)? TTL、延時和?動重通 Namespace?持多租?持容量橫向擴容以 遷可擴展多 引擎，目前只? 為什么是基于Redis數(shù)據(jù)結(jié)構(gòu)和命令豐富，適合來實現(xiàn)任務(wù)狀態(tài)遷任務(wù)隊列的本ReachMax注TTRTimeToY-ReadyQueue(listTimerSet(zset)-?來實現(xiàn)延遲任務(wù)的排序，由 ReadyQueue??DeadLetter(list存放重試次數(shù)到達(dá)上JobPool(string)-單獨 JobID?不拷?任務(wù)，從?節(jié)省 Y任務(wù)寫在不搶占過多Redis資源前提下盡量做到實原子遷A,B，那么A??如果有任務(wù)則會優(yōu) 必須需要直接從TimerSet消費也可以，使?ReadyQueue是為了 可以依賴RedisBlockingPop實現(xiàn)多隊列消費和 timeout等待功能Cluster ClusterCluster

ClusterCluster 引擎，目前?持Redis和 appendonlyyes開啟AOF，避免重 noeviction-Redis作 no-appendfsync-on-rewriterewrite時做fsync避免阻塞主進程導(dǎo)致超appendfsyncalways對于數(shù)據(jù)可靠性要求?較?時使?，一般是repl-backlog-size-根據(jù)寫入量適當(dāng)調(diào)大，減少full使 RedisSentinel做故障?動切設(shè)置Redis最大FY單個隊列最大?度受限于單 Redis容目前只?持 ?持磁 服務(wù)作為二? RedisCluster模 特性:指數(shù)回退重架構(gòu)設(shè)計簡架構(gòu)設(shè)計簡消費者實例數(shù)量降低問題定 分鐘級延時降 可擴展容 容 以 擴

容 以 擴系統(tǒng)可觀察性包含什么明確最核?指標(biāo)，太多符合問題定位邏輯，先統(tǒng) 組織要有邏輯，「有指標(biāo)但組織地不好約等于沒有細(xì) Tracing容易在異步化流程被中斷，最好是在基 SDK去做好串為了保證數(shù)據(jù)完整性我們通過業(yè)務(wù)層去做了數(shù)據(jù)追蹤，再根據(jù)這些數(shù)據(jù)容 以 擴遷