- Сервер Spring Cloud Data Flow (SCDF) для Cloud Foundry v1.4.x
- Плитка службы RabbitMQ подготовлена для передачи сообщений
Развернутый поток потока данных Spring Cloud имеет процессор, который может создавать исходящие сообщения быстрее, чем нижестоящий процессор или приемник могут обрабатывать входящие сообщения. Это создает узкое место в транспорте RabbitMQ, что в конечном итоге приводит к потере сообщений.
В нашей частной облачной среде наша плитка службы Rabbit имеет настройки по умолчанию max-length=1000 и max-length-bytes=1000000. В настоящее время мы не можем изменить эти настройки, чтобы увеличить любую из этих возможностей.
Мы попытались установить значение prefetch для приложения-потребителя (я полагаю, что значение будет deployer.<appname>.rabbit.bindings.consumer.prefetch=10000), что, по-видимому, фактически увеличивает способность приложения-потребителя потреблять больше сообщений за более короткий период времени, но это будет эффективно только в ограниченных сценариях. . Если у нас есть чрезвычайно большой объем данных, проходящих через поток, мы все равно столкнемся с ограничением, при котором сообщения будут отбрасываться. В приведенном выше примере мы, кажется, увеличиваем мощность потребляющего приложения с 1000 до 11000, настроив предварительную выборку.
Мы также попытались использовать службу автоматического масштабирования, поэтому мы можем увеличить количество активных экземпляров приложения-потребителя, что также, очевидно, может увеличить его производительность. Однако это также похоже на решение проблемы с помощью пластыря, а не на использование инфраструктуры и/или сервисов, которые по своей природе способны эластично справляться с базовыми ожиданиями объема. Что, если мы не знаем конкретное время суток, когда объемы будут значительно увеличиваться, и что, если объем будет увеличиваться с такой скоростью, что пороговые значения ЦП в настройках автоматического масштабирования не могут достаточно быстро успевать за активными экземплярами, чтобы избежать потерянные сообщения?
- мы не пытались настроить службу RabbitMQ для гарантии доставки. Основываясь на документации, кажется, что легче сказать, когда сообщение не было доставлено, чем гарантировать доставку. мы не знаем, является ли это хорошим жизнеспособным вариантом, и ищем совета.
- мы не пытались реализовать какое-либо регулирование в самих наших потоковых приложениях. мы не знаем, является ли это хорошим жизнеспособным вариантом, и ищем совета.
- мы не пробовали привязывать приложения к DLQ или повторно ставить в очередь сообщения, которые не обрабатываются. мы не знаем, является ли это хорошим жизнеспособным вариантом, и ищем совета.
- мы не пытались привязать сервер SCDF к нашему собственному экземпляру службы Rabbit за пределами плиток службы Cloud Foundry. Теоретически это был бы экземпляр RabbitMQ, над которым мы могли бы лучше контролировать глубину очереди и ограничения размера байта, где мы могли бы настроить их так, чтобы они легче справлялись с нашими ожидаемыми нагрузками.
- мы не пробовали альтернативный транспортный механизм, такой как Kafka. мы не знаем, является ли это хорошим жизнеспособным вариантом, и ищем совета.
Мне было бы трудно поверить, что другие не сталкивались с проблемой аналогичного характера в этих парадигмах потоковой передачи, и мне любопытно, существует ли принятое передовое решение, или нам нужно более внимательно взглянуть на то, парадигма неправильно используется в этих ситуациях.
Наши основные требования таковы, что потеря сообщений в любом контексте потокового приложения является неприемлемой ситуацией, и нам необходимо определить лучший способ подхода к настройке нашей среды или анализу наших вариантов реализации, чтобы гарантировать, что наши реализации будут надежными и надежными при большой нагрузке.
Есть ли какие-нибудь советы от сообщества или от людей из Pivotal по этому поводу?
