История изменений

Исправление Deleted, 17.02.17 19:03 (текущая версия) :

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

Синхронный код приведет к тому что у тебя кончится лимит потоков, потом заполнится очередь - и только после этого код отправляющий сообщения (и то в очередь) узнает что там что-то не так. Вотчдог скажет - «микросервис испортился» и перезапустит его, ведь это нормально для микросервисов! И вся пачка обрабатываемых сообщений похерится.

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

Исходная версия Deleted, 17.02.17 19:00:

Начало хорошее, а вот «типа в асинхронном коде очереди не нужны.» - не верно. Асинхронность это не «дернуть коллбек вместо метода», это «проектировать с учетом того что результат может быть, может быть с ошибкой, а может истечь таймаут и не только» - и тогда оказывается, что нельзя тупо сделать «стопицот потоков» или «жирную очередь», а надо прорабатывать механизмы диагностики и отправки оповещения наверх, источнику сообщений, чтобы источник не слал сообщения.