Проблемы с размером сообщения RabbitMQ - PullRequest
Новая
       90

Проблемы с размером сообщения RabbitMQ

0 голосов
/ 22 октября 2018

Мы использовали RabbitMQ в качестве брокера.Он находится между нашим клиентом, написанным на Go с NGINX, и сервером API.Мы успешно использовали его до сих пор.Размер используемого нами сообщения увеличился до ~ 20 МБ.Отправка этого большого сообщения постоянно вызывает следующую ошибку:

= ОТЧЕТ ОБ ОШИБКАХ ==== 20 октября 2018 года :: 11: 17: 59 === Ошибка в процессе <0.21106.0> вкл.узел 'rabbit @ pc11213' со значением выхода: {[{reason, {badmatch, {more, << 8001224 bytes >>, {http_req, # Port <0.99287>, ranch_tcp, keepalive, <0.21106.0>, << 4байты >>, 'HTTP / 1.1', {{127,0,0,1}, 58904}, << 9 байтов >>, неопределенный, 15672, << 39 байтов >>, неопределенный, << 0 байтов >>, [], [{exchange, << 12 байтов >>}, {vhost, << 3 байта >>}], [{<< 4 байта >>, << 15 байтов >>}, {<< 10 байтов>>, << 18 байтов >>}, {<< 14 байтов >>, << 8 байтов >>}, {<< 13 байтов >>, << 26 байтов >>}, {<< 12 байтов >>, << 16 байтов >>}, {<< 15 байтов >>, << 4 байта >>}], [{<< 14 байтов >>, 20432940}, {<< 17 байтов >>, [<< 8байты >>]}, {<< 6 байтов >>, не определено}, {<< 12 байтов >>, {<< 11 байтов >>, << 4 байта >>, []}}, {<< 17 байтов>>, не определено}, {<< 13 байт >>, не определено}, {<< 19 байт >>, не определено ...

  • просмотр сетевого трафика с помощью Wireshark показывает, чтосервер отправляет ответ 500 в середине потока передачи TCP, отправленного клиентом, которыйуказывает, что сервер не может справиться с входящими данными

Мы используем конечную точку управления HTTP и плагины: 

=INFO REPORT==== 19-Oct-2018::14:28:44 === Server startup complete; 6 plugins started.
  * rabbitmq_management
  * rabbitmq_web_dispatch
  * rabbitmq_management_agent
  * cowboy
  * cowlib
  * amqp_client

Мы попытались изменить конфигурацию сервера rabbitMQ / cowboy на noнапример, 

[{rabbitmq_management,
   [{listener, [{port,        15672},
                {cowboy_opts, [{ max_request_line_length, 16000 },{max_keepalive, 1000}]}
               ]}
   ]
}].
  • значение по умолчанию max_request_line_length было 8000 -> увеличено до 160000 как я могу быть уверен, что эти параметры действительно применяются?
  • также изменяет требование.Header.Set («Content-Type», «multipart / form-data») не помогли клиенту go

Поэтому мы считаем, что нам нужно либо отойти от rabbitMQ, либо использовать какой-то другойпротокол с другим плагином.

Мы считаем, что rabbitMQ не должен ограничиваться размером сообщения.Мы не будем пытаться ссылаться на полезную нагрузку в сообщении.Любые предложения о том, как мы можем увеличить допустимый размер сообщения?

Редактировать: Мы попытались внести дополнительные изменения в настройки ковбоя: 

{rabbitmq_management,
     [{cors_allow_origins,[]},
      {cors_max_age,1800},
      {http_log_dir,none},
      {listener,
          [{port,15672},
           {cowboy_opts,
               [{compress,true},
                {max_request_line_length,160000},
                {max_keepalive,1000},
                {idle_timeout,120000},
                {inactivity_timeout,120000},
                {request_timeout,120000}]}]},
      {load_definitions,none},
      {management_db_cache_multiplier,5},
      {process_stats_gc_timeout,300000},
      {stats_event_max_backlog,250}]},

, которые привели к той же ошибке:

2018/10/24 16:31:06 Размер списка файлов: 20431558 2018/10/24 16:31:06 Извлеченный pid: 20. # 2018/10/24 16:31:07 сообщение http://derived: # @ localhost: # / api / exchanges /% 2F / производный-обмен / публикация : net / http: HTTP / 1.x транспортное соединение разорвано: запись tcp 127. # ->127. #: запись: сброс соединения по пиру

1 Ответ

0 голосов
/ 23 октября 2018

похоже ошибка вводит в заблуждение.в идеале rabbitmq не должен ограничивать размер сообщения.Но HTTP API может иметь ограничения.

RabbitMQ (фактически любое решение для организации очередей) не идеально подходит для обмена сообщениями большого размера.Вместо этого сохраните сообщение большого размера в хранилище объектов (AWS s3) и опубликуйте метаданные хранимых объектов в очереди.

Другие параметры ...

  1. Попробуйте использовать AMQP для обмена сообщениями большого размера с RabbitMQ.

  2. Попробуйте увеличить cowboy_opts -> request_timeout (миллисекунды)). 

           {cowboy_opts, [{compress, true},
                      %% 120 seconds
                      {idle_timeout,      120000},
                      {inactivity_timeout,120000},
                      {request_timeout,   120000}]}
      ]}
...