Aidan 大家好,今天小编来为大家解答以下的问题，关于rabbitmq github，rabbitmq基础配置中文说明文档这个很多人还不知道，现在让我们一起来看看吧！
本文目录
rabbitmq压力测试结果rabbitmq基础配置中文说明文档android 进程间通信 rabbitmqrabbitmq日志异常处理rabbitmq压力测试结果 性能相关情况
集群稳定性
集群的高用性
3个节点，节点服务器均为4核8G
每个节点均为磁盘节点
使用镜像队列
rabbitmq-perf-test
PerfTest是一个基于Java客户端的吞吐量测试工具，可以将其配置为模拟基本工作负载和更高级的工作负载。PerfTest还有一些额外的工具，可以生成输出的HTML图形。
RabbitMQ集群可能受到多种因素的限制，从基础架构级别的约束（例如，网络带宽）到RabbitMQ配置和拓扑，再到发布和使用的应用程序。PerfTest可以演示节点或节点集群的基准性能。
https://rabbitmq.github.io/rabbitmq-perf-test/stable/htmlsingle/#basic-usage
https://github.com/rabbitmq/rabbitmq-perf-test/blob/master/html/README.md
跑统计：bin/runjavacom.rabbitmq.perf.PerfTestMultihtml/test1/spec.jshtml/test1/result.js
起服务看结果：bin/runjavacom.rabbitmq.perf.WebServer 服务器IP地址:8080/test1/result.html
一开始进行单场景脚本测试时，发送速率也基本维持在35k/s左右，无法往上涨；开启多场景多脚本同步进行施加压力之后，发送速率也无法上升，反而一直在降，同时压测机器的负载也很高，性能跟不上。调整升级压测机器后，当我们多场景多脚本进行施压时，发送速率依旧变化不大，这是因为rabbitmq有相应的流控机制：
服务端默认配置是当内存使用达到40%，磁盘空闲空间小于50M，即启动内存报警，磁盘报警；报警后服务端触发流控（flowcontrol）机制。
一般地，当发布端发送消息速度快于订阅端消费消息的速度时，队列中堆积了大量的消息，导致报警，就会触发流控机制。
触发流控机制后，RabbitMQ服务端接收发布来的消息会变慢，使得进入队列的消息减少；
与此同时RabbitMQ服务端的消息推送也会受到极大的影响，测试发现，服务端推送消息的频率会大幅下降，等待下一次推送的时间，有时等1分钟，有时5分钟，甚至30分钟。
一旦触发流控，将导致RabbitMQ服务端性能恶化，推送消息也会变得非常缓慢；
调整测试脚本，增大生产者的并发数量到1000，5个队列，50个消费者，此时rabbitmq节点1的负载被打满；然后依次不停降低生产者和消费者的并发数量，直至生产者与消费者均只为30的场景，发现rabbitmq节点1服务器的cpu负载均很高，此时发现rabbitmq节点1服务器的cpu资源几乎都被四个线程也即rabbitmq的调取器线程占用，通过调整rabbitmq的调度器线程数量，我们发现发现速率以及服务器cpu负载有一定的变化，rabbitmq单节点的瓶颈在于其调度器的线程数：
4个线程全打开时，发送速率限制在了35k/s，此时空闲的cpu最大不到10%
打开3个调度器线程时，发送速率限制在25k/s，此时空闲的cpu最大为25%
打开2个调度器线程时，发送速率限制在20k/s，此时空闲的cpu最大为30%
因此，我们可以通过以下措施来提升rabbitmq的服务性能：
我们应当尽量避免触发rabbitmq的流控机制，要做好数据设计，使得发送速率和接收速率保持平衡，而不至于引起服务器堆积大量消息，进而引发流控。通过增加服务器集群节点，增加消费者，来避免流控发生，治标不治本，而且成本高。
如果当前的性能达不到业务要求时，可以升级服务器，将服务器由4核升级到8核，增加rabbitmq的调度器线程数量，来提升性能。
1个节点，节点内存为3G，只发布不消费，1个队列，10个消费者，生产速率上限约为60k/s，发送速率为0时是触发了rabbitmq的流控机制
1个节点，节点内存为3G，只发布不消费，1个队列，15个生产者，上限约为70k/s，发送速率为0时是触发了rabbitmq的流控机制
3、1个节点，节点内存为3G，只发布不消费，1个队列，30个生产者，上限约为60k/s，发送速率为0时是触发了rabbitmq的流控机制
1个节点，节点内存为3G，只发布不消费，1个队列，60个生产者，上限约为60k/s，发送速率为0时是触发了rabbitmq的流控机制
1个节点，节点内存为4G，只发布不消费，1个队列，30个生产者，上限约为70k/s，发送速率为0时是触发了rabbitmq的流控机制
1个节点，节点内存为4G，生产者大于消费者，1个队列，30个生产者，10个消费者，发送速率上限约为50k/s，消费速率上限约为25k/s
1个节点，节点内存为4G，生产者大于消费者，1个队列，30个生产者，15个消费者，发送速率上限约为60k/s，消费速率上限约为35k/s
1个节点，节点内存为4G，生产者大于消费者，1个队列，30个生产者，30个消费者，发送速率上限约为60k/s，消费速率上限约为35k/s
1个节点，节点内存为4G，生产者大于消费者，2个队列，30个生产者，30个消费者，发送速率上限约为60k/s，消费速率上限约为45k/s
1个节点，节点内存为4G，生产者大于消费者，1个队列，5个消费者，生产者从[1,5,10,15]逐步增加，消息体的大小由[0,1000,5000,10000,50000]逐步增加，下图的rate为发送速率
1个节点，节点内存为4G，生产者大于消费者，3个队列，5个消费者，生产者从[1,5,10,15]逐步增加，消息量由[0,1000,5000,10000,50000]逐步增加，消费速率约等于三个队列加总的发送速率
过程中队列有积压
1个节点，节点内存为4G，生产者大于消费者，1个队列，生产者和消费者数量均从[1,5,10,15,20]逐步增加，前台查看发送和接收速率基本持平，大部分在25k/s-30k/s
11、1个节点，节点内存为4G，生产者大于消费者，4个队列，生产者和消费者数量均从[1,5,10,15]逐步增加
rabbitmq基础配置中文说明文档本文为官方文档翻译版本rabbitmq3.7.5版本，原地址：https://github.com/rabbitmq/rabbitmq-server/blob/master/docs/rabbitmq.conf.example。以#开头的行为配置，key和等号以及value之间尽量保持有一个空格。以下的"默认"指的为在没有添加配置文件或者该key没有配置。
rabbitmq是使用基于tcp的amqp协议通信(如果需要ssl，可参考这里)，所以这里都是监听的tcp的端口。rabbitmq支持监听多端口，并支持指定网卡的ipv4和ipv6。格式为listeners.tcp.${name}=${value}，name可以是任意不重复的值，如：defaul、local、local_v6等。value的格式有：
(1)包括了(2)和(3)，(2)包括了(4)和(6)，(3)包括了(5)和(7)。下面对应的为其中情况的配置，按需求进行配置，不需要都配，大部分情况只配置(1)。默认的配置为listeners.tcp.default=5672
例:
接受TCP侦听器连接的Erlang进程数。一旦打开了一个使用tcp连接的套接字，它就始终保持打开状态，直至任何一方关闭它或因为一个错误而终止。在建立一个连接时，一般为每一次请求产生一个新进程，num_acceptors就是控制产生新进程的个数。假设有一个监听进程，其任务是等待传入的tcp请求。只要一个请求到达，响应该连接请求的进程就变成了接收进程。默认的配置为num_acceptors.tcp=10。
例:
AMQP0-9-1握手（socket连接和TLS握手之后）的最大时间，以毫秒为单位。
默认的配置为handshake_timeout=10000。
例:
设置为'true'以在接受一个连接时执行反DNS反查询。在rabbitmqctl中和web管理中将显示主机名称而不是IP地址。默认的配置为reverse_dns_lookups=true。
例:
开启后的效果
仅允许通过本地（即localhost）连接到代理的用户列表。如果您希望允许guest用户远程连接，则需要将其更改为loopback_users=none。
要将其他用户限制为仅限localhost的连接，请像这样执行（monitoring是用户的名称）：loopback_users.monitoring=true。默认的配置为loopback_users.guest=true。推荐设置loopback_users.guest=false。
例:
关于ssl的配置，内容比较多，参考官网。默认不配置。
选择要使用的认证/授权后端。可以配置ldap相关的设置。具体可以参考access-control。internal为由rabbitmq内部处理，默认的配置为auth_backends.1=internal。
例:
RabbitMQ具有对各种SASL认证机制的可插拔支持。服务器内置了三种这样的机制：PLAIN，AMQPLAIN和RABBIT-CR-DEMO，以及EXTERNAL可作为插件使用。您还可以通过在插件中实现rabbit_auth_mechanism行为来实现自己的身份验证机制。有关常规插件开发的更多信息，请参阅插件开发指南。默认的配置为PLAIN和AMQPLAIN。
内置的机制：
例:
有关rabbitmq-auth-mechanism-ssl插件的配置，查看:https://github.com/rabbitmq/rabbitmq-auth-mechanism-ssl
SSLhandshake超时时间,毫秒为单位。默认的配置为ssl_handshake_timeout=5000
。
例:
rabbitmq的用户的密码加密算法。修改该值只会影响新创建的用户，对应老用户需要重置密码进行更新。一般情况下不更改。默认的配置为password_hashing_module=rabbit_password_hashing_sha256。要使用SHA-512，请设置为rabbit_password_hashing_sha512。
例:
和web端的Importdefinitions、Exportdefinitions有关。好像没啥用==。
默认的用户及其权限和vhost。如果一个connect没有配置以下的配置，则使用默认值进行连接。
默认用户的tag。默认的配置default_user_tags.administrator=true。一般不需要改。
例:
heartbeat通常用来检测通信的对端是否存活（未正常关闭socket连接而异常crash）。其基本原理是检测对应的socket连接上数据的收发是否正常，如果一段时间内没有收发数据，则向对端发送一个心跳检测包，如果一段时间内没有回应则认为心跳超时，即认为对端可能异常crash了。
rabbitmq也不例外，heatbeat在客户端和服务端之间用于检测对端是否正常，即客户端与服务端之间的tcp链接是否正常。
heartbeat检测时间间隔的设置：
这里要注意的是：如果时间间隔配置为0，则表示不启用heartbeat检测。
例:
设置amqp协议最大允许的字节数。默认的配置为frame_max=131072(单位为字节，也就是128k)，注意该值不要设置过大，如果一条消息比较大(如传输文件)，可以通过PublishConfirm和ConsumerAcknowledgement机制，如设置过大，那么broker内存会容易被占完。也不要设置过小，保持在128k-1m之间。引用:使用RabbitMQ传输大文件，保证其完整性
例:
初始化时的最大字节，不知道哪里使用的。原文：Setthemaxframesizetheserverwillacceptbeforeconnectiontuningoccurs。
例:
设置每个连接的最大允许通道数量。0表示“没有限制”。默认的配置为channel_max=128。
例:
tcp连接相关的配置。尽量不要改。以下为默认的配置
例:
设置rabbitmq使用内存的阈值。有相对和绝对两种阈值。默认为vm_memory_high_watermark.relative=0.4。
队列开始将消息导出到光盘来释放内存的高水位限制的值。
例如，当vm_memory_high_watermark被设置为0.4并且该值被设置为0.5时，
可以在节点使用总可用RAM的20％时开始分页。大于1.0的值可能很危险，应谨慎使用。
一种替代方法是使用持久队列并发布消息，作为持久性。有了这个组合队列将消息更快地移动到磁盘。
另一种方法是配置队列来分页所有消息（都是持久和瞬态）到磁盘。
尽可能参阅http://rabbitmq.com/lazy-queues.html。
例:
内存使用情况报告策略。可以是以下之一，默认的配置为rss：
allocated：使用Erlang内存分配器统计信息
rss：使用操作系统RSS内存报告。这使用特定于操作系统的手段，并可能启动短暂的子进程。
legacy：使用legacy内存报告（运行时考虑使用多少内存）。这个策略相当不准确。
erlang：与legacy相同，为了向后兼容而保留
例:
根据watermarks检查内存级别。没发现具体作用。
例:
可用内存总量，不使用特定于操作系统的方式从环境中推断内存。只有当节点可用的实际最大RAM数量与节点将要推断的值不匹配时，才应使用这种方法。该值可以设置为整数个字节，或者可以以信息单位（例如“8GB”）设置。例如，当该值设置为4GB时，该节点会认为它在具有4GBRAM的计算机上运行。默认不设置该值。
例:
和vm_memory_high_watermark类似，disk_free_limit是控制硬盘的使用阈值。RabbitMQ正在存储数据的分区的磁盘可用空间限制。当可用磁盘空间低于此限制时，将触发流量控制。该值可以相对于RAM的总量或以字节或以信息单位表示的绝对值（例如"50MB"或"5GB"或"5KB"）来设置，或者，我们可以设置相对于可用RAM总量的限制。低于1.0的值可能很危险，应谨慎使用。默认为disk_free_limit.absolute=50MB。
例:
网络分裂。一种在系统的任何两个组之间的所有网络连接同时发生故障后所出现的情况。发生这种情况时，分裂的系统双方都会从对方一侧重新启动应用程序，进而导致重复服务或裂脑。由网络分裂造成的最为严重的问题是它会影响共享磁盘上的数据。默认为ignore模式。如何处理网络分裂？详细的文档可以参考官网文档
可用的模式是：
在消息中镜像同步批量大小。增加这将加快同步，但批量总大小（以字节为单位）不得超过2GiB。该设置可用于RabbitMQ3.6.0或更高版本。默认的配置为mirroring_sync_batch_size=4096(4k)。
例:
集群相关的配置，为了形成一个集群，新的（“空白”）节点需要能够发现他们的同伴。这可以使用各种机制（后端）来完成。有些机制假定所有集群成员都提前知道（例如，在配置文件中列出），其他机制是动态的（节点可以动态增删）。
内置的发现机制如下:
cluster_formation.node_type：节点类型。默认为disc。
cluster_keepalive_interval：像集群里的其他子节点发送存活消息的间隔(毫秒)。默认为cluster_keepalive_interval=10000
统计相关，与web管理插件显示有关。可配置的值如下：
例:
设置为true，以便使用HiPE预编译RabbitMQ的部分，这是Erlang的即时编译器。这会以增加启动时间为代价来提高服务器吞吐量。
您可能会看到启动时延迟几分钟的成本提高20-50％。这些数据非常依赖于工作负载和硬件。
HiPE支持可能不会编译到您的Erlang安装中。如果不是，启用此选项只会导致显示一条警告消息，启动将按正常进行。例如，Debian/Ubuntu用户需要安装erlang-base-hipe软件包。
HiPE在某些平台上完全不可用，特别包括Windows。
HiPE在17.5之前的Erlang/OTP版本中存在已知问题。HiPE强烈建议使用最新的Erlang/OTP版本。默认的配置为hipe_compile=false。
等待集群中的Mnesiatables变得可用时使用的超时。默认的配置mnesia_table_loading_retry_timeout=30000。
在等待集群中的Mnesiatables可用时，需要重试的次数。默认的配置mnesia_table_loading_retry_limit=10。
在消息的字节数中，消息将被直接嵌入到队列索引中。详情请看persistertuning。默认的配置queue_index_embed_msgs_below=4096。
是否启用后台定期强制GC为“等待”状态运行节点上的所有Erlang进程。
禁用后台GC可以减少客户端操作的延迟，保持启用状态可以减少二进制堆的RAM使用量（请参阅https://www.erlang-solutions.com/blog/erlang-garbage-collector.html）。
在尝试此选项之前，请查看内存（http://www.rabbitmq.com/memory-use.html）。
默认的配置background_gc_enabled=false，当配置为true时，可以设置gc的间隔，默认的配置为background_gc_target_interval=60000(毫秒)。
设置是否启用代理，启用后不能直连到broker。默认的配置proxy_protocol=false。
未知
有关web管理后台的配置。
查看http://www.rabbitmq.com/stomp.html。
http://www.rabbitmq.com/mqtt.html
查看https://github.com/rabbitmq/rabbitmq-amqp1.0
查看http://rabbitmq.com/ldap.html。
android 进程间通信 rabbitmqhttps://github.com/Harry-III/RabbitMQ-Android
上手了RabbitMQ？再来看看它的交换机(Exchange)吧
RabbitMQ的Java应用(1)--RabbitJavaClient使用
RabbitMQ（三）入门——RabbitMQ的五种模式和四种交换机
本例子是改编自上面的github链接
1、android端不采用轮询的方式请求服务器，有点类似推送的感觉，能即时收到服务器的信息
1、将rabbitmq放到单独的进程中
2、重新定义一些方法
1、在多进程中通过message.replyTo方法将通信方式传递给Service端
2、rabbitmq的管道创建是要在线程里面，否则会报错
3、如果有2个用户都采用一个管道(管道名A)，当服务器将信息都输送到A管道后，哪个用户处理消息快，哪个用户得到的信息就多，所以最好就是每个用户一个管道
本项目github
RabbitMQClient.java
RabbitMQUtil.java
rabbitmq日志异常处理openstacknewton版本
rabbitmq3.6.5
pika0.10.0
rabbimq日志报错信息：”Missedheartbeatsfromclient,timeout:60s”
最终heartbeat选取原则：rabbitmq建立连接时会从服务端和客户端的配置中挑选最小值作为该连接的心跳超时时间。
rabbitmq在3.5.5以前的版本heartbeat默认为580s，3.5.5之后才改为60s，这样就就出现了很多这样问题。
因此，可考虑修改heartbeat，改为200s甚至更大的值，这会很大程度上减少该问题发生。
方案1虽然可以很大程度避免问题出现，但总归不能完全消除。
因此可以考虑改用tcp的keepalive机制：
3.配置linux系统的tcpkeepalive参数，由传输层做tcp连接保活检测，效率更高，且与应用层服务互不干扰，但灵活性差（内核级别配置，全局生效）。配置方式可参考：https://blog.csdn.net/dackchen/article/details/97535297
主要是三个内核配置项，一个参考值：
参考链接：
https://www.cnblogs.com/mingao/p/10626297.html
http://doc.okbase.net/quqi99/archive/230499.html
https://github.com/pika/pika/pull/956
好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！
