Как реализовать конкурентное in-memory хранилище с TTL для записей в Go?

Что проверяют

Умеете ли вы совместить синхронизацию, фоновую горутину и её корректную остановку. Map с мьютексом пишут все, отличает ответ то, как вы удаляете просроченное и не течёт ли горутина. Следом спрашивают, как это тестировать без time.Sleep.

Как отвечать

Каркас:

• структура: Store[K comparable, V any] с sync.RWMutex и map[K]entry[V], где entry хранит значение и expiresAt time.Time. Дженерики вместо interface{} избавляют от приведения типов;
• ленивое истечение: Get под RLock проверяет time.Now().After(e.expiresAt) и не отдаёт просроченное. Удалить под RLock нельзя: нужно отпустить его, взять Lock и перепроверить запись, её мог перезаписать другой Set;
• фоновая чистка: горутина с time.NewTicker раз в интервал удаляет истёкшие записи, иначе ключи, которые никто не читает, живут вечно;
• остановка: конструктор принимает context.Context или у хранилища есть Close(), закрывающий канал done. Горутина выходит по select, тикер останавливается через defer ticker.Stop(), повторный Close защищён sync.Once;
• монотонное время: time.Now() несёт показания монотонных часов, поэтому After не ломается при переводе системных часов.

Полный обход map под Lock на миллионе ключей блокирует все операции. Варианты: чистить за проход случайную выборку ключей, как делает Redis, держать мин-кучу по времени истечения на container/heap или разбить хранилище на шарды с отдельной чисткой.

Для тестов время внедряется функцией now func() time.Time, и истечение проверяется сдвигом фейковых часов. В свежих версиях Go для этого есть пакет testing/synctest. Всё гоняется с go test -race.

Где спотыкаются

Запускают чистку горутиной без способа её остановить. Каждый экземпляр из тестов оставляет висящую горутину, и утечку видно по росту их числа.

Считают, что Get, который возвращает «не найдено» для просроченной записи, решает задачу. Память при этом не освобождается, пока запись не удалит кто-то ещё.

Держат Lock во время посторонней работы, например вызывают колбэк удаления под мьютексом. Колбэк обращается к хранилищу, мьютекс в Go не реентерабельный, и получается взаимная блокировка.