Size: a a a

2021 January 31

B

Bogdan in pro.elixir
Andrey Fadeev
Почитал документацию, в разделе про reliable delivery сказано, что бывают persistent очереди и сообщения. И для них общаны гарантии доставки.

Если этого не делать, то в варианте с дедупликацией в продьюсере могут (будут) возникать сообщения которые потеряны, но он не отправит их повторно до перезапуска.
Потеря сообщений в данном случае не является проблемой.

Он сделает потом ре-диливери со следующей query из Postgres - в любом случае.

Я это затеял все внезапно, пару дней назад сообщение писал, мне указали на бэдпрактис по поводу того, что два сервиса у меня одну табличку читает))
источник

B

Bogdan in pro.elixir
Вот теперь с БД работает только один сервис,  и дальше уже по шине их пускает.
источник

B

Bogdan in pro.elixir
Потом из другой очереди принимает и грузит в базу
источник

AF

Andrey Fadeev in pro.elixir
Bogdan
Потеря сообщений в данном случае не является проблемой.

Он сделает потом ре-диливери со следующей query из Postgres - в любом случае.

Я это затеял все внезапно, пару дней назад сообщение писал, мне указали на бэдпрактис по поводу того, что два сервиса у меня одну табличку читает))
Как он сделает ре-диливери, если он пытается избегать дубликатов. Только если всю очередь вычитывать.
источник

B

Bogdan in pro.elixir
Andrey Fadeev
Как он сделает ре-диливери, если он пытается избегать дубликатов. Только если всю очередь вычитывать.
Да логично.
источник

B

Bogdan in pro.elixir
Забыл про этот важный момент 🙂
источник

B

Bogdan in pro.elixir
Но в любом случае, там три мода для ре-диливере reject, redelivery, redelivery once
источник

B

Bogdan in pro.elixir
Я не тестил еще как клиент работает на nodejs по этому вопросу.
источник

B

Bogdan in pro.elixir
У меня консумер на нем.
источник

B

Bogdan in pro.elixir
Но в Elixir все ок работало по той же схеме, с re-delivery.
источник

B

Bogdan in pro.elixir
Andrey Fadeev
Почитал документацию, в разделе про reliable delivery сказано, что бывают persistent очереди и сообщения. И для них общаны гарантии доставки.

Если этого не делать, то в варианте с дедупликацией в продьюсере могут (будут) возникать сообщения которые потеряны, но он не отправит их повторно до перезапуска.
Еще раз прочитал сообщение твое.

Вроде эти сообщения же не возвращаются к продюсеру, а просто в очередь скидываются обратно.
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Bogdan
Нет я на очередь же наоборот никак не надеюсь.

Там сейчас вот так:
1.  Запрос в Postgres.
2. Проверяет на уникальность(в стейте).
3. Закидывает в RabbitMQ.
4. По тику смотрит кол-во сообщений в очереди.
5. Подкидывает если их мало.


Если продюсер падает вместе со стейтом:

То на запуске он полностью пуржит всю очередь и грузит данные с постгри.
В таком случае дубликаты практически исключены.
Почему вообще появилась идея использовать rabbit mq для такого взаимодействия?
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Для меня всегда было очевидно что http requestresponce cycle обеспечивает back pressure из коробки
источник

ŹR

Źmićer Rubinštejn in pro.elixir
Сама идея «смотрим что там в очереди и если мало - подкладываем ещё» звучит как натягивание совы на глобус
источник

ŹR

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

ŹR

Źmićer Rubinštejn in pro.elixir
А потом уже думать что с этим делать
источник

ŹR

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

IK

Ihor Katkov in pro.elixir
Źmićer Rubinštejn
Сама идея «смотрим что там в очереди и если мало - подкладываем ещё» звучит как натягивание совы на глобус
Согласен. К тому же, rabbitmq обычно берут когда нужно гарантировать доставку, если даже сервисы упадут
источник
2021 February 01

DR

Dmitry Russ (Aleksan... in pro.elixir
Привет!

Вопрос, есть какие-то в ecto проблемы с обновлением данных не связанных с тем, что хочешь обновить?

Т.е. загружаешь без preload-а данные и хочешь добавить одну ассоциацию - а он говорит:

** (RuntimeError) attempting to cast or change association something_unrelated from FooBar that was not loaded. Please preload your associations before manipulating them through changesets

При том по совершенно не связанной ассоциации. Т.е. по той, которую обновлять не планировал
источник

DR

Dmitry Russ (Aleksan... in pro.elixir
Т.е. нужно всегда загружать preload-ы, даже если хочешь обновить поле, с ними никак не связанное, я правильно понимаю?
источник