Size: a a a

2021 February 01

DR

Dmitry Russ (Aleksan... in pro.elixir
(Бред какой-то - но код Ecto выглядит, что такое есть в коде)
источник

DR

Dmitry Russ (Aleksan... in pro.elixir
А, разобрался, но ошибка весёлая. 🙂
источник

DR

Dmitry Russ (Aleksan... in pro.elixir
Ситуация из тех, когда много лет не трогал ecto 🙂 И снова активно его используешь.
источник

DI

Dmitry Ivanov in pro.elixir
Хехе, главное разобрался
источник

T

Tharin in pro.elixir
Dmitry Russ (Aleksandrov)
А, разобрался, но ошибка весёлая. 🙂
Ну напиши хоть объяснение :)
источник

T

Tharin in pro.elixir
Dmitry Russ (Aleksandrov)
Ситуация из тех, когда много лет не трогал ecto 🙂 И снова активно его используешь.
А что вы использовали для маппинга данных?
источник

B

Bogdan in pro.elixir
Źmićer Rubinštejn
Почему вообще появилась идея использовать rabbit mq для такого взаимодействия?
1. Чтобы горизонтально масштабировать, плюс так сложилось, что мне когда есть очередь проще понимать, что происходит в системе в целом чем когда рест апи. Может я какой-то испорченый :)
2. Читал гайд по практикам к RMQ там было сказано,  что очередь лагает если сгружать туда все поэтому желательно держать ее практически пустой всегда. Это не так?
3. Kafka мне говорили сложно в плане менеджмента и поддержки.  RMQ/NATS/Google Pub/Sub - примерно такие я слышал рекомендации.
источник

IK

Ihor Katkov in pro.elixir
> Читал гайд по практикам к RMQ там было сказано,  что очередь лагает если сгружать туда все поэтому желательно держать ее практически пустой всегда. Это не так?
источник

IK

Ihor Katkov in pro.elixir
не замечал
источник

AL

Anton Lapshin in pro.elixir
если на стороне потребителей не будет ограничений на приём, потребители будут захлёбываться в потоке. может, это имелось в виду? самому rmq в целом пофиг, ну до тех пор, пока он все ресурсы не выжрет, в таком ключе много что лагать может
источник

LL

Lama Lover in pro.elixir
Bogdan
1. Чтобы горизонтально масштабировать, плюс так сложилось, что мне когда есть очередь проще понимать, что происходит в системе в целом чем когда рест апи. Может я какой-то испорченый :)
2. Читал гайд по практикам к RMQ там было сказано,  что очередь лагает если сгружать туда все поэтому желательно держать ее практически пустой всегда. Это не так?
3. Kafka мне говорили сложно в плане менеджмента и поддержки.  RMQ/NATS/Google Pub/Sub - примерно такие я слышал рекомендации.
Если у тебя один продьюсер, то ничего масштабировать не получится, он будет бутылочным горлышком
Если у тебя несколько продьюсеров, то гарантировать отсутствие дублей на стороне продьюсера будет очень сложно

Самый простой вариант — добавить гарантию того, что одно и то же сообщение попадёт в один и тот же консьюмер (например, шардирование) и, как сказал @maxlapshin , читать идемпотентно, запоминая прочитанные сообщения (не обязательно все, можно очищать старые запо

И вообще, зачем тут кролик. Сделать пулл модель — консьюмеры делают REST запрос в продьюсер когда они ничего не обрабатывают (или обработка вот-вот кончится), REST это совсем не дорого, особенно учитывая что практически любой http-клиент в наше время умеет держать соединение и инициировать его с tcp fast open
источник

ŹR

Źmićer Rubinštejn in pro.elixir
В таких задачах очевидно не идет разговор о скорости
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Если нужон риалтайм - broadway нужон с kafka/sqs
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Rabbit - это про бизнес
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Вообще если бы я скрпил 1кк страниц и у меня 5% повторений было бы - я бы забил наверное
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Идемпотентность обеспечивается на выходе из консьюмера когда пишешь в базу
источник

B

Bogdan in pro.elixir
Anton Lapshin
если на стороне потребителей не будет ограничений на приём, потребители будут захлёбываться в потоке. может, это имелось в виду? самому rmq в целом пофиг, ну до тех пор, пока он все ресурсы не выжрет, в таком ключе много что лагать может
https://www.cloudamqp.com/blog/2018-01-08-part2-rabbitmq-best-practice-for-high-performance.html

“eep your queue short (if possible)
To get optimal performance, keep queues as short as possible. Longer queues require more processing overhead. We recommend that queues always stay around 0 for optimal performance.”
источник

AL

Anton Lapshin in pro.elixir
Bogdan
https://www.cloudamqp.com/blog/2018-01-08-part2-rabbitmq-best-practice-for-high-performance.html

“eep your queue short (if possible)
To get optimal performance, keep queues as short as possible. Longer queues require more processing overhead. We recommend that queues always stay around 0 for optimal performance.”
я думаю, тут речь уже о каких-то огромных значениях. но, опять же, если так критична скорость обработки большого числа сообщений, возможно, rmq не лучший выбор под этот кейс. выше уже всё сказали на эту тему как раз..
источник

B

Bogdan in pro.elixir
Anton Lapshin
я думаю, тут речь уже о каких-то огромных значениях. но, опять же, если так критична скорость обработки большого числа сообщений, возможно, rmq не лучший выбор под этот кейс. выше уже всё сказали на эту тему как раз..
Понял. Нет не критична скорость.
источник

B

Bogdan in pro.elixir
Lama Lover
Если у тебя один продьюсер, то ничего масштабировать не получится, он будет бутылочным горлышком
Если у тебя несколько продьюсеров, то гарантировать отсутствие дублей на стороне продьюсера будет очень сложно

Самый простой вариант — добавить гарантию того, что одно и то же сообщение попадёт в один и тот же консьюмер (например, шардирование) и, как сказал @maxlapshin , читать идемпотентно, запоминая прочитанные сообщения (не обязательно все, можно очищать старые запо

И вообще, зачем тут кролик. Сделать пулл модель — консьюмеры делают REST запрос в продьюсер когда они ничего не обрабатывают (или обработка вот-вот кончится), REST это совсем не дорого, особенно учитывая что практически любой http-клиент в наше время умеет держать соединение и инициировать его с tcp fast open
Один продюсер можно вертикально масштабировать + можно убирать из стейта уже обработанные данные которые прилетают обратно от консумиров, и не давать ему тем самым разростаться.
источник