Система с TTL удаляет одну запись в разные моменты на разных репликах из-за расхождения часов. Как определить момент истечения так, чтобы локальные часы реплик не меняли фактический срок жизни записи?
Момент истечения должен задаваться не локальными часами каждой реплики, а авторитетным источником: например, лидером, координатором или сервисом времени, который фиксирует единый дедлайн. Реплики хранят этот дедлайн вместе с записью, а окончательное удаление выполняют через согласованное событие истечения или безопасно проверяют с учётом известной погрешности часов.
Полностью точное истечение по физическому времени невозможно гарантировать при неограниченном расхождении часов и сетевых задержках. На практике выбирают одно из свойств: не удалять данные раньше срока, не хранить их дольше допустимого срока или обеспечивать приближённый TTL с ограниченной погрешностью.
TTL появился как простой способ автоматически удалять временные данные: кэш, сессии, временные токены и устаревающие записи. В односерверной системе достаточно сравнить локальное время с моментом истечения.
В распределённой системе одна запись может храниться на нескольких узлах, чьи часы синхронизированы неточно, а сообщения между узлами задерживаются. Поэтому наивное сравнение локального времени превращает TTL из единого свойства записи в независимые решения каждой реплики.
При записи система должна сохранить не только значение, но и единый срок действия. Если каждая реплика вычисляет его самостоятельно, небольшая ошибка часов может привести к преждевременному удалению данных или к выдаче уже истёкшей записи.
Преждевременное удаление опасно для сессий, токенов и кэшей: клиент может получить отказ раньше обещанного срока. Позднее удаление критично для авторизационных данных и ограничений безопасности, поскольку истёкший токен способен оставаться действительным.
Сетевой раздел может дополнительно задержать уведомление об истечении. Поэтому нужно заранее определить, какое нарушение допустимо: временное сохранение данных дольше TTL обычно безопаснее, чем их преждевременная недоступность, но для секретов может потребоваться обратное требование.
Авторитетный узел при создании записи вычисляет абсолютный дедлайн и распространяет его как часть данных. Реплики не пересчитывают TTL от собственного времени записи: они используют полученный дедлайн и применяют единое правило истечения.
Если допустимо удаление не раньше срока, реплика может удалять запись только после наступления дедлайна с запасом на максимальную известную погрешность часов. При неизвестной или неограниченной погрешности безопасное физическое удаление нельзя обосновать одними локальными часами.
Более строгий вариант — авторитетный узел публикует согласованное событие истечения, например логическую tombstone-запись. Реплики применяют её в порядке журнала. Это устраняет расхождение решений, но не гарантирует, что недоступная реплика немедленно прекратит обслуживать локальные чтения.
Для безопасности часто используют сочетание механизмов: короткий TTL локального кэша, проверку токена в авторитетном сервисе и отзыв через согласованную запись. Синхронизация часов по NTP или другому протоколу уменьшает ошибку, но не превращает часы в единый источник истины.
Монотонные часы полезны для измерения интервалов внутри одного процесса, однако их значения нельзя напрямую сравнивать между узлами. Логические часы хорошо описывают порядок событий, но сами по себе не измеряют физический срок жизни. Гибридные логические часы уменьшают часть проблем, но также зависят от модели физических часов и правил системы.
Сервис выдаёт токены доступа с TTL 15 минут и реплицирует их между площадками. На одной площадке часы отстают на 40 секунд, поэтому токен удаляется позже; на другой часы спешат на 25 секунд, и токен исчезает раньше заявленного срока.
Вариант с локальным вычислением TTL прост и не требует координации, но даёт разные результаты на репликах. Вариант с синхронизацией часов дешевле, однако сохраняет остаточную погрешность и зависит от качества мониторинга времени.
Выбранное решение: авторитетный сервис при выдаче токена фиксирует дедлайн, а реплики хранят его вместе с токеном. Для проверки доступа используется авторитетная версия или согласованная запись отзыва; локальный кэш может отказать в обслуживании после консервативного, более раннего безопасного срока.
Такой подход уменьшает риск использования истёкшего токена. Его цена — дополнительные сетевые проверки, задержка отзыва и необходимость явно определить поведение при недоступности авторитетного сервиса.
Нет. Синхронизация лишь ограничивает расхождение с некоторой погрешностью. Для строгой гарантии нужно учитывать эту погрешность, задержки доставки и момент, с которого запись считается доступной на конкретной реплике; иначе часть узлов всё равно может удалить запись раньше или обслужить её позже срока.
Реплика может не получить обновление или tombstone из-за сетевого разделения. Пока она доступна клиентам и не имеет свежего состояния, она способна вернуть устаревшую запись. Поэтому строгий TTL требует либо чтения через актуальный кворум или авторитетный узел, либо отказа от чтений на репликах, чья свежесть не подтверждена.
Только если контракт явно разрешает приближённый TTL или досрочная недоступность безопасна для конкретного типа данных. Для кэша это часто приемлемо: промах вызывает повторное получение значения. Для токена доступа раннее удаление может нарушить пользовательский контракт, а позднее удаление — создать уязвимость, поэтому обычно разделяют срок, после которого выдача запрещена, и срок физической очистки данных.