Пожалуйста, не используйте в Redis структуру List для сообщений. Это древний механизм чтения "из стека с блокировкой", не надо так (с)
В Redis уже давно есть publish / subscribe для рассылки сообщений в каналы подписчикам (сообщения не хранятся).
И уже года 4 как (с версии 5, текущая - 7) есть механизм Stream, функциональный аналог топиков Кафки. С хранением сообщений, чтением разными группами одного стрима с load balancing внутри группы, отдельным подтверждением обработки сообщения (ack), сбором полученных и не обработанных "потеряшек" и т.д. В результате получается очень быстрый и почти не требующий настроек брокер сообщений.
Кроме того, кроме самого Redis есть продукт Redis Stack от тех же авторов с кучкой очень полезных расширений (JSON storage с индексами и поиском по множеству ключей, например). Плюс админка :)
Обфускация не преодалевает блокировки. Обфускация маскирует источник трафика, что в случае "VPN против блокировок" вот совсем не нужно обычному юзеру. Для преодоления блокировок нужно маскировать трафик под стандартные варианты и вовремя менять адреса точек подключения, доставляя свежие неблокируемыми способами. Плюс некоторые дополнительные трюки, если это Китай :)
Кстати, ещё момент — все 3 модуля, указанные в статье как Redis Enterprise, доступны и в виде open source — собираются и подключаются.
Единственный минус тут — нет готового докера со всеми батарейками сразу, или качаешь докер с редисом плюс один из них, либо голый редис и собирать и включать плагины.
Очень упрощенно написано про Redis.
1. Key-value — можно использовать и так, но гораздо чаще key используется для доступа к более сложным структурам данных внутри value, про которых тут написано мало: стеки, хэши, хэш + индекс, stream,… Redis действительно хранилище структур, а не значений.
2. Забыт stream — крайне полезная и эффективная структура, может т.ч. использоваться для логов и гарантированной доставки сообщений — готовая основа для оркестровки групп воркеров с балансировкой нагрузки из коробки, например.
3. Несколько open source плагинов от той же команды, фактически части Redis:
Search — вторичное индексирование и мощный поиск по содержимому хэшей а-ля эластик — c агрегацией, лексикой и т.д.
JSON — хранит бинарно, поддерживает Path и вторичное индексирование с поиском по множеству ключей.
И ещё time series, графы, гео,…
Да для любых «плоских» (id и пары ключ: значение) неизменяемых данных (удаляемых «с хвоста») — отличная штука. А ещё в стримах есть группы воркеров с пометками получили-обработали, что позволяет делать эффективную оркестровку с распараллеливанием обработки, например.
Как я понимаю, «нельзя просто так взять», и сагрегировать :)
Например — можно во внешней структуре (в приложении, или в Redis sorted set, если сохранить надо) создать список интервалов, потом для каждого в стриме взять диапазон и суммировать. Можно прямо в Редисе на lua скриптик написать (но тогда для много-данных лучше по интервалу за раз, он блокирующий).
Поиск — в момент, подсчёт — в памяти, так что д.б. недолго. Ну, для lua или UDS коннекта, без накладных на сеть.
Для оценки числа уников есть отдельные структуры (см. loglog). В принципе, Redis — штука отличная по скорости, но много ручной работы :)
Пожалуйста, не используйте в Redis структуру List для сообщений. Это древний механизм чтения "из стека с блокировкой", не надо так (с)
В Redis уже давно есть publish / subscribe для рассылки сообщений в каналы подписчикам (сообщения не хранятся).
И уже года 4 как (с версии 5, текущая - 7) есть механизм Stream, функциональный аналог топиков Кафки. С хранением сообщений, чтением разными группами одного стрима с load balancing внутри группы, отдельным подтверждением обработки сообщения (ack), сбором полученных и не обработанных "потеряшек" и т.д. В результате получается очень быстрый и почти не требующий настроек брокер сообщений.
Кроме того, кроме самого Redis есть продукт Redis Stack от тех же авторов с кучкой очень полезных расширений (JSON storage с индексами и поиском по множеству ключей, например). Плюс админка :)
Обфускация не преодалевает блокировки. Обфускация маскирует источник трафика, что в случае "VPN против блокировок" вот совсем не нужно обычному юзеру.
Для преодоления блокировок нужно маскировать трафик под стандартные варианты и вовремя менять адреса точек подключения, доставляя свежие неблокируемыми способами. Плюс некоторые дополнительные трюки, если это Китай :)
Кстати, ещё момент — все 3 модуля, указанные в статье как Redis Enterprise, доступны и в виде open source — собираются и подключаются.
Единственный минус тут — нет готового докера со всеми батарейками сразу, или качаешь докер с редисом плюс один из них, либо голый редис и собирать и включать плагины.
1. Key-value — можно использовать и так, но гораздо чаще key используется для доступа к более сложным структурам данных внутри value, про которых тут написано мало: стеки, хэши, хэш + индекс, stream,… Redis действительно хранилище структур, а не значений.
2. Забыт stream — крайне полезная и эффективная структура, может т.ч. использоваться для логов и гарантированной доставки сообщений — готовая основа для оркестровки групп воркеров с балансировкой нагрузки из коробки, например.
3. Несколько open source плагинов от той же команды, фактически части Redis:
Search — вторичное индексирование и мощный поиск по содержимому хэшей а-ля эластик — c агрегацией, лексикой и т.д.
JSON — хранит бинарно, поддерживает Path и вторичное индексирование с поиском по множеству ключей.
И ещё time series, графы, гео,…
И зря — есть ack и фактически load balancer. Фактически zero administration и предельно шустро. Но рридется повозится — готовых фреймворков вроде нет.
Например — можно во внешней структуре (в приложении, или в Redis sorted set, если сохранить надо) создать список интервалов, потом для каждого в стриме взять диапазон и суммировать. Можно прямо в Редисе на lua скриптик написать (но тогда для много-данных лучше по интервалу за раз, он блокирующий).
Поиск — в момент, подсчёт — в памяти, так что д.б. недолго. Ну, для lua или UDS коннекта, без накладных на сеть.
Для оценки числа уников есть отдельные структуры (см. loglog). В принципе, Redis — штука отличная по скорости, но много ручной работы :)