大家好，关于rabbitmq官方中文文档很多朋友都还不太明白，不过没关系，因为今天小编就来为大家分享关于rabbitmq官方教程中文的知识点，相信应该可以解决大家的一些困惑和问题，如果碰巧可以解决您的问题，还望关注下本站哦，希望对各位有所帮助！

本文目录

rabbitmq基础配置中文说明文档Python 异步任务队列Celery 使用soulcoder——消息队列知识总结(偏向于 Kafka)零基础学Python需要从哪里开始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。

Python 异步任务队列Celery 使用在Python中定义Celery的时候，我们要引入Broker，中文翻译过来就是“中间人”的意思。在工头(生产者)提出任务的时候，把所有的任务放到Broker里面，在Broker的另外一头，一群码农(消费者)等着取出一个个任务准备着手做。这种模式注定了整个系统会是个开环系统，工头对于码农们把任务做的怎样是不知情的。所以我们要引入Backend来保存每次任务的结果。这个Backend也是存储任务的信息用的，只不过这里存的是那些任务的返回结果。我们可以选择只让错误执行的任务返回结果到Backend，这样我们取回结果，便可以知道有多少任务执行失败了。

其实现架构如下图所示：

可以看到，Celery主要包含以下几个模块：

celery可以通过pip自动安装。

broker可选择使用RabbitMQ/redis，backend可选择使用RabbitMQ/redis/MongoDB。RabbitMQ/redis/mongoDB的安装请参考对应的官方文档。

------------------------------rabbitmq相关----------------------------------------------------------

官网安装方法：http://www.rabbitmq.com/install-windows.html

启动管理插件：sbin/rabbitmq-pluginsenablerabbitmq_management启动rabbitmq：sbin/rabbitmq-server-detached

rabbitmq已经启动，可以打开页面来看看地址：http://localhost:15672/#/

用户名密码都是guest。进入可以看到具体页面。关于rabbitmq的配置，网上很多自己去搜以下就ok了。

------------------------------rabbitmq相关--------------------------------------------------------

项目结构如下：

使用前，需要三个方面：celery配置，celery实例，需执行的任务函数，如下：

Celery的配置比较多，可以在官方配置文档：http://docs.celeryproject.org/en/latest/userguide/configuration.html查询每个配置项的含义。

当然，要保证上述异步任务and下述定时任务都能正常执行，就需要先启动celeryworker，启动命令行如下:

需启动beat，执行定时任务时,Celery会通过celerybeat进程来完成。Celerybeat会保持运行,一旦到了某一定时任务需要执行时,Celerybeat便将其加入到queue中.不像worker进程,Celerybeat只需要一个即可。而且为了避免有重复的任务被发送出去，所以Celerybeat仅能有一个。

命令行启动：

如果你想将celeryworker/beat要放到后台运行，推荐可以扔给supervisor。

supervisor.conf如下：

soulcoder——消息队列知识总结(偏向于 Kafka)[toc]

分析一个消息队列主要从这几个点出来。

在后半部分主要分析了kafka对以上几点的保证。

详见下文分析重点分析。

事务支持方面，ONS/RocketMQ较为优秀，但是不支持消息批量操作,不保证消息至少被消费一次.

Kafka提供完全分布式架构,并有replica机制,拥有较高的可用性和可靠性,理论上支持消息无限堆积,支持批量操作,消费者采用Pull方式获取消息,消息有序,通过控制能够保证所有消息被消费且仅被消费一次.但是官方提供的运维工具不友好，开源社区的运维工具支持的版本一般落后于最新版本的Kafka.

目前使用的MNS服务，拥有HTTPRESTAPI,使用简单,数据可靠性高,但是不保证消息有序，不能回溯数据.

RabbitMQ为重量级消息系统，支持多协议(很多协议是目前业务用不到的),但是不支持回溯数据,master挂掉之后，需要手动从slave恢复,可用性略逊一筹.

以rcoketMQ为例，他的集群就有

第一眼看到这个图，就觉得和kafka好像，只是NameServer集群，在kafka中是用zookeeper代替，都是用来保存和发现master和slave用的。

通信过程如下:

Producer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer获取Topic路由信息，并向提供Topic服务的BrokerMaster建立长连接，且定时向Broker发送心跳。

Producer只能将消息发送到Brokermaster，但是Consumer则不一样，它同时和提供Topic服务的Master和Slave建立长连接，既可以从BrokerMaster订阅消息，也可以从BrokerSlave订阅消息。

那么kafka呢？

为了对比说明直接上kafka的拓补架构图

如上图所示，一个典型的Kafka集群中包含若干Producer（可以是web前端产生的PageView，或者是服务器日志，系统CPU、Memory等），若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干ConsumerGroup，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在ConsumerGroup发生变化时进行rebalance。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。

