Distributed lock vs fencing token¶
Тип материала: инженерное сравнение. Выводы зависят от workload и failure model; схема и сценарии иллюстративные.
Проверка источников: 2026-11-02. Численные latency, throughput, cost и SLA не измерялись.
Критерии выбора¶
| Критерий | Distributed lock / lease | Resource-enforced fencing |
|---|---|---|
| Workload | Выбор текущего владельца работы | Защита sink от старого владельца |
| Consistency | Зависит от authority и lease assumptions | Атомарное отклонение stale epoch самим resource |
| Latency / throughput | Acquire/renew round trips | Token check на каждой защищаемой записи |
| Cost / scalability | Lease service и renew traffic | Epoch state в каждом protected resource |
| Operational complexity | Expiry, pause, failover, owner-safe release | Monotonicity после restore, equal-epoch protocol |
Механизм и ограничения¶
Это не взаимоисключающие альтернативы: lease распределяет работу, fencing защищает эффект после смены владельца. Если resource не принимает token, lock alone не предотвращает late stale write. Для локального PG ledger row locks/constraints предпочтительнее дополнительного remote mutex, когда вся invariant boundary уже в одной БД.
Надёжный fencing token получается из monotonic authority и корректного ownership protocol. Timestamp клиента не подходит. Token меньше сохранённого reject; повтор того же epoch требует identity/result lookup, иначе два writes одной generation могут конфликтовать.
Иллюстративная схема решения¶
flowchart TD
W[Workload and invariant] --> B[Define durable boundary]
B --> F[Compare failure and recovery obligations]
F --> L[Choose protocol for explicit scope]
L --> T[Fault test and reconciliation]Failure и recovery¶
Поставьте old worker на pause, дождитесь нового lease, запишите e2, затем возобновите old worker e1. Проверяйте состояние sink, а не lock key. После restore authority убедитесь, что tokens не переиспользуются.
Практическое упражнение¶
Опишите atomic check для публикации settlement generation и поведение при повторе одного epoch. Укажите, где хранится last accepted epoch и кто имеет право его менять.
Связанные материалы и источники¶
- etcd API guarantees — 3.5.
- Redis distributed locks — rolling; examples 7.4.