Если их жизненный цикл ограничен временем жизни приложения, то зачем их вообще оттуда куда-то складывать?

Если много-поток? Много-воркер?

Блин, ок. Что такое IPC?

Тем более не надо увеличивать контеншн и выходить за рамки собственного адресного пространства

Это почему-то тяжело доходит до человека, не знаю, как объяснить даже

оО

Эм… нет, надо.

Один поток создал кеш, другому он нужен вместо того, чтобы идти час в базу данных и считать все заново. И?

Нужен общий стейт у единого приложения, которое может исполняться на дубликатах процессов или даже серверов. Не вижу причин и возможности не делать это в отдлельном едином storage, который тоже может быть много-серверным, кстати. PSQL это или Redis — вопрос другой.

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

Затем, что кому-то не хочется сваливать данные любого типа в 1 хранилище, которое иногда обладает излишней функциональностью и недостаёт нужной (TTL), приходится игнорировать одно и достраивать другое. Вам хочется иначе — пожалуйста.

Вы в курсе что у потоков общее адресное пространство и можно просто из разных потоков в одну оперативку ходить? Что можно не в редис это через сеть класть, а вот прямо по адресу?

Shared Memory Segment'ы - вполне себе данные хранят. Сделаны через Ж, поэтому Redis. А ещё потому что воркеры или микросервисы могут быть на разных "хостах"

Я-то в курсе, а как насчёт приставов синхронизации и связанным с этим геморроем? Или как насчёт не только многопоточных, но и многозадачных приложений? Многозадачных, где ещё сами задачи могут по кластеру размазываться?

Где во всем описанном ипц нужен ттл отдельных записей?
(Я даже больше скажу. Ттл на самом деле не нужен практически никогда, необходимость данных зависит от событий, а не от времени)

Во-первых shm это просто общий кусок память. Он сделан как кусок памяти. Ничем не отличается. Но это полбеды.

Во-вторых он не используется в многопоточных приложениях. У потоков разница в оперативки только в стеке, все остальное у них общее.

Инвалидация кеша через некоторое время? Мне была нужна несколько раз. Потому что кеш должен сколько-то жить и да, в нём данные могут отставать от актуальных, это нормально.

Я вот на днях столкнулся, дам ссылочку: https://yookassa.ru/developers/using-api/basics#idempotence

> ЮKassa обеспечивает идемпотентность в течение 24 часов после первого запроса, потом повторный запрос будет обработан как новый.

Есть вещи, зависщие от времени.

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

Если у вас не было такого опыта или просто морально иной подход — ваше право, но настаивать на такой точке зрения… глупо?

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

Ну, кроме того, что у разных процессов этот кусок будет отображён на разные адреса .