Согласование протоколов Gossip и Raft вызывает состояния гонки при обнаружении отказов. #1

New Issue

gvsafronov · 2026-08-17T21:11:23Z

gvsafronov commented

2026-08-17 21:11:23 +00:00

Проблема

Система одновременно запускает два протокола обнаружения отказов: GossipManager (в конечном счёте согласованный, AP-стиль) для распространения информации о состоянии узлов и RaftCoordinator (строго согласованный, CP-стиль) для консенсуса и управления кластером.
Эти протоколы обмениваются информацией асинхронно, без механизма координации, что приводит к состояниям гонки при принятии решений о восстановлении узлов. Ложные срабатывания возникают, когда SelfHealingManager инициирует восстановление узла, который Raft всё ещё считает живым. Ложные пропуски происходят, когда узел помечен Gossip как живой, но Raft считает его мёртвым.
Состояния «разделённого мозга» во времени проявляются, когда разные компоненты системы имеют разное представление о состоянии кластера.

Архитектурная проблема

Как согласовать информацию от протокола Gossip (AP, в конечном счёте согласованный) и протокола Raft (CP, строго согласованный), чтобы принимать единые решения о состоянии кластера и работоспособности узлов?

Предлагаемые направления исследований

Гибридное обнаружение отказов — реализация взвешенной оценки, объединяющей сигналы от Raft и Gossip с настраиваемыми порогами достоверности.
Верификация на основе кворума — требование подтверждения через Raft перед выполнением действий по восстановлению на основе информации от Gossip.
Протокол синхронизации состояний — периодическая синхронизация состояний Gossip и Raft со стратегиями разрешения конфликтов.
Двухфазная проверка работоспособности — сначала быстрая и дешёвая проверка через Gossip, затем надёжная проверка через Raft.
Монотонный конечный автомат — поддержание монотонного состояния, допускающего только поступательное движение и предотвращающего конфликтующие решения.
Обнаружение отказов на основе консенсуса — использование консенсуса Raft для окончательного обнаружения отказов и использование Gossip только для «best-effort» обнаружения.

Соответствующие файлы с исходным кодом

```
internal/cluster/gossip.go
```
```
internal/cluster/raft_coordinator.go
```

**Проблема** Система одновременно запускает два протокола обнаружения отказов: GossipManager (в конечном счёте согласованный, AP-стиль) для распространения информации о состоянии узлов и RaftCoordinator (строго согласованный, CP-стиль) для консенсуса и управления кластером. Эти протоколы обмениваются информацией асинхронно, без механизма координации, что приводит к состояниям гонки при принятии решений о восстановлении узлов. Ложные срабатывания возникают, когда SelfHealingManager инициирует восстановление узла, который Raft всё ещё считает живым. Ложные пропуски происходят, когда узел помечен Gossip как живой, но Raft считает его мёртвым. Состояния «разделённого мозга» во времени проявляются, когда разные компоненты системы имеют разное представление о состоянии кластера. **Архитектурная проблема** Как согласовать информацию от протокола Gossip (AP, в конечном счёте согласованный) и протокола Raft (CP, строго согласованный), чтобы принимать единые решения о состоянии кластера и работоспособности узлов? **Предлагаемые направления исследований** 1. Гибридное обнаружение отказов — реализация взвешенной оценки, объединяющей сигналы от Raft и Gossip с настраиваемыми порогами достоверности. 2. Верификация на основе кворума — требование подтверждения через Raft перед выполнением действий по восстановлению на основе информации от Gossip. 3. Протокол синхронизации состояний — периодическая синхронизация состояний Gossip и Raft со стратегиями разрешения конфликтов. 4. Двухфазная проверка работоспособности — сначала быстрая и дешёвая проверка через Gossip, затем надёжная проверка через Raft. 5. Монотонный конечный автомат — поддержание монотонного состояния, допускающего только поступательное движение и предотвращающего конфликтующие решения. 6. Обнаружение отказов на основе консенсуса — использование консенсуса Raft для окончательного обнаружения отказов и использование Gossip только для «best-effort» обнаружения. **Соответствующие файлы с исходным кодом** - internal/cluster/gossip.go - internal/cluster/raft_coordinator.go

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gvsafronov/futriix#1