R2DBC

Тема дорожной карты · Spring Boot

R2DBC (Reactive Relational Database Connectivity) в Spring обеспечивает полностью неблокирующий, реактивный доступ к реляционным базам данных — включая PostgreSQL, MySQL, H2 и Microsoft SQL Server — в Spring Boot-приложениях, построенных на Project Reactor и Spring WebFlux. Добавление spring-boot-starter-data-r2dbc вместе с соответствующим драйвером (например, r2dbc-postgresql) заставляет Spring Boot авто-настроить реактивную ConnectionFactory на основе spring.r2dbc.url, spring.r2dbc.username и spring.r2dbc.password без какой-либо зависимости от JPA или Hibernate в classpath. Разработчики объявляют интерфейсы ReactiveCrudRepository<Entity, ID> или R2dbcRepository и используют выводимые методы запросов, возвращающие Mono<T> и Flux<T>, обеспечивая сквозные реактивные пайплайны от HTTP-слоя через @RestController Spring WebFlux до базы данных и максимизируя пропускную способность на одном пуле потоков. Для пользовательского SQL DatabaseClient предоставляет fluent API для параметризованных запросов, выполнения DDL и маппинга строк, тогда как @Transactional с ReactiveTransactionManager обеспечивает атомарность без блокирующего I/O. R2DBC в Spring — стандартный выбор для создания высоконагруженных Spring Boot-микросервисов, где модель один-поток-на-соединение JDBC стала бы узким местом при горизонтальном масштабировании в Kubernetes.

Как это работает

R2DBC: Spring WebFlux — non-blocking reactive стек на Project Reactor (типы Mono + Flux). Вместо one thread per request (Servlet), маленький thread pool handle-ит много concurrent запросов через event loop. R2DBC — reactive DB driver, аналог JDBC. WebClient (non-blocking, reactive HTTP-клиент) заменяет RestTemplate. Reactive код читается иначе: цепочки операторов (map, flatMap, filter) вместо imperative. Big learning curve, реальная польза только на high concurrency.

Когда применять

WebFlux только когда (а) huge fan-out + нужен backpressure, (б) streaming, (в) downstream reactive end-to-end. Смешение blocking JDBC в reactive-флоу убивает суть (offloading осторожно). Для типичного CRUD MVC + Servlet проще, debuggable, достаточно быстро. Virtual threads (JDK 21+) закрывают gap для многих случаев — рассмотрите до WebFlux.

Типичные ошибки

Ловушки R2DBC: blocking calls внутри reactive-цепочек (убивает модель + deadlocks); reactive везде "потому что быстрее" (медленнее для wrong shape работы); сложнее debugging (stack traces бесполезны; checkpoint() + reactor debug agent); over-use flatMap, когда map работает.

Связанные понятия

Полезные ресурсы

Проверить знания (1)

Загрузка вопросов…