Reactive có phải giải pháp duy nhất cho high traffic

gists:

id: 8b02d3b87d953ce96be1cdfb58e9d5dd url: 'https://gist.github.com/lyminhtanh/8b02d3b87d953ce96be1cdfb58e9d5dd' createdAt: '2025-06-12T05:14:55Z' updatedAt: '2025-06-12T05:14:55Z' filename: Reactive có phải giải pháp duy nhất cho high traffic?.md isPublic: false baseUrl: 'https://api.github.com'

From [[why reactive]] Thông tin bạn cung cấp về reactive programming là khá chính xác và thực tế. Tôi sẽ xác thực và bổ sung một số điểm quan trọng:

✅ Những điểm chính xác

1. Về hiệu suất và tài nguyên:

Con số 10,000 threads cho 10,000 concurrent users là realistic với blocking model
R2DBC và WebClient thực sự giúp giảm thread usage đáng kể
Context switching overhead là vấn đề thực tế với nhiều threads

2. Về công nghệ:

R2DBC cho reactive database access là đúng
WebClient thay thế RestTemplate cho reactive HTTP client
Latency 300-500ms cho DB + HTTP call là hợp lý

🔧 Bổ sung và làm rõ

Thread Pool thực tế:

// Blocking (Traditional)
@RestController
public class ProductController {
    // Mỗi request = 1 thread từ Tomcat thread pool (default 200)
    // Với 10k concurrent users → thread pool exhausted
    
    @GetMapping("/product/{id}")
    public Product getProduct(@PathVariable String id) {
        Product product = productRepository.findById(id); // Block thread
        Inventory inventory = inventoryClient.getInventory(id); // Block thread
        return enrichProduct(product, inventory);
    }
}

// Reactive
@RestController  
public class ReactiveProductController {
    // Threads được release ngay khi gặp I/O, tái sử dụng cho requests khác
    
    @GetMapping("/product/{id}")
    public Mono<Product> getProduct(@PathVariable String id) {
        return productRepository.findById(id) // Non-blocking
            .flatMap(product -> 
                inventoryClient.getInventory(id) // Non-blocking
                    .map(inventory -> enrichProduct(product, inventory))
            );
    }
}

Thực tế về Thread Usage:

Blocking: Tomcat default thread pool = 200, có thể tăng lên ~1000-2000
Reactive: Netty event loop thường chỉ cần 2-4 threads/CPU core
Với 10k users: Blocking cần hàng nghìn threads, Reactive chỉ cần vài chục

Bổ sung quan trọng:

3. Backpressure handling:

// Reactive hỗ trợ backpressure tự động
Flux<Product> products = productService.getProducts()
    .onBackpressureBuffer(1000) // Buffer 1000 items
    .onBackpressureDrop(); // Drop excess items

4. Error handling phức tạp hơn:

// Blocking - đơn giản
try {
    return productService.getProduct(id);
} catch (Exception e) {
    return handleError(e);
}

// Reactive - cần reactive error handling
return productService.getProduct(id)
    .onErrorReturn(DefaultProduct.empty())
    .onErrorMap(DatabaseException.class, ex -> new ServiceException(ex));

5. Testing và debugging:

// Reactive testing cần StepVerifier
@Test
public void testReactiveFlow() {
    StepVerifier.create(productService.getProduct("123"))
        .expectNextMatches(product -> product.getId().equals("123"))
        .verifyComplete();
}

📊 Bổ sung bảng so sánh:

Tiêu chí	Blocking	Reactive	Ghi chú
Memory usage	Cao (mỗi thread ~1MB stack)	Thấp	10k threads ≈ 10GB memory
Latency under load	Tăng exponentially	Ổn định	Blocking có thread pool exhaustion
Learning curve	Dễ	Khó	Reactive cần tư duy hoàn toàn khác
Ecosystem maturity	Rất mature	Đang phát triển	Một số libs chưa hỗ trợ reactive
Error stack traces	Rõ ràng	Phức tạp	Reactive stack traces khó debug

🎯 Khi nào nên dùng Reactive:

✅ Nên dùng khi:

High concurrency (>1000 concurrent users)
I/O intensive operations
Microservices với nhiều external calls
Real-time data streaming
Mobile apps với limited resources

❌ Không cần thiết khi:

Ứng dụng nhỏ (<100 concurrent users)
CPU-intensive tasks
Team thiếu kinh nghiệm reactive
Legacy systems với nhiều blocking dependencies

💡 Lời khuyên thực tế:

Đừng reactive hoá toàn bộ - Bắt đầu với các endpoints high-traffic
Monitoring quan trọng - Reactive metrics khác với blocking
Test thoroughly - Reactive bugs khó reproduce
Team training - Đầu tư thời gian học reactive patterns

Nhìn chung, phân tích của bạn rất thực tế và phù hợp với kinh nghiệm production. Bạn có muốn tôi demo code cụ thể cho case study này không?

🌊 Backpressure Handling - Giải thích chi tiết

Backpressure là gì?

Backpressure xảy ra khi producer tạo ra data nhanh hơn consumer xử lý. Giống như nước chảy vào bồn nhanh hơn thoát ra → bồn tràn.

Ví dụ thực tế:

// Producer tạo 1000 items/giây
// Consumer chỉ xử lý được 100 items/giây
// → 900 items/giây bị tích tụ → OutOfMemoryError

Backpressure Strategies trong Reactive:

// 1. BUFFER - Lưu trữ tạm thời
Flux<String> data = dataProducer()
    .onBackpressureBuffer(1000) // Buffer tối đa 1000 items
    .doOnNext(item -> processSlowly(item));

// 2. DROP - Bỏ qua items mới nhất
Flux<String> data = dataProducer()
    .onBackpressureDrop(dropped -> log.warn("Dropped: " + dropped))
    .doOnNext(item -> processSlowly(item));

// 3. LATEST - Chỉ giữ item mới nhất
Flux<String> data = dataProducer()
    .onBackpressureLatest()
    .doOnNext(item -> processSlowly(item));

// 4. ERROR - Throw exception
Flux<String> data = dataProducer()
    .onBackpressureError() // Ném BackpressureException
    .doOnNext(item -> processSlowly(item));

Ví dụ thực tế - Live Trading System:

@Service
public class TradingDataService {
    
    // Market data stream - 10,000 updates/second
    public Flux<MarketData> getMarketDataStream() {
        return marketDataSource.stream()
            .onBackpressureLatest() // Chỉ quan tâm giá mới nhất
            .sample(Duration.ofMillis(100)); // Sample mỗi 100ms
    }
    
    // Order processing - có thể xử lý 500 orders/second => DO NOT DO THIS
    public Flux<OrderResult> processOrders() {
        return orderStream
            .onBackpressureBuffer(1000, // Buffer 1000 orders
                BufferOverflowStrategy.DROP_OLDEST) // Drop orders cũ
            .flatMap(order -> processOrder(order), 10); // Max 10 concurrent
    }
}