我们知道RabbitMQ可以配置成Queue做主从复制（按照官方的说法叫配置mirror queue），对master queue的写操作会被复制到其他slave上去（也就是复制到mirror queue上去）。这对rabbitmq的这个特性，有些人会问这样的问题，rabbitmq的主从复制是同步的还是异步的？
为什么有些人会问这个问题那？主要这些人往往是将rabbitmq这个主从复制过程和mysql的主从复制做类比。我们知道mysql主从同步是支持同步、半同步、异步3种模式的。采用哪种模式，决定了mysql的数据可靠性。如果是异步方式主从同步，client发请求给主，当主将数据写入后，从就复制主上的这条的数据，与此同时，主就会告知客户端数据保存成功，但是这时从可能还没有成功的存储这条数据。如果这时主挂掉了，我们进行主从切换就会丢数据。在要求保证数据可靠性的场景下，我们不能采用异步模式，我们需要采用同步模式或者半同步模式，这里我们就不再展开同步模式和半同步模式了。这些人将mysql的分析方式放到了rabbitmq，用同样的方式分析rabbitmq的数据可靠性，所以就提出了这样的问题。
实际上，rabbitmq的主从复制是异步的，但是rabbitmq并不存在mysql这种场景的丢数据（这句话不是说rabbitmq保证不丢数据）。在这里，我们来分析一下RabbitMQ的副本复制的过程。
首先，我们来说一下mysql和rabbitmq的使用接口是不同的，这时很关键的一点。mysql是同步的接口，也就是说client将sql发给server，server处理sql后将结果返回给client，在server返回client结果前，client不能发起下一个sql的请求。对于rabbitmq来说，访问接口是异步的。client（我们这里说的是publisher）向rabbitmq server publish一条消息，在默认的情况下server是不返回成功还是失败的，也就是说client在不到成功还是失败的情况下就可以发起下一个请求。如果client关心server是否成功处理完这条消息，可以开启confirm模式，server会异步的返回ack通知client消息投递成功还是失败。但是client仍然不必等待收到当前消息的ack就可以继续发下一条。
接下来，我们来说rabbitmq的主从复制过程。实际上，RabbitMQ主从之间的数据复制是异步的，但是在rabbitmq中不会出现mysql那种丢数据的情况，这是因为rabbitmq的接口也是异步的，主收到一条消息写入本地存储，然后在发起写入从的请求。当所有从写入成功后，主才会给client返回ack说这次写入成功了。所以可以看出，虽然rabbitmq的主从复制是异步的，但是并且不会出现mysql丢数据的场景。只要客户端收到ack，就说明这条消息已经写入主和从了。
所以需要强调的一点是，同步和异步并非是决定数据可靠性的关键点。客户端收到成功通知时，所有副本是否写入成功才是判断数据可靠的关键点。因为mysql的接口是同步，所以才需要在主从复制同步还是异步上做出选择。rabbitmq的接口本身就是异步的接口，所以rabbitmq的主从复制就自然而然的是异步的方式。