Все схемы с fire and forget должны: 1) использовать кольцевой буффер или другой механизм добровольной потери отправляемых данных. 2) Обязательно поддерживать механиз backpressure для оной добровольной потери данных.
Обычный кольцевой буффер сообщений с tcp транспортом эту проблему решает.
Если используется что-то другое (пул tcp-воркеров, udp) - нужно городить свою версию backpressure, иначе операторы будут сильно негодовать.
Современные быстрые языки (node/go/rust) могут генерировать сообщений достаточного для полного saturation 10G линка. Это может быть сообщение, например, о том, что в числе найдена запятая вместо точки в конфиге. И не факт, что вся инсталляция готова пожертвовать 10G линком ради этого сообщения, повторяемого в loop {} в микросервисе для экспериментальных стикеров.
Простыми словами: если кто-то шлёт что-то в режиме fire and forget, то для получающего это может быть больно и много (полностью утилизированный линк в 10G из-за опечатки в коде, например). Решение - механизм, который тормозит отправку таких сообщений.
Варианты торможения: 1) Тормозится приложение (ожидает буфферизованного вывода) 2) Сообщения теряются как только получатель начинает высказывать недовольство.
Если этого не сделать, то приложению хорошо, а инфраструктуре плохо, причём в моменты, когда этого как раз лучше не делать (например, во время аварии).
понял надо подумать как это применимо к нашей ситуации (хотя я надеюсь возвращаться туда не придется, проект реально проклятый, жаль что это сраная оборонка и нельзя в деталях похвастаться степенью его идиотизма)
у нас ситуация была чуть другая - даже близко не хайлоад в плане "насыщения интерфейса". если выключить логи то рабочих сообщений единицы в секунду, но жесткая внешняя тактировка всей системы
а семантика потери сообщения определена очень плохо (самый нормальный вариант - делать вид что ничего не произошло)
и я вот уже в самом конце проекта понял, что и fire & forget, и квитанции были ошибкой. бессмысленное усложнение, и в итоге обе фичи которые позиционировались как важные, оказались совершенно бессмыслены
важным было бы выделить логгинг в отдельную инфраструктуру, чтобы сообщения лога никогда не могли конкурировать в одном канале/потоке с рабочими сообщениями, но в команде было слишком много рокстаров и слишком мало времени
Comments 5
1) использовать кольцевой буффер или другой механизм добровольной потери отправляемых данных.
2) Обязательно поддерживать механиз backpressure для оной добровольной потери данных.
Обычный кольцевой буффер сообщений с tcp транспортом эту проблему решает.
Если используется что-то другое (пул tcp-воркеров, udp) - нужно городить свою версию backpressure, иначе операторы будут сильно негодовать.
Современные быстрые языки (node/go/rust) могут генерировать сообщений достаточного для полного saturation 10G линка. Это может быть сообщение, например, о том, что в числе найдена запятая вместо точки в конфиге. И не факт, что вся инсталляция готова пожертвовать 10G линком ради этого сообщения, повторяемого в loop {} в микросервисе для экспериментальных стикеров.
Reply
Reply
Простыми словами: если кто-то шлёт что-то в режиме fire and forget, то для получающего это может быть больно и много (полностью утилизированный линк в 10G из-за опечатки в коде, например). Решение - механизм, который тормозит отправку таких сообщений.
Варианты торможения:
1) Тормозится приложение (ожидает буфферизованного вывода)
2) Сообщения теряются как только получатель начинает высказывать недовольство.
Если этого не сделать, то приложению хорошо, а инфраструктуре плохо, причём в моменты, когда этого как раз лучше не делать (например, во время аварии).
Reply
надо подумать как это применимо к нашей ситуации (хотя я надеюсь возвращаться туда не придется, проект реально проклятый, жаль что это сраная оборонка и нельзя в деталях похвастаться степенью его идиотизма)
у нас ситуация была чуть другая - даже близко не хайлоад в плане "насыщения интерфейса". если выключить логи то рабочих сообщений единицы в секунду, но жесткая внешняя тактировка всей системы
а семантика потери сообщения определена очень плохо (самый нормальный вариант - делать вид что ничего не произошло)
и я вот уже в самом конце проекта понял, что и fire & forget, и квитанции были ошибкой. бессмысленное усложнение, и в итоге обе фичи которые позиционировались как важные, оказались совершенно бессмыслены
важным было бы выделить логгинг в отдельную инфраструктуру, чтобы сообщения лога никогда не могли конкурировать в одном канале/потоке с рабочими сообщениями, но в команде было слишком много рокстаров и слишком мало времени
Reply
Leave a comment