Что такое Availability в CAP?

Availability в CAP теореме

CAP теорема (теорема Брюера) является фундаментальным принципом в распределённых системах. Она гласит, что невозможно одновременно гарантировать все три свойства: Consistency, Availability и Partition Tolerance.

Что такое Availability?

Availability (Доступность) означает, что система всегда отвечает на запросы в разумное время, независимо от состояния некоторых узлов. Другими словами:

• Каждый запрос к живому узлу получит ответ (успешный или с ошибкой, но не timeout)
• Нет недоступного периода
• Система работает 99.9% времени
• Каждый узел может обработать запрос независимо

Определение Availability

Доступность = (количество успешных ответов / общее количество запросов) × 100%

Система с высокой доступностью:
- 99% (3 девятки) = 7.2 часа простоя в год
- 99.9% (4 девятки) = 43 минуты простоя в год
- 99.99% (5 девяток) = 4.3 минуты простоя в год

Пример: кэш vs база данных

// Высокая Availability - всегда отвечает
public class AvailableCache {
    private Cache<String, User> cache = CacheBuilder.newBuilder()
        .expireAfterWrite(1, TimeUnit.HOURS)
        .build();
    
    public User getUser(String id) {
        // Сначала проверяем кэш - ЭТО ВСЕГДА РАБОТАЕТ
        User cached = cache.getIfPresent(id);
        if (cached != null) {
            return cached;  // Instant response
        }
        
        try {
            // Если кэш пустой, идём в БД
            User user = database.findUser(id);
            cache.put(id, user);
            return user;
        } catch (Exception e) {
            // БД недоступна? Возвращаем последнее известное значение
            return cache.getIfPresent(id);  // Graceful degradation
        }
    }
}

Сравнение стратегий

Availability-ориентированная система (AP)

// NoSQL кластер (например, Cassandra)
// Гарантирует: Availability + Partition Tolerance
// Жертвует: Consistency

public class AvailabilityOrientedDB {
    public User getUser(String id) {
        // Запрашиваем соседний узел - ВСЕГДА получим ответ
        // Даже если некоторые узлы down
        // Данные могут быть немного устаревшими
        return cassandraCluster.getUser(id);  // ← Быстро и надёжно
    }
    
    public void updateUser(User user) {
        // Обновляем в кластере без координации
        // Несколько узлов может иметь разные версии (eventual consistency)
        cassandraCluster.update(user);  // ← Быстро, но возможны несогласованности
    }
}

Consistency-ориентированная система (CP)

// Реляционная БД с двухфазной фиксацией (2PC)
// Гарантирует: Consistency + Partition Tolerance
// Жертвует: Availability

public class ConsistencyOrientedDB {
    public void updateAcrossPartitions(Transaction txn) {
        try {
            // Фаза 1: Prepare - проверяем все участников
            coordinator.prepare(txn);
            
            // Фаза 2: Commit - коммитим все или откатываем
            coordinator.commit(txn);
        } catch (PartitionException e) {
            // Если некоторые узлы недоступны - ОТКАЗЫВАЕМ в запросе
            throw new UnavailableException("Cannot guarantee consistency");
        }
    }
}

Practical Trade-offs

// Сценарий: e-commerce система с платежами

// Вариант 1: Availability первый (AP)
@PostMapping("/buy")
public ResponseEntity<Order> buyProduct(@RequestBody Purchase request) {
    try {
        Order order = createOrder(request);
        // Асинхронная обработка платежа
        paymentService.processAsync(order.getId());
        return ResponseEntity.ok(order);  // ← Быстрый ответ
    } catch (ServiceUnavailableException e) {
        // Платёж недоступен? Сохраняем заказ локально
        Order order = createOrder(request);
        localQueue.add(order);  // Retry позже
        return ResponseEntity.ok(order);  // ← Система доступна!
    }
}

// Вариант 2: Consistency первый (CP)
@PostMapping("/buy")
public ResponseEntity<Order> buyProductStrict(@RequestBody Purchase request) {
    // Нужна согласованность данных
    Order order = createOrder(request);
    
    try {
        boolean success = paymentService.processSynchronously(order.getId());
        if (!success) {
            throw new PaymentFailedException();
        }
        return ResponseEntity.ok(order);
    } catch (TimeoutException e) {
        // Платёж не ответил в отведённое время - ОТКАЗЫВАЕМ
        cancelOrder(order);
        return ResponseEntity.status(503).build();  // Service Unavailable
    }
}

Реальные примеры

Высокая Availability:

• Google Docs (работает даже offline)
• DNS системы
• CDN (Content Delivery Networks)
• Кэши (Redis, Memcached)

Высокая Consistency:

• Банковские системы
• Системы с двухфазной фиксацией
• ACID базы данных

Метрики Availability

public class AvailabilityMetrics {
    private MeterRegistry meterRegistry;
    
    public void recordRequest(boolean success, long responseTime) {
        Counter counter = meterRegistry.counter(
            "requests.total",
            "status", success ? "success" : "failure"
        );
        counter.increment();
        
        Timer timer = meterRegistry.timer(
            "requests.duration",
            "status", success ? "success" : "failure"
        );
        timer.record(responseTime, TimeUnit.MILLISECONDS);
    }
    
    public double calculateAvailability() {
        // successful / (successful + failed) * 100%
        return (successfulRequests / totalRequests) * 100;
    }
}

В контексте Java разработки, понимание Availability критично при выборе между различными подходами: использовать кэширование, асинхронную обработку, eventual consistency или требовать immediate consistency.