Я в своё время наплясался с кластерным кроликом, и теперь без человека с конкретным опытом внедрения и эксплуатации кроличьего кластера на продакшене за такое не возьмусь.

к sql так же относится

собственно, куда деньги можно нести :-)

хорошо, когда понимаешь чем между собой различаются redis pubsub, redis streams и amqp.
плохо, когда не :)

хз редис очень дешёвый per request, но редко у кого нагрузки такие есть чтобы его использовать

Зависит от топологии кластера. Если он шардированный, то вроде передача идёт между мастерами шардов, и потом внутри шардов. А поскольку у нас fault tolerance, то внутри шардов каждый сервер висит на своём свитче.

https://aphyr.com/posts/283-jepsen-redis


In this post, we demonstrate Redis losing 56% of writes during a partition.

Вот по поверхностному прочтению складывается ощущение, что pubsub не шардируется, в том то и беда.

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

Ну кроме "The cluster bus is also used in order to propagate Pub/Sub messages across the cluster" в описании кластера и диалога "How clustering works with pub/sub, PubSub works by broadcasting every publish to every other Redis Cluster node?" - "According to pub sub - yes, every message goes everywhere and it limits"

Вообще если планируется поток в 10к+ сообщений в секунду (как в том issue на гитхабе), то наверное Редис уже не оптимальный вариант,  лучше всё же Кафку расчехлить.

В понедельник спрошу у девопсов.

а тебе ссылка на aphyr’а не понравилась?)

Not really. It’s less likely to break horribly, but it’ll still break. Don’t use it as a lock service. Don’t use it as a queue. Don’t use it for any data you can’t reconstruct automatically. Redis is a cache. A terrific one with lovely data structures, but still a cache. Plan for its contents to be out of date, for updates to be lost, etc.

Да даже если выкинуть хайлоад, я не очень понимаю как оно будет работать.
У нас есть архитектура без проксирования (это заявляется), сообщения раскидывает клиент, куда записал - туда записал (ну, по хэшу). С просто почитать по ключу все понятно - прочитал и ладно, если что тебя средиректит нода на правильную.
Но в pub/sub получается, что сервер пушит сообщения в коннект клиенту, то есть или тебе надо чтобы клиент держал открыте коннекты ко всем нодам вообще всегда (мы же заранее не знаем куда запишут следующее сообщение), плюс траблы с синхронизацией, либо (как судя по всему сделано) ты держиш коннект к любой ноде и все ноды имеют у себя копию pubsub топика и по сути это одна такая большая жирная нода, но в этом случае непонятно как оно себя будет вести с репликой. Ну то есть потерять наверно сложно будет, но вот сдублировать при сбоях - легко.

Я вот читаю. Но вдруг у Сергея есть тайные знания. Точнее у его девопсов:)

Но вообще - там такой, неоднозначный топик. Я в целом понимаю риски и в целом как работает сентинел с редисом и вот это все. Но вот про pubsub ваще непонятно)

я хз как у редиса pubsub, но думаю, что так же как у pg:
если читателя на твое сообщения не было, сообщение уходит в /dev/null

ну и длина сообщения наверняка ограничена

Так, у меня тут 3 вакансии - мобильщик андроид, бэкендщик и менеджер, все в мою команду заниматься перфомансом мобильных приложений, можно ремоут из стран, где есть офис спотифая (Россия тоже). Плюсы: спотифай, работа со мной, универсальные навыки, которые потом можно применять в любой компании. Минусы: нет. Зарплата зависит от страны и на какой левел пройдете интервью, для сравнения у меня 6500€, кроме зарплаты еще стоки и много других плюшек. Если ответите на простой вопрос, напишу реферрал. Ссылки на все три вакансии в этом посте https://www.linkedin.com/posts/tynja_we-just-launched-80-markets-and-36-additional-activity-6786217800206733312-YPDM

Подписка спотифай бесплатная?

У работников