Redis · Lettuce · 차이 중심 안내서
LeaderGroupElector는 token과 lease 모델을 그대로 두고 경계 하나만 바꿉니다. 최대 maxLeaders개의 후보가 독립적인 slot token을 소유할 수 있습니다.
동기식 모델 · 결정적 tick · 외부 요청 없음
| tick | 후보 | 연산 | token | TTL | 결과 |
|---|
01 · 차이 모델
상세 LeaderElector 자료에서 acquire, 소유권 token, TTL, 만료, release를 먼저 설명합니다. 여기서는 허용된 후보마다 독립적인 slot token이 생기는 차이만 봅니다.
모든 후보는 같은 lockName을 사용합니다.
활성 token은 최대 maxLeaders개입니다.
activeCount, availableSlots, isFull로 현재 용량을 읽습니다.
token은 소유권 증거이지 안정적인 shard 번호가 아닙니다.
02 · 용량 설정
동시에 슬롯을 소유할 수 있는 후보 수입니다. 직접 API는 1 이상을 허용합니다.
그룹이 포화일 때 후보가 슬롯을 기다리는 상한입니다.
각 slot token의 TTL입니다.
짧은 작업도 최소 소유 시간을 지킵니다.
명시적인 active-lock 연장은 고급 계약으로 존재하지만 이 차이 중심 자료에서는 애니메이션하지 않습니다.
03 · 직접 API
val group = connection.leaderGroupElection(
LeaderGroupElectionOptions(
maxLeaders = 3,
waitTime = 500.milliseconds,
leaseTime = 10.seconds,
)
)
val value = group.runIfLeader("thumbnail-workers") {
processNextClaimedBatch()
}
val state: LeaderGroupState =
group.state("thumbnail-workers")processNextClaimedBatch()에는 여전히 queue 또는 claim table이 필요합니다. 슬롯 허용 자체는 작업을 고유하게 분배하지 않습니다.
04 · Spring Boot
@LeaderGroupElection(
name = "thumbnail-workers",
maxLeaders = 3,
waitTime = "PT0.5S",
leaseTime = "PT10S",
)
fun processNextClaimedBatch(): BatchSummary? =
service.processNextClaimedBatch()직접 LeaderGroupElectionOptions는 maxLeaders >= 1을 허용하지만 Spring 시작 검증은 @LeaderGroupElection.maxLeaders > 1을 요구합니다. 단일 리더에는 @LeaderElection을 사용합니다.
T?, suspend T?, Mono<T>를 지원합니다. 슬롯별 stream lease 연장이 정의되지 않아 Flux<T>와 Kotlin Flow<T>는 거부합니다.
05 · 만료와 회복
만료 후 진입 시나리오에서 작업 시간이 leaseTime보다 길면 기존 token의 TTL이 0이 됩니다. 그 token은 stale이며, 이후 후보가 새로운 token으로 빈 슬롯에 진입합니다.
tick 6 slot-token-A-1 TTL 0 → expired
tick 6 node-D acquire → slot-token-D-3
// 기존 token은 새 소유자의 슬롯을 release할 수 없습니다.리스 만료 뒤 이전 작업이 계속될 수 있으므로 부작용은 중복 실행을 견디거나 stale writer를 거부해야 합니다.
고정 기준