콘텐츠로 이동
Leader 문서0.4

Exposed R2DBC 백엔드

최신 안정판 Leader 0.4.0 릴리스 기준

라이브러리 모듈

Exposed R2DBC transaction으로 코루틴 단일·그룹 선출을 구현하며 JDBC와 같은 SQL 소유권 규칙을 따릅니다.

R2DBC를 쓰는 코루틴 중심 서비스에 선택합니다. 주변 API가 블로킹이거나 가상 스레드 기반이면 JDBC가 자연스럽습니다.

Maven 좌표: io.github.bluetape4k.leader:bluetape4k-leader-exposed-r2dbc

dependencies {
implementation(platform("io.github.bluetape4k:bluetape4k-dependencies:<version>"))
implementation("io.github.bluetape4k.leader:bluetape4k-leader-exposed-r2dbc")
}

suspend transaction의 조건부 쓰기, 만료 시각, owner token으로 lease를 구현합니다. 취소된 호출은 자신이 가진 lease만 정리해야 합니다.

val elector = ExposedR2DbcSuspendLeaderElector(database)
elector.runIfLeader("projection-refresh") { refreshProjection() }

suspend 단일/group elector, R2dbcDatabase 확장 함수, factory, initializer, suspend history sink를 사용합니다.

acquire/use/release를 structured scope에 두고 블로킹 JDBC를 숨겨 넣지 않습니다. 공통 스키마 migration을 먼저 적용하세요.

DB, schema, 릴리스가 같다면 JDBC와 namespace를 공유할 수 있습니다. Spring과 Ktor는 suspend factory/elector를 사용합니다.

wait, lease, retry, schema, R2DBC pool, statement timeout, 생명주기 소유권을 조정합니다.

경쟁은 null입니다. 취소는 owner-safe 정리 후 다시 던지며 연결·transaction 실패는 예외로 드러납니다.

acquire 지연, pool 대기, retry, 취소 정리, DB 부하를 관측합니다.

실제 R2DBC DB에서 두 client 경쟁, 그룹 슬롯, 만료, acquire/action 중 취소를 검증합니다.

JDBC와 비교한 뒤 migration-gate와 Ktor 예제에서 생명주기 통합을 확인하세요.

R2DBC는 막힌 스레드를 줄이지만 DB 왕복과 가용성 위험을 없애지는 않습니다.

아래 그림은 0.4.0 배포본의 README 자산을 해당 배포 커밋에서 직접 불러옵니다. 이후 SNAPSHOT이 아니라 이 매뉴얼 버전의 구조와 실행 흐름을 보여 줍니다. 미리보기를 누르면 같은 배포 커밋의 SVG 원본이 열립니다.

leader exposed r2dbc 클래스 구조도

배포본 README: leader-exposed-r2dbc/README.ko.md

Elector · Initializer · 안정판 안내