Что обеспечивает Kafka из CAP-теоремы

Kafka и CAP-теорема

CAP-теорема (теорема Брюера) утверждает, что распределённая система может одновременно гарантировать только ДВА из трёх свойств: Consistency, Availability, Partition tolerance. Kafka обеспечивает Availability и Partition Tolerance (AP).

CAP-теорема: три свойства

1. Consistency (Консистентность) — все узлы видят одни и те же данные в один момент времени
2. Availability (Доступность) — система всегда отвечает на запросы
3. Partition Tolerance (Отказоустойчивость) — система работает несмотря на разделение сети

Что обеспечивает Kafka

// Kafka = AP система
// A - Availability (доступность)
// P - Partition Tolerance (отказоустойчивость к разделениям сети)
// Отсутствие - Consistency (строгая консистентность)

Availability в Kafka

// 1. Kafka работает даже при сбое узлов
public class AvailabilityExample {
    private final KafkaProducer<String, String> producer;
    
    public void publishMessage(String message) {
        // Система остаётся доступной
        // Даже если один из брокеров упал
        producer.send(new ProducerRecord<>("topic", message));
    }
    
    public void consumeMessage() {
        // Consumer всегда может читать из доступных партиций
        // Система не блокируется
    }
}

// 2. Репликация обеспечивает высокую доступность
// Topic с replication-factor=3
// Leader (Broker 1) + Replicas (Broker 2, Broker 3)
// Если Leader упал, один из Replicas становится Leader

Partition Tolerance в Kafka

// Kafka продолжает работать при разделении сети

// Сценарий: разделение сети между Broker 1 и (Broker 2, 3)
public class PartitionToleranceExample {
    
    // Раздел 1: Broker 1 - изолирован
    // Раздел 2: Broker 2, 3 - кластер продолжает работу
    
    // Поведение:
    // - Consumer может читать из Broker 2, 3
    // - Новый Leader выбирается из здоровых брокеров
    // - Данные из Broker 1 становятся недоступны до восстановления сети
    
    public void produceWithoutConsistency() {
        // Producer отправляет в доступную партицию
        // Не ждёт ответа от всех репликас
        // Система остаётся доступной
    }
}

Потеря Consistency

// Kafka жертвует STRONG CONSISTENCY ради Availability и Partition Tolerance

public class ConsistencyTradeoff {
    // Сценарий потери данных
    
    // 1. Producer отправляет сообщение
    KafkaProducer<String, String> producer = new KafkaProducer<>(props);
    producer.send(new ProducerRecord<>("topic", "message1"));
    
    // 2. Данные пишутся в Leader и репликуются
    // Leader (Broker 1): message1
    // Replica1 (Broker 2): message1
    // Replica2 (Broker 3): ?  <- ещё в процессе репликации
    
    // 3. Broker 1 (Leader) падает ПЕРЕД репликацией на все узлы
    // Leader election выбирает Broker 2
    // Broker 3 может не иметь message1
    
    // 4. Результат: данные потеряны или имеют рассинхронизацию
    // Это цена за Availability
}

Конфигурация Kafka для увеличения Consistency

// Хотя Kafka = AP система, можно улучшить консистентность

public class KafkaConsistencyTuning {
    
    public void configureProducer() {
        Properties props = new Properties();
        props.put("bootstrap.servers", "localhost:9092");
        props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        
        // 1. acks=all - ждём ответа от всех in-sync replicas
        props.put("acks", "all");  // более безопасно
        // acks="1" - только от leader (быстрее, но менее безопасно)
        // acks="0" - без подтверждения (самый быстрый)
        
        // 2. min.insync.replicas=2 - минимум 2 реплики для ack
        props.put("min.insync.replicas", "2");
        
        // 3. Retries для обработки временных ошибок
        props.put("retries", "3");
        
        KafkaProducer<String, String> producer = new KafkaProducer<>(props);
        
        // Отправка с ожиданием подтверждения
        producer.send(new ProducerRecord<>("topic", "message"),
            (metadata, exception) -> {
                if (exception != null) {
                    System.err.println("Ошибка отправки");
                } else {
                    System.out.println("Данные подтверждены");
                }
            });
    }
    
    public void configureConsumer() {
        Properties props = new Properties();
        props.put("bootstrap.servers", "localhost:9092");
        props.put("group.id", "consumer-group");
        
        // isolation.level=read_committed - читаем только committed сообщения
        props.put("isolation.level", "read_committed");
        
        // enable.auto.commit=false - ручная коммитизация для контроля
        props.put("enable.auto.commit", "false");
        
        KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
        consumer.subscribe(Collections.singletonList("topic"));
        
        ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
        records.forEach(record -> {
            // Обработка сообщения
            System.out.println(record.value());
        });
        
        // Явная коммитизация после обработки
        consumer.commitSync();
    }
}

Сравнение с другими системами

Практическое значение для Java Developer

// Понимание AP природы Kafka критично при дизайне

public class KafkaDesignConsiderations {
    
    // 1. Идемпотентность - обрабатывай дубликаты
    public void processMessage(Message msg) {
        // Сообщение может быть доставлено 2+ раза
        // Твой код должен быть идемпотентным
        database.upsert(msg.getId(), msg.getData());
    }
    
    // 2. Ordering гарантирован только в одной партиции
    public void ensureOrdering() {
        // Используй один и тот же partition key для ordered events
        producer.send(new ProducerRecord<>(
            "topic",
            userId,  // partition key
            event    // значение
        ));
    }
    
    // 3. Eventual consistency вместо strong consistency
    public void acceptDelays() {
        // Consumer может отстать от Producer
        // Это нормально для Kafka
    }
}

Заключение

Kafka обеспечивает Availability и Partition Tolerance (AP), жертвуя Strong Consistency. Это означает, что система остаётся доступной при сбоях и разделениях сети, но может иметь временные несоответствия данных. Для критичных данных используй правильную конфигурацию (acks=all, min.insync.replicas) и разрабатывай с учётом eventual consistency и идемпотентности.