最骚的一个操作，消费者业务自己去保证幂等性。

换一个说法，如何保证消息队列的幂等性?

另外说一点，幂等性的保证需要在一次请求中所有链路都是幂等的，再能最终保证这次请求的幂等，比如前段按钮点击两次，后端认为都是这是两次不同的请求，当然处理成两次请求，所以说一个请求的幂等性，需要全局的幂等才能保证。

其实无论是哪种消息队列，造成重复消费原因其实都是类似的。正常情况下，消费者在消费消息时候，消费完毕后，会发送一个确认信息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除。只是不同的消息队列发送的确认信息形式不同。

例如RabbitMQ是发送一个ACK确认消息，RocketMQ是返回一个CONSUME_SUCCESS成功标志，kafka实际上有个offset的概念，简单说一下(后续详细解释),就是每一个消息都有一个offset，kafka消费过消息后，需要提交offset，让消息队列知道自己已经消费过了。

那造成重复消费的原因?，就是因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将该消息分发给其他的消费者。

如何解决?这个问题针对业务场景来答分以下几点

其实这个可靠性传输，每种MQ都要从三个角度来分析:生产者弄丢数据、消息队列弄丢数据、消费者弄丢数据。

从生产者弄丢数据这个角度来看，RabbitMQ提供transaction和confirm模式来确保生产者不丢消息。

transaction(事物机制)机制就是说，发送消息前，开启事物(channel.txSelect())，然后发送消息，如果发送过程中出现什么异常，事物就会回滚(channel.txRollback())，如果发送成功则提交事物(channel.txCommit())。然而缺点就是吞吐量下降了。

生产上用confirm模式的居多。一旦channel进入confirm模式，所有在该信道上面发布的消息都将会被指派一个唯一的ID(从1开始)，一旦消息被投递到所有匹配的队列之后，rabbitMQ就会发送一个Ack给生产者(包含消息的唯一ID)，这就使得生产者知道消息已经正确到达目的队列了.如果rabiitMQ没能处理该消息，则会发送一个Nack消息给你，你可以进行重试操作。

简单来讲confirm模式就是生产者发送请求，到了消息队列，消息队列会回复一个消息收到的应答，如果没收到，生产者开始重试。

处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。这个持久化配置可以和confirm机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个Ack信号。这样，如果消息持久化磁盘之前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。

消费者丢数据一般是因为采用了自动确认消息模式。这种模式下，消费者会自动确认收到信息。这时rahbitMQ会立即将消息删除，这种情况下如果消费者出现异常而没能处理该消息(但是消息队列那边已经认为消息被消费了)，就会丢失该消息。

至于解决方案，采用手动确认消息即可。

kafka为例

Producer在发布消息到某个Partition时，先通过ZooKeeper找到该Partition的Leader，然后无论该Topic的ReplicationFactor为多少（也即该Partition有多少个Replica），Producer只将该消息发送到该Partition的Leader。Leader会将该消息写入其本地Log。每个Follower都从Leader中pull数据。

在kafka生产中，基本都有一个leader和多个follwer。follwer会去同步leader的信息。因此，为了避免生产者丢数据，做如下两点配置

针对消息队列丢数据的情况，无外乎就是，数据还没同步，leader就挂了，这时zookpeer会将其他的follwer切换为leader,那数据就丢失了。针对这种情况，应该做两个配置。

这种情况一般是自动提交了offset，然后你处理程序过程中挂了。kafka以为你处理好了。再强调一次offset是干嘛的。

offset：指的是kafka的topic中的每个消费组消费的下标。简单的来说就是一条消息对应一个offset下标，每次消费数据的时候如果提交offset，那么下次消费就会从提交的offset加一那里开始消费。

比如一个topic中有100条数据，我消费了50条并且提交了，那么此时的kafka服务端记录提交的offset就是49(offset从0开始)，那么下次消费的时候offset就从50开始消费。

针对这个问题，通过某种算法，将需要保持先后顺序的消息放到同一个消息队列中(kafka中就是partition,rabbitMq中就是queue)。然后只用一个消费者去消费该队列。

有的人会问:那如果为了吞吐量，有多个消费者去消费怎么办？

简单来说消息的时序性也可以通过错误重试来解决。

比如我们有一个微博的操作，发微博、写评论、删除微博，这三个异步操作。如果是这样一个业务场景，那只要重试就行。比如你一个消费者先执行了写评论的操作，但是这时候，微博都还没发，写评论一定是失败的，等一段时间。等另一个消费者，先执行写评论的操作后，再执行，就可以成功。

总之，针对这个问题，我的观点是保证入队有序就行，出队以后的顺序交给消费者自己去保证，没有固定套路。

为了做到水平扩展，一个topic实际是由多个partition组成的，遇到瓶颈时，可以通过增加partition的数量来进行横向扩容。

单个parition内是保证消息有序。

订阅topic是以一个消费组来订阅的，一个消费组里面可以有多个消费者。

同一个消费组中的两个消费者，只能消费一个partition。

换句话来说，就是一个partition，只能被消费组里的一个消费者消费，但是可以同时被多个消费组消费。

如果消费组内的消费者如果比partition多的话，那么就会有个别消费者一直空闲。

kafkaapi提供了很多功能比如

生产者能指定topic和Partition来投递消息，并且还有延迟消息，事务消息等等，详见下面的api文档

http://kafka.apache.org/documentation.html#api

这个是api的中文文档

http://orchome.com/66

KakfaBroker集群受Zookeeper管理。

这里先说下

关于partition的分配，还有leader的选举，总得有个执行者。在kafka中，这个执行者就叫controller。kafka使用zk在broker中选出一个controller，用于partition分配和leader选举。

所有的KafkaBroker节点一起去Zookeeper上注册一个临时节点，并且只有一个KafkaBroker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个KafkaBroker会成为KafkaBrokerController，其他的Kafkabroker叫KafkaBrokerfollower。（这个过程叫Controller在ZooKeeper注册Watch）。

这个Controller会监听其他的KafkaBroker的所有信息，如果这个kafkabrokercontroller宕机了，在zookeeper上面的那个临时节点就会消失，此时所有的kafkabroker又会一起去Zookeeper上注册一个临时节点。

Kafka提供3种消息传输一致性语义：最多1次，最少1次，恰好1次。

最少1次(atmostonce)：可能会重传数据，有可能出现数据被重复处理的情况;

最多1次(atleastonce)：可能会出现数据丢失情况;

恰好1次(Exactlyonce)：并不是指真正只传输1次，只不过有一个机制。确保不会出现“数据被重复处理”和“数据丢失”的情况。

操作系统本身有一层缓存，叫做pagecache，是在内存里的缓存，我们也可以称之为oscache，意思就是操作系统自己管理的缓存。

每新写一条消息，kafka就是在对应的文件append写，所以性能非常高。

https://mp.weixin.qq.com/s/sCRC5h0uw2DWD2MixI6pZw

我觉得的靠的是这两个参数

这篇主要从生产和消费的角度详细给出的过程

https://www.cnblogs.com/cyfonly/p/5954614.html

零基础学Python需要从哪里开始分享Python学习路线：第一阶段：Python基础与Linux数据库这是Python的入门阶段，也是帮助零基础学员打好基础的重要阶段。你需要掌握Python基本语法规则及变量、逻辑控制、内置数据结构、文件操作、高级函数、模块、常用标准库模板、函数、异常处理、mysql使用、协程等知识点。

学习目标：掌握Python的基本语法，具备基础的编程能力；掌握Linux基本操作命令，掌握MySQL进阶内容，完成银行自动提款机系统实战、英汉词典、歌词解析器等项目。

第二阶段：web全栈这一部分主要学习web前端相关技术，你需要掌握html、cssJavaScript、JQuery、Bootstrap、web开发基础、Vue、FIaskViews、FIask模板、数据库操作、FIask配置等知识。

学习目标：掌握web前端技术内容，掌握web后端框架，熟练使用FIask、Tornado、Django，可以完成数据监控后台的项目。

第三阶段：数据分析+人工智能这部分主要是学习爬虫相关的知识点，你需要掌握数据抓取、数据提取、数据存储、爬虫并发、动态网页抓取、scrapy框架、分布式爬虫、爬虫攻防、数据结构、算法等知识。

学习目标：可以掌握爬虫、数据采集，数据机构与算法进阶和人工智能技术。可以完成爬虫攻防、图片马赛克、电影推荐系统、地震预测、人工智能项目等阶段项目。

第四阶段：高级进阶这是Python高级知识点，你需要学习项目开发流程、部署、高并发、性能调优、Go语言基础、区块链入门等内容。

学习目标：可以掌握自动化运维与区块链开发技术，可以完成自动化运维项目、区块链等项目。

按照上面的Python学习路线图学习完后，你基本上就可以成为一名合格的Python开发工程师。当然，想要快速成为企业竞聘的精英人才，你需要有好的老师指导，还要有较多的项目积累实战经验。

对于Python开发有兴趣的小伙伴们，不妨先从看看Python开发教程开始入门！B站搜索尚学堂官方号，Python教学视频，从基础到高级的都有，还挺不错的，知识点讲得很细致，还有完整版的学习路线图。也可以自己去看看，下载学习试试。关于本次rabbitmq官方中文文档和rabbitmq官方教程中文的问题分享到这里就结束了，如果解决了您的问题，我们非常高兴。

股市何时是底

支付宝买基金低风险

指数基金c与a的区别