d'Ivan

Используй упорядоченные множества

Добавлено:
Другой вариант - хранить в ключах с указанием истечения времени.

Могу ли я теперь найти все записи пользователя по маске например refresh:userId * ?

в случае автоматического истечения проверять старые не придётся.

Для "общения" серверов между собой можно использовать WebSocket, gRPC, HTTP и много чего ещё. Если они в одной подсети, то это значительно упрощает их взаимодействие.
Сервер в роли диспетчера может отправлять задачи и контролировать их выполнение: отправить задачу с её идентификатором, а при получении ответа записать в СУБД, что задача Х выполнена. Там же и проверить, что если все задачи подсерверов выполнены, то перейти к следующему этапу.

Redis - это хранилище ключ-значение. Ключ надо знать заранее. Похоже, надо было использовать JSON вместо набора

users:boris:*

А если делать через одно мягкое место, то бери SCAN

RedisInsight, например

Официальный источник: https://redis.io/docs/getting-started/installation...

scan <cursor> MATCH user:* COUNT 100
вместо <cursor> выставить 0 и дальше изменять согласно полученному курсору.
https://redis.io/commands/scan/

С помощью модуля RediSearch можно так.
https://redis.io/docs/stack/search/reference/query...

Наверное, при замере смешано время запроса к Redis и обработки данных.

Redis проектирована для других целей: мы должны знать ключ и по нему можно быстро найти значение (1 ключ - 1 значение).
Команда KEYS работает медленно. Вместо нее рекомендуется использовать SCAN.
Если сценарий использования другой (не 1:1), то стоит использовать реляционную СУБД с индексом по искомой колонке.

MongoDB хранит по ключу документ (структуру данных), а Redis - просто набор байтов. Соответственно, последний не умеет извлекать данные из тех байтов. Для этого приложение должно распаковать их.
И с запросами к БД также есть разница.

Что-то мне подсказывает, что Redis не подходит для этих целей.
И сомневаюсь, что этот "очень слабый ПК" настолько слаб, что ему трудно выполнить сортировку при получении данных.

Что указано в общем volumes:?
Должно быть типа

volumes:
  data-volume:

Заменить restart: always на restart: unless-stopped.

RPOPLPUSH mylist mylist

Попробуй заново установить
https://github.com/igbinary/igbinary
Разделы: How to use, Installing.

За кодировку отвечает клиент, взаимодействующий с Redis - а это spring boot data redis, у которого под капотом Lettuce.

1. Проверьте в документации, не отвечает ли за кодировку строк некоторый параметр при соединении.
2. Попробуйте занести в ключ foo значение, содержащее кириллицу, а затем проверить хранимое содержимое при помощи клиента redis-cli. Если там хранится простая строка, а не какой-то особый формат, то будет видно корректно ли само значение.

Попробуй так:

ports:
     - "6379:6379"

Redis, насколько мне известно, имеет лишь статичные ключи. То есть "A:B:C:D" это верный ключ, по которому можно найти одно единственное значение.
Можно по ключу записывать хэш список. HGET/HSET.

Тогда Redis должен вернуть все ключи по такой маске (*:B*:*)

Похоже на команду SCAN. Она как раз по маске ищет ключи.
Но этот случай подходит натурально для использования реляционных СУБД.

Может ли Redis гарантировать сохранность данных и их доступность?

Я рассматриваю Redis как быстро восстанавливающийся из snapshot кэш. С некоторой вероятностью данные будут сохранены (негарантированно). Данные сбрасываются периодически в виде дельта.
https://redis.io/topics/persistence

Можно ли, к примеру не хранить данные вроде категорий в основной БД а всегда использовать Redis для их хранения?

Можно, но не советую использовать её как основную СУБД. Хотя она хорошо масштабируется, оперативная память намного дороже SSD. В результате нужно будет платить счета за сервера с большим объемом памяти со множеством экземпляров Redis.
https://stackoverflow.com/a/42677671

для чего редис вообще может пригодиться.

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