我们一直在使用RabbitMQ作为经纪人。它位于我们使用NGINX用Go语言编写的客户端和API服务器之间。到目前为止,我们已经成功使用了它。我们正在使用的消息大小已增加到〜20mb。始终发送此大消息会导致以下错误:
=错误报告==== 2018年10月20日:: 11:17:59 ===节点'rabbit @ pc11213'上的进程<0.21106.0>中的错误,具有退出值: {[{原因,{不良匹配,{更多,<< 8001224 字节>>,{http_req,#Port <0.99287>,ranch_tcp,keepalive,<0.21106.0>,<< 4 位元组>>,'HTTP / 1.1',{{127,0,0,1},58904},<< 9 字节>>,未定义,15672,<< 39字节>>,未定义,<< 0 字节>>,[],[{交换,<< 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 字节>>,未定义...
我们正在使用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 /牛仔服务器配置更改为无用。
[{rabbitmq_management,
[{listener, [{port, 15672},
{cowboy_opts, [{ max_request_line_length, 16000 },{max_keepalive, 1000}]}
]}
]
}].
所以我们的感觉是我们要么需要脱离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/derived-exchange/publish: net / http:HTTP / 1.x传输连接断开:写入tcp 127。#-> 127.#:写:对等连接重置
答案 0 :(得分:1)
看起来错误是令人误解的。理想情况下,rabbitmq不应限制邮件大小。但是HTTP API可能有限制。
RabbitMQ(实际上是任何排队解决方案)都不适合交换大型消息。而是将大型消息存储在对象存储(AWS s3)中,并将存储的对象元数据发布到队列中。
其他选项...
尝试增加cowboy_opts-> request_timeout(毫秒)。
{cowboy_opts, [{compress, true},
%% 120 seconds
{idle_timeout, 120000},
{inactivity_timeout,120000},
{request_timeout, 120000}]}
]}