Привет, классая идея, как-то забыл про этот продход:) Я как раз планирую провести детальное тестирование разных подходов (теперь включу и этот) и сравнить их производительность в следующей статье. Спасибо! :)
Триггер — это не для ручного лазания админа в БД, а гарантия, что независимо от источника изменений (ваш API, админка, миграция или даже прямой доступ в экстренном случае) — кеш синхронизируется. Это механизм "последней линии обороны", встроенный прямо в уровень данных.
1. Про «диск»: Вы правы, это упрощение. Речь не о физическом диске, а о накладных расходах сетевого взаимодействия и парсинга SQL. Даже из кеша буферов Postgres получение данных требует сетевого обмена и десериализации (десятые доли мс). Чтение же из локальной map в памяти Go — это наносекунды. Экономия именно на устранении межпроцессного взаимодействия.
2. Про «гарантированную консистентность»: Абсолютно верно, здесь я переоценил формулировку. NOTIFY — асинхронный механизм, он не даёт гарантий доставки, как очередь. Это очень быстрая eventual consistency. В нашем случае (стабильное соединение, маленькая таблица) потеря сигнала маловероятна и быстро компенсируется, но строгой гарантии нет.
Вы абсолютно правы, в статье сравнение идёт для случая, когда бэкенд и база данных развернуты в одном сегменте сети (например, в одном дата-центре). В такой конфигурации разница действительно измеряется микросекундами против миллисекунд.
Однако ключевой момент в том, что при использовании облачной инфраструктуры или микросервисной архитектуры, где Redis вынесен в отдельный сервис, разница становится ещё ощутимее. Добавляются дополнительные сетевые хопы, что увеличивает задержку (latency). И да, важный фактор — однопоточная модель Redis, которая при высокой конкурентной нагрузке может стать узким местом, в то время как локальная мапа в Go масштабируется на количество ядер.
Добрый, я бы сказал, что собственное решение в базовом случае простó в реализации и крайне гибко для дальнейшего улучшения и оптимизаций в будущим под нагрузку)
Добрый день, знаю об этой в ситуации. Это не сыграет значимой роли в рамках нашего проекта без колоссальных нагрузок.
В ситуации, если нагрузка будет большой, описанную Вами проблему можно решить добавлением бóльшего числа коннектов, которое зависит от количества реплик sso.
Если есть предложения по улучшению решения, с удовольствием выслушаю.
Привет, классая идея, как-то забыл про этот продход:)
Я как раз планирую провести детальное тестирование разных подходов (теперь включу и этот) и сравнить их производительность в следующей статье. Спасибо! :)
Имели ввиду реплики sso в кубере)
Спорить на основе предположений — неблагодарное дело. Конкретные цифры под конкретную нагрузку всегда важнее теоретических выкладок.
Я обязательно проведу честные тесты в ближайшее время, сравнив:
In-memory кэш (по схеме из статьи).
Redis на том же хосте (loopback).
Redis в отдельном сетевом сервисе.
Замерю не только чистую latency при разном количестве потоков, но и влияние на общую пропускную способность (RPS) системы.
Вы правы, это серьёзное ограничение
NOTIFY. В нашем сценарии (редкие события, мало данных) риск невелик, но в production обязательно нужны:Мониторинг состояния подключений в
pg_stat_activity.Таймауты и health-checks в клиенте.
План на случай сбоя: переподключение с принудительным
Reload().Триггер — это не для ручного лазания админа в БД, а гарантия, что независимо от источника изменений (ваш API, админка, миграция или даже прямой доступ в экстренном случае) — кеш синхронизируется. Это механизм "последней линии обороны", встроенный прямо в уровень данных.
Думаю напишу статью, отдельно с тестированием по данной теме, там будет всё честно)
1. Про «диск»:
Вы правы, это упрощение. Речь не о физическом диске, а о накладных расходах сетевого взаимодействия и парсинга SQL. Даже из кеша буферов Postgres получение данных требует сетевого обмена и десериализации (десятые доли мс). Чтение же из локальной
mapв памяти Go — это наносекунды. Экономия именно на устранении межпроцессного взаимодействия.2. Про «гарантированную консистентность»:
Абсолютно верно, здесь я переоценил формулировку.
NOTIFY— асинхронный механизм, он не даёт гарантий доставки, как очередь. Это очень быстрая eventual consistency. В нашем случае (стабильное соединение, маленькая таблица) потеря сигнала маловероятна и быстро компенсируется, но строгой гарантии нет.Вы абсолютно правы, в статье сравнение идёт для случая, когда бэкенд и база данных развернуты в одном сегменте сети (например, в одном дата-центре). В такой конфигурации разница действительно измеряется микросекундами против миллисекунд.
Однако ключевой момент в том, что при использовании облачной инфраструктуры или микросервисной архитектуры, где Redis вынесен в отдельный сервис, разница становится ещё ощутимее. Добавляются дополнительные сетевые хопы, что увеличивает задержку (latency). И да, важный фактор — однопоточная модель Redis, которая при высокой конкурентной нагрузке может стать узким местом, в то время как локальная мапа в Go масштабируется на количество ядер.
Добрый, я бы сказал, что собственное решение в базовом случае простó в реализации и крайне гибко для дальнейшего улучшения и оптимизаций в будущим под нагрузку)
Добрый день, знаю об этой в ситуации. Это не сыграет значимой роли в рамках нашего проекта без колоссальных нагрузок.
В ситуации, если нагрузка будет большой, описанную Вами проблему можно решить добавлением бóльшего числа коннектов, которое зависит от количества реплик sso.
Если есть предложения по улучшению решения, с удовольствием выслушаю